Les anciens logiciels sont presque toujours pénibles. Il y a de nombreuses raisons pour lesquelles une réécriture n'est pas possible.

Que peut-on faire?

1. Il suffit de le maintenir. Mettez en œuvre les modifications demandées et uniquement ces modifications . Essayez de faire le meilleur travail possible, sans en faire trop.

2. Avec l'accord de vos supérieurs (si nécessaire), réparez progressivement le désordre. Veillez à NE PAS modifier le comportement vu par l'utilisateur final. Si le comportement doit changer, passez par une boucle de demande de changement / correction de bogue appropriée. Ce que vous considérez comme une correction de bogue mineur peut entraîner une interruption majeure des fonctionnalités pour le client.

Je vous le dis car je devais entretenir moi-même un logiciel vieux de plus de 20 ans. J'ai même dû créer un "nouveau" logiciel à partir de ce désordre. La seule vraie alternative était de brancher une grande partie d'un code spaghetti - contre mon souhait de tout réécrire.

Le problème est si courant et si répandu que des livres entiers ont été écrits à ce sujet. Effectuez simplement une recherche sur Google pour trouver des livres sur l'utilisation des anciens logiciels.

Essayez de tout formuler en termes de coûts et d'avantages pour l'entreprise. «Le logiciel a X quantité de bogues (connus)» n'est pas vraiment une mesure. Il y a beaucoup de bogues dont les effets sont mineurs ou sont déclenchés très rarement.

Vos collègues ingénieurs et vous pensez que le logiciel est défectueux et contient des bogues, mais qu'en pensent les utilisateurs? Vos utilisateurs déposent-ils des rapports de bogues? Votre entreprise perd-elle de l'argent ou des opportunités à cause de ces bugs? Les bogues que personne ne semble remarquer n'ont pas une haute priorité à corriger.

Comment ce gouffre peut-il être résolu?

Vous et votre responsable doivent comprendre les deux côtés.

Parmi les bogues que vous connaissez, collectez des données. Quel est l'effet du bogue? Quels sont les coûts de conservation? (Production perdue, argent perdu, responsabilité, etc.). Quel est le coût de sa réparation? (Autrement dit, combien de temps vous faudra-t-il pour le réparer - pas seulement écrire le code, aussi le déployer et gérer les retombées, etc.). Ensuite, vous pouvez présenter un argument à votre responsable. Vous avez une liste de bogues. Vous avez les coûts liés à ce bug. Vous avez le coût de le corriger.

Ensuite, votre responsable peut décider s'il est plus utile pour l'entreprise que vous consacriez du temps à corriger ces bogues ou à faire autre chose. Et vous devez accepter que parfois il vaut plus la peine de développer de nouvelles choses que de corriger des bogues.

Et rappelez-vous que le code ne devient un «code hérité» que si c'est du code qui continue de gagner de l'argent; ou bien il aurait été abandonné il y a longtemps.

Avant, j'étais dans une entreprise où je devais gérer deux applications héritées. D'après ce que j'ai compris, avant de partir, les deux développeurs ont réussi à cacher (ou à corriger rapidement) la majorité des bogues lorsqu'ils sont apparus. Rapidement à un ou deux ans après le départ de ces développeurs, l'application s'effondrait et les utilisateurs commençaient à être frustrés. Il a fallu du temps à mon manager pour vraiment comprendre que les applications n'étaient pas assez stables et comme vous l'avez dit, corriger même les petits bugs a commencé à prendre beaucoup de temps pour moi et cela a commencé à vraiment diminuer ma productivité quand j'ai dû créer de nouvelles fonctionnalités. .

Donc ce que j'ai fait était juste d'être honnête, chaque fois que je trouvais quelque chose de louche ou de cassant, je le disais à mon manager même s'il n'aimait pas ça. À un moment donné, il a pris la décision d'embaucher des personnes afin que nous puissions créer de nouvelles applications tout en maintenant l'ancienne pour le moment.

