Apprenez à coder proprement

dev mars 01, 2020

Récemment, j'ai dû reprendre un projet qui jusqu’aujourd'hui était développé en solo.


5 ans de code PHP/Symfony3 à reprendre, en soi ce n'est pas censé être compliqué si votre prédécesseur code avec les bonnes pratiques.

Là où tout se complique, c'est lorsque vous vous retrouvez face à un projet qui pendant plusieurs années a tourné sans CI, sans versionning, sans norme, et sans commentaires (mon cas). C'est pratiquement un exploit que ce code tourne encore.
Lorsque j'ai demandé comment il était possible de produire du code comme celui-ci, on m'a répondu que le développeur a appris sur le tas et qu'il n'avait pas le temps de faire de refracto, car il faut suivre la cadence à savoir 1mise en prod/semaine.


Ici nous faisons face à un problème assez fréquent: envoyer des features rapidement, peu importe la qualité du code et pour ce qui est des tests ? On testera manuellement. Au début, tout est super et tout le monde est content, les features sortent vite,  le dev ne se prend pas la tête il met en prod sans trop se poser de questions, puis un beau jour l'équipe s'agrandit ou on se dis "tiens tiens si je faisais un peu d'optimisations, ou un peu de refracto par ci, par la" et là on se heurte à une montagne de code empilé n'importe comment et on comprend qu'il est trop tard, qu'il y a tellement de choses à modifier que cela nous prendrait des mois pour retrouver un  code sain. Alors  on continue à jouer avec notre caca, et l'enfer commence. Les reports de bugs n'en finissent plus de grimper, la sortie de features est de plus en plus retardée, et on ne s'en sort plus.
Au final on met en péril tout le projet alors que des règles simples auraient permis des le départ d'éviter cela.

Testez votre code

Tester son code manuellement c'est bien, mais ce n'est pas une façon optimale de procéder, car plus vous allez avoir de features, plus vous allez devoir tester et 99% du temps vous passerez à cote de bugs, failles de sécu et j'en passe. Les tests unitaires ne sont pas une solution miracle, ils vont tester ce que vous leur direz de tester c'est pourquoi il existe des outils tels que SonarQube, Jenkins, Travis, Gitlab CI... pour vous permettre de savoir quel pourcentage de code vos tests unitaires couvrent (coverage) et ainsi les améliorer. Lancer un projet sans tests unitaires c'est foncer dans le mur, lorsque vous ou votre équipe allez vouloir déployer, si personne n'a effectué de tests et que tout crash vous vous assurez des heures de travail pour remonter qui a fait quoi et comment fixer tout ça.

Bon, j'espère que c'est bien compris maintenant, on teste son code correctement quand on travaille sur un projet, peu importe sa taille.

Respectez la norme !

Je vois encore sur certains projets des développeurs qui codent sans norme, peu importe le langage que vous utilisez vous devez respecter une norme, que ce soit pour vous seul, ou pour un projet en équipe une norme s'impose. Pourquoi ? Parce que lire du code mal formate c'est une perte de temps et que si tout le monde peut lire le même code de la même façon vous allez gagner un temps précieux. De plus il existe une flopée d'outils pour nommer votre code (EsLint sous nodeJS par exemple) alors vous auriez tort de vous en priver.

Versionnez

Du code qui n'est pas versionné c'est du code qui n'existe pas. Et pourtant le projet que j'ai repris et dont je vous parlais plus haut n'avait aucun versionning et le dev n'en voyait pas la nécessité. C'est pourtant une aberration, le versionning (via Git par exemple) est nécessaire voir crucial dans un projet peux importe sa taille, comment voulez-vous vous organiser avec votre équipe sans versionning ? Comment voulez-vous vous y retrouver dans votre code sans versionning ? Versionner votre code est une chose simple, rapide et obligatoire dans tout projet, cela vous permet de vous organiser, de travailler en équipe, de communiquer bref ce n'est pas facultatif et encore moins une perte de temps comme certains pourrait le croire.

Documentez votre code

Pondre du code c'est bien beau, mais qu'en est-il de votre doc ? Pareil, dans mon exemple on m'a refilé des centaines de fonctions et lignes de code sans aucune doc, c'est tout simplement impensable de procéder de cette façon. Bien sûr en solo vous vous dites '' c'est mon code je sais ce que j'ai fait et comment il fonctionne '' mais dans la réalité, après plusieurs années de travail vous perdez du temps a retrouver ce que fait tel ou telle fonction et puis un beau jour vous êtes perdus, écrire une doc la plus simple soit elle vous sauvera dans bien des situations et vous fera gagner du temps en plus de permettre a vos collaborateurs de comprendre votre code plus facilement.

Optimisez

Parce que personne n'aime quand une application tourne à 2 à l´heure, il est important dès le départ de chercher l'optimisation. Là vous vous dites '' j'optimiserai quand tout sera fini '' oui, mais ce ne sera jamais fini, il y aura toujours quelque chose à faire et finalement vous vous retrouverez avec un moteur de twingo dans une Ferrari, mon conseil ici, cherchez comment optimiser votre code au fur et à mesure que vous le développez et non quand vous pensez avoir tout fini, parce que bien souvent vous allez devoir bouger votre code et quand le projet est trop gros, bon courage.

En Conclusion

Il n'est jamais plaisant de reprendre du code ''sale'' alors pour le bien de vos collègues ou futurs collègues s'il vous plaît soignez ce que vous produisez, vous y gagnerez en productivité et vos collègues vous en serons reconnaissants.

Ceci est le premier post sur ce blog, si vous voyez des pistes d'amélioration merci de m'en faire part dans les commentaires.

Faurest

Touche-à-tout et passionne par l'informatique et plus particulièrement le développement, j'en ai fait mon métier et aujourd'hui je partage avec vous mes dernières humeurs et expériences sur ce blog