De bonnes habitudes de développement logiciel

• Cet article n’est pas un recueil de conseils, mais une présentation des habitudes de développement que l’auteur applique actuellement
• Il rassemble des expériences menées pour éviter les mauvaises habitudes et en construire de bonnes, et présente 10 habitudes qui l’ont aidé à gagner en productivité tout en maintenant la qualité

1. Garder des commits petits

• Il faut garder les commits aussi petits que possible. De petits commits permettent de ne revenir que sur un commit précis en cas de bug, ce qui aide à éviter des conflits de fusion complexes
• L’auteur s’impose comme règle de pouvoir commit dès que « le logiciel compile »

2. Refactorer en continu

• Conseil de Kent Beck : « Quand vous voulez un changement, rendez d’abord le changement facile, puis faites le changement facile. »
• Au moins la moitié des commits incluent du refactoring. De petits refactorings sont d’une grande aide quand de grosses demandes arrivent
• Il faut éviter les gros refactorings. À la place, mieux vaut effectuer en continu de petites améliorations de moins de 10 minutes

3. L’importance du déploiement du code

• Le code en lui-même est une dette potentielle, et le code non déployé est la plus grande des dettes
• Les tests donnent de la confiance, mais le déploiement réel représente la véritable validation
• Une fréquence de déploiement plus élevée peut augmenter les coûts d’hébergement, mais le fait de vérifier que les derniers changements fonctionnent réellement est un avantage important

4. Ne pas tester les fonctionnalités du framework

• Il ne faut pas tester les fonctionnalités du framework. Le framework a déjà été suffisamment validé
• En gardant les composants petits, on laisse le framework faire l’essentiel du travail, ce qui réduit les tests nécessaires
• Les gros composants ajoutent de la complexité, et exigent donc beaucoup plus de tests

5. Créer un nouveau module

• Si une fonctionnalité donnée ne s’intègre pas à un module existant, il vaut mieux créer un nouveau module
• Il est préférable de la laisser comme module indépendant plutôt que de la forcer dans un module existant

6. Une application souple du développement piloté par les tests (TDD)

• Quand la conception d’une API n’est pas claire, écrire d’abord les tests permet de réfléchir du point de vue du « client »
• Le TDD n’est pas suivi comme un principe religieux. Si nécessaire, on peut travailler sur une unité plus large avant d’écrire les tests
• Il n’est pas indispensable de faire échouer de petites unités de code, ni de s’enfermer dans un dogmatisme qui nuit à la productivité

7. Le copier-coller n’est autorisé qu’une seule fois

• Une première copie peut passer, mais à partir de la deuxième, on crée de la duplication
• À ce moment-là, il faut supprimer la duplication via une abstraction adaptée. Même si la paramétrisation semble un peu étrange, c’est préférable à la fusion de plusieurs implémentations

8. Accepter l’évolution du design

• Le design vieillit avec le temps. Le refactoring peut ralentir ce vieillissement, mais au final le design finira forcément par changer
• Il ne faut pas trop s’accrocher au design précédent, mais accepter le changement
• Il n’existe pas de design parfait, et la capacité à bien réagir au changement est au cœur du développement logiciel

9. Les trois types de dette technique

• La dette technique peut être classée en trois catégories :
  1. Ce qui gêne le travail actuel
  2. Ce qui pourrait gêner le travail futur
  3. Ce qui pourrait peut-être devenir gênant
• Il faut minimiser le premier type de dette, se concentrer sur le deuxième, et ignorer le troisième

10. Le lien entre testabilité et bonne conception

• Si c’est difficile à tester, il y a de fortes chances que le design pose problème
• La conception des tests peut elle aussi être améliorée. Par exemple, si créer un mock pour em.getRepository(User).findOneOrFail({id}) vous paraît difficile, il vaut mieux extraire cela dans une fonction séparée ou utiliser des utilitaires de test
• Si les tests ne sont pas écrits, c’est souvent parce qu’ils sont difficiles à écrire, et cela peut révéler un problème de conception

[yangeok]

Il vaut mieux atteindre le SRP que le DRY ; même en le confiant à une IA, elle raconte moins de bêtises.

[progdesigner]

Je pense que le plus important, c’est à quel point on a su mettre en place un code et un environnement capables de s’adapter rapidement au changement.

Et grâce à une abstraction appropriée, on peut améliorer la réutilisabilité et l’extensibilité du code, tout en exploitant les outils d’IA pour maximiser la vitesse de développement.

[pcj9024]

C’est vraiment un excellent article. J’aimerais le recommander un peu partout.

[tsboard]

Accueillez le changement, copiez-collez une seule fois, faites en sorte que les tests fonctionnent mieux, faites des commits plus petits... !

[aer0700]

C’est un bon article.

[puersum]

Je pense que cet article vaut vraiment la peine d’être lu dans sa version originale.
Quand une actualité m’intéresse, j’ai tendance à aller voir la source, mais pour celle-ci c’est particulièrement recommandé. Si vous regardez le point 1, le texte original dit :
Keep commits small enough that you wonder if you're taking this "keep commits small" thing a little too far. mais cela a été résumé en « il faut garder les commits aussi petits que possible »..

[ilbanin00]

C’est vraiment un excellent article.

[joon14]

Le point 7 est vraiment très pertinent.

[GN⁺]

Avis Hacker News

• Il vaut mieux utiliser des paramètres pour éviter plusieurs implémentations. Il est plus facile d’améliorer des paramètres que d’unifier plusieurs implémentations.

  • S’il est impossible d’éviter des « paramètres bizarres », il vaut mieux séparer le code. Il faut éviter les drapeaux booléens et les multiples paramètres d’énumération.
  • Des signatures de fonction complexes rendent la maintenance plus difficile.

• Copier du code une fois peut passer, mais à partir de la deuxième fois, il faut éviter la duplication. Il faut créer de bonnes abstractions quand on dispose d’assez de cas concrets.

  • Même si le code est identique au départ, il faut surtout se demander s’il doit évoluer ensemble quand des changements deviennent nécessaires.
  • L’objectif n’est pas d’éviter la duplication en soi, mais de garder ensemble le code qui doit évoluer ensemble.

• DRY (ne pas se répéter) ou WET (écrire tout deux fois) ne sont pas des règles absolues. La vraie difficulté est de comprendre le bon moment entre duplication du code et unification.

• Comme alternative aux petits commits, on peut ajouter un nouveau commit qui corrige le bug sans annuler un gros commit.

  • On ne voit pas clairement pourquoi les gros refactorings seraient mauvais.
  • Il vaut mieux créer une structure indépendante que de forcer son intégration dans un module existant.
  • Lors de la conception d’une API, on peut organiser des sessions de design au lieu de s’appuyer sur des tests unitaires.

• La testabilité est liée à une bonne conception. Ce qui ne se teste pas facilement peut être le signe qu’un changement de conception est nécessaire.

  • Le code de test doit aussi être relu par d’autres moyens.

• Il faut être prudent lorsqu’on teste les fonctionnalités d’un framework. Un framework peut évoluer avec le temps.

  • L’un des rôles importants des tests est de vérifier qu’une mise à niveau des dépendances reste sûre.

• Concernant la taille des commits, il faut viser des commits faciles à annuler au cas où un changement précis devrait être revert.

• Les entreprises veulent une base de code stable, mais un refactoring continu reste nécessaire. Cela peut entrer en conflit avec la stabilité.