vraiment mauvais

Question

Comment voulez-vous commencer à améliorer sur un système vraiment mauvais? Permettez-moi d'expliquer ce que je veux dire avant de recommander la création de tests unitaires et de refactoring. Je pourrais utiliser ces techniques, mais ce serait inutile dans ce cas.

En fait, le système est donc cassé, 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 principalement mais dans certains cas, il "oublie" d'augmenter la valeur du compteur de messages. Le problème est que tant d'autres modules avec leurs propres solutions de contournement s'appuient sur ce compteur que si je corrige le compteur, le système dans son ensemble deviendrait pire qu'il ne l'est actuellement. La solution pourrait être de modifier tous les modules et supprimer leurs propres corrections, mais avec plus de 150 modules qui nécessiteraient tellement de coordination que je ne peux pas me le permettre.

Encore pire, il y a quelques problèmes qui ont des solutions de rechange 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 associés dans un groupe de messages. Certains services nécessiteraient cinq messages groupés ensemble. Le service comptable connaît cette limitation et chaque fois qu'ils comptent les messages pour ces services, ils comptent les groupes de messages et multiplier par 5/4 pour obtenir le nombre exact des messages. Il n'y a absolument aucune documentation sur ces déviations et personne ne sait combien de ces choses sont présentes dans le système maintenant.

Alors, comment voulez-vous commencer à travailler sur l'amélioration de ce système? Quelle stratégie suivriez-vous? Quelques autres choses: Je suis une armée d'un homme qui travaille sur ce point, donc ce n'est pas une réponse acceptable d'embaucher suffisamment d'hommes et de refaire le système. Et dans quelques semaines ou quelques mois, je devrais vraiment montrer une progression visible, donc ce n'est pas une option non plus pour faire le refactoring moi-même dans quelques années.

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

Informations complémentaires:

La question du compteur 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 est de faire en sorte que ce soit un aspect pour les modules qui en ont besoin, ce qui rend impossible de l'oublier plus tard. Je n'ai aucun problème à réparer des choses comme ça, mais si je faisais ce changement, je casserais 10 autres modules.

Mise à jour:

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

Answer 1

1. Éteignez les incendies. S'il y a des problèmes de priorité critique, quels qu'ils soient, vous devez d'abord les gérer. Hack dans si vous devez, avec une base de code malodorante c'est ok. Vous savez que vous allez l'améliorer à l'avenir. C'est votre technique de vente ciblée sur qui vous rapportez.
2. Choisissez des fruits mûrs. Je suppose que vous êtes relativement nouveau dans ce logiciel et que vous avez été chargé de le faire. Trouver quelques problèmes apparemment faciles dans un sous-système du code qui ne devrait pas prendre plus d'un jour ou deux pour résoudre chacun, et les réparer. Cela peut impliquer le refactoring, ou il ne peut pas. Le but est de vous familiariser avec le système et avec le style de l'auteur original. Vous ne pouvez pas vraiment avoir de la chance (L'un des deux incompétents qui travaillaient sur mon système avant moi fixait toujours ses commentaires avec quatre signes de ponctuation au lieu d'un, ce qui rendait très facile de distinguer qui écrivait le segment de code.), mais vous développerez un aperçu des faiblesses de l'auteur afin que vous sachiez quoi faire attention. Un couplage étendu et étroit avec l'état global par rapport à une mauvaise compréhension des outils linguistiques, par exemple.
3. Fixez un objectif important. Si votre expérience correspond à la mienne, vous vous retrouverez de plus en plus souvent dans un morceau de code spaghetti lorsque vous effectuerez l'étape précédente. C'est le premier nœud dont vous avez besoin pour démêler.Avec l'expérience que vous avez acquise à comprendre le composant et la connaissance de ce que l'auteur original a probablement mal fait (et donc, ce que vous devez surveiller), vous pouvez commencer à imaginer un meilleur modèle pour ce sous-ensemble du système. Ne vous inquiétez pas si vous devez maintenir certaines interfaces désordonnées pour maintenir les fonctionnalités, prenez-les une étape à la fois.

