Comment maintiendriez-vous les anciennes applications? [Fermé]

Question

Comment mainteneriez-vous les applications héritées qui:

1. N'a pas de tests unitaires ont de grandes méthodes

2. avec beaucoup de logique dupliquée ont

3. pas de séparation des responsabilités
4. avoir beaucoup de hacks rapides et codés en dur chaînes
5. ont dépassé et mal documentation
6. Les exigences ne sont pas correctement documentées ! Cela a entraîné des conflits entre les testeurs, les développeurs et les clients par le passé. Bien sûr, il existe des exigences non fonctionnelles telles que ne pas être lent, ne pas se heurter et autres logiques d’entreprise connues des utilisateurs de l’application. Mais au-delà du scénario le plus répandu et du workflow commercial le plus répandu, il existe peu de conseils sur ce qui devrait être fait ou non.

???

Answer 1

Vous avez besoin du livre Travailler efficacement avec du code hérité par Michael C. Feathers .

Answer 2

Rédigez des tests dès que possible. De préférence contre les exigences (si elles existent). Commencez avec des tests fonctionnels. Refactor en petits morceaux. Chaque fois que vous touchez un code, laissez-le plus propre et mieux qu'au début.

Answer 3

Deux choses.

1. Écrivez les tests unitaires à votre guise.
2. Une fois que vous avez suffisamment de tests unitaires pour être sûr de vous, commencez la refactorisation.

La vitesse à laquelle vous accomplissez cela peut être lente ... En règle générale, vous êtes censé le "maintenir" pas le réparer.

Pendant le " apprendre à le maintenir " phase, cependant, vous pouvez écrire beaucoup de tests unitaires.

Ensuite, à mesure que des bogues sont détectés et que des améliorations sont demandées, vous pouvez ajouter encore plus de tests.

C’est agile, appliqué à l’héritage.

Answer 4

J'ai vu, travaillé et travaille dans une base de code qui remplit toutes les conditions mentionnées dans la question: -)

L'approche suivie pour maintenir cette base de code est Ne rien casser . FWIW, le code fonctionne et les utilisateurs finaux sont satisfaits. Personne ne va écouter les pleurs du développeur qui dit qu'il y a une duplication de code, de chaînes codées en dur, etc.

Answer 5

Je pense que je créerais un petit ensemble d'informations "Up To Date": quelle action appelle quelle fonction, etc.

À partir de là, je regarderais la refactorisation. La logique dupliquée semble être quelque chose qui pourrait être refactorisé, mais rappelez-vous que

• Cela peut être une tâche énorme lorsque vous réalisez dans de nombreux endroits que la logique est appelée et
• Deux fonctions qui semblent similaires peuvent avoir une différence minime, à savoir un - au lieu d'un +

Je pense que le plus grand besoin de résistance est "Il suffit de reconstruire ce foutu projet!" et d’avoir d’abord un aperçu du système pour démystifier la bête.

Answer 6

sudo rm -rf /

Mais plus sérieusement, je pense que cela doit être évalué. Si le code est continuellement une source de demandes de changement et que les changements sont difficiles, vous devez bientôt déterminer s'il vaut la peine d'essayer de refactoriser / réorganiser le système en un système plus moderne. Bien sûr, cela n’est pas toujours pratique, et vous vous retrouvez souvent avec quelques membres de l’équipe responsables de la maintenance des éléments hérités. Dans la mesure du possible, tous les membres de l'équipe doivent être en mesure de gérer toutes les parties du système ......

Une autre chose qui, à mon avis, est importante est de suivre le temps et les efforts consacrés par une équipe à travailler sur un système hérité en effectuant des demandes de maintenance / de fonctionnalités. Ces mesures peuvent être convaincantes lors de l’évaluation de la planification d’un nouvel effort visant à remplacer les systèmes / composants existants.

Answer 7

Je suis fondamentalement d’accord avec tout ce que Paul C a dit. Je ne suis pas un prêtre TDD, mais chaque fois que vous touchez une base de code héritée - en particulier une avec laquelle vous n'êtes pas intimement familier - vous devez disposer d'un moyen solide de réessayer et de vous assurer que vous avez suivi Hippocrates: Premier , ne fais pas de mal. Les tests, les bons tests unitaires et les tests de régression en particulier, constituent à peu près le seul moyen de jouer ce jeu.

Je recommande vivement de prendre un exemplaire de Inverser: les secrets de l'ingénierie inverse Logiciel s'il s'agit d'une base de code avec laquelle vous n'êtes pas familier. Bien que ce livre a une profondeur qui dépasse vos besoins actuels (et les miens d'ailleurs), il m'a beaucoup appris sur la façon de travailler en toute sécurité et en toute sécurité avec le code de quelqu'un d'autre.