Améliorer les très mauvais systèmes

Question

Comment commenceriez-vous à améliorer un système vraiment mauvais?

Laissez-moi vous expliquer ce que je veux dire avant de recommander la création de tests unitaires et de la refactorisation. Je pourrais utiliser ces techniques, mais cela ne servirait à rien dans ce cas.

En fait, le système est tellement endommagé qu'il ne fait pas ce qu'il doit faire.

Par exemple, le système doit compter le nombre de messages qu’il envoie. Cela fonctionne généralement, mais dans certains cas, il "oublie". pour augmenter la valeur du compteur de messages. Le problème est que tant d'autres modules avec leurs propres solutions de contournement reposent sur ce compteur. Si je le corrige, le système dans son ensemble deviendrait pire qu'actuellement. La solution pourrait consister à modifier tous les modules et à supprimer leurs propres corrections, mais avec plus de 150 modules qui nécessiteraient une telle coordination que je ne peux pas me le permettre.

Pire encore, il existe des problèmes qui ont des solutions de contournement non pas dans le système lui-même, mais dans la tête des gens. Par exemple, le système ne peut pas représenter plus de quatre messages liés dans un groupe de messages. Certains services nécessiteraient cinq messages regroupés. Le service de la comptabilité connaît cette limitation et chaque fois qu'il compte les messages de ces services, il compte les groupes de messages et le multiplie par 5/4 pour obtenir le nombre correct de messages. Il n’existe absolument aucune documentation sur ces écarts et personne ne sait combien de choses de ce type sont présentes dans le système.

Alors, comment commenceriez-vous à améliorer ce système? Quelle stratégie suivriez-vous?

Quelques points supplémentaires: je suis une armée composée d’un seul homme et je ne travaille donc pas sur ce point. Il n’est donc pas acceptable de recruter un nombre suffisant d’hommes et de restructurer / restructurer le système. Et dans quelques semaines ou quelques mois, je devrais vraiment montrer une progression visible, ce n’est donc pas une option non plus de refacturer moi-même dans quelques années.

Quelques détails techniques: le système est écrit en Java et PHP mais je ne pense pas que cela compte vraiment. Il y a deux bases de données derrière elle, une Oracle et une PostgreSQL. Outre les défauts mentionnés avant que le code lui-même ne sente pas trop, il est vraiment mal écrit et mal documenté.

Informations supplémentaires:

Le problème de compteur n'est pas un problème de synchronisation. Les instructions counter ++ sont ajoutées à certains modules et ne sont pas ajoutées à d'autres modules. Une solution rapide et sale consiste à les ajouter là où ils sont manquants. La solution longue consiste à en faire un aspect pour les modules qui en ont besoin, rendant impossible de l’oublier plus tard. Cela ne me pose aucun problème, mais si je faisais ce changement, je briserais plus de 10 autres modules.

Mise à jour:

J'ai accepté la réponse de Greg D. Même si j'aime davantage Adam Bellaire, cela ne m'aiderait pas de savoir ce qu'il serait idéal de savoir. Merci à tous pour les réponses.

Answer 1

1. Éteignez les feux . S'il y a des problèmes de priorité critique, quels qu'ils soient, vous devez les traiter en premier. Hack it in si vous devez, avec un code puant c'est bon. Vous savez que vous l'améliorerez à l'avenir. C’est votre technique de vente qui s'adresse à qui vous rapportez.
2. Choisissez des solutions simples. Je suppose que vous êtes relativement nouveau dans ce logiciel et que vous avez été chargé de le gérer. Trouvez quelques problèmes apparemment faciles dans un sous-système associé du code qui ne devrait pas prendre plus d'un jour ou deux pour résoudre chacun d'eux et corrigez-les. Cela peut impliquer une refactorisation ou non. Le but est de vous familiariser avec le système et avec le style de l'auteur original. Vous risquez de ne pas être vraiment chanceux (l'un des deux incompétents qui travaillait sur mon système avant moi post-fixait toujours ses commentaires avec quatre signes de ponctuation au lieu d'un, ce qui permettait très facilement de distinguer qui écrivait le segment de code en question.), mais vous développerez un aperçu des faiblesses de l'auteur pour que vous sachiez quoi regarder. Couplage étendu et étroit avec l’état global vs une faible compréhension des outils linguistiques, par exemple.
3. Définissez un objectif important. Si votre expérience est parallèle à la mienne, vous vous retrouverez de plus en plus fréquemment dans un code particulier de spaghetti au cours de l'étape précédente. C'est le premier noeud que vous devez démêler. Avec l'expérience que vous avez acquise en comprenant le composant et les connaissances sur ce que l'auteur original a probablement fait de mal (et donc sur ce que vous devez surveiller), vous pouvez commencer à envisager un meilleur modèle pour ce sous-ensemble du système. Ne vous inquiétez pas s'il vous reste encore des interfaces désordonnées à entretenir pour maintenir les fonctionnalités, procédez étape par étape.

