Évolution des normes de codage, comment les gérez-vous?

Comment gérez-vous l'évolution des normes de codage / guide de style dans un projet pour la base de code existante? Disons qu'un membre de votre équipe a découvert une meilleure façon d'instancier un objet dans le langage de programmation. Ce n'est pas que l'ancienne façon est mauvaise ou boguée, c'est juste que la nouvelle façon est moins verbeuse et se sent beaucoup plus élégante. Et tous les membres de l'équipe aiment vraiment ça. Souhaitez-vous changer tout le code existant?

Supposons que votre base de code compte environ 500 000+ lignes de code. Souhaitez-vous toujours modifier tout le code existant? Ou voudriez-vous seulement laisser le nouveau code adhérer à la nouvelle norme? Perdre fondamentalement la cohérence?

Comment gérez-vous une évolution des normes de codage de votre projet?

Des normes de codage existent pour rendre les équipes plus productives. En théorie, ils facilitent la compréhension, la modification et le test du code. En pratique, ils peuvent créer une quantité dangereuse de méta-travail; les équipes réécrivent le code existant encore et encore à la recherche de la solution la plus correcte et la plus élégante. Malheureusement, le problème du méta-travail semble pire dans les équipes où tout le monde est engagé, passionné et obsédé à faire la bonne chose.

En tant que consultant passant d'un projet à l'autre, j'ai constaté qu'une excellente discipline avec une norme de codage rigide contribue beaucoup moins à la réussite d'un projet que d'excellents développeurs qui sont intéressés par les résultats. Les styles de codage incohérents sont une nuisance mineure pour les développeurs incroyables. Ils sont productifs avec ou sans cohérence. Certes, s'ils rencontrent un code incohérent, ils vous poseront des questions sur le courantstandard et respectez-le. Cependant, ils n'insisteront pas pour mettre à jour chaque ligne de code du projet à la norme actuelle. Ils n'insistent pas parce qu'ils ont vu des bonnes pratiques se multiplier. La bonne façon de faire quelque chose aujourd'hui n'est pas la même que la bonne façon de faire quelque chose demain. Si c'était le cas, vos normes de codage n'évolueraient pas. Donc, si la façon correcte de faire quelque chose change avec le temps, peut-être que notre définition de «correct» est cassée.

Cela ne veut pas dire que les normes n'ont pas d'importance. N'oubliez pas que l'objectif des normes est la productivité. Si vous ne pouvez pas garantir que la réécriture d'une nouvelle norme sera rentable à long terme, ne perdez pas de temps dessus. Il est beaucoup plus facile de justifier une nouvelle norme dans un code nouveau ou refactorisé. L'élégance est cool mais ce n'est pas la même chose que les résultats.

Ce que nous faisons est aussi une évolution (pas une révolution) pour la base de code, nous utiliserions la norme mise à jour quand;

• un nouveau code est écrit
• le code est refactorisé
• les bugs sont corrigés
• de nouvelles portions sont ajoutées à une classe existante

Il est important que votre base de code soit cohérente, donc si le changement ouvre une possibilité de confusion entre le code de style "ancien" et "nouveau", il pourrait être préférable de réserver la mise à jour de votre norme de codage au prochain projet.

Tout d'abord, je n'inclurais pas ces «meilleures pratiques» dans les (partie obligatoire des) directives de codage. Ils pourraient être mentionnés, par exemple dans une annexe, comme exemple de la façon dont vous pourriez faire quelque chose, mais pas que cela devrait être fait de cette façon.

Cela dit, il y a deux cas à considérer pour les modifications d'une norme de codage:

1. Modifications sans impact sur la lisibilité, même si l'ancien et le nouveau code sont mélangés sans mettre à jour l'ancien code.
   Ces modifications peuvent être ajoutées immédiatement à la norme de codage et doivent être prises en compte pour tout code nouveau et modifié. L'ancien code devrait être adapté progressivement selon le temps et les changements dans ce domaine.
   Un exemple de ce type de changement, que j'ai réellement rencontré, est un changement dans la déclaration de copyright au début de chaque fichier.
2. Modifications qui détériorent la lisibilité si l'ancien et le nouveau code sont mélangés.
   Ces modifications doivent être appliquées à la base de code entière en une seule fois, ou doivent être reconsidérées si elles sont vraiment nécessaires.
   Un exemple de ce type de changement est un changement d'indentation ou de mise en place d'accolade.

Cela doit vraiment dépendre du type de produit que vous créez:

• Pour une application commerciale écrite en interne et que vous déployez auprès de clients, votre objectif principal doit être le chiffre d'affaires. Tant que l'ancien code n'est pas bogué, peu importe que de nouvelles normes de codage aient évolué, vous devez vous concentrer sur l'ajout de nouvelles fonctionnalités à votre produit et générer des revenus. Bien sûr, adapter les nouvelles normes de codage pour un nouveau code, mais changer tout le code existant serait une perte de temps.
• Si vous développez un produit open source, ou un produit où plusieurs entreprises (peut-être même vos clients) verront et travailleront sur la source, alors la lisibilité du code devient beaucoup plus importante et dans ce cas, une décision raisonnable doit être prise en fonction de la quantité de code à modifier et les avantages à long terme. Bien que nous aimions tous le joli code, la réalité est que pour une entreprise commerciale traitant de sources fermées, l'adaptation constante de nouvelles normes signifie que vous perdrez des revenus à long terme.

Personnellement, je choisirais de conserver les anciens codes tels quels et de suivre les nouvelles normes, quoi que vous fassiez. Plus précisément, je n'utiliserai pas de double standard dans old.c. Mais si je vais créer new.c, il peut utiliser les nouvelles syntaxes raffinées :)