Catégorie : Livres

Dans le livre Les 97 choses qu’un développeur devrait savoir, Mike Lewis a écrit un article traitant de la factorisation du code, ou la manière de mieux agencer le code pour une meilleure maintenabilité.

Voici cette article :

Tout le monde ayant une expérience dans l’industrie a sans aucun doute travaillé sur un projet où la base de code était précaire au mieux. Le système est mal factorisé, et changer une chose aura toujours pour effet de casser une autre caractéristique non liée. Chaque fois qu’un module est ajouté, l’objectif du codeur est de changer aussi peu que possible et de retenir son souffle pendant chaque sortie. C’est l’équivalent du logiciel de Jenga avec I-beams dans un gratte-ciel, et est destiné à un désastre.

La raison pour laquelle les changements sont tellement énervant est parce que le système est malade. Il a besoin d’un médecin, sinon sa condition ne fera que s’aggraver. Vous savez déjà ce qui ne va pas avec votre système, mais vous avez peur de briser les œufs pour faire votre omelette. Un chirurgien qualifié sait que des coupes doivent être faites pour fonctionner, mais elle sait aussi que les coupes sont temporaires et guérissent. Le résultat final de l’opération vaut la peine initiale, et le patient doit guérir à un meilleur état qu’il ne l’était avant la chirurgie.

N’ayez pas peur de votre code. Qui se soucie si quelque chose se brise temporairement pendant que vous déplacez les choses? Une peur paralysante du changement est ce que votre projet a commencé dans cet état. Investir du temps de refactoring plusieurs fois sur le cycle de vie de votre projet, paiera sur le long terme. Un avantage supplémentaire est que l’expérience, de votre équipe traitant du système malade, vous fera tous des experts, sur le comment du fonctionnement. Appliquer cette connaissance plutôt que de la repousser. Travailler sur un système que vous détestez n’est pas une bonne méthode à avoir pour passer son temps.

Redéfinir les interfaces internes, restructurer les modules, factoriser le code copié et simplifier votre conception en réduisant les dépendances. Vous pouvez réduire de manière significative la complexité du code en éliminant les cas d’angle, qui résultent souvent de caractéristiques couplées incorrectement. Transformez lentement l’ancienne structure en une nouvelle, en testant tout le long du chemin. Essayer d’accomplir une grande refactorisation dans «un grand boum» causera des problèmes suffisants pour que vous envisagiez d’abandonner tout l’effort à mi-parcours.

Soyez le chirurgien qui n’a pas peur de couper les parties malades pour amorcer la guérison. L’attitude est contagieuse et inspirera les autres à commencer à travailler sur les projets de nettoyage qu’ils ont abandonnés. Gardez une liste d’amélioration des tâches que l’équipe juge valables pour le bien général du projet. Convaincre la direction que, bien que ces tâches ne produisent pas de résultats visibles, elles réduiront les dépenses et accéléreront les versions futures. N’arrêtez jamais de prendre soin de la «santé» générale du code.

Suite à l’article de la semaine dernière sur les commentaires, je met une deuxième couche, avec d’autres arguments sur ce sujet.
Cet article est toujours tiré du livre 97 choses que tout programmeur devrait savoir, et Kevlin Henney partage son avis la-dessus.

Voici son avis :

La différence entre la théorie et la pratique est plus grande dans la pratique que dans la théorie : une observation qui s’applique certainement aux commentaires. En théorie, l’idée générale de commenter le code ressemble à une valeur digne : offrir le détail du lecteur, une explication de ce qui se passe. Quel pourrait être plus utile que d’être utile ? Dans la pratique, cependant, les commentaires deviennent souvent un problème. Comme pour toute autre forme d’écriture, il existe une compétence pour rédiger de bons commentaires. Une grande partie de la compétence consiste à savoir quand ne pas les écrire.

Lorsque le code est mal formé, les compilateurs, les interprètes et d’autres outils seront sûrs de s’opposer. Si le code est en quelque sorte fonctionnellement incorrect, les examens, les analyses statiques, les tests et l’utilisation quotidienne dans un environnement de production éliminent la plupart des erreurs. Mais qu’en est-il des commentaires ? Dans The Elements of Programming Style (Computing McGraw-Hill), Kernighan et Plauger notent que « un commentaire est nul (ou négatif) s’il est faux. » Et pourtant, de tels commentaires souvent lèvent et survivent dans une base de code d’une manière qui les erreurs de codage ne l’ont jamais pu. Ils fournissent une source constante de distraction et de désinformation, une subtile mais constante traînée sur la pensée d’un programmeur.

