Penser son code pour le futur

Cela fait 4 ans que je développe de manière professionnelle pour le compte d'un client, et bien plus longtemps que je développe pour mon propre compte. Parfois j'ai dû coder sous pression, parfois j'ai dû récupérer le code d'autres développeurs, et parfois c'était à mon tour d'écrire du code qui sera ensuite repris par d'autres.

La seule constante dans tout ça : le code que j'ai écrit est toujours resté bien plus longtemps que ma participation dans le projet. Il n'est pas rare pour moi aujourd'hui de voir des collègues qui viennent me demander comment fonctionne un bout de code que j'ai écrit en 2016.

Aujourd'hui, je partage un petit tour d'horizon sur la maintenance de code, ou comment faire en sorte de ne pas compliquer la vie de vos successeurs.

Ne jamais cesser d'apprendre

Les projets vont et viennent, le code apparaît, disparaît, ne refait surface que quand il ne fonctionne plus. Pourtant qu'est ce qui importe réellement à la fin de la journée ?

Ce n'est pas ce code buggé que vous avez écrit toute la journée. Ce n'est pas non plus ce bug que vous avez créé par inadvertance en 2005 et qui ressort aujourd'hui.

La seule question vraiment importante aujourd'hui c'est : Si vous deviez le refaire, est-ce que vous feriez mieux ? Êtes vous meilleurs aujourd'hui que vous ne l'étiez il y a 2 jours ? 1 an ? 5 ans ?

Pour cela, il ne faut jamais cesser d'apprendre ! Vous apprendrez des bonnes pratiques, probablement des mauvaises aussi, mais un jour vous apprendrez aussi à faire la différence entre les deux.

C'est, pour moi, la facette à la fois la plus belle dans notre métier, mais aussi la plus difficile à suivre et à garder en vue !

Ne jamais oublier la qualité de code

Pour du code maintenable, le code review est obligatoire !

Personne n'a la vérité exacte, personne n'est infaillible, et personne ne connait la meilleure façon absolue de faire une chose. Par contre ce qui est sûr, c'est que deux développeurs valent mieux qu'un.

Quelle que soit la taille de l'équipe, chaque ligne de code écrite doit être consultée et revue par au moins un autre développeur avant de passer en production. Cela permet de corriger certaines erreurs, mais permet aussi de partager l'information et de faire apprendre toute l'équipe à partir des forces et faiblesses de chacun.

Un code est lu, en moyenne, 100 fois plus qu'il n'est écrit ! Alors oui, mettre une quadruple ternaire imbriquée fait gagner pas mal de caractères, mais si son auteur est le seul à la comprendre, peut être qu'il faudrait penser à changer ça !

Le code review permet de savoir directement si cette incompréhension vient d'une disparité dans le niveau technique, ou d'un code très mal écrit. Le plus beau c'est que dans ces deux cas, le problème sera réglé par ce code review.

Documenter et commenter

Un code bien écrit doit se commenter lui-même. Utilisez au maximum des noms de fonctions ou des découpages logiques correctement nommés pour rendre votre code lisible et compréhensible. En regardant le contenu de la fonction registerNewClient, on doit être capable de comprendre ce qu'elle fait, même si on n'a aucune idée de comment la fonction sendClientInvoice est conçue.

Utilisez aussi des patterns connus qui se passent de documentation. Tout le monde sait (doit savoir) ce qu'un singleton est. Le commentaire ceci est un singleton au-dessus du getInstance() est inutile. Par contre, quand vous commencerez à chainer des map, dans des flatMap dans des filter, il est fortement probable qu'un commentaire décrivant le format d'entrée et le format de sortie soit utile. Vos prochains collègues vous remercieront!

Pensez aussi à documenter de façon globale la conception de l'application. Un README décrivant chaque dossier principal, avec à chaque fois les technos utilisées et pourquoi fera parfaitement l'affaire! Et comme ça dans 2 ans, tout le monde saura pourquoi vous avez mixé fluxible et redux dans la même application!

Le meilleur code est celui qui n'existe pas

Quand on est développeur junior, on part souvent du principe que plus il y a de code, mieux c'est. Qu'il faut écrire son propre code afin d'avoir "un contrôle total sur ce que l'on fait". Tout cela est faux !

À chaque fois que l'on écrit une ligne de code, on écrit du code qui, potentiellement, contient des bugs. C'est un fait. Or pour garantir le contentement des utilisateurs, notre code ne doit pas bugger, jamais, sous aucune raison. Qui plus est cette ligne de code va devoir être de qualité, testée, documentée, puis maintenue pour le reste de la vie de notre application.

La solution la plus logique serait donc de ne jamais écrire de code. Oui mais du coup il n'y a plus de programme, et nos utilisateurs sont certes contents, mais on ne répond pas à leur besoin.

Si seulement quelqu'un pouvait avoir inventé une solution pour avoir du code, mais sans l'écrire nous-mêmes ?

C'est pour cela qu'on a inventé les librairies Open Source. Imaginez du code, déjà écrit, déjà documenté et déjà débuggé. Alors certes, on n'a aucun contrôle dessus (et encore), mais si la librairie fait ce qu'on veut, et qu'elle est maintenue, pensez-vous vraiment à vous tout seul pouvoir faire mieux que les dizaines de personnes qui maintiennent la librairie en question ?

Bien sûr, si votre but est d'apprendre, recréer soi-même une librairie est un très bon choix. C'est auprès des meilleurs que l'on apprend le plus vite. Mais c'est à vous de choisir si vous voulez apprendre, ou fournir un logiciel qui marche.

Choisissez bien votre camp!

Testez, testez et retestez

Un code non-testé, est bien pire qu'un code qui n'existe pas. C'est une bombe qui peut sauter n'importe quand. Aujourd'hui votre calcul d'âge du capitaine fonctionne, mais qui vous dit que plus tard, quand quelqu'un changera le format des prénoms dans la base, il fonctionnera toujours ?

La solution : il suffit de considérer tout code non testé, comme un code qui ne fonctionne pas.

Quand vous codez, écrivez des tests. Quand vous débuggez, écrivez des tests. Quand on vous remonte un bug, écrivez des tests.

Plutôt que de faire 25 clics pour reproduire votre bug, et de le refaire à chaque test d'une nouvelle version, il faut extraire le code problématique dans un test isolé qui reproduit uniquement ce bug. Ensuite vous pourrez modifier jusqu'à ce que tout fonctionne.

Ce test rejoindra la batterie de test en même temps que le correctif rejoindra notre code. Et dans 2 ans quand vous pousserez en production, vous n'aurez pas (moins) la sueur au front car "les tests passent".

Conclusion

Aujourd'hui je commence un nouveau projet, et je dois concevoir l'architecture de base et la structure pour de nombreux développements à venir. Potentiellement ce code sera relu par des centaines de personnes, et utilisé par des milliers dans les années à venir. Sauf que cette fois je suis armé de toutes les erreurs et expériences du passé pour faire moins pire que la derniére fois !

Toutes ces remarques ne sont pas à prendre au pied de la lettre et s'appliquent surtout a ma vision du développement. Certaines sont probablement discutables, et il est possible que certains conseils soient totalement mauvais.

J'espère juste vous avoir aidé à vous forger votre propre opinion et je serais heureux d'en discuter sur twitter.