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 faire 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é?
Réponses:
Le code n'est qu'un moyen pour parvenir à une fin. Ce que pourrait être cette fin varie, mais c'est généralement le profit.
Si c'est du profit; puis argumenter avec succès tout ce que vous voulez montrer que cela améliorera les bénéfices - 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 va améliorer les bénéfices; alors vous dites simplement que ce serait une façon amusante de jeter de l'argent dans les toilettes.
la source
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 de l'entreprise (ou d'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 écrire 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 :) Croyez-moi, ce n'est pas ce que vous voulez faire.
la source
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 ayez trouvé et corrigé 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 qu'ils "apprécient" non seulement, 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. Il est donc utile d'activer les avertissements du compilateur un par un, de vérifier s'ils sont utiles (tous ne sont pas utiles) et de corriger ces avertissements.
la source
Si ce n'est pas cassé, ne le répare 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 appelé 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 ..."
la source
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 qu'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é.
la source
Contrôle des risques….
Coût….
Avantage
Vous espérez que le respect des normes de codage conduit à une meilleure conception du code.
Mais il est très peu probable que quelqu'un passe plusieurs semaines à changer de code juste pour supprimer les avertissements d'un outil de vérification de la norme de codage, ce qui améliorera la conception du code.
Recommandation….
Expérience personnelle….
la source
La discussion porte-t-elle sur la baisse 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.
la source
J'essaierais de séparer le code hérité du nouveau code propre. Par exemple, dans Eclipse, vous pouvez le faire en les mettant dans différents projets qui s’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 élever 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.
la source