Faites mousser, rincez, répétez! :)

Si vous en avez le temps, envisagez d'ajouter des tests unitaires pour votre nouveau modèle un niveau sous vos interfaces avec le reste du système. Ne gravez pas les mauvaises interfaces dans le code via des tests qui les utilisent, vous les modifierez lors d'une prochaine itération.

Abordez les problèmes particuliers que vous avez mentionnés:

Lorsque vous rencontrez une situation dans laquelle les utilisateurs travaillent manuellement, discutez avec les utilisateurs de la modification de celle-ci. Vérifiez qu'ils accepteront le changement si vous le fournissez avant de perdre du temps. S'ils ne souhaitent pas le changement, votre travail consiste à conserver le comportement perturbé.

Lorsque vous rencontrez un composant buggy sur lequel plusieurs autres composants ont travaillé, j'adopte une technique de composant parallèle. Créez un compteur qui fonctionne comme l'existant devrait . Fournissez une interface similaire (ou, si possible, identique) et faites glisser le nouveau composant dans la base de code. Lorsque vous touchez des composants externes qui fonctionnent autour du composant endommagé, essayez de remplacer l’ancien composant par le nouveau. Des interfaces similaires facilitent le portage du code, et l'ancien composant est toujours là si le nouveau échoue. Ne supprimez pas l'ancien composant avant que vous ne puissiez le faire.

Answer 2

Qu'est-ce qu'on vous demande en ce moment? Vous demande-t-il d'implémenter des fonctionnalités ou de corriger des bugs? Est-ce qu'ils savent même ce qu'ils veulent que vous fassiez?

Si vous ne disposez pas de la main-d'oeuvre, du temps ou des ressources nécessaires pour "réparer" le système dans son ensemble, alors tout ce que vous pouvez faire est de renflouer l'eau. Vous dites que vous devriez être en mesure de faire des "progrès visibles". dans quelques mois. Eh bien, avec le système aussi mauvais que celui que vous avez décrit, vous risquez même de l’aggraver. Sous la pression de faire quelque chose de remarquable, vous allez simplement ajouter du code et rendre le système encore plus compliqué.

Vous devez éventuellement refactoriser. Il n'y a pas moyen de contourner cela. Si vous parvenez à trouver un moyen de refactoriser visible par vos utilisateurs finaux, ce serait idéal , même si cela prend 6 à 9 mois ou un an au lieu de "quelques mois". Mais si vous ne pouvez pas, alors vous avez le choix:

• Refactor, et risquer d'être considéré comme "n'accomplissant rien". malgré vos efforts
• Ne refactorisez pas, accomplissez " visible " objectifs, et rendre le système plus compliqué et plus difficile à refactor un jour. (Peut-être après avoir trouvé un meilleur emploi et espéré que le prochain développeur qui arrive ne pourra jamais savoir où vous habitez.)

Laquelle vous est la plus bénéfique dépend de la culture de votre entreprise. Est-ce qu'ils vont un jour décider d'embaucher plus de développeurs ou de remplacer complètement ce système par un autre produit?

Inversement, si vous tentez de "réparer les erreurs". vont-ils réellement comprendre la monstruosité que l'on vous demande de combattre seul?

Pas de réponse facile ici, désolé. Vous devez évaluer en fonction de votre situation individuelle unique.

Answer 3

Ceci est un livre entier qui dira essentiellement un test unitaire et un refactor, mais avec des conseils plus pratiques sur la façon de le faire

http://ecx.images-amazon.com/images/I/51RCXGPXQ8L._SL500_AA240_.jpg

http://www.amazon.com/Working-Effectively-Legacy-Robert -Martin / dp / 0131177052

Answer 4

Vous ouvrez le répertoire contenant ce système avec l'Explorateur Windows. Ensuite, appuyez sur Ctrl-A, puis sur Maj-Suppr. Cela ressemble à une amélioration dans votre cas.

Sérieusement, ce compteur ressemble à des problèmes de sécurité des threads. Je mettrais un verrou sur les fonctions croissantes.