Lather, rincer, répéter! :)

Avec le temps, envisager d'ajouter des tests unitaires pour votre nouveau modèle d'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 changerez dans une itération future.

Répondre aux questions particulières que vous mentionnez:

Lorsque vous exécutez dans une situation que les utilisateurs travaillent manuellement autour, parler avec les utilisateurs sur le changer. Vérifiez qu'ils acceptent le changement si vous le fournissez avant d'y glisser le temps. S'ils ne veulent pas le changement, votre travail consiste à maintenir le comportement brisé.

Lorsque vous rencontrez un composant bogué que plusieurs autres composants ont travaillé, j'épouse une technique de composant parallèle. Créer un compteur qui fonctionne comment fonctionne le existant. Fournissez une interface similaire (ou, si possible, identique) et glissez 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 retirez pas l'ancien composant tant que vous ne pouvez pas le faire.

Answer 2

Vous ouvrez le répertoire contenant ce système avec Windows Explorer. Ensuite, appuyez sur Ctrl-A, puis sur Maj + Suppr. Cela ressemble à une amélioration dans votre cas. Sérieusement cependant: ce compteur semble avoir des problèmes de sécurité. Je mettrais un verrou autour des fonctions croissantes.

Et concernant le reste du système, vous ne pouvez pas faire l'impossible alors essayez de faire le possible. Vous devez attaquer votre système à partir de deux fronts. Prenez soin des problèmes les plus visiblement problématiques en premier, afin de pouvoir montrer les progrès.Dans le même temps, vous devriez traiter les problèmes d'infrastructure plus, de sorte que vous avez une chance de réparer cette chose un jour.

Bonne chance, et que la source soit avec vous.

Answer 3

Choisissez une zone qui serait de difficulté moyenne à refactoriser. Créer un squelette du code original avec seulement les signatures de méthode des existants; peut-être utiliser une interface même. Puis commencez à pirater. Vous pouvez même pointer les "nouvelles" méthodes vers les anciennes jusqu'à ce que vous y arriviez.

Ensuite, test, test, test. Puisqu'il n'y a pas de tests unitaires, peut-être utilisez-vous simplement de bons tests à l'ancienne (Voice-Activated-Unit Tests)? Ou écrivez vos propres tests au fur et à mesure.

Documentez vos progrès au fur et à mesure dans une sorte de référentiel, y compris les frustrations et les questions, de sorte que lorsque le prochain pauvre schmuck qui obtient ce projet ne sera pas où vous êtes :).

Une fois la première partie terminée, passez à la suivante. La clé est de construire au-dessus des progrès incrémentiels, c'est pourquoi vous ne devriez pas commencer par la partie la plus difficile en premier; Ce sera trop facile de se démoraliser.

Joel a deux ou trois articles sur la réécriture/refactoring:

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

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

Answer 4

Eh bien, vous devez commencer quelque part, et il semble que il y a des bugs qui ont besoin de fixation. Je travaillerais à travers ces bogues, en faisant des refactorings rapides de gain, et en écrivant n'importe quels essais unitaires possibles le long du chemin. Je voudrais également utiliser un outil comme SourceMonitor pour identifier certaines des parties les plus «complexes» du code dans le système et voir si je pouvais simplifier leur conception en aucune façon. En fin de compte, vous devez juste accepter que ce sera un processus lent, et faire de petites étapes vers un meilleur système.

Answer 5

Ceci est un livre qui dit essentiellement test unitaire et refactoring, mais avec plus de conseils 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 6

Ce qui est demandé de vous en ce moment ? Vous demande-t-on d'implémenter des fonctionnalités ou de corriger des bogues? Est-ce qu'ils savent même ce qu'ils veulent que tu fasses?