Qu’en est-il des commentaires qui ne sont pas techniquement faux, mais n’ajoute aucune valeur au code ? De tels commentaires sont du bruit. Ces commentaires, tel un perroquet du code, n’offrent rien d’extra au lecteur: en précisant quelque chose une fois dans le code et à nouveau dans un langage naturel, il ne le rend plus vrai ou plus réel. Le code commenté n’est pas un code exécutable, donc il n’a aucun effet utile pour le lecteur ou l’exécution. Il devient également très rapide. Les commentaires liés à la version et le code commenté essaient de répondre aux questions de version et d’historique. Ces questions ont déjà été répondu (beaucoup plus efficacement) par des outils de contrôle de version.

Une prévalence de commentaires bruyants et de commentaires incorrects dans une base de code encourage les programmeurs à ignorer tous les commentaires, soit en les ignorant soit en prenant des mesures actives pour les cacher. Les programmeurs sont ingénieux et enlèveront tout ce qui est perçu comme un dommage : replier des commentaires; changer le colorier pour que les commentaires et l’arrière-plan soient de la même couleur; scripts pour filtrer les commentaires. Pour sauvegarder une base de code à partir de telles mauvaises applications de l’ingéniosité du programmateur, et pour réduire le risque de négliger tout commentaire de valeur authentique, les commentaires devraient être traités comme s’il s’agissait d’un code. Chaque commentaire devrait ajouter de la valeur pour le lecteur, sinon il s’agit de déchets qui devraient être supprimés ou réécrits.

Qu’est-ce qui se qualifie alors en valeur ? Les commentaires doivent expliquer les choses que le code ne fait pas, et ne dit pas. Un commentaire expliquant ce qu’un code devrait déjà dire est une invitation à modifier la structure du code ou les conventions de codage afin que le code parle de lui-même. Au lieu de compenser la mauvaise méthode ou les noms de classe, renommez-les. Au lieu de commenter les sections dans de longues fonctions, extraire des fonctions plus petites dont les noms capturent l’intention des premières sections. Essayez d’exprimer autant que possible par code. Tout manque à gagner entre ce que vous pouvez exprimer en code et ce que vous souhaitez exprimer au total devient un candidat plausible pour un commentaire utile. Commenter ce que le code ne peut pas dire, pas simplement ce qu’il ne dit pas.

Nouvel article que je tire du contenu du livre 97 choses que tout programmeur devrait savoir.

Cal Evans, qui a écrit l’article de base en anglais, y parle des commentaires.

Voici le contenu traduit de l’article :

Dans ma première classe de programmation au collège, mon professeur a remis deux fiches de codage BASIC. Au tableau, la mission était : « Écrivez un programme qui saisit 10 scores de bowling et en fait une moyenne. » Ensuite, le professeur a quitté la salle. Quelle difficulté pourrait-il être? Je ne me souviens pas de ma solution finale, mais je suis sûr qu’elle nécessitait une boucle FOR / NEXT et ne pouvait pas dépasser 15 lignes au total. Les feuilles de codage – pour vous, les enfants qui lisent ceci, oui, nous écrivions du code avant d’être autorisé à enregistrer, dans un ordinateur, environ 70 lignes de code chacun. J’étais très confus quant à savoir pourquoi l’enseignant nous aurait donné deux feuilles. Comme mon écriture a toujours été atroce, j’ai utilisé la seconde pour recopier mon code très soigneusement, en espérant obtenir quelques points supplémentaires pour le style.

À ma grande surprise, lorsque j’ai reçu la mission au début de la prochaine classe, j’ai reçu une note très moyenne. (Ce fut pour moi un souci pour le reste de mon temps au collège.) Le commentaire au dessus de mon code était «Pas de commentaires ?»

Il n’était pas suffisant que, le professeur et moi-même, savions ce que le programme devait faire. Une partie de la mission était de m’apprendre ceci : mon code devait être compréhensible au prochain programmeur venant après moi. C’est une leçon que je n’ai jamais oubliée.

Les commentaires ne sont pas mauvais. Ils sont nécessaires à la programmation autant pour les branchements de base que pour les constructions en boucle. La plupart des langues modernes ont un outil similaire à javadoc, qui analysera correctement les commentaires formatés pour créer automatiquement un document API. C’est un très bon début, mais pas assez. Dans votre code, vous devez expliquer ce que le code devrait faire. Coder selon le vieil adage: «S’il était difficile à écrire, il devrait être difficile à lire», déservira votre client, votre employeur, vos collègues et votre avenir.

