La qualité de code, c'est juste la vélocité dans la durée

Il faut qu'on parle qualité de code.

La qualité de code, pour moi, ce n'est qu'une chose : la capacité à continuer à construire et enrichir une app de manière constante.

Quand on dit ça, à mon sens, ça englobe tout.

Si ton code n'est pas lisible, mal architecturé, avec des méthodes de 200 lignes, revenir dessus devient pénible. Onboarder aussi. Et in fine, tu réduis ta vélocité.

À l'heure de l'IA ? Pas besoin d'un modèle frontière pour avoir un code d'aussi bonne qualité que 90 % des devs. Et dans 100 % des cas, ce sera produit plus rapidement.

Depuis trois ans, je code de manière assistée en Ruby, Elixir et Go. Mention spéciale à Go, où l'IA est vraiment impressionnante. Sur la qualité du code produit, je n'ai pas grand-chose à redire.

Je n’ai vraiment que deux bémols.

Le premier : le côté "solution à tout prix". L'IA n'hésitera pas à faire des choses inmaintenables pour atteindre l'objectif. Ça semble presque dans son « ADN », je n’ai vu aucune rules qui permettait vraiment d’éviter ce comportement.

Le second : l'extension de périmètre. Elle cherche souvent à aller au-delà de ce qui est demandé, fonctionnellement. Parfois c’est positif car tu as vraiment oublié quelquechose, d’autre fois non. Le recours au mode plan systématique corrige une bonne partie de ce problème.

La production de code devient cheap, ce qui m’amène une question :

La qualité du code est-elle encore une bonne métrique ?