Comment s'opposer à la baisse des normes de qualité pour la base de code héritée? [fermé]

28

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

keiki
la source
2
est la discussion sur l'abaissement des seuils de l'outil? ... ou ai-je mal compris. C'est écrit d'une manière déroutante.
dagnelies
4
La question comporte des parties très floues. "réduire ces violations" - entendez-vous réduire le nombre réel de violations (en réécrivant l'ancien code), le nombre de règles testées par Sonar dans la base de code héritée ou le nombre de règles de votre norme de codage que vous souhaitez suivre lors de la modification de quelque chose dans le code hérité?
Doc Brown
4
Nous avons également un produit hérité d'une qualité de code terrible. Puisqu'il sera remplacé par le nouveau produit, il n'y a presque aucune valeur à nettoyer cet ancien code. Cela signifie: nous acceptons une norme inférieure dans la base de code héritée.
Bernhard Hiller
4
@keiki: toujours pas clair: la nouvelle base de code est-elle suffisamment séparée pour avoir des règles de validation différentes pour l'ancien et le nouveau code? Qu'en est-il des parties que vous modifiez dans la base de code héritée? Votre problème est-il que le fait de soulever les pièces modifiées à la norme la plus élevée entraîne trop d'efforts, ou est-ce que vous ne pouvez pas séparer ces pièces dans la validation de Sonar, pour permettre de valider uniquement ces pièces modifiées dans leur intégralité?
Doc Brown

Réponses:

73

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.

Brendan
la source
15
Je crois qu'il y a une autre dimension dans cette discussion qui est le professionnalisme, dans de nombreuses professions, si votre patron vous demande de couper les coins ronds, vous pouvez refuser de le faire sur la base d'un motif moral (parfois même la loi vous soutient), je ne le fais pas comprendre pourquoi les développeurs de logiciels devraient se comporter différemment.
Alessandro Teruzzi
21
@AlessandroTeruzzi Vous pouvez refuser de faire quoi que ce soit pour des motifs moraux (personnels) partout sans égard au professionnalisme. Cela ne garantit pas que vous continuerez à travailler à cet endroit.
Kromster dit soutenir Monica le
De plus, les bases de code étant souvent extrêmement compliquées, il serait difficile de prouver l'une des choses mentionnées, même si un développeur chevronné sait par expérience que couper les coins deviendra coûteux à long terme.
mkataja
17
Rien de mal dans cette réponse, mais néanmoins, il est IMHO pas utile pour la plupart des situations du monde réel. L'amélioration de la qualité d'une base de code réduira souvent les coûts de maintenance, notamment à long terme, mais ces effets sont rarement quantifiables. C'est donc souvent une décision stratégique.
Doc Brown
2
@DocBrown Je suis provisoirement d'accord, mais je pense que le développement basé sur le nombre de nids-ifs, à la OP, n'est pas une approche efficace pour améliorer une base de code héritée.
brian_o
44

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.

John Forkosh
la source
2
Cela répond à une question «Faut-il réécrire l'héritage». Mais OP ne demande pas comment corriger les avertissements ou si la réécriture doit se produire. La question portait sur la norme de qualité - essentiellement une exigence pour chaque changement de ne pas augmenter le nombre d'avertissements de validation.
Basilevs
9
Cela répond directement à la question, qui ne concerne pas la réécriture. L'OP veut plaider en faveur du «traitement de la maintenance du code hérité de la même manière que pour les nouveaux développements». Cette réponse dit "WOAH! Tu ne devrais pas faire ça!" Peut-être pas la réponse du PO ou que vous vouliez entendre, mais complètement sensible à la question.
Jonathan Eunice
1
@Basilevs (et @ JonathanEunice). Ce que Jonathan a dit. Et notez que j'ai commencé par dire directement "oubliez l'outil, il ne s'applique pas à la situation", ce qui répond directement à la question, bien que négativement. Mais comme le dit le dicton, si vous voulez critiquer, offrez une critique constructive. Je ne pouvais donc pas simplement dire «ne fais pas ça». J'ai également dû suggérer quoi faire à la place (et cela a été un peu plus long que je ne l'avais prévu lorsque j'ai commencé à l'écrire).
John Forkosh
1
Lorsque je travaille avec des projets de code hérités, j'aime parfois concevoir une couche d'interface qui se situe entre l'ancien et le nouveau code. Cela permet une division nette entre les anciennes et les nouvelles pièces, et facilite le dépannage des nouvelles pièces que si elles étaient glommées avec un tas de code que je ne comprends pas.
supercat
@supercat Si cela peut être fait, c'est certainement une bonne approche. Mais en rappelant divers de mes projets de correction y2k, il vous suffisait de "plonger" au milieu du code existant et de jouer avec. Pas de (re) factorisation possible en ancien / nouveau possible (sans réécriture >> massive <<). Par exemple, plutôt que d'ajouter deux octets aux champs de date pour une année au format ccyy de quatre octets, nécessitant des mises à jour massives de bases de données massives, interprétez simplement yy> 50 comme 19yy et yy <= 50 comme 20yy. Mais la seule implémentation sensée pour cela implique beaucoup de petits changements à chaque endroit où yy est utilisé.
John Forkosh
13

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.

gnasher729
la source
2
Une fois, je suis arrivé à un projet qui s'est fait rapidement (ignoré les avertissements du compilateur, etc.). Le projet était un gâchis, il y avait un bug. Un certain nombre débordait. L'équipe cherchait depuis 2 semaines. J'ai configuré l'environnement du compilateur avec tous les indicateurs d'avertissement (le nombre est passé de 500 à plusieurs milliers d'avertissements). J'ai parcouru tous les avertissements. Après seulement 3h, je n'ai eu aucun avertissement. Pour une raison quelconque, le code a fonctionné. Mais nous ne savions pas pourquoi. J'ai engagé le code à chaque changement dans ma succursale. Après un peu de recherche, je l'ai trouvé. Une fonction déclarée implicitement, qui a fait perdre à C la valeur de retour.
CodeMonkey
7

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 ..."

nigel222
la source
2
Voulez-vous dire Western Digital ? S'agit-il de ce rappel ? Pouvez-vous fournir des sources pour sauvegarder votre histoire?
Courses de légèreté avec Monica le
3
À peu près sûr, il signifie Digital Equipment Corp dont une faible lueur peut encore vivre au cœur noir de Hewlett Packard.
John Hascall
1
Oui - numérique également connu sous le nom de DEC.
nigel222
5

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

Basilevs
la source
Je pourrais faire objection au mot jamais à la fin de votre premier paragraphe. Si, par exemple, quelques dizaines de lignes de changements sont nécessaires au milieu d'une fonction de plusieurs centaines de lignes dont le style génère des avertissements, je vais quand même essayer de suivre le style existant, tant qu'il n'est pas défectueux degré d'illisibilité. Je veux rendre la vie aussi facile que possible pour le prochain pauvre gars qui vient et doit traverser tout ça. Mélanger les styles sans autre raison que de satisfaire aux normes de certains outils est en soi un mauvais style. Au lieu de cela, suivez les normes / style d'origine autant que possible.
John Forkosh du
J'ai dit commit, pas line ou function. Soi-disant, vous nettoyez suffisamment de dégâts dans votre édition, pour avoir un budget pour un emplacement de problème.
Basilevs
3

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 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.

  • 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 changements 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 les revenus 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), cela nécessitait 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 continus.
  • 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….
Ian
la source
0

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.

dagnelies
la source
0

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.

MrSmith42
la source