Et en ce qui concerne le reste du système, vous ne pouvez pas faire l'impossible, essayez donc de faire le possible. Vous devez attaquer votre système sur deux fronts. Traitez d'abord les problèmes les plus visibles, de manière à pouvoir montrer vos progrès. Dans le même temps, vous devez vous attaquer aux problèmes d’infrastructure plus nombreux, de manière à pouvoir réellement régler ce problème un jour.

Bonne chance et que la source soit avec vous.

Answer 5

Choisissez un domaine où il serait difficile de refactoriser. Créez un squelette du code original avec uniquement les signatures de méthodes des codes existants. peut-être même utiliser une interface. Puis commencez à pirater. Vous pouvez même indiquer le " nouveau " méthodes aux anciennes jusqu'à ce que vous y arriviez.

Ensuite, tester, tester, tester. Puisqu'il n'y a pas de tests unitaires, peut-être juste utiliser de bons vieux tests unitaires à activation vocale (personnes)? Ou écrivez vos propres tests au fur et à mesure.

Documentez vos progrès au fur et à mesure que vous allez dans un référentiel, y compris les frustrations et les questions, de sorte que le prochain pauvre convoyeur qui aura ce projet ne soit plus là où vous êtes:).

Une fois que vous avez terminé la première partie, passez à la suivante. La clé est de s’appuyer sur les progrès graduels, c’est pourquoi vous ne devriez pas commencer par la partie la plus difficile; il sera trop facile de se démoraliser.

Joel a publié quelques articles sur la réécriture / refactorisation:

http://www.joelonsoftware.com/articles/fog0000000069.html

http://www.joelonsoftware.com/articles/fog0000000348.html

Answer 6

Je travaille avec un système existant qui présente les mêmes caractéristiques depuis près de trois ans et je ne connais aucun raccourci.

Ce qui me dérange le plus dans notre système existant, c'est que je ne suis pas autorisé à corriger certains bugs, car de nombreuses autres fonctions pourraient ne plus fonctionner correctement. Cela appelle des solutions de contournement laides ou la création de nouvelles versions d'anciennes fonctions. Les appels aux anciennes fonctions peuvent ensuite être remplacés par les nouvelles fonctions (lors des tests).

Je ne sais pas quel est l'objectif de votre tâche, mais je vous conseille vivement de manipuler le moins de code possible. Ne faites que ce que vous devez faire.

Vous voudrez peut-être documenter autant que possible en interrogeant des personnes. C'est une tâche énorme, car vous ne savez pas quelles questions poser et les gens auront oublié beaucoup de détails.

Autre que cela: assurez-vous de recevoir un salaire et un soutien moral suffisants. Il y aura des pleurs et des grincements de dents ...

Answer 7

Eh bien, vous devez commencer quelque part, et il semble que certains bogues doivent être corrigés. Je corrigeais ces bugs, réalisais des modifications de gain rapides et rédigeais tous les tests unitaires possibles en cours de route. J'utiliserais également un outil comme SourceMonitor pour identifier certaines des parties de code les plus "complexes" dans le système et voir si je pouvais simplifier leur conception de quelque façon. En fin de compte, vous devez simplement accepter le fait que le processus sera lent et faire de petits pas vers un meilleur système.

Answer 8

J'essaierais de choisir une partie du système qui pourrait être extraite et réécrite de manière isolée assez rapidement. Même si cela ne fait pas grand chose, vous pouvez montrer les progrès assez rapidement et vous n’aurez pas de problème d’interface directe avec le code hérité.

Espérons que si vous pouviez choisir quelques-unes de ces tâches, ils vous verront faire des progrès visibles et vous pourrez avancer un argument en faveur de l’embauche de plus de personnes pour réécrire les modules les plus volumineux. Lorsque certaines parties du système reposent sur un comportement défaillant, vous n'avez pas beaucoup d'autre choix que de vous séparer avant de réparer quoi que ce soit.

Espérons que vous pourrez progressivement construire une équipe capable de réécrire le tout.

Tout cela devrait aller de pair avec une formation décente, sinon les vieilles habitudes des gens resteront, et votre travail sera blâmé lorsque les choses ne fonctionneront pas comme prévu.

Bonne chance!

Answer 9

Déconseillez tout ce qui existe actuellement qui pose problème et écrivez-en de nouveaux qui fonctionnent correctement. Documentez autant que possible sur ce qui va changer et placez de grands panneaux clignotants rouges pointant vers cette documentation.

En procédant ainsi, vous pouvez conserver vos bogues existants (ceux qui sont compensés ailleurs) sans ralentir vos progrès vers l’obtention d’un système qui fonctionne réellement.