En remarque: recherchez un nouvel emploi. Celui-ci ne s'améliorerait pas.
Les objectifs du code que vous examinez sont les suivants:
Pour expédier une fonctionnalité, qui devrait fonctionner selon les exigences.
Réduire la croissance de la dette technique.
Le premier objectif est revu en vérifiant que les tests unitaires, d'intégration, de système et fonctionnels sont bien là, qu'ils sont pertinents et qu'ils couvrent toutes les situations à tester. Vous devez également vérifier les croyances que l'auteur original peut avoir sur le langage de programmation, ce qui pourrait conduire à des bogues subtils ou au code faisant semblant de faire quelque chose de différent de ce qu'il fait réellement.
Le deuxième objectif est celui sur lequel votre question se concentre. D'une part, le nouveau code ne devrait pas augmenter la dette technique. D'un autre côté, la portée de l'examen est le code lui-même, mais dans le contexte de la base de code entière. À partir de là, vous, en tant que critique, pouvez vous attendre à deux approches de l'auteur original:
Le code extérieur n'est pas de ma faute. Je viens d'implémenter la fonctionnalité et je ne me soucie pas de la base de code entière.
Dans cette perspective, le code copiera les défauts de la base de code, et donc augmentera inévitablement la dette technique: plus de mauvais code est toujours pire.
Bien qu'il s'agisse d'une approche à court terme valable, à long terme, elle entraînerait une augmentation des retards et une faible productivité, et conduirait finalement à un processus de développement si coûteux et risqué que le produit cesserait d'évoluer.
La rédaction d'un nouveau code est l'occasion de refactoriser l'ancien.
Dans cette perspective, l'effet des défauts du code hérité sur le nouveau pourrait être limité. De plus, la dette technique pourrait être réduite, ou du moins ne pas augmenter proportionnellement à la croissance du code.
Bien qu'il s'agisse d'une approche à long terme valable, elle présente des risques à court terme. Le principal est que, à court terme, il faudrait parfois plus de temps pour expédier la fonctionnalité spécifique. Un autre aspect important est que si le code hérité n'est pas testé, sa refactorisation présente un risque énorme d'introduire des régressions.
Selon le point de vue que vous souhaitez encourager, vous pourriez être enclin à conseiller aux réviseurs de refaçonner plus ou non. Dans tous les cas, ne vous attendez pas à un morceau de code impeccable et propre avec une architecture et un design agréables dans une base de code merdique. Ce que vous ne devriez pas encourager, c'est le comportement où un développeur compétent qui doit travailler sur une base de code merdique essaie de bien faire sa part . Au lieu de simplifier les choses, cela ne fait que les rendre plus compliquées qu'avant. Maintenant, au lieu d'un mauvais code uniforme, vous avez une partie avec des modèles de conception, une autre partie avec du code clair et clair, une autre partie qui a été largement refactorisée au fil du temps, et aucune unité du tout.
Imaginez, par exemple, que vous découvrez une base de code héritée d'un site Web de taille moyenne. Vous êtes surpris par l'absence de toute structure habituelle et par le fait que la journalisation, lorsqu'elle est terminée, se fait en ajoutant des éléments à un fichier texte à la main, au lieu d'utiliser un cadre de journalisation. Vous décidez que la nouvelle fonctionnalité utilise MVC et un cadre de journalisation.
Votre collègue met en œuvre une autre fonctionnalité et est très surpris par l'absence d'un ORM où l'on ferait une taille parfaite. Il commence donc à utiliser un ORM.
Ni vous, ni votre collègue ne pouvez parcourir des centaines de milliers de lignes de code pour utiliser MVC, un cadre de journalisation ou un ORM partout. En fait, cela nécessiterait des mois de travail: imaginez l'introduction de MVC; Combien de temps cela prendrait-il? Ou qu'en est-il d'un ORM dans des situations où les requêtes SQL ont été générées de manière chaotique par concaténation (avec des emplacements occasionnels pour l'injection SQL) dans du code que personne ne pouvait comprendre?
Vous pensez que vous avez fait du bon travail, mais maintenant, un nouveau développeur qui rejoint le projet doit faire face à beaucoup plus de complexité qu'auparavant:
L'ancienne façon de traiter les demandes,
La façon MVC,
L'ancien mécanisme de journalisation,
Le cadre de journalisation,
L'accès direct à la base de données avec des requêtes SQL construites à la volée,
L'ORM.
Sur un projet sur lequel je travaillais, quatre (!) Frameworks de journalisation étaient utilisés côte à côte (plus la journalisation manuelle). La raison est que chaque fois que quelqu'un voulait enregistrer des trucs, il n'y avait pas d'approche commune pour le faire, donc au lieu d'apprendre un nouveau cadre (qui dans tous les cas n'était utilisé que dans 5% de la base de code), on en ajoutait simplement un autre qu'il sait déjà. Imaginez le désordre.
Une meilleure approche serait de refactoriser la base de code une étape à la fois. Reprenant l'exemple de la journalisation, le refactoring comprendrait les petites étapes suivantes:
Recherchez tous les endroits où la journalisation héritée est effectuée (c'est-à-dire lorsque le fichier journal est accessible directement) et assurez-vous qu'ils appellent tous les mêmes méthodes.
Déplacez ce code vers une bibliothèque dédiée, le cas échéant. Je ne veux pas enregistrer la logique de stockage dans ma classe de panier.
Modifiez, si nécessaire, l'interface des méthodes de journalisation. Par exemple, nous pouvons ajouter un niveau indiquant si le message est informel ou s'il s'agit d'un avertissement ou d'une erreur.
Utilisez les méthodes nouvellement refactorisées dans la nouvelle fonctionnalité.
Migrez vers la structure de journalisation: le seul code affecté est le code de la bibliothèque dédiée.