Que pouvez-vous faire pour une base de code existante qui aura le plus grand impact sur l'amélioration de la qualité?

Question

Alors que vous travaillez dans une base de code héritée, qu'est-ce qui aura le plus d'impact au fil du temps et qui améliorera la qualité de la base de code?

• Supprimer le code inutilisé
• Supprimer le code dupliqué
• Ajouter des tests unitaires pour améliorer la couverture de test lorsque la couverture est faible
• Créez une mise en forme cohérente dans tous les fichiers
• Mettre à jour le logiciel tiers
• Réduit les avertissements générés par les outils d'analyse statique (i.e.Findbugs)

La base de code a été écrite par de nombreux développeurs possédant différents niveaux d’expertise au cours de nombreuses années, avec de nombreux domaines non testés et certains testables sans passer beaucoup de temps à écrire des tests.

Answer 1

• Lisez le livre de Michael Feather " Travailler efficacement avec le code hérité & ;

Ceci est un excellent livre.

Si vous n'aimez pas cette réponse, le meilleur conseil que je puisse vous donner serait:

• Tout d'abord, arrêtez de créer le nouveau code hérité [1]

[1]: Code hérité = code sans tests unitaires, donc inconnu

Changer le code existant sans une suite de tests automatisés est dangereux et irresponsable. Sans une bonne couverture des tests unitaires, vous ne pouvez absolument pas savoir ce que ces changements auront comme conséquence. Feathers recommande un "étranglement". approchez-vous où vous isolez les zones de code que vous devez modifier, écrivez des tests de base pour vérifier les hypothèses de base, effectuez de légères modifications, sur la base de tests unitaires, puis effectuez une analyse à partir de là.

REMARQUE: je ne dis pas que vous devez tout arrêter et passer des semaines à écrire des tests pour tout. Bien au contraire, testez simplement les domaines que vous devez tester et travailler à partir de là.

Jimmy Bogard et Ray Houston ont réalisé une intéressante projection d’écran sur un sujet très similaire à celui-ci: http: // www .lostechies.com / blogs / jimmy_bogard / archive / 2008/05/06 / pablotv-éliminant-statique-dépendances-screencast.aspx

Answer 2

Je travaille avec une ancienne application LOC 1M écrite et modifiée par environ 50 programmeurs.

* Remove unused code

Presque inutile ... juste l'ignorer. Vous ne recevrez pas un grand retour sur investissement (ROI) de celui-là.

* Remove duplicated code

En fait, quand je répare quelque chose, je cherche toujours les doublons. Si j'en trouve, je mets une fonction générique ou commente toutes les occurrences de code pour les dupliquer (parfois, l'effort de mettre une fonction générique n'en vaut pas la peine). L'idée principale est que je déteste faire la même chose plus d'une fois. Une autre raison est qu'il y a toujours quelqu'un (peut-être moi) qui oublie de vérifier s'il se produit un autre événement ...

* Add unit tests to improve test coverage where coverage is low

Les tests unitaires automatisés sont merveilleux ... mais si vous avez un arriéré important, la tâche en elle-même est difficile à promouvoir, sauf en cas de problème de stabilité. Allez avec la partie sur laquelle vous travaillez et espérez que vous aurez une couverture décente dans quelques années.

* Create consistent formatting across files

IMO, la différence de formatage fait partie de l'héritage. Cela vous donne un indice sur qui ou quand le code a été écrit. Cela peut vous aider à comprendre comment se comporter dans cette partie du code. Faire le travail de reformatage, ce n’est pas amusant et cela n’apporte aucune valeur à votre client.

* Update 3rd party software

Faites-le uniquement s'il existe de nouvelles fonctionnalités vraiment intéressantes ou si la version que vous possédez n'est pas prise en charge par le nouveau système d'exploitation.

* Reduce warnings generated by static analysis tools

Cela peut en valoir la peine. Un avertissement peut parfois cacher un bug potentiel.

Answer 3

Ajoutez des tests unitaires pour améliorer la couverture des tests. Avoir une bonne couverture de test vous permettra de refactoriser et d’améliorer les fonctionnalités sans crainte.

Il existe un bon livre écrit par l'auteur de CPPUnit, Utilisation efficace du code hérité .

Ajouter des tests au code existant est certes plus difficile que de les créer à partir de zéro. Le concept le plus utile que j’ai retenu du livre est la notion de "coutures", que Feathers définit comme

  

"Un lieu où vous pouvez modifier le comportement de votre programme sans le modifier à cet endroit."

Parfois, il vaut la peine de refactoriser pour créer des joints qui faciliteront les futurs tests (ou tout d’abord possible). Le google Le blog de test contient plusieurs articles intéressants sur le sujet, qui traitent principalement du processus de Injection de dépendance .

Answer 4

Je dirais que «supprimer le code dupliqué» signifie assez que vous devez extraire le code et le résumer pour qu'il puisse être utilisé à plusieurs endroits - ceci, en théorie, rend les bogues plus faciles à corriger, car vous n'avez qu'à en réparer un morceau de code, par opposition à de nombreux morceaux de code, pour y réparer un bogue.

Answer 5

Je peux comprendre cette question, car j'ai actuellement sur mon genoux l'une de ces bases de code de la vieille école. Ce n'est pas vraiment un héritage, mais ce n'est certainement pas la tendance des années.

Je vais vous dire les choses que j'aimerais beaucoup y remédier car elles me plantent tous les jours:

