AngeZanetti.com

Internet et ses usages, développement Web et humeurs diverses

Comment savoir que son code est de bonne qualité?

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 :)

Comment produire du code de qulité

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é ?

 

 

4 Comments

  1. J’ai trouvé l’article intéressant et je souhaitais le commenter car la qualité du code est un sujet qui me passionne depuis assez longtemps. J’espère que ces commentaires seront utiles.

    Tout d’abord je crois qu’il est très difficile de définir la qualité. C’est quelque chose qui est au mieux relatif (deux personnes peuvent avoir un point de vue différent sur un même code, parfois on peut soi-même un jour considérer avoir fait du bon code et ne plus avoir le même avis quelque temps après), au pire c’est une chose qui ne veut rien dire (j’ai rencontré des gens qui ne sont pas programmeurs et m’ont dit ‘la qualité du code’ ça n’a aucun sens pour moi).

    Mes critères sont assez proches de l’article : il fonctionne, il est simple, il est bien conçu (sous-entendu il peut évoluer facilement).

    Le premier critère est assez facile à mesurer.

    Le second est déjà plus difficile mais il existe un indicateur simple que l’on appelle la complexité cyclomatique. Le terme semble barbare mais en gros il permet de savoir si le code est plus proche du plat de spaghettis ou de la grille orthogonale, et ça en un seul chiffre.

    Un code simple n’est pas forcément bien conçu (même si la réciproque est vraie). Et là on arrive sur mon troisième critère, qui est le plus difficile à faire.
    La seule solution valable que je connaisse c’est d’avoir des harnais de tests
    qui permettent de remanier (‘refactorer’), remanier, et encore remanier.
    Un peu comme quand on va polir un diamant brut pour en faire une pièce d’exception. La bonne “conception spontanée” n’existe pas, c’est un travail que l’on fait avec le temps, avec la maturation que l’on a de la compréhension du système et de nos compétences de programmeur. Pour ça il faut évidemment échanger avec les autres développeurs mais aussi apprendre d’eux indirectement en allant dans du code open source ou en lisant des livres de référence (ceux que je préfère sont chez Addison Wesley et Wiley).

    Pour conclure, je crois qu’on est tous autodidacte quand il s’agit de la qualité
    du code (je me souviens pas avoir eu un cours sur le sujet dans mon cursus
    pourtant purement informatique – ça a peut-être changé toutefois). Je dirai même qu’être autodidacte c’est absolument nécessaire pour atteindre une bonne qualité.

  2. Xavier

    July 29, 2014 at 12:22

    Merci Olivier pour ce commentaire bien fourni!

    Il faut que je jette un œil à la complexité cyclomatique que je ne connaissais pas. Pour le reste nous sommes d’accord, plus on itère, plus on refactorise plus la qualité est bonne !
    Tu utilises des outils pour monitorer tout ça?

  3. Sébastien ELET

    July 30, 2014 at 13:43

    Pour les outils : sonarqube, platojs, codacy, codeclimate et scrutinizer.

    Il en existe un tas d’autres…

  4. Bonjour,
    Les critères pour définir la “santé” ou la qualité du code est multiples, ils sont listés dans la norme ISO 9126 .
    C’est surtout utile pour une application qui doit vivre dans le temps, complexe (3 tiers), avec plusieurs DEV en //

    Capacité fonctionnelle : Est-ce que le logiciel répond aux besoins fonctionnels exprimés ?
    Pertinence
    Exactitude
    Interopérabilité
    Sécurité
    Conformité
    Fiabilité : Est-ce que le logiciel maintient son niveau de service dans des conditions précises et pendant une période déterminée ?
    Maturité
    Tolérance aux pannes
    Facilité de récupération
    Facilité d’utilisation : Est-ce que le logiciel requiert peu d’effort à l’utilisation ?
    Facilité de compréhension
    Facilité d’apprentissage
    Facilité d’exploitation
    Pouvoir d’attraction
    Rendement / Efficacité : Est-ce que le logiciel requiert un dimensionnement rentable et proportionné de la plate-forme d’hébergement en regard des autres exigences ?
    Comportement temporel
    Utilisation des ressources
    Maintenabilité : Est-ce que le logiciel requiert peu d’effort à son évolution par rapport aux nouveaux besoins ?
    Facilité d’analyse
    Facilité de modification
    Stabilité
    Testabilité
    Portabilité : Est-ce que le logiciel peut être transféré d’une plate-forme ou d’un environnement à un autre ?
    Facilité d’adaptation
    Facilité d’installation
    Coexistence
    Interchangeabilité

    Après la qualité du code, ne fait pas la qualité (uniquement) de l’application, il y a aussi la stratégie de test (test fonctionnel, perf, sécurité…) … le chemin est long mais il faut intégrer cette problématique des la phase de conception de l’application…

Répondre

© 2016 AngeZanetti.com

Theme by Anders NorenUp ↑