Pour ce faire, je pense que vous devriez documenter chaque bogue que vous rencontrez, du code douteux et essayer de leur faire comprendre que cela va éventuellement leur coûter de l'argent et créer de plus en plus de problèmes en cours de route. Ne comptez pas sur vos collègues pour vous aider. Et si, à un moment donné, vous ne voyez aucun changement dans l'opinion de votre responsable à ce sujet, je vous suggère de commencer à chercher autre chose.

1) Familiarisez-vous avec les objectifs de votre entreprise, les objectifs de votre département et les objectifs de votre équipe. Comment sont-ils tous liés ensemble? Les discussions sur la dette technique doivent être pertinentes par rapport à ces objectifs.

2) Lorsque vous discutez du problème de la dette technique avec des non-développeurs, rendez-le pertinent en le présentant comme un risque que l'entreprise doit atténuer. La dette technique peut rendre plus difficile l'ajout de fonctionnalités et rendre les versions plus boguées, ce qui augmente le temps de développement, ce qui coûte de l'argent à l'entreprise.

3) Si vous ne le faites pas déjà, commencez à utiliser source -contrôle. Vous devriez pouvoir annuler les modifications si elles causent de nouveaux problèmes. Pendant que vous y êtes, examinez les autres étapes du test Joel.

4) Négociez du temps pour faire face à la dette technologique et réglez vous-même le temps alloué. En étudiant le code hérité, vous trouverez des dragons. Vous n'aurez pas le temps de les aborder tout de suite, mais la chose merveilleuse à propos du contrôle de code source et des branches est que vous pouvez enregistrer votre progression afin de pouvoir y revenir plus tard.

5) Si vous ne pouvez pas faites en sorte que votre direction accepte d'allouer du temps pour faire face à la dette technique, assurez-vous de mentionner l'impact de la dette technologique sur le développement des nouvelles fonctionnalités qu'elle demande et son rôle dans les bogues qui surgissent. Cela le rendra plus visible.

6) Au fil du temps, si vous ne parvenez toujours pas à obtenir l'adhésion pour faire face à la dette technologique, apprenez à vivre avec, ou cherchez un nouvel emploi si vous le pouvez » t.

Ce problème est souvent exprimé dans le monde du développement logiciel, car il y est facilement visible. Mais la vérité est que cela se généralise à presque tout le monde des affaires. Qu'il s'agisse de logiciel, de fabrication ou de service, il y a toujours un processus ou une fonction qui peut être amélioré. Les personnes occupant des rôles «d'ingénierie» (c'est-à-dire des rôles qui se concentrent sur la conception et la modification de processus ou d'outils, par rapport à leur utilisation) ressentent souvent un sentiment de difficulté car elles peuvent «voir» l'opportunité d'amélioration là où les personnes occupant des rôles plus axés sur les opérations peuvent leur semblent parfois aveugles.

Ceci est particulièrement vrai dans les logiciels, car la vue du produit final (le logiciel) est très différente - les développeurs voient le code, les utilisateurs finaux voient l'interface utilisateur.

En fin de compte, il y a quelques points que vous pouvez garder à l'esprit:

Les opportunités d'amélioration sont toujours encadrées dans un contexte spécifique. Il existe des opportunités d'un contexte purement technique ( facilitant la maintenance du code) et les opportunités d'un contexte purement fonctionnel (écriture de code qui ajoute une fonctionnalité spécifique). En fin de compte, avec les logiciels, il y a souvent des décideurs différents pour les différents contextes - un responsable d'unité commerciale peut être responsable en dernier ressort de la compréhension et de l'approbation des changements fonctionnels, tandis qu'un directeur technique, un développeur principal ou un architecte peut être responsable des changements techniques. Cette répartition des responsabilités peut facilement faire trébucher un développeur qui essaie d'obtenir l'adhésion pour un correctif spécifique, car l'unité commerciale peut être complètement indifférente à une amélioration purement technique et peut même voir ce travail comme une "perte de temps" ou même "risqué" car il pourrait potentiellement introduire des changements fonctionnels ou des bogues.