• Documentez les variables d'entrée et de sortie
• Refactorisez les noms de variable pour qu’ils signifient réellement autre chose et un préfixe de notation hongrois suivi d’un acronyme de trois lettres avec une signification obscure. CammelCase est la voie à suivre.
• J'ai peur de changer de code car cela affectera des centaines de clients qui utilisent le logiciel et quelqu'un remarquera même l'effet secondaire le plus obscur. Tout test de régression pouvant être répété serait une bénédiction puisqu'il n'y en a plus maintenant.

Le reste est vraiment de la cacahuète. Ce sont les principaux problèmes avec une base de code héritée, ils prennent vraiment beaucoup de temps.

Answer 6

Je dirais que cela dépend en grande partie de ce que vous voulez faire avec le code hérité ...

S'il reste indéfiniment en mode maintenance et qu'il fonctionne correctement, ne rien faire est votre meilleur choix. "Si ce n'est pas le cas, ne le corrigez pas."

Si cela ne fonctionne pas bien, supprimer le code inutilisé et refactoriser le code dupliqué facilitera beaucoup le débogage. Cependant, je ne ferais que ces modifications sur le code erroné.

Si vous envisagez de passer à la version 2.0, ajoutez des tests unitaires et nettoyez le code que vous allez générer

.

Answer 7

Bonne documentation. En tant que personne qui doit maintenir et étendre le code hérité, c'est le problème numéro un. Il est difficile, voire carrément dangereux de changer de code que vous ne comprenez pas. Même si vous avez la chance de recevoir du code documenté, dans quelle mesure êtes-vous sûr que la documentation est correcte? Qu'il couvre toute la connaissance implicite de l'auteur original? Qu'il parle à tous les "astuces" et les cas de bord?

Une bonne documentation est ce qui permet à ceux qui ne sont pas l’auteur original de comprendre, de réparer et d’étendre même un code incorrect. Je prendrai du code piraté et pourtant bien documenté que je comprend tout code de la semaine parfait mais impénétrable.

Answer 8

La plus grande chose que j'ai faite au code hérité avec lequel je dois travailler est de créer une véritable API autour de ce code. C’est une API COBOL de style années 1970 sur laquelle j’ai construit un modèle d’objet .NET, de sorte que tout le code non sécurisé se trouve au même endroit, que toute la traduction entre les types de données natifs de l’API et les types de données .NET se trouve au même endroit, Les méthodes primaires renvoient et acceptent les ensembles de données, etc.>.

C’était immensément difficile à faire correctement et il ya encore quelques défauts que je connais. Ce n'est pas terriblement efficace non plus, avec toute la triage qui se passe. Mais d’un autre côté, je peux créer un DataGridView qui renvoie les données à une application vieille de 15 ans qui conserve ses données dans Btrieve (!) Pendant environ une demi-heure et cela fonctionne. Lorsque des clients me soumettent des projets, mes estimations sont exprimées en jours et en semaines plutôt qu'en mois et en années.

Answer 9

Comme un parallèle avec ce que Josh Segall a dit, je dirais commenter l’enfer. J'ai travaillé sur plusieurs systèmes hérités très volumineux qui ont été abandonnés sur mes genoux et j'ai constaté que le plus gros problème était de garder trace de ce que j'avais déjà appris sur une section de code en particulier. Une fois que j'ai commencé à placer des notes au fur et à mesure, en incluant "To Do" notes, j'ai cessé de re-comprendre ce que j'avais déjà compris. Je pourrais ensuite me concentrer sur la manière dont ces segments de code circulent et interagissent.

Answer 10

Je dirais qu'il suffit de le laisser seul pour la plupart. Si ce n'est pas cassé alors ne le répare pas. S'il est cassé, corrigez et améliorez la partie du code qui est cassée et le code qui l'entoure immédiatement. Vous pouvez utiliser la douleur du bogue ou une fonctionnalité qui manque cruellement pour justifier les efforts et les dépenses consacrés à l'amélioration de cette partie.

Je ne recommanderais aucun type de réécriture, de refactorisation, de reformatage ou de mise en place de tests unitaires en gros qui ne soit pas dicté par les besoins réels des utilisateurs ou des entreprises.

Si vous avez la possibilité de réparer quelque chose, faites-le correctement (la possibilité de le faire correctement du premier coup peut déjà être passée, mais puisque vous touchez à nouveau cette partie, vous pourriez aussi bien le faire à temps) et cela inclut tous les éléments que vous avez mentionnés.

Donc, en résumé, vous ne devez faire aucune ou quelques petites choses. Vous devriez tout faire, mais en petites portions et de manière opportuniste.

Answer 11

En retard pour le parti, mais ce qui suit peut être utile si une fonction / méthode est utilisée ou référencée souvent:

• Les variables locales ont souvent tendance à être mal nommées dans le code hérité (souvent en raison de leur étendue élargie lorsqu'une méthode est modifiée, et non mises à jour pour refléter cela). Si vous les renommez conformément à leur objectif réel, vous pourrez clarifier le code hérité.
• Même si vous modifiez légèrement la méthode, vous pourrez faire des merveilles - par exemple, placer toutes les clauses d'un if sur une seule ligne.
• Il pourrait déjà y avoir des commentaires de code périmés / déroutants. Supprimez-les s'ils ne sont pas nécessaires ou modifiez-les si vous devez absolument le faire. (Bien entendu, je ne préconise pas la suppression de commentaires utiles, mais uniquement ceux qui constituent un obstacle.)

Celles-ci peuvent ne pas avoir l'impact de titre énorme que vous recherchez, mais elles présentent un faible risque, en particulier si le code ne peut pas être testé à l'unité.