Comment s'opposer à la baisse des normes de qualité pour la base de code héritée?
Nous avons ici une grande base de code héritée avec un mauvais code que vous ne pouvez pas imaginer.
Nous avons défini maintenant certaines normes de qualité et souhaitons les respecter dans une base de code entièrement nouvelle, mais aussi si vous touchez le code hérité.
Et nous appliquons ceux avec Sonar (outil d'analyse de code), qui a déjà quelques milliers de violations.
Maintenant, la discussion est venue pour réduire ces violations pour l'héritage. Parce que c'est un héritage.
La discussion porte sur les règles de lisibilité. Comme le nombre de si/imbriqués imbriqués.
Maintenant, comment puis-je m'opposer à une baisse de notre qualité de codage sur le code hérité?
Le code n'est qu'un moyen pour parvenir à une fin. Ce que peut être cette fin varie, mais c'est généralement le profit.
Si c'est du profit; puis pour argumenter avec succès tout ce que vous voulez montrer que cela améliorera le profit - par exemple en augmentant les ventes, en réduisant les coûts de maintenance, en réduisant les coûts de développement, en réduisant les salaires, en réduisant les coûts de recyclage, etc. Si vous ne pouvez pas/ne montrez pas que cela améliorera les bénéfices; alors vous dites simplement que ce serait une façon amusante de jeter de l'argent dans les toilettes.
Moi, moi-même et moi avons été à la fois producteur et mainteneur de code hérité. Si votre outil génère "des milliers de violations" (voire des centaines d'ailleurs), oubliez l'outil, il est inapplicable à la situation ...
Je suppose que les développeurs d'origine ont disparu depuis longtemps et ne sont pas disponibles pour discussion. Donc, personne autour ne comprend le pourquoi et le pourquoi du style de conception et de codage. Corriger des centaines ou des milliers de violations ne sera pas une question de réécrire ici et là quelques lignes de code. Au lieu de cela, il nécessite sans aucun doute une refactorisation/re-décomposition fonctionnelle. Vous essayez de faire cela à n'importe quelle grande base de code existante, sans comprendre intimement sa conception actuelle, et vous êtes obligé d'introduire un tout nouvel ensemble de bogues/problèmes/etc. Juste une nouvelle boîte de vers encore pire que celle que vous avez maintenant (ou pire que votre outil >> pense << que vous avez maintenant).
La seule approche raisonnable pour lutter contre "des milliers de violations" serait de réécrire à partir de zéro. Un effort long et coûteux, et presque impossible à vendre à la direction. Et dans ce cas, ils ont probablement raison ...
Le code hérité ne nécessite généralement que des ajustements. Comme pour l'an 2000, ou lorsque les actions sont passées de 256 à la décimale. J'ai fait des tas de ces deux cr * p. Et plein d'autres trucs similaires. C'est généralement assez "précis" en ce sens que vous pouvez "lire" le style parfois mauvais, la mauvaise décomposition fonctionnelle, la mauvaise etc., et localiser la collection d'endroits qui doivent être modifiés. Et puis, ce qui se passe "entre ces endroits", c'est-à-dire quel est le flux le plus élevé, peut rester un mystère pour vous. Assurez-vous simplement de comprendre la fonctionnalité localisée que vous modifiez, puis testez, testez, testez les effets secondaires, etc., vos connaissances localisées ne seront pas en mesure d'anticiper.
Si vous ne pouvez pas voir votre chemin à travers un code comme celui-ci, alors vous n'êtes peut-être pas la meilleure personne pour conserver le code hérité. Certaines personnes peuvent commencer avec un écran vide et écrire de beaux programmes, mais ne peuvent pas commencer avec une grande base de code du code d'autres personnes et le maintenir. D'autres personnes peuvent conserver le code, mais ne peuvent pas recommencer à zéro. Certains peuvent faire les deux. Assurez-vous que les bonnes personnes gèrent votre ancien code.
Parfois, vous voudrez peut-être reconcevoir et réécrire votre base de code héritée à partir de zéro lorsque les exigences commerciales (ou autres) changent à un point tel que les "ajustements" du siège du pantalon ne peuvent tout simplement plus s'adapter aux exigences modifiées. . Et à ce stade, vous pourriez tout aussi bien commencer par rédiger un nouveau document d'exigences fonctionnelles en premier lieu, en vous assurant que toutes les parties prenantes sont à bord. C'est fondamentalement un tout nouveau jeu de balle.
La seule et unique >> mauvaise << chose à faire est d'essayer de traiter la maintenance du code hérité de la même manière que pour les nouveaux développements. Et cette mauvaise chose semble être exactement le chemin que vous aimeriez emprunter :) Prenez ma parole, ce n'est pas ce que vous voulez faire.
La question n'est pas de savoir si ce code est bon ou mauvais. La question est de savoir quel avantage vous tirez de combien d'investissement.
Vous disposez donc d'un outil qui trouve des milliers de choses qu'il n'aime pas. Vous avez le choix d'ignorer les résultats de l'outil ou d'investir du travail pour changer des milliers de choses. Ça fait beaucoup de choses. Les gens ne seront pas concentrés, pas en faisant les changements, pas en les examinant, et cela ne sera pas correctement testé car il faut des années pour comprendre comment tester (ou simplement essayer) chaque changement, donc il y aura des bugs. Donc, jusqu'à ce que vous trouviez et corrigiez ces bogues, vous avez investi beaucoup de temps et d'argent avec un résultat global négatif.
D'un autre côté, les outils peuvent trouver des choses non seulement "qu'ils n'aiment pas", mais qui sont des bogues ou des bogues potentiels. Si le code hérité est toujours largement utilisé, alors le bon outil peut réellement trouver des bogues. Donc, activer les avertissements du compilateur un par un, vérifier s'ils sont utiles (tous ne sont pas utiles) et corriger ces avertissements peut être utile.
Si ce n'est pas cassé, ne le réparez pas
Cela devrait pratiquement être tatoué sur tous les développeurs et gestionnaires de logiciels afin qu'ils ne l'oublient jamais.
Oui, il rompt toutes les conventions de codage modernes. Oui, il est écrit en FORTRAN-77 avec un wrapper en C afin qu'il puisse être invoqué depuis Python. Oui, ce sont des GOTO non structurés. Oui, il y a un sous-programme de trois mille lignes. Oui, les noms de variables n'ont de sens que pour un Croate. etc.
Mais s'il a été testé dans la colère pendant plus d'une décennie ou plus et est passé, laissez-le tranquille! Si la modification requise est petite, gardez-la aussi petite et aussi locale que possible. Toute autre chose risque davantage de casser quelque chose qui n'a pas besoin d'être réparé.
Bien sûr, parfois, vous trouvez que c'est vraiment un kluge non maintenable et que la seule façon d'accommoder la "petite" modification est de réécrire à partir de zéro. Dans ce cas, vous devez revenir à celui qui demande le changement et lui dire ce qu'il en coûtera (à la fois en dollars ou en heures-homme pour la réécriture, et en sueur de sang et en larmes pour les nouveaux bogues inévitables).
Il y a longtemps, il y a eu une série de pannes sur l'un des disques durs de Digital. Ils ont fini par se rappeler et les remplacer tous à gord sait quel coût. Apparemment, il y avait une goutte de colle tenant un filtre à l'intérieur du HDA. Le manifeste d'ingénierie disait de la colle "Non paramétriquement spécifié, AUCUN SUBSTITUT ACCEPTABLE". Un compteur de haricots "enregistré" sous un cent par lecteur de disque en achetant une autre colle. Il a dégagé une vapeur à l'intérieur du HDA qui a tué le lecteur après quelques années de service. Il n'a pas été cassé jusqu'à ce qu'il le corrige. Sans doute "ce n'était qu'un tout petit changement ..."
Il est certainement inutile de réduire le niveau de qualité du code hérité. Il n'est pas non plus nécessaire de corriger les avertissements immédiatement. Assurez-vous simplement que tous vos "nouveaux" changements dans chaque composant de votre projet respectent des normes de qualité élevées. C'est à dire. aucun commit ne devrait augmenter le nombre d'avertissements.
Il s'agit d'une approche simple et uniforme.
Il permet à l'ancien code hérité de fonctionner tel quel (car aucune modification inutile n'est apportée). Il garantit que le nouveau code est de haute qualité. Aucun coût supplémentaire n'est impliqué.
Contrôle des risques….
- Le code dans la grande base de code héritée a été testé au moins par l'utilisation réelle du logiciel.
- Il est très différent que le code dans la grande base de code héritée soit couvert par des tests unitaires automatisés.
- Par conséquent, toute modification du froid dans la grande base de code héritée présente un risque élevé.
Coût….
- Faire passer du code à un vérificateur de code pendant que vous écrivez le code est bon marché
- Le faire à un stade ultérieur est beaucoup plus coûteux
Avantage
Vous espérez que le respect des normes de codage conduit à une meilleure conception du code.
Mais il est très improbable que quelqu'un passe plusieurs semaines à changer de code juste pour supprimer les avertissements d'un outil de vérification standard de codage, ce qui améliorera la conception du code.
- Le code simple est plus clair et a tendance à être plus facile à comprendre, à moins que le code complexe ne soit divisé en méthodes courtes par quelqu'un qui ne le comprend pas…
Recommandation….
- S'il s'avère qu'une section de code contient beaucoup de bogues ou a besoin de beaucoup de modifications pour ajouter des fonctions supplémentaires, passez le temps à 100% à comprendre ce qu'elle fait.
- Passez également du temps à ajouter un bon test unitaire à cette section de code, car vous en avez un besoin avéré.
- Vous pouvez ensuite envisager de refactoriser le code (vous comprenez maintenant) afin qu'il passe également la nouvelle vérification de code.
Expérience personnelle….
- Au cours des 20 autres années de travail en tant que programmeur, je n'ai jamais vu de cas où le changement aveugle de l'ancien pour supprimer toutes les sorties d'un nouveau vérificateur de normes de codage aurait eu des avantages en plus d'augmenter le revenu des entrepreneurs qui ont été chargés de le faire.
- De même, lorsque l'ancien code doit être fait pour passer les revues de code (TickIt/ISO 9001 mal fait), il fallait que l'ancien code ressemble à la nouvelle norme de codage.
- J'ai vu de nombreux cas où l'utilisation d'outils de vérification standard de codage sur un nouveau code a eu de grands avantages en réduisant les coûts permanents.
- Je n'ai jamais vu une entreprise échouer aux coûts de maintenance de l'ancien code utilisé dans un produit avec beaucoup de clients.
- J'ai vu une entreprise échouer en raison du manque de revenus des clients en étant trop lent à commercialiser….
La discussion porte-t-elle sur l'abaissement des seuils de l'outil? ... ou ai-je mal compris. C'est écrit d'une manière déroutante. Si ce n'est pas le cas, veuillez jeter ma réponse.
À mon humble avis, ce serait une bonne idée de réduire la sensibilité de l'outil. Pourquoi? Parce que cela mettrait en évidence les morceaux de code les plus velus. L'alternative produit des rapports avec des milliers de violations, devenant inutiles par sa taille.
... à part ça, il suffit d'en parler avec les personnes impliquées et d'entendre leurs raisons aussi.
J'essaierais de séparer le code hérité du nouveau code propre. Dans par exemple Eclipse, vous pouvez le faire en les mettant dans différents projets qui utilisent les uns les autres. projet "propre" et projet "hérité".
De cette façon, vous pouvez analyser les deux projets dans le sonar avec des normes de qualité différentes. Les normes ne devraient différer que par l'importance des règles. Les règles elles-mêmes devraient être les mêmes. De cette façon, vous pouvez voir dans le projet "hérité" ce qui doit être "corrigé" pour répondre aux normes du projet "propre".
Chaque fois que vous avez réussi à soulever un code hérité aux normes plus élevées, vous pouvez le déplacer vers le projet "propre".
Dans le travail quotidien, vous ne pouvez pas accomplir pour soulever chaque classe que vous touchez aux normes du projet "propre" en raison du décalage du temps. Mais vous devriez essayer d'y arriver par petites étapes en essayant d'améliorer un peu le code hérité chaque fois que vous le touchez.