D’autre part, vous pouvez aussi aller trop loin dans vos commentaires. Assurez-vous que vos commentaires expliquent votre code mais ne l’obscurcissent pas. Saupoudrez votre code de commentaires pertinents, expliquant ce que le code est censé accomplir. Vos commentaires d’en-tête devraient donner à tout programmeur suffisamment d’informations pour utiliser votre code sans avoir à le lire, alors que vos commentaires en ligne devraient aider le prochain développeur à le réparer ou à l’étendre.

Dans un même travail, je peux ne pas être d’accord avec une décision de conception prise par ceux qui me l’ont indiqué. Je me suis senti plutôt sarcastique, comme le sont souvent les jeunes programmeurs, j’ai copié-collé le texte, issu du courrier électronique de la personne qui m’a demandé d’utiliser leur conception, dans le bloc de commentaires d’en-tête du fichier. Il s’est avéré que les gestionnaires de ce magasin en particulier ont révisé le code lors de leur engagement. C’était ma première introduction au terme de changement de carrière.

Voici un deuxième article que je tire d’une traduction du livre 97 choses que tout programmeur devrait savoir.

Cet article, écrit par Mattias Karlsson, traitera du code review.

Voici cet article :

Vous devriez faire du Code Reviews. Pourquoi? Parce qu’ils augmentent la qualité et réduisent le taux de défauts. Mais pas nécessairement pour les raisons que vous pourriez penser.

Parce qu’ils avaient déjà eu de mauvaises expériences avec des critiques de code, de nombreux programmeurs ont tendance à ne pas les aimer. J’ai vu des organisations exigeant que tout le code passe un examen formel avant d’être déployé dans la production. Souvent, c’est l’architecte ou un développeur principal qui effectue cette revue, une pratique qui peut être décrite comme un examen complet de l’architecte. Ceci est indiqué dans le manuel de processus de développement de logiciels de l’entreprise, auquel tous les programmeurs doivent se conformer.

Il se peut que certaines organisations aient besoin d’un processus rigide et formel, mais la plupart ne le font pas. Dans la plupart des organisations, une telle approche est contre-productive. Les examinateurs peuvent avoir l’impression qu’ils sont jugés par une commission des libérations conditionnelles. Les examinateurs ont besoin à la fois du temps pour lire le code et le temps nécessaire pour se tenir au courant de tous les détails du système; ils peuvent rapidement devenir le goulet d’étranglement dans ce processus, et le processus peut dégénérer rapidement.

Au lieu de simplement corriger les erreurs dans le code, le but des Code Reviews devrait être de partager des connaissances et d’établir des lignes directrices communes sur le codage. Le partage de votre code avec d’autres programmeurs permet la propriété de code collectif. Laissez un membre aléatoire de l’équipe parcourir le code avec le reste de l’équipe. Au lieu de chercher des erreurs, vous devriez examiner le code en essayant de l’apprendre et de le comprendre.

Soyez doux lors des Code Reviews. Assurez-vous que les commentaires sont constructifs, pas caustiques. Introduire différents rôles pour la réunion d’évaluation afin d’éviter d’avoir une ancienneté organisationnelle parmi les membres de l’équipe affectant le Code Review. Des exemples de rôles pourraient inclure un focus sur la documentation, un autre sur les exceptions et un tiers pour examiner la fonctionnalité. Cette approche contribue à répartir le fardeau de la Review entre les membres de l’équipe.

Ayez une journée régulière de Code Reviews chaque semaine. Passez quelques heures dans une réunion de review. Faites pivoter la revue chaque réunion dans un pattern de round-robin. N’oubliez pas de changer également les rôles entre les membres de l’équipe. Impliquez des débutants dans des critiques de code. Ils peuvent être inexpérimentés, mais leur nouvelle connaissance universitaire peut donner une perspective différente. Inventez des experts pour leur expérience et leurs connaissances. Ils identifient le code sujet aux erreurs plus rapidement et avec plus de précision. Les code reviews vont plus facilement si l’équipe possède des conventions de codage vérifiées par des outils. De cette façon, le formatage du code ne sera jamais discuté lors de la réunion d’examen du code.

