Que pouvez-vous faire à un héritage de la base de code qui auront le plus d'impact sur l'amélioration de la qualité?

Question

Comme vous travaillez dans un héritage à la base de ce qui aura le plus d'impact au fil du temps qui permettra d'améliorer la qualité de la base de code?

• Supprimer code inutilisé
• Supprimer le code dupliqué
• Ajouter des tests unitaires afin d'améliorer la couverture de test, où la couverture est faible
• Créer une mise en forme cohérente à travers les fichiers
• Mise à jour de la 3ème partie logiciel
• Réduire les avertissements générés par les outils d'analyse statique (j'.e.Findbugs)

Le code a été écrit par de nombreux développeurs avec différents niveaux d'expertise depuis de nombreuses années, avec beaucoup de zones de non testés et certains invérifiables, sans dépenser beaucoup de temps sur l'écriture de tests.

Answer 1

• Lire Michael Plume du livre "Travailler efficacement avec le Code existant"

C'est un GRAND livre.

Si vous n'aimez pas la réponse, alors le meilleur conseil que je peux donner:

• Tout d'abord, arrêter de faire du nouveau code legacy[1]

[1]: l'Héritage, code = code sans tests unitaires et par conséquent d'un inconnu

Modification du code existant sans un test automatisé suite en place est dangereux et irresponsable. Sans une bonne couverture de tests unitaires, tu ne peux pas savoir quel effet de ces modifications. Plumes recommande une "mainmise" approche où vous isoler les zones de code à modifier, écrire des tests pour vérifier les hypothèses de base, faire de petits changements soutenus par les tests unitaires, et de travailler à partir de là.

NOTE: je ne dis pas que vous devez tout arrêter et de passer des semaines à écrire des tests pour tout. Bien au contraire, il suffit de tester autour de la domaines où vous avez besoin de tester et de travailler à partir de là.

Jimmy Bogard et Ray Houston a fait un intéressant écran exprimés sur un sujet très similaire à ceci: http://www.lostechies.com/blogs/jimmy_bogard/archive/2008/05/06/pablotv-eliminating-static-dependencies-screencast.aspx

Answer 2

Je travaille avec un héritage 1M LOC demande écrite et modifié par environ 50 programmeurs.

* Remove unused code

Presque inutile... juste l'ignorer. Vous ne obtenir un grand Retour Sur Investissement (ROI) à partir de celui-ci.

* Remove duplicated code

En fait, quand je fixe quelque chose que j'ai toujours à la recherche de doublons. Si j'ai trouvé certains j'ai mis une fonction générique ou un commentaire tous les code d'événement de duplication (parfois, l'effort de mettre une fonction générique n'est pas la peine). L'idée principale, c'est que je déteste faire la même action plusieurs fois. Une autre raison est parce qu'il y a toujours quelqu'un (peut-être moi) qui oubliez pas de vérifier pour d'autres occurrence...

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

Les tests unitaires automatisés est merveilleux... mais si vous avez un gros carnet de commandes, la tâche elle-même est difficile à promouvoir, sauf si vous avez des problème de stabilité. Aller à la partie sur laquelle vous travaillez et de l'espoir que dans quelques années, vous avez une protection décente.

* Create consistent formatting across files

IMO la différence dans la mise en forme est une partie de l'héritage. Il donne un indice sur qui ou lorsque le code a été écrit. Cela peut vous a donné des indices sur la façon de se comporter dans cette partie du code. De faire le travail de reformatage, n'est-ce pas amusant et il ne faut pas donner n'importe quelle valeur pour votre client.

* Update 3rd party software

Faire cela seulement si il y a des nouvelles vraiment sympa de la fonctionnalité ou la version que vous avez n'est pas pris en charge par le nouveau système d'exploitation.

* Reduce warnings generated by static analysis tools

Il peut valoir la peine. Parfois avertissement peut en cacher un bug potentiel.

Answer 3

Ajouter des tests unitaires afin d'améliorer la couverture de test. Avoir une bonne couverture de test va vous permettre de revoir et d'améliorer les fonctionnalités sans crainte.

Il y a un bon livre sur cette écrit par l'auteur de CPPUnit, de Travailler de façon Efficace avec le Code existant.

L'ajout de tests de code legacy est certianly plus difficile que de les créer à partir de zéro. Le concept le plus utile que j'ai pris à l'écart de ce livre est la notion de "coutures", qui définit comme des Plumes

"un endroit où vous pouvez modifier le comportement de votre programme sans modification en ce lieu."

Parfois vaut le coup de refactoring pour créer des coutures qui feront de futurs tests plus facile (ou possible en premier lieu.) Le google blog de tests a plusieurs posts sur le sujet, la plupart tournant autour du processus de l'Injection de Dépendance.

Answer 4

Je dirais que "supprimer le code dupliqué" joli beaucoup signifie que vous avez à tirer de code et abstraite, de sorte qu'il peut être utilisé dans plusieurs endroits, ce qui, en théorie, permet de bugs plus facile à corriger car vous n'avez qu'à fixer un morceau de code, contrairement à de nombreux morceaux de code, pour corriger un bug.

Answer 5

Je peux rapporter à cette question que j'ai actuellement dans mon premier tour de la vieille école de la base de code. Ce n'est pas vraiment hérité, mais sa certainement pas suivi la tendance des années.

Je vais vous dire les choses que j'aimerais fixer comme ils m'emmerdent tous les jours:

• Document de l'entrée et des variables de sortie
• Refactoriser les noms de variables, de sorte qu'ils signifient réellement quelque chose d'autres et certains notation hongroise préfixe suivi d'un acronyme de trois lettres avec quelque obscure sens. CammelCase est le chemin à parcourir.
• Je suis mort de peur de changer tout le code car il affecte des centaines de clients qui utilisent le logiciel et ce SERA quelqu'un d'avis même les plus obscurs des effets secondaires. Tout reproductibles, des tests de régression serait une bénédiction, car il y a zéro maintenant.

Le reste est vraiment peanuts. Ce sont les principaux problèmes avec un héritage de la base de code, ils mangent beaucoup de temps.