{"id":19701,"date":"2023-07-19T12:28:14","date_gmt":"2023-07-19T12:28:14","guid":{"rendered":"https:\/\/devologyx.io\/clean-code-a-handbook-of-agile-craftsmanship-en-anglais\/"},"modified":"2024-10-31T17:46:28","modified_gmt":"2024-10-31T17:46:28","slug":"clean-code-a-handbook-of-agile-craftsmanship-en-anglais","status":"publish","type":"post","link":"https:\/\/devologyx.io\/fr\/clean-code-a-handbook-of-agile-craftsmanship-en-anglais\/","title":{"rendered":"CLEAN CODE – A HANDBOOK OF AGILE CRAFTSMANSHIP (EN ANGLAIS)"},"content":{"rendered":"\n
\"\"<\/figure>\n\n

Un mauvais code peut fonctionner. Mais s’il n’est pas propre, il peut mettre une soci\u00e9t\u00e9 de d\u00e9veloppement de logiciels \u00e0 genoux. Dans le monde entier, des ressources exceptionnelles sont perdues \u00e0 cause d’un code mal con\u00e7u. Mais ce n’est pas une fatalit\u00e9. En ao\u00fbt 2008, le c\u00e9l\u00e8bre expert en logiciels Robert C Martin a pr\u00e9sent\u00e9 un livre complet intitul\u00e9 Clean Code. Ce livre vous inculque les valeurs fondamentales d’un artisan du logiciel et des approches pour concevoir un code propre et faire de vous un meilleur programmeur. <\/p>\n\n

COMMENT CE LIVRE NOUS A-T-IL AID\u00c9S ?<\/strong><\/p>\n\n

Ce livre nous a aid\u00e9s \u00e0 comprendre que devenir de meilleurs artisans du logiciel et \u00e9crire un code propre est ce que nous devons faire pour nous consid\u00e9rer comme des professionnels. Le code propre nous \u00e9claire sur les tests unitaires, le formatage, le d\u00e9bogage et l’utilisation de noms descriptifs, qui nous aident \u00e0 \u00e9crire un code plus propre et plus robuste pour nos clients. L’\u00e9criture d’un code propre est une question d’habitude personnelle et de comp\u00e9tence. Au fil du temps, vous devrez acqu\u00e9rir de l’exp\u00e9rience et des connaissances pour \u00e9crire du code propre. <\/p>\n\n

LE LIVRE EXPLIQU\u00c9 EN MOINS DE 60 SECONDES<\/strong><\/p>\n\n

L’auteur met l’accent sur les fonctions : elles doivent \u00eatre petites, effectuer une seule t\u00e2che et avoir des noms descriptifs. Il affirme que si une fonction n\u00e9cessite de nombreux arguments de configuration, il faut envisager de les int\u00e9grer dans une seule variable d’options de configuration. <\/p>\n\n

Le livre insiste sur le fait que les d\u00e9veloppeurs doivent s’en tenir au principe de la responsabilit\u00e9 unique, qui stipule qu’une classe ou un module ne doit avoir qu’une seule raison de changer. Ce principe nous a donn\u00e9 une d\u00e9finition de la responsabilit\u00e9 et des lignes directrices pour la taille des classes. Les classes doivent avoir une seule responsabilit\u00e9 et une seule raison de changer. <\/p>\n\n

TROIS CITATIONS PRINCIPALES<\/strong><\/p>\n\n

\u00ab\u00a0Un code sans tests n’est pas propre. Quelle que soit son \u00e9l\u00e9gance, sa lisibilit\u00e9 et son accessibilit\u00e9, il est impur s’il n’est pas test\u00e9\u00a0\u00bb.<\/p>\n\n

\u00ab\u00a0Chaque syst\u00e8me est construit \u00e0 partir d’un langage sp\u00e9cifique \u00e0 un domaine, con\u00e7u par les programmeurs pour d\u00e9crire ce syst\u00e8me. Les fonctions sont les verbes de ce langage et les classes sont les noms.<\/p>\n\n

\u00ab\u00a0La gestion des erreurs est importante, mais si elle obscurcit la logique, elle est erron\u00e9e.<\/p>\n\n

\"\"<\/figure>\n\n

R\u00c9SUM\u00c9S ET NOTES DE LECTURE<\/strong><\/p>\n\n

Premier chapitre : Un code propre<\/strong><\/p>\n\n

La propret\u00e9 du code est importante : un code erron\u00e9 finira par entra\u00eener l’effondrement d’une entreprise car, au fur et \u00e0 mesure du d\u00e9veloppement, la productivit\u00e9 se rapproche progressivement de z\u00e9ro.<\/p>\n\n

Le co\u00fbt total du d\u00e9sordre augmente avec le temps. Plus le code devient d\u00e9sordonn\u00e9, moins il y a de chances de le nettoyer. La productivit\u00e9 de l’\u00e9quipe diminue au fur et \u00e0 mesure que le d\u00e9sordre s’accro\u00eet parce qu’elle est sous pression pour respecter un d\u00e9lai ou qu’elle veut augmenter sa productivit\u00e9. <\/p>\n\n

Il faut du temps et des ressources pour reconstruire un syst\u00e8me \u00e0 partir de z\u00e9ro. Le remaniement et les am\u00e9liorations progressives sont g\u00e9n\u00e9ralement les meilleures options \u00e0 prendre. Garder votre code propre est rentable et c’est une question de survie professionnelle. <\/p>\n\n

Vous passeriez des mois \u00e0 essayer d’accomplir une t\u00e2che qui n’aurait pris que quelques heures dans un code d\u00e9sordonn\u00e9. Un bon code pourrit rapidement un mauvais code parce que les changements d’exigences dans les approches contrecarrent la conception d’origine. <\/p>\n\n

Un code propre est bien test\u00e9 et ex\u00e9cute efficacement une seule t\u00e2che, alors qu’un code m\u00e9diocre en fait g\u00e9n\u00e9ralement trop par n\u00e9gligence.<\/p>\n\n

Les codes d\u00e9sordonn\u00e9s ralentissent les d\u00e9veloppeurs, mais tous se sentent oblig\u00e9s de faire du d\u00e9sordre pour respecter les d\u00e9lais. En g\u00e9n\u00e9ral, vous ne respecterez pas le d\u00e9lai en faisant du d\u00e9sordre. La seule fa\u00e7on de respecter le d\u00e9lai est de maintenir un code propre. <\/p>\n\n

Citation pr\u00e9f\u00e9r\u00e9e du chapitre : \u00ab\u00a0\u00c9crire du code propre est ce que vous devez faire pour vous consid\u00e9rer comme un professionnel. Il n’y a pas d’excuse raisonnable pour ne pas faire de son mieux.\u00a0\u00bb<\/em><\/strong><\/p>\n\n

Chapitre deux : Noms significatifs<\/strong><\/p>\n\n

Il n’est pas n\u00e9cessaire de pr\u00e9ciser que les noms doivent divulguer leur raison d’\u00eatre. La s\u00e9lection de bons noms prend du temps mais permet d’en gagner plus qu’il n’en faut. Prenez soin des noms que vous avez choisis et changez-les lorsque vous en trouvez de meilleurs. <\/p>\n\n

Le choix d’un bon nom est complexe, et le nom d’une fonction ou d’une variable doit expliquer ce qu’elle est, comment elle est utilis\u00e9e et pourquoi elle existe. Si un nom appelle un commentaire, il ne r\u00e9v\u00e8le pas son intention. <\/p>\n\n

Vous devez \u00e9viter de laisser de faux indices qui cachent le sens du code. \u00c9vitez les mots dont le sens \u00e9tabli diff\u00e8re du sens que vous souhaitez donner. <\/p>\n\n

\u00c9vitez d’utiliser des abr\u00e9viations dans les noms de fonctions et les noms de variables \u00e0 un seul caract\u00e8re, \u00e0 l’exception des noms couramment utilis\u00e9s tels que \u00ab\u00a0i\u00a0\u00bb pour la variable compteur dans une boucle.<\/p>\n\n

Les variables doivent \u00eatre pronon\u00e7ables afin que vous puissiez en parler et les dire \u00e0 haute voix. Vous ne pouvez en discuter avec vos co\u00e9quipiers que si vous pouvez les prononcer. <\/p>\n\n

Les noms \u00e0 une lettre et les constantes num\u00e9riques posent un probl\u00e8me sp\u00e9cifique. Il faut du temps pour les localiser dans un corps de texte. Les noms \u00e0 une lettre ne peuvent \u00eatre utilis\u00e9s comme variables locales qu’\u00e0 l’int\u00e9rieur de m\u00e9thodes courtes. <\/p>\n\n

Citation pr\u00e9f\u00e9r\u00e9e du chapitre : \u00ab\u00a0Un long nom descriptif vaut mieux qu’un long commentaire descriptif\u00a0\u00bb.<\/em><\/strong><\/p>\n\n

Chapitre trois : Les fonctions<\/strong><\/p>\n\n

La premi\u00e8re r\u00e8gle des fonctions est qu’elles doivent \u00eatre mineures et la seconde qu’elles ne doivent ex\u00e9cuter qu’une seule t\u00e2che. Les fonctions doivent \u00eatre insignifiantes au point de contenir des structures imbriqu\u00e9es. Par cons\u00e9quent, le niveau d’indentation d’une fonction ne doit pas \u00eatre sup\u00e9rieur \u00e0 un ou deux. Les fonctions sont ainsi plus faciles \u00e0 lire et \u00e0 comprendre. <\/p>\n\n

Les fonctions devraient avoir le moins de param\u00e8tres possible. Les param\u00e8tres ont tendance \u00e0 rendre les fonctions difficiles \u00e0 comprendre et se situent \u00e0 un niveau d’abstraction inf\u00e9rieur. \u00c9vitez autant que possible d’utiliser des param\u00e8tres en introduisant des classes d’aide abstraites ou en transformant les arguments en variables membres. <\/p>\n\n

Pour vous assurer que vos fonctions ex\u00e9cutent une seule t\u00e2che, vous devez veiller \u00e0 ce que les instructions qu’elles contiennent se situent toutes au m\u00eame niveau d’abstraction.<\/p>\n\n

Utilisez des noms significatifs pour d\u00e9signer vos fonctions. Les noms descriptifs expliquent ce que fait une fonction. Plus une fonction est petite et cibl\u00e9e, plus il est facile de choisir un nom descriptif. <\/p>\n\n

Citation pr\u00e9f\u00e9r\u00e9e du chapitre : \u00ab\u00a0Vous savez que vous travaillez sur un code propre lorsque chaque routine s’av\u00e8re \u00eatre \u00e0 peu pr\u00e8s ce \u00e0 quoi vous vous attendiez.\u00a0\u00bb<\/em><\/strong><\/p>\n\n

Chapitre quatre : Commentaires<\/strong><\/p>\n\n

\"\"<\/figure>\n\n

L’utilisation des commentaires compense votre incapacit\u00e9 \u00e0 vous exprimer en code. Les commentaires sont des \u00e9checs constants. Vous devez les avoir parce que vous n’arrivez que parfois \u00e0 vous d\u00e9crire sans eux. <\/p>\n\n

Un code propre et expressif avec peu de commentaires est bien meilleur qu’un code encombr\u00e9 et complexe avec de nombreux commentaires. Par cons\u00e9quent, passez du temps \u00e0 nettoyer le d\u00e9sordre de votre code plut\u00f4t qu’\u00e0 r\u00e9diger des commentaires qui expliquent votre d\u00e9sordre. <\/p>\n\n

La plupart des commentaires sont des b\u00e9quilles et des justifications pour un code m\u00e9diocre. Les commentaires peuvent \u00eatre \u00e9vit\u00e9s en utilisant des variables nomm\u00e9es distinctement et en extrayant des sections de code dans des fonctions clairement nomm\u00e9es. <\/p>\n\n

N’utilisez pas les Javadocs juste pour le plaisir de les utiliser. Les commentaires qui expliquent ce que fait une m\u00e9thode, les arguments qu’elle prend et ce qu’elle renvoie sont g\u00e9n\u00e9ralement au mieux redondants et au pire trompeurs. <\/p>\n\n

Les commentaires doivent contenir toutes les informations applicables et le contexte dont les personnes qui les lisent auront besoin. Ne soyez pas paresseux dans la r\u00e9daction de vos commentaires. <\/p>\n\n

Citation pr\u00e9f\u00e9r\u00e9e du chapitre : \u00ab\u00a0Ne commentez pas un mauvais code, r\u00e9\u00e9crivez-le\u00a0\u00bb.<\/em><\/strong><\/p>\n\n

Chapitre 5 : Mise en forme<\/strong><\/p>\n\n

Veillez \u00e0 ce que votre code soit format\u00e9 de mani\u00e8re attrayante. S\u00e9lectionnez un ensemble sp\u00e9cifique de r\u00e8gles g\u00e9rables qui contr\u00f4lent le format de votre code. Ensuite, appliquez syst\u00e9matiquement ces r\u00e8gles \u00e0 votre code. Il est pr\u00e9f\u00e9rable de disposer d’un outil pour mettre en \u0153uvre ces r\u00e8gles de formatage. <\/p>\n\n

Le formatage des codes est essentiel. Elle est trop cruciale pour \u00eatre ignor\u00e9e. Ne comptez pas sur les humains pour d\u00e9tecter et corriger manuellement chaque erreur de formatage. Utilisez plut\u00f4t un formateur de code automatis\u00e9 et un linter de code. Cette m\u00e9thode est efficace et productive et permet de gagner du temps lors des revues de code. <\/p>\n\n

Les fichiers sources doivent ressembler \u00e0 un article de journal. Le nom doit \u00eatre simple mais explicite. Le nom doit permettre de savoir si vous vous trouvez dans un module appropri\u00e9. Les parties les plus \u00e9lev\u00e9es de votre fichier source doivent pr\u00e9senter des concepts et des algorithmes de haut niveau. Ensuite, les d\u00e9tails doivent augmenter au fur et \u00e0 mesure que vous descendez. <\/p>\n\n

Les variables doivent \u00eatre d\u00e9clar\u00e9es \u00e0 proximit\u00e9 de l’endroit o\u00f9 elles sont utilis\u00e9es. Pour les petites fonctions, il s’agit g\u00e9n\u00e9ralement du d\u00e9but de la fonction. M\u00eame pour les fonctions courtes, mettez-les bien en forme au lieu de les \u00e9crire sur une seule ligne. <\/p>\n\n

Citation pr\u00e9f\u00e9r\u00e9e du chapitre : \u00ab\u00a0Le formatage des codes est important. Il est trop important pour \u00eatre ignor\u00e9, et il est trop important pour \u00eatre trait\u00e9 religieusement. La mise en forme du code est une question de communication, et la communication est la premi\u00e8re t\u00e2che du d\u00e9veloppeur professionnel.\u00a0\u00bb<\/em><\/strong><\/p>\n\n

Chapitre six : Objets et structures de donn\u00e9es<\/strong><\/p>\n\n

Vous gardez vos variables priv\u00e9es parce que vous ne voulez pas que quelqu’un d’autre en d\u00e9pende. Vous voulez conserver la libert\u00e9 de modifier leur type ou leur impl\u00e9mentation de mani\u00e8re impulsive. De nombreux d\u00e9veloppeurs ajoutent automatiquement des getters et setters \u00e0 leurs objets, r\u00e9v\u00e9lant ainsi leurs variables priv\u00e9es comme si elles \u00e9taient publiques. <\/p>\n\n

N’ajoutez pas de getters et de setters par d\u00e9faut, mais fournissez plut\u00f4t une interface abstraite pour les donn\u00e9es afin que vous puissiez ajuster l’impl\u00e9mentation sans penser aux clients.<\/p>\n\n

Les objets placent leurs donn\u00e9es derri\u00e8re des abstractions et r\u00e9v\u00e8lent les fonctions qui travaillent sur ces donn\u00e9es \u00e0 l’abri des regards. Les structures de donn\u00e9es exposent leurs donn\u00e9es et n’ont pas de fonctions significatives. <\/p>\n\n

La loi de Demeter stipule qu’un module ne doit pas conna\u00eetre les entrailles de l’objet qu’il manipule. Cela signifie qu’un objet ne doit pas r\u00e9v\u00e9ler sa structure interne par le biais d’accesseurs, car cela revient \u00e0 exposer, au lieu de cacher, sa structure interne. Comme les objets cachent les donn\u00e9es et exposent le comportement, il est facile d’ajouter de nouveaux objets sans modifier les comportements actuels. Les structures de donn\u00e9es r\u00e9v\u00e8lent les donn\u00e9es et n’ont pas de comportement inhabituel, ce qui facilite l’ajout de nouveaux comportements aux structures de donn\u00e9es existantes. <\/p>\n\n

Citation pr\u00e9f\u00e9r\u00e9e du chapitre : \u00ab\u00a0Dans un syst\u00e8me donn\u00e9, nous voudrons parfois avoir la flexibilit\u00e9 d’ajouter de nouveaux types de donn\u00e9es, et nous pr\u00e9f\u00e9rerons donc les objets pour cette partie du syst\u00e8me. D’autres fois, nous voudrons avoir la possibilit\u00e9 d’ajouter de nouveaux comportements. Nous pr\u00e9f\u00e9rons alors les types de donn\u00e9es et les proc\u00e9dures dans cette partie du syst\u00e8me.\u00a0\u00bb<\/em><\/strong><\/p>\n\n

Chapitre sept : Gestion des erreurs<\/strong><\/p>\n\n

La gestion des erreurs est essentielle, et il y en a g\u00e9n\u00e9ralement beaucoup au cours de la programmation. Cependant, elle ne doit pas masquer l’intention principale du code. Par cons\u00e9quent, utilisez des attentes plut\u00f4t que des codes de retour. <\/p>\n\n

Les exceptions doivent \u00eatre informatives et fournir des informations objectives, contextuelles et d\u00e9taill\u00e9es sur le type d’erreur \u00e0 une personne qui re\u00e7oit le message d’erreur et qui a besoin d’un d\u00e9pannage efficace.<\/p>\n\n

Les exceptions d\u00e9finissent la port\u00e9e de votre programme. Lorsque vous impl\u00e9mentez du code dans la partie try d’une instruction try-catch-finally, vous indiquez que l’ex\u00e9cution peut s’arr\u00eater \u00e0 n’importe quel point et red\u00e9marrer au niveau du catch. <\/p>\n\n

Lorsque vous enveloppez les API de tiers dans une fine couche d’abstraction, il devient plus facile d’\u00e9changer une biblioth\u00e8que contre une autre \u00e0 l’avenir et de simuler la biblioth\u00e8que pendant les tests.<\/p>\n\n

Citation pr\u00e9f\u00e9r\u00e9e du chapitre : \u00ab\u00a0Un code propre est lisible, mais il doit aussi \u00eatre robuste. Ces objectifs ne sont pas contradictoires. Nous pouvons \u00e9crire un code propre et robuste si nous consid\u00e9rons la gestion des erreurs comme une pr\u00e9occupation particuli\u00e8re.\u00a0\u00bb<\/em><\/strong><\/p>\n\n

Chapitre huit : Limites<\/strong><\/p>\n\n

\"\"<\/figure>\n\n

Le code tiers vous aidera \u00e0 obtenir plus de fonctionnalit\u00e9s en moins de temps. Ce n’est pas \u00e0 vous de tester le code tiers, mais vous devriez avoir int\u00e9r\u00eat \u00e0 \u00e9crire des tests pour le code tiers que vous utilisez. <\/p>\n\n

Les tests d’apprentissage sont des exp\u00e9riences pr\u00e9cises qui permettent d’am\u00e9liorer votre compr\u00e9hension. Les tests d’apprentissage confirment que les paquets tiers que vous utilisez fonctionnent comme vous l’avez pr\u00e9vu. Il n’y a aucune garantie que le code tiers restera compatible avec vos besoins lorsqu’il sera combin\u00e9. <\/p>\n\n

Les bons logiciels s’adaptent aux changements sans n\u00e9cessiter d’investissements importants ni de remaniements. Lorsque vous utilisez un code sur lequel vous n’avez aucun contr\u00f4le, des pr\u00e9cautions exceptionnelles doivent \u00eatre prises pour prot\u00e9ger votre investissement et faire en sorte que les changements futurs soient g\u00e9rables. <\/p>\n\n

Les limites des tiers sont g\u00e9r\u00e9es par quelques endroits du code qui y font r\u00e9f\u00e9rence.<\/p>\n\n

\u00c9vitez de laisser une trop grande partie de votre code conna\u00eetre les particularit\u00e9s de la tierce partie. Il est pr\u00e9f\u00e9rable de s’appuyer sur quelque chose que vous pouvez contr\u00f4ler plut\u00f4t que sur quelque chose que vous ne pouvez pas contr\u00f4ler. <\/p>\n\n

Citation pr\u00e9f\u00e9r\u00e9e du chapitre : \u00ab\u00a0Nous devrions \u00e9viter de laisser une trop grande partie de notre code conna\u00eetre les particularit\u00e9s des tiers. Il vaut mieux d\u00e9pendre de quelque chose que vous contr\u00f4lez que de quelque chose que vous ne contr\u00f4lez pas, de peur qu’il ne vous contr\u00f4le.\u00a0\u00bb<\/em><\/strong><\/p>\n\n

Chapitre neuf : Tests d’unit\u00e9<\/strong><\/p>\n\n

Le d\u00e9veloppement pilot\u00e9 par les tests exige que vous \u00e9criviez des tests unitaires avant d’\u00e9crire le code de production. Vous ne pouvez pas \u00e9crire le code de production tant que vous n’avez pas \u00e9crit un test unitaire qui \u00e9choue. Le code de test doit \u00eatre aussi propre que le code de production, \u00e0 quelques exceptions pr\u00e8s, g\u00e9n\u00e9ralement li\u00e9es \u00e0 la m\u00e9moire ou \u00e0 l’efficacit\u00e9. <\/p>\n\n

Veillez \u00e0 ce que vos tests soient propres ou moins, vous les perdrez. Et en leur absence, vous perdez la seule chose qui permet \u00e0 votre code d’\u00eatre r\u00e9utilisable, flexible et maintenable. Vous ne craindrez pas de modifier votre code en pr\u00e9sence de tests, mais sans eux, chaque modification est un bogue r\u00e9alisable. <\/p>\n\n

La lisibilit\u00e9 est ce qui rend un test propre. La lisibilit\u00e9 est peut-\u00eatre encore plus essentielle dans les tests unitaires que dans le code de production. La clart\u00e9, la simplicit\u00e9 et la densit\u00e9 d’expression sont ce qui rend les tests lisibles. Dans un test, vous devez dire beaucoup de choses avec le moins d’expressions possible. <\/p>\n\n

En g\u00e9n\u00e9ral, vous souhaitez tester un seul concept dans chaque fonction de test. Vous ne voulez pas de fonctions de test \u00e9tendues qui testent une chose diversifi\u00e9e apr\u00e8s l’autre. <\/p>\n\n

Tout comme le code de production, les tests sont \u00e9galement essentiels \u00e0 la robustesse du projet. Les tests sont n\u00e9cessaires parce qu’ils am\u00e9liorent et pr\u00e9servent la r\u00e9utilisation, la maintenabilit\u00e9 et la flexibilit\u00e9 du code. Veillez \u00e0 ce que vos tests soient propres et faites en sorte qu’ils soient significatifs et brefs. D\u00e9veloppez des API qui agissent comme un langage sp\u00e9cifique au domaine qui vous aide \u00e0 \u00e9crire des tests. <\/p>\n\n

Citation pr\u00e9f\u00e9r\u00e9e du chapitre : \u00ab\u00a0Les tests doivent \u00eatre \u00e9crits en temps voulu. Les tests unitaires doivent \u00eatre \u00e9crits juste avant le code de production qui les fait passer.\u00a0\u00bb<\/em><\/strong><\/p>\n\n

Chapitre dix : Les classes<\/strong><\/p>\n\n

Les classes doivent commencer par une liste de variables. Les constantes statiques publiques doivent venir en premier, puis les variables statiques priv\u00e9es, suivies des variables d’instance priv\u00e9es. Les utilitaires priv\u00e9s appel\u00e9s par une fonction publique doivent \u00eatre plac\u00e9s juste apr\u00e8s. <\/p>\n\n

La premi\u00e8re r\u00e8gle des classes est qu’elles doivent \u00eatre petites. Tout comme les fonctions, la petite taille est la r\u00e8gle principale pour cr\u00e9er des classes. Mais la vraie question est toujours : \u00ab\u00a0quelle taille ?\u00a0\u00bb. Avec les fonctions, vous calculez la taille en comptant les lignes physiques. Avec les classes, vous mesurez la taille en comptant les responsabilit\u00e9s. <\/p>\n\n

Les classes doivent avoir un petit nombre de variables d’instance. Chaque m\u00e9thode d’une classe doit contr\u00f4ler une ou plusieurs de ces variables. Plus une m\u00e9thode influence de variables, plus elle est coh\u00e9rente avec sa classe. <\/p>\n\n

Utilisez de nombreuses petites classes plut\u00f4t que quelques grandes classes dans votre application. Cela minimise la quantit\u00e9 d’informations qu’un coll\u00e8gue d\u00e9veloppeur devra comprendre lorsqu’il travaillera sur une t\u00e2che donn\u00e9e. <\/p>\n\n

Citation pr\u00e9f\u00e9r\u00e9e du chapitre : \u00ab\u00a0Une classe ou un module doit avoir une, et une seule, raison de changer.\u00a0\u00bb<\/em><\/strong><\/p>\n\n

COMMENT CE LIVRE PEUT-IL AIDER LES D\u00c9VELOPPEURS DE LOGICIELS ?<\/strong><\/p>\n\n

\u00ab\u00a0Clean Code\u00a0\u00bb de Robert C. Martin peut aider les d\u00e9veloppeurs de logiciels \u00e0 am\u00e9liorer la qualit\u00e9 de leur code. Il fournit des conseils pratiques et des lignes directrices sur la mani\u00e8re d’\u00e9crire un code lisible, facile \u00e0 maintenir et efficace. Le livre couvre les th\u00e8mes du nommage, des commentaires, du formatage et des tests et souligne l’importance de la simplicit\u00e9, de la clart\u00e9 et de la coh\u00e9rence dans les pratiques de codage. En suivant les principes d\u00e9crits dans le livre, les d\u00e9veloppeurs peuvent r\u00e9duire la dette technique, augmenter la productivit\u00e9 et cr\u00e9er des logiciels plus faciles \u00e0 comprendre, \u00e0 modifier et \u00e0 \u00e9tendre. Il fournit aux d\u00e9veloppeurs de logiciels une approche compl\u00e8te du codage qui peut les aider \u00e0 am\u00e9liorer leurs comp\u00e9tences et \u00e0 r\u00e9duire le co\u00fbt de la maintenance. Ce livre aide les programmeurs \u00e0 \u00e9crire un code facile \u00e0 modifier et \u00e0 remanier \u00e0 l’avenir. Il s’agit d’un ouvrage incontournable pour tout d\u00e9veloppeur de logiciels qui souhaite devenir un meilleur programmeur. <\/p>\n","protected":false},"excerpt":{"rendered":"

Un mauvais code peut fonctionner. Mais s’il n’est pas propre, il peut mettre une soci\u00e9t\u00e9 de d\u00e9veloppement de logiciels \u00e0 genoux. Dans le monde entier, des ressources exceptionnelles sont perdues \u00e0 cause d’un code mal con\u00e7u. Mais ce n’est pas une fatalit\u00e9. En ao\u00fbt 2008, le c\u00e9l\u00e8bre expert en logiciels Robert C Martin a pr\u00e9sent\u00e9 […]<\/p>\n","protected":false},"author":1,"featured_media":17640,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_themeisle_gutenberg_block_has_review":false,"_jet_sm_ready_style":"","_jet_sm_style":"","_jet_sm_controls_values":"","_jet_sm_fonts_collection":"","_jet_sm_fonts_links":"","footnotes":""},"categories":[102],"tags":[],"writer":[],"class_list":["post-19701","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-club-de-lecture"],"_links":{"self":[{"href":"https:\/\/devologyx.io\/fr\/wp-json\/wp\/v2\/posts\/19701","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/devologyx.io\/fr\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/devologyx.io\/fr\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/devologyx.io\/fr\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/devologyx.io\/fr\/wp-json\/wp\/v2\/comments?post=19701"}],"version-history":[{"count":1,"href":"https:\/\/devologyx.io\/fr\/wp-json\/wp\/v2\/posts\/19701\/revisions"}],"predecessor-version":[{"id":19703,"href":"https:\/\/devologyx.io\/fr\/wp-json\/wp\/v2\/posts\/19701\/revisions\/19703"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/devologyx.io\/fr\/wp-json\/wp\/v2\/media\/17640"}],"wp:attachment":[{"href":"https:\/\/devologyx.io\/fr\/wp-json\/wp\/v2\/media?parent=19701"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/devologyx.io\/fr\/wp-json\/wp\/v2\/categories?post=19701"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/devologyx.io\/fr\/wp-json\/wp\/v2\/tags?post=19701"},{"taxonomy":"writer","embeddable":true,"href":"https:\/\/devologyx.io\/fr\/wp-json\/wp\/v2\/writer?post=19701"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}