C’est une question qui m’a été posée en entretien d’embauche il y a peu de temps:
“Comment un autodidacte comme vous peut-il être sur que son code est de bonne qualité?”
Ça peut paraître une question naïve, surtout venant d’un RH, mais ça me fait pas mal cogiter depuis, au delà de la technique.
Pendant l’entretien j’ai répondu un truc bâteau, qui a d’ailleurs eu l’air de lui plaire, mais il me semble que cette question de comment je produit du code et pourquoi il est bon ou mauvais mérite bien un petit article.
Au passage, si tu passes par là Mme la RH et bien tu trouveras ci dessous une réponse un peu plus complète à ta question :)
DISCLAIMER: Je vais parler ici de méthodes et pas de techniques pure. Si tu cherches à savoir comment indenter ton code ou si tu dois ou non commenter tu ne trouveras pas ton bonheur :)
1 – Mon code marche
Réponse simpliste. Mon code fonctionne, ça tourne en prod depuis des jours/mois/années, mon code est de qualité.
C’est pas faux, mais ce n’est pas suffisant. On a tous en tête des codes qui tournent mais qui ne seront jamais mis à jour tellement l’effort de maintenance est important.
Un code qui tourne n’est pas un bon code, c’est nécessaire mais loin d’être suffisant.
2 – Mon code est le fruit d’une méthode de travail
Produire du code de qualité c’est, pour moi, avant tout la mise en place d’une méthode. Toute l’équipe de développeurs doit être impliquée et faire en sorte que la base de code de tous les projets soit de qualité ou en constante évolution vers une qualité optimale.
Pour ça j’essaie d’appliquer ces trois méthodes :
Merge Request
Je travaille le plus possible avec le workflow de github. Tout mon code est crée sur de nouvelles branches avec Git et quand j’ai fini une fonctionnalité ou un fix je fais relire le tout par un collègue. Tout le code produit est relu, commenté, et n’est mergé que quand celui à qui est affecté la merge request n’est satisfait.
Ce système permet de produire du code bien meilleur, on sait que l’on va être relu, du coup on fait gaffe et on essaye de commenter un peu plus, de mettre des variables explicites etc…
Si jamais des erreurs se sont glissées, il y a de grandes chances que le mainteneur nous le fasse remarquer (autant sur le fond que sur la forme d’ailleurs)
Autre point positif de cette méthode, le mainteneur du code changeant tout le temps, toute l’équipe “voit passer” le nouveau code sur le projet. Cela réduit considérablement l’effort de maintenance.
Extreme Programming
Depuis plusieurs mois j’essaye de mettre en place les règles de l’extreme programming. Au programme, pair programming, ne pas sur optimiser, garder le code le plus simple possible et impliquer toute l’équipe à ces problématiques.
La mise en place des tests automatisés est au programme, mais pour le moment ils ne sont pas encore écrit.
Les retombées sont impressionnantes, l’équipe est plus motivée, le code produit est de meilleure qualité car revu de manière régulière et le pair programming permet d’abattre plus rapidement les situations de blocages – sans avoir à faire des hacks tout moches que l’on aurait tendance à faire seul dans son coin!
Code Sniffer
Enfin, dernier point plus technique, j’ai mis un code sniffer sur mon éditeur de texte préféré. Il râle si mon code n’est pas formaté comme il faut, et, du coup, je râle si le code que je récupère d’un collègue ne respecte pas les règles du standard.
Cela peut paraître anecdotique mais c’est primordial. Cela donne une base de code uniforme sur les milliers de lignes de code de nos applicatifs et cela facilite la maintenance.
3 – Je suis un être social
Autre point qui me tient particulièrement à cœur: l’échange.
Un développeur isolé est un développeur qui travaille mal.
Moi qui n’ai jamais étudié la programmation à l’école (ou très peu) j’ai toujours codé en restant en contact avec des groupes de dev qui pouvait répondre à mes question et vide versa. C’est ce que je fais avec StackOverflow, sur IRC, Twitter etc…
C’est primordial pour moi, cela permet aussi de confronter les idées, d’aller chercher les best-pratices et “d’aspirer” une quantité d’expérience bien plus importante et de manière beaucoup plus interactive qu’en lisant des bouquins!
Par exemple, il y a peu j’ai du concevoir et coder une API RESTFull avec Symfony2. Au final j’ai du passer plus de 70% de mon temps à lire des posts de blogs sur le sujet, à échanger avec des pointures sur IRC et à chercher les meilleurs design pattern et les meilleurs bundle AVANT de commencer à coder.
Seul je n’aurai pas fait un dixième du résultat final et la qualité aurait été réellement en deçà de ce que j’ai finalement produit.
Voilà en substance comment je fais pour savoir si mon code est de bonne qualité, et vous quels sont vos #proTips pour produire du code de qualité ?