Faire des commentaires sur le code est peut-être le facteur le plus important pour le succès. Les commentaires portent sur la révision des personnes. Si la réunion d’examen est douloureuse ou ennuyeuse, il sera difficile de motiver quelqu’un. Faites-en une code review informel dont le but principal est de partager les connaissances entre les membres de l’équipe. Laissez les commentaires sarcastiques à l’extérieur et apportez un gâteau ou un déjeuner à café à la place.

Il y a quelque mois, j’ai écrit un article sur le livre 97 choses que tout programmeur devrait savoir. Livre anglais très intéressant sur des bonnes pratiques à avoir.

Aujourd’hui, j’ai décidé de vous traduire un des articles qui s’intitule Automate Your Coding Standard. Cela donne en français : Automatisez votre Norme de codage. L’article d’origine (en anglais) a été écrit par Filip van Laenen.

Voici cet article :

Vous avez probablement été là aussi. Au début d’un projet, tout le monde a beaucoup de bonnes intentions – appelé «résolutions du nouveau projet». Très souvent, ces résolutions sont consignées dans les documents. Ceux sur le code se retrouvent dans la norme de codage du projet. Au cours de la réunion de lancement, le développeur principal passe par le document et, dans le meilleur des cas, tout le monde s’engage à essayer de les suivre. Une fois que le projet est en cours, cependant, ces bonnes intentions sont abandonnées, une à la fois. Lorsque le projet est finalement livré, le code ressemble à un désordre, et personne ne semble savoir comment cela s’est avéré être ainsi.

A quel moment les choses ont mal tourné ? Probablement déjà lors de la réunion de lancement. Certains membres du projet n’ont pas fait attention. D’autres n’ont pas compris le point. Pire encore, certains étaient en désaccord et prévoyaient déjà leur rébellion standard de codage. Enfin, certains ont pris le point et ont convenu, mais lorsque la pression dans le projet était trop élevée, ils devaient laisser tomber quelque chose. Le code bien formaté ne gagne pas de points avec un client qui veut plus de fonctionnalités. En outre, après une norme de codage peut être une tâche ennuyeuse si elle n’est pas automatisée. Essayez simplement d’indenter une classe désordonnée à la main pour découvrir cela par vous-même.

Mais si c’est un tel problème, pourquoi est-ce que nous voulons une norme de codage en premier lieu ? L’une des raisons de formater le code d’une manière uniforme est que personne ne peut « posséder » un morceau de code simplement en le formant à sa manière privée. Nous pouvons vouloir empêcher les développeurs d’utiliser certains antipatterns afin d’éviter certains bogues communs. Au final, une norme de codage devrait faciliter le travail dans le projet et maintenir la vitesse de développement du début à la fin. Il s’ensuit, ensuite, que tout le monde devrait s’entendre sur la norme de codage aussi, cela ne contribue pas si un développeur utilise trois espaces pour indenter le code et un autre en utilise quatre.

Il existe une foule d’outils qui peuvent être utilisés pour produire des rapports de qualité de code et pour documenter et maintenir la norme de codage, mais ce n’est pas la solution complète. Il devrait être automatisé et appliqué dans la mesure du possible. Voici quelques exemples :

• Assurez-vous que le formatage du code fait partie du processus de construction, de sorte que tout le monde l’exécute automatiquement chaque fois qu’ils compilent le code.
• Utilisez des outils d’analyse de code statique pour numériser le code pour les antipatternes indésirables. Si vous le trouvez, brisez la construction.
• Apprenez à configurer ces outils afin que vous puissiez rechercher vos propres antipatterns spécifiques au projet.
• Ne mesurez pas seulement la couverture des tests, mais vérifiez également automatiquement les résultats. Encore une fois, brisez la construction si la couverture du test est trop faible.

Essayez de le faire pour tout ce que vous considérez comme important. Vous ne pourrez pas automatiser tout ce dont vous vous intéressez vraiment. En ce qui concerne les choses que vous ne pouvez pas repérer ou résoudre automatiquement, considérez-les comme un ensemble de directives complémentaires à la norme de codage automatisée, mais acceptez le fait que vous et vos collègues ne les suivrez pas avec diligence. Enfin, la norme de codage devrait être dynamique plutôt que statique. Au fur et à mesure que le projet évolue, les besoins du projet changent, et ce qui peut sembler intelligent au début n’est pas nécessairement intelligent quelques mois plus tard.

Qu’en pensez-vous ?