Si vous n'avez pas la main d'oeuvre, le temps ou les ressources nécessaires pour "réparer" le système dans son ensemble, tout ce que vous pouvez faire est de mettre l'eau sous pression. Vous dites que vous devriez être en mesure de faire des «progrès visibles» dans quelques mois. Bien, avec le système étant aussi mauvais que vous l'avez décrit, vous pouvez réellement aggraver le système. Sous la pression de faire quelque chose de notable, vous allez simplement ajouter du code, et rendre le système encore plus compliqué.

Vous devez refactoriser, éventuellement. Il n'y a pas moyen de contourner cela. Si vous pouvez trouver un moyen de refactoriser qui est visible à vos utilisateurs finaux, 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 un choix à faire:

• Refactor, et le risque d'être considéré comme « ne pas accomplir quoi que ce soit », malgré vos efforts
• Ne pas Refactoriser, atteindre les objectifs « visibles », et rendre le système plus compliqué et plus difficile à refactoriser un jour.(Peut-être après avoir trouvé un meilleur travail, et espère que le prochain développeur à venir ne peut jamais savoir où vous vivez.)

Lequel vous est le plus bénéfique dépend de la culture de votre entreprise. Vont-ils un jour décider d'embaucher plus de développeurs, ou remplacer ce système complètement par un autre produit? Inversement, si vos efforts pour «réparer les choses» brisent d'autres choses, seront-ils compréhensifs à propos de la monstruosité qu'on vous demande de résoudre seul?

Pas de réponses faciles ici, désolé. Vous devez évaluer en fonction de votre situation individuelle et individuelle.

Answer 7

Je voudrais essayer de choisir une partie du système qui pourrait être extraite et réécrite assez rapidement. Même si cela ne fait pas grand-chose, vous pouvez montrer la progression assez rapidement, et vous n'avez pas le problème d'interfaçage direct avec le code existant. Heureusement, si vous pouviez sélectionner quelques tâches de ce type, elles vous verront progresser de façon visible, et vous pourriez proposer un argument pour embaucher plus de personnes pour réécrire les plus gros modules. Lorsque des parties du système s'appuient sur un comportement brisé, 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 pourriez progressivement construire une équipe capable de réécrire le tout. Tout cela devrait aller de pair avec un entraînement décent, sinon les vieilles habitudes resteront et votre travail sera blâmé lorsque les choses ne fonctionnent pas comme prévu.

Bonne chance!

Answer 8

Dépréciez tout ce qui existe actuellement qui a des problèmes et écrivez de nouveaux qui fonctionnent correctement. Documentez autant que possible ce qui va changer et mettez de grands signes clignotants rouges partout dans la documentation. De cette façon, vous pouvez garder vos bogues existants (ceux qui sont compensés ailleurs) sans ralentir votre progression vers l'obtention d'un véritable système de travail.

Answer 9

Je travaille avec un système existant avec les mêmes caractéristiques depuis presque trois ans maintenant, et il n'y a aucun raccourci que je suis au courant.

Ce qui me dérange le plus avec notre ancien système est que je ne suis pas autorisé à corriger quelques bugs, car beaucoup d'autres fonctions peuvent se casser si je les fixe. Cela nécessite des solutions de contournement laides ou la création de nouvelles versions des anciennes fonctions. Les appels aux anciennes fonctions peuvent ensuite être remplacés par les nouveaux à la fois (en cours de test).

Je ne suis pas sûr de ce que l'objectif de votre tâche, mais je vous conseille fortement de toucher aussi peu de code possible. Fais seulement ce que tu as besoin de faire.

Vous voudrez peut-être obtenir le plus de documentation possible en interrogeant les gens. C'est une tâche énorme, puisque vous ne savez pas quelles questions poser, et les gens auront oublié beaucoup de détails.

Autre que cela: assurez-vous que vous êtes payé et assez de soutien moral. Il y aura des pleurs et des grincements de dents ...