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.