En tant que tel, il est important de vous assurer que vous comprenez qui sont les décideurs en ce qui concerne les corrections de bogues, l'approbation des délais ou des niveaux d'effort, etc. En tant que développeur d'entrée de gamme, il arrive parfois que tout soit filtré via un chef d'équipe ou une autre personne interne à votre équipe, mais d'après votre description, il semble que vous soyez pris entre deux feux entre ces décideurs.

Deuxièmement, il y aura toujours des possibilités d'amélioration. Se concentrer trop sur l'auto-identification et la promotion de ces opportunités peut être une pente glissante. Surtout si "corriger chaque dernier bogue" n'est pas vraiment conforme à la stratégie d'une organisation pour un logiciel spécifique. Au fur et à mesure que vous le découvrez, parfois lorsque vous découvrez un bogue par vous-même et que vous travaillez à le corriger, vous pouvez vous retrouver dans ce que vous décrivez comme une «boîte de vers». La leçon à tirer ici est que s'il peut y avoir des choses que vous voyez comme des bogues, il est important de respecter le processus de prise de décision en termes de ce que vous soulevez à votre direction et sur quoi vous travaillez.

Il peut être facile de dire, "hey boss, puis-je travailler sur ce bug que j'ai trouvé?" lorsque vous êtes enthousiasmé par l'opportunité de corriger quelque chose, mais que vous n'êtes pas encore vraiment sûr de la portée ou de l'impact du bogue. En tant que tel, il est presque toujours préférable d'adopter l'approche "hé patron, nous pourrions avoir une opportunité d'améliorer X. Voulez-vous que je passe un peu de temps à comprendre la portée et l'impact de ce bogue?" Et si ou quand vous obtenez l'approbation, il est important de la rattacher à quelque chose de concret. "Salut patron, maintenant que j'ai regardé le bogue, il n'a vraiment d'impact que sur X, et il faudra Y pour le corriger." De cette façon, vous supprimez l'ambiguïté de la situation et vous aidez ceux qui sont responsables de choses comme X (fonctionnalité commerciale ou technique) et Y (votre temps en tant que ressource) à vous diriger efficacement.

Comment résoudre ce gouffre?

Malheureusement, vous vous êtes préparé pour une chute ici en faisant cela;

Comme Je n'avais pas d'autres tâches, j'ai essayé de corriger certains bugs et lors de discussions ultérieures avec le superviseur et le manager, nous avons convenu que je corrige un bug spécifique. Cela s'est avéré être une boîte de vers que j'ai ensuite tenté de réparer. Quand 2 heures plus tard, j'ai expliqué que je ne peux pas donner de garantie pour résoudre ce problème dans une semaine, il a commencé à se mettre légèrement en colère, soulignant également qu'il voulait le présenter vendredi et "le logiciel fonctionnait".

Réponse courte: Tenez-vous en à la tâche à accomplir et ne l'élargissez pas au hasard.

Réponse plus longue: Malheureusement parce que vous avez essayé d'être productif, vous avez découvert de plus en plus de bogues et laissé le logiciel dans un état inutilisable. Vous vous êtes mis dans cette position à cette occasion - Vous auriez pu simplement dire honnêtement lors de l'enquête que vous avez constaté que le problème sur lequel vous étiez censé travailler est un non-problème et fermé le ticket.

L'ancien logiciel sur lequel vous travaillez est compliqué pour de nombreuses raisons et certains éléments compliqués sont en fait là pour introduire des changements de dernière minute et des corrections de bogues - En d'autres termes, vous vouliez des changements.

Si vous sont nécessaires pour travailler et refactoriser ce code à l'avenir, alors vous devez d'abord vous assurer de ne pas changer la façon dont il fonctionne. Il existe de nombreux bons livres et ressources sur Internet qui vous guideront dans l'art de l'introduction des tests unitaires au code hérité.

Il y a beaucoup de bonnes réponses ici, mais j'ajouterai une autre perspective, qui est que le code et l'organisation ne sont (probablement) pas le problème ici. Votre désir de résoudre chaque problème peut bien être, ainsi que ce qui ressemble à des problèmes d'outils ou de processus.

D'abord et avant tout, vous devez réaliser que vous travaillez maintenant pour une entreprise, et très probablement , cette entreprise a besoin de gagner de l'argent. Par conséquent, à un certain niveau, chaque décision qui est prise devrait être celle du coût par rapport à la récompense. Bien que le logiciel puisse avoir des bogues dans un certain sens, à moins que ces bogues n'affectent d'une manière ou d'une autre l'entreprise, ce ne sont que des bogues théoriques. Il est tout à fait possible que des personnes / d'autres processus en soient venus à s'appuyer sur ces bogues, par exemple. Donc, avant de changer quoi que ce soit, vous devez avoir une analyse de rentabilisation pour effectuer un changement.

Cette analyse de rentabilisation peut être que le bogue a vraiment un impact sur autre chose et doit donc être corrigé. Ou le cas commercial doit être que la correction des bogues en général est si difficile dans le code qu'en restructurant le code, vous gagnerez du temps à l'avenir. Et si c'est le dernier cas, que vous restructurez le code pour faciliter les choses à l'avenir (c'est-à-dire rembourser la dette technique), vous devrez faire beaucoup de travail avant d'apporter ces modifications. Certains des livres / liens mentionnés dans d'autres réponses couvriront cela, mais en général, vous devrez vous assurer que vous disposez d'une suite de régression très complète, afin de pouvoir être sûr que le changement que vous apportez n'est pas impact sur autre chose. Si une telle suite de régression n'existe pas, vous seriez bien mieux servi en en construisant une avant d'apporter des modifications au programme de production. Est-ce beaucoup moins amusant et satisfaisant que de corriger des bugs? Oui, mais cela signifie qu'à l'avenir, lorsque vous corrigerez des bogues, vous pourrez le faire en toute sécurité.

J'aimerais également répondre à votre déclaration

Quand 2 heures plus tard, j'ai expliqué que je ne peux pas donner de garantie pour réparer cela en une semaine, il a commencé à se mettre légèrement en colère, soulignant également qu'il voulait le présenter vendredi et "le logiciel fonctionnait auparavant".

Il y a un certain nombre de problèmes potentiels ici. Premièrement, cela signifie-t-il que le programme est maintenant interrompu en production? Cela ne devrait jamais, jamais arriver pour un changement volontaire de code. S'il s'agit d'une sorte de correctif d'urgence, ce n'est pas une bonne situation, mais c'est en quelque sorte compréhensible. Mais sinon, de leur point de vue, vous venez de violer la règle «si ce n'est pas enfreint, ne le réparez pas». Le code peut être horrible, il peut mal fonctionner, etc. Mais il effectuait un service important, et maintenant ce n'est pas le cas. Donc, encore une fois, comme la suite de régression, votre temps serait bien mieux servi pour déterminer comment créer un environnement de test où vous pouvez tester les modifications avant de déployer quoi que ce soit en production. Et, deuxièmement, cela suggère également un manque de contrôle du code source, qui, encore une fois, si vous ne l'avez pas, votre temps serait beaucoup mieux servi à construire, avant d'apporter des modifications au code.

Don ' Ne vous méprenez pas, en parlant en tant que pur programmeur informatique, c'est vraiment irritant de savoir que quelque chose que j'ai écrit n'est pas parfait. Je regarde le code que j'ai écrit il y a cinq ans avec une certaine horreur, et je veux vraiment revenir en arrière et le réécrire. Mais en tant qu'ingénieur logiciel, une grande partie du travail consiste à faire des compromis, et ce code fait toujours ce pour quoi il a été conçu, et le réécrire signifierait que je ne travaillerais pas sur de nouveaux programmes qui résolvent de nouveaux problèmes. D'un point de vue commercial, il est bien préférable pour moi de résoudre un nouveau problème plutôt que de résoudre un problème déjà résolu d'une manière légèrement meilleure, d'une manière que personne d'autre ne remarquera.