Code propre – 2 jours avec Uncle Bob

L’évangéliste pragmatique du software craftsmanship, Robert Cecil Martin alias Uncle Bob était l’invité d’honneur de Xebia pour un atelier software craftsmanship sur le code propre (a.k.a Clean Code).

Pendant 2 jours, se sont succédés conseils pratiques, prises de conscience (« aha… »), analogies originales, discussions sur l’industrie à l’heure du repas, randori TDD, kata, coding dojo, décortication minutieuse de classes, effacement de nombreuses lignes de code inutiles et ses fameuses diversions scientifiques (de la mitochondrie au réchauffement du soleil). Tout ça saupoudré d’une expérience de 40 ans dans l’industrie logiciel aux Etats-Unis.

Instants choisis.

Clean code

Dans l’optique d’un code propre, Uncle Bob a rappelé que la première mission d’un programmeur est de communiquer à travers son code. Nous avons passé aussi du temps à décortiquer, de façon plus poussée que dans son livre Clean Code, des classes (notamment org.jfree.date.SerialDate). Nous avons cherché toute trace de duplication ou de répétition d’information (code, commentaires, javadoc, licences, …) et les avons supprimés. Et quand on cherche on trouve !

Ensuite, il y a eu débat ouvert sur le rôle des codings standards dans une équipe de développement. Pour Robert Martin, le document qui rassemble les standards d’écriture du code c’est le code lui même. Ainsi un nouveau développeur sur le projet étudie le code pour savoir comment l’écrire. Un simple fichier de configuration IDE suffit pour les problèmes de formatting. De la même façon, M. Martin explique qu’il n’utilise pas forcément Checkstyle ou alors avec une configuration vraiment minimale, car le fait de forcer la propreté du code n’encourage pas à entretenir de bonnes pratiques. Appliquer bêtement les règles juste parce que l’outil remonte des violations, sans parcimonie, n’est pas une bonne solution.

Refactoring

Une question qui revient trés souvent a ensuite était soulevée : que faire dans le cas ou l’on se retrouve devant du code legacy spaghetti ? On a hérité du produit et l’on doit le faire évoluer.

Dans la salle quelques suggestions : « On pourrait tout refaire ? ». Et Uncle Bob de répondre « Non. Pourquoi ferrait-on mieux cette fois-ci ? ». Un autre lance : « On pourrait faire des sprints de refactoring ? ». Un autre « non » retentissant de la part de Bob. Il explique alors qu’il faut accepter le fait que l’on se retrouve face à une montagne de mauvais code et qu’il faut le nettoyer. Il ne faut pas que le refactoring soit sur l’agenda du sprint, il faut que ce soit un travail de continuous cleaning et de continuous refactoring. Cela implique que chaque développeur en connaisse les pratiques.

Uncle Bob résume par : « The only way to go fast is to clean at the same time! ». Il a donné pour cela une bonne analogie : celle du Sushi chef. Une fois que le Sushi chef vous présente son sushi fraichement assemblé de main de maître, observez son espace de travail. La planche à découper est immaculée et le chef est prêt à recommencer un autre sushi.

Toujours sur les pratiques du refactoring et donc de la détection de code smells, on a eu droit à une trés belle démonstration du côté diabolique du switch statement. On sait tous que le switch statement est fragile et qu’il est facile d’y introduire des bogues. Uncle bob nous indique également qu’il entraîne des couplages dans les déploiements d’artefacts en empêchant le polymorphisme. Tout un programme et peut être le sujet d’un prochain article d’ailleurs, d’autant que lors de cette démonstration nous avons parcouru l’histoire des types de langage (Structuré, Fonctionelle et Orienté Objet) et que les ramifications des raisons sont structurelles.

Test Driven Development

M. Martin a avancé un bel argument pour le TDD. Imaginez une salle remplie de développeurs pratiquant tous le TDD. Choisissez un développeur au hasard. Faites tourner son code. Tous ses tests passent. C’est à dire que dans cette salle tout code à n’importe quel moment (à un intervalle de temps minimal prés) fonctionne selon les specifications. Puissant le concept, non ?

Robert Martin a illustré l’importance de la couverture des tests avec son produit Fitnesse qu’il développe avec une petite équipe. Fitnesse a une couverture de test de 96%. Impressionnant. Pour toute évolution du produit il explique : « I ship it when it is green! ». Comprenez donc que Fitnesse est mise à disposition de la communauté avec les nouvelles fonctionnalités simplement lorsque les test passent. Et Robert ajoute qu’il ne fait même pas tourner l’application, seulement les tests !

Ensuite sur la question d’écriture d’une méthode de test, il est toujours bon de rappeler la règle des 3 A(s) :

• Arrange (préparation des objets et mocks pour le test)
• Act (appel de la méthode à tester)
• Assert (lignes d’assertions)

Le nombre d’assertions dans la méthode n’est pas important mais un test doit tester une fonctionnalité et une seule. Les assertions doivent donc rester dans un groupement logique.

Aussi il a presenté une façon d’écrire la méthode de test qui est assez concise. En voici un exemple:

public void givenVipUser_returnAccessRights()

Dans le cadre du TDD, nous avons abordé la notion de principe de priorité de transformation. Il s’agit d’une technique qui aide à trouver la bonne transformation à faire à son code pour qu’il passe un nouveau cas de test. Vous retrouverez l’essentiel de la description de cette technique dans ce billet de blog : the transformation priority premise. L’avenir pourrait être une série de raccourci-clavier nous suggérant les transformations à faire dans notre code…

Pragmatisme

Son côté pragmatique est ressorti lorsqu’il explique que Fitnesse n’utilise pas de base relationnelle car il n’en a jamais eu besoin. Au départ, pendant la phase de développement initiale, la persistence se faisait en mémoire, puis l’équipe est passée à de la persistence sur le système de fichiers. D’après Bob, un seul client a étendu Fitnesse pour utiliser une base MySql – grâce aux mécanismes d’extensions de Fitnesse. La raison de cette extension est que la DSI de ce client ne permettait pas de persistence sur le système de fichiers !

Une pratique qui lui tenait particulièrement à coeur, et qu’il nous a démontré sur un projet assez simple de legacy, est qu’avant de toucher ou même de regarder le code de production, il faut nettoyer et améliorer les tests existants si il y en a. C’est seulement ensuite, une fois que les tests sont de haute qualité, que le code peut être étudier et modifier.

Sur la question du defensive programming (assertions dans le code de production, null checking, etc), Robert Martin explique qu’il comprend cette procédure pour les APIs publiques. Cependant, faire du defensive programming dans votre propre système d’entreprise n’a pas forcément de sens. Robert observe qu’à chaque fois qu’il a vu du code en style defensing programming en entreprise, c’est que l’équipe n’écrivait pas de tests unitaires.

Conclusion

Il serait difficile de résumer tout ce qu’il s’est passé en 2 jours d’atelier. Heureusement, le craftsmanship et les pratiques associées sont accessibles à tous à travers les rencontres, le web et les livres. Cependant, il est toujours appréciable d’observer la pédagogie, la verve et l’argumentation souvent implacable de quelqu’un dont la façon de coder à radicalement changé après une courte session de TDD avec Kent Beck.