Quels sont les points clés pour travailler efficacement avec le code hérité? [fermé]

J'ai déjà vu le livre Travailler efficacement avec Legacy Code recommandé à plusieurs reprises. Quels sont les points clés de ce livre?

Y at-il beaucoup plus à faire avec le code hérité que d’ajouter des tests unitaires / d’intégration et ensuite de refactoriser?

Le problème clé du code hérité est qu’il n’a pas de test. Vous devez donc en ajouter (et plus encore ...).

Cela en soi prendrait beaucoup de travail, comme @mattnz l'a noté. Mais le problème particulier du code existant est qu’il n’a jamais été conçu pour être testé . En règle générale, il s’agit d’un énorme gâchis complexe de codes spaghetti, dans lequel il est très difficile, voire impossible, d’isoler les petites pièces à tester. Donc, avant de tester les unités, vous devez reformuler le code pour le rendre plus testable.

Cependant, pour pouvoir refactoriser en toute sécurité, vous devez passer des tests unitaires afin de vérifier que rien n'a été cassé avec vos modifications ... Il s'agit de la capture 22 du code hérité.

Le livre vous apprend à sortir de cette situation en apportant les modifications minimales, les plus sûres, au code, juste pour activer les premiers tests unitaires. Celles-ci ne sont pas conçues pour rendre la conception plus agréable, mais uniquement pour permettre des tests unitaires. En fait, ils rendent parfois le design plus laid ou plus complexe. Cependant, ils vous permettent d’écrire des tests - et une fois que vous avez mis en place des tests unitaires, vous êtes libre d’améliorer la conception.

Il existe de nombreuses astuces pour rendre le code testable - certaines sont évidentes, d'autres pas du tout. Il y a des méthodes que je n'aurais jamais pensé à moi-même sans lire le livre. Mais ce qui est encore plus important, c’est que Feathers explique en quoi une unité de code peut être testée. Vous devez couper les dépendances et introduire des barrières dans votre code, mais pour deux raisons distinctes:

• détection - afin de vérifier et de vérifier les effets de l'exécution d'un morceau de code, et
• séparation - afin d’obtenir d’abord le code spécifique dans un harnais de test.

Réduire les dépendances en toute sécurité peut être délicat. L'introduction d'interfaces, de simulacres et d' injection de dépendance est un objectif simple et agréable, mais qui n'est pas nécessairement sans danger pour le moment. Nous devons donc parfois recourir à la sous-classe de la classe testée afin de remplacer une méthode qui normalement déclencherait par exemple une demande directe à une base de données. D'autres fois, nous pourrions même avoir besoin de remplacer une classe de dépendance / jar par une fausse dans l'environnement de test ...

Pour moi, le concept le plus important introduit par Feathers sont les coutures . Une couture est un endroit dans le code où vous pouvez changer le comportement de votre programme sans modifier le code lui-même . Construire des coutures dans votre code permet de séparer le code sous test, mais également de détecter le comportement du code sous test même lorsqu'il est difficile ou impossible de le faire directement (par exemple parce que l'appel modifie un autre objet ou sous-système , dont l’état n’est pas possible d’interroger directement à partir de la méthode de test).

Cette connaissance vous permet de remarquer les germes de la testabilité dans le plus méchant tas de code et de rechercher les modifications minimales, les moins gênantes et les plus sûres pour y parvenir. En d'autres termes, pour éviter de faire des refactorisations "évidentes" qui risquent de rompre le code sans vous en rendre compte - car vous n'avez pas encore les tests unitaires pour le détecter.

Des moyens rapides pour obtenir les points clés du travail efficace avec le code hérité

• Lisez le PDF de 12 pages de Michael Feathers , écrit 2 ans avant le livre.
• Regardez la présentation de Michael Feathers: 68 diapositives
• Écoutez une interview en podcast avec Michael Feathers. Par exemple, cet épisode de Hanselminutes de 30 minutes .

Je travaille sur une base de code contenant des millions de lignes de code, certaines remontant aux années 1980. Il ne s'agit que de logiciels. Il suffit donc de rédiger quelques tests unitaires pour pouvoir les reformuler et les améliorer.

Le mot clé ici est juste - c'est un mot de quatre lettres qui n'appartient pas au vocabulaire des programmeurs, sans parler de celui qui travaille sur des systèmes hérités.

Combien de temps pensez-vous qu'il faut pour écrire un test unitaire, pour tester une heure d'effort de développement? Pour la discussion, disons une heure de plus.

Combien de temps est investi dans ce système hérité vieux de 20 millions d'années? Disons que 20 développeurs pendant 20 ans multiplient les 2000 heures / an (ils ont travaillé assez dur). Choisissons maintenant un numéro - vous avez de nouveaux ordinateurs et de nouveaux outils, et vous êtes tellement plus intelligent que les gars qui ont écrit ce morceau de $% ^^ en premier lieu - disons que vous en valez 10. Avez-vous 40 années-hommes, eh bien, avez-vous ...?

Donc, la réponse à votre question est qu'il y a beaucoup plus. Par exemple, cette routine de 1 000 lignes (quelques-unes en compte plus de 5 000) est excessivement complexe et constitue un morceau de spaghetti. Il suffirait (encore un mot de quatre lettres) de quelques jours pour le re-factoriser en quelques routines de 100 lignes et quelques aides de 20 lignes supplémentaires, non? FAUX. 100 corrections de bogues sont cachées dans ces 1000 lignes, chacune correspondant à une exigence utilisateur non documentée ou à un cas obscur. C'est 1000 lignes parce que la routine d'origine de 100 lignes n'a pas fait le travail.

Vous devez travailler avec l'état d'esprit " si ce n'est pas cassé, ne le répare pas ". Quand il est cassé, vous devez être très prudent lorsque vous le corrigez - car vous améliorez les choses, vous ne changez pas accidentellement autre chose. Notez que "cassé" peut inclure du code non maintenable, mais fonctionnant correctement, qui dépend du système et de son utilisation. Demandez «Qu'est-ce qui se passe si je gâche ça et que j'aggrave la situation?», Car vous le ferez un jour et vous devrez dire au patron des patrons pourquoi vous avez choisi de le faire.

Ces systèmes peuvent toujours être améliorés. Vous aurez un budget, un calendrier, peu importe. Si vous ne le faites pas, allez en fabriquer un. Arrêtez de faire mieux quand l'argent / le temps est écoulé. Ajoutez une fonctionnalité, donnez-vous le temps de l'améliorer. Corrigez un bogue - encore une fois, passez un peu plus de temps et améliorez-le. Ne livrez jamais pire que ce que vous aviez commencé.

Il faut retenir deux points essentiels du livre.

1. Le code hérité est tout code qui n'a pas de couverture de test.
2. Chaque fois que vous devez modifier le code existant, vous devez vous assurer qu'il est couvert.

Comme d'autres intervenants l'ont fait remarquer, essayer de mettre à jour de manière préventive votre code existant est une tâche insensée . Au lieu de cela, chaque fois que vous devez apporter une modification au code hérité (pour une nouvelle fonctionnalité ou une correction de bogue), prenez le temps de supprimer son statut hérité.

En un mot, c’est vrai: ajouter des tests et une refactorisation, c’est l’essentiel.

Mais le livre vous propose de nombreuses techniques différentes pour le faire avec un code très difficile à tester et à refactoriser en toute sécurité.