Avons-nous la responsabilité d'améliorer l'ancien code?


64

Je cherchais un vieux code que j'ai écrit. Cela fonctionne, mais ce n'est pas un bon code. J'en sais plus maintenant qu'à l'époque, afin de pouvoir l'améliorer. Ce n'est pas un projet en cours, mais un code de production actuel, fonctionnel. Avons-nous la responsabilité de revenir en arrière et d'améliorer le code que nous avons écrit dans le passé, ou bien la bonne attitude est-elle "si ce n'est pas cassé, ne le corrigez pas"? Mon entreprise a parrainé un cours de révision de code il y a quelques années et l'un des principaux enseignements à retenir est que, parfois, c'est juste suffisant. passez.

Donc, à un moment donné, devriez-vous simplement l'appeler suffisamment bon et passer à autre chose, ou devriez-vous essayer de pousser les projets à améliorer l'ancien code lorsque vous pensez qu'il pourrait être meilleur?


Faites-vous cela à votre propre rythme ou à la caisse de l'entreprise?
JBRWilkinson

42
dans la plupart des cas, votre première responsabilité est d’ ajouter de la valeur à l’entreprise . Si vous faites quelque chose qui n'ajoute pas directement au résultat, tout autre effort est gaspillé. L'ancien code de travail testé est un code de travail testé. Touchez-le pour le rendre meilleur comme un exercice de plaquage or. Il devient maintenant un nouveau code non testé et donc non fonctionnel , ce qui n'ajoute aucune valeur au résultat final.

7
Demandez à votre patron ce qu'il veut que vous fassiez. On vous demandera probablement de le laisser tranquille. En outre, les modifications de code ne devraient, selon mon expérience, être effectuées que dans le cadre d'une livraison réelle. Les changements aléatoires au fil du temps ont une trop grande probabilité d'introduire des erreurs, ce qui vous prend trop de temps à corriger car vous n'avez pas ces changements à l'esprit.

1
Ajouter des commentaires sur les améliorations possibles de la documentation et en rester là?
James P.

2
Écrire des tests unitaires ou des tests de régression. Ne changez pas le code, mais donnez la possibilité à quelqu'un de revenir plus tard et apportez les modifications nécessaires en toute confiance, même s'il n'est pas familiarisé avec le code.
James Youngman

Réponses:


66

À moins que vous ne modifiiez cet "ancien code" pour corriger des bugs ou ajouter des fonctionnalités, je ne voudrais pas l'améliorer simplement pour le plaisir de le faire. Si vous souhaitez éventuellement l'améliorer, assurez-vous de disposer de tests unitaires permettant de tester le code avant de commencer à le refactoriser.

Vous pouvez utiliser "l'ancien code" pour apprendre de meilleures pratiques. Si vous faites cela, c'est une expérience d'apprentissage à temps partiel et vous ne devez pas vous attendre à ce que ce code remplace ce qui est actuellement publié ou déployé par les clients / clients.


4
Ce que je pensais, c’est la "pourriture logicielle" et la théorie de la fenêtre cassée des programmeurs pragmatiques et les effets de l’entropie logicielle. pragprog.com/programmer-pragmatic/extracts/entrale-software
jmq

5
À moins que vous n'apportiez de la valeur à la société en refacturant un code qui fonctionne déjà et est en production, il sera difficile de justifier le temps nécessaire pour supprimer la "pourriture logicielle" de vos supérieurs. Ne le faites que si vous travaillez activement dans ce code, sinon il n’y aurait pas grand avantage à acquérir une expérience de refactoring.
Bernard

11
@jmquigley, le logiciel ne pourrit que si son code source est modifié, et les fenêtres cassées n'ont d'effet que si elles sont vues. Une ancienne base de code, s’il n’est pas nécessaire de la toucher, fonctionnera de la même manière tant que son environnement le permettra.
Péter Török

2
Essayez de ne pas introduire d'erreur dans un programme de travail en train de "l'améliorer" ;-)
robrambusch

4
Je pense que le code "pourriture" est une métaphore malheureuse. le code ne pourrit pas, si vous ne faites rien, il ne change pas du tout. si quelque chose se passe, le travail du code se durcit - vous introduisez l'entropie au fur et à mesure que vous la travaillez, et vous pouvez la supprimer en dépensant beaucoup d'énergie pour la refactoriser (similaire à la refonte / forgeage)
jk.

32

Refactorisez les zones de code que vous devez modifier le plus souvent . Étant donné que vous visitez fréquemment ces zones, la refactorisation améliorera votre compréhension du code et la lisibilité lorsque vous devrez les visiter à nouveau, alors qu'il est inutile de refactoriser le code que personne ne regardera plus jamais.

De plus, si vous ne refactorisez que des zones de code lorsque vous avez besoin de les modifier, cela vous donnera une excuse valable si votre refactoring provoque une régression . Bien sûr, essayez de couvrir vos refactorisations avec des tests unitaires, mais cela n’est pas toujours possible, en particulier avec le code hérité et vous devez vous attendre à ce que les grandes refactorisations créent des régressions de temps en temps.

Si vous avez besoin d'ajouter des fonctionnalités et que votre conception vous ralentit ou entraîne des doublons, refactorisez . Lorsque je conçois du code, je ne prévois presque jamais exactement quels changements seront nécessaires dans le futur. Cependant, lorsque j'ajoute de nouvelles fonctionnalités, je finis généralement par refactoriser le code partagé. Au moment où j'ai ajouté un troisième cycle fonctionnalité / refactoring, mon refactoring est déjà rentable et mon code partagé est assez stable.

TLDR: refactoriser au besoin, il n'y a pas d'obligation.


Pourriez-vous être plus précis sur ce que vous entendez par "refactorisation provoque une régression"? Le refactoring a-t-il pour but d'améliorer la conception de votre logiciel sans en modifier le comportement? Pouvez-vous donner un exemple?
Manfred

3
@ John: Oui, c'est l'objectif du refactoring: améliorer le code tout en maintenant le comportement.
Bernard

@ John, toute refactorisation non triviale risque de modifier involontairement les comportements, notamment en l'absence de tests de régression.
Garrett Hall

14

Tout ce que vous faites a un coût. Vous avez peu de temps pour programmer. Tout ce que vous faites dans la programmation doit être examiné contre "Quel est l’avantage de le faire?" et "Quel est l'avantage de faire autre chose?"

Si vous ne prenez pas en compte le coût d'opportunité (Quel est le coût de faire autre chose?), La qualité est gratuite. Il vaut mieux améliorer votre code. Vous allez apprendre quelque chose. Ça va mieux. Ça va vendre plus.

La vraie question est la suivante: quelle est la meilleure chose à faire avec votre temps? Et puis vous devez faire des compromis.

Va-t-il vendre plus du logiciel?

Cela causera-t-il moins de maux de tête à supporter?

Qu'allez-vous apprendre?

Est-ce que ça va devenir plus esthétique?

Cela améliorera-t-il votre réputation?

Posez ces questions (et toute autre question pertinente pour vous) pour cette activité et d’autres dans votre file d’attente, et cela vous aidera à répondre si cela vaut la peine de la réparer. Ces compromis sont la raison pour laquelle l’économie est importante pour les programmeurs. Joel l'a dit avant moi, et un vieux mentor me l'a dit avant même Joel.

Ou si vous voulez une réponse plus simple, arrêtez de regarder la télévision jusqu'à ce que vous ayez corrigé le code. :-)


4
Pour emprunter à un exemple réel ne figurant pas dans un logiciel, certaines entreprises de transport paieront leurs employés pour nettoyer et peaufiner leurs plates-formes, et ce, pour diverses raisons, souvent parce que cela aide les conducteurs / opérateurs à être fiers de "leur" unité et à prendre soin de et y prêter une attention particulière; éviter les problèmes rapidement et facilement. Dans le même ordre d'idées, s'il y a des kilomètres à parcourir, montez dans le camion, conduisez-le et inquiétez-vous de le nettoyer après quelques milliers de kilomètres supplémentaires (d'un océan à l'autre).
JustinC

@justinC - exactement! Votre exemple illustre à la fois une autre raison et le coût d’opportunité.
MathAttack

Le coût (ou la valeur , etc.) est en effet le mot clé de la bonne réponse. Cela devrait ajouter de la valeur à la somme totale, en considérant également que toucher du vieux code pourrait casser des choses (supprimer de la valeur), peu importe à quel point il pourrait être optimisé.
cregox

6

Je pense que vous devriez commencer par vous poser la question qui semble avoir été manquée. En quoi le code est-il mauvais? Et par là vous vous demandez vraiment ce qui suit:

  • Le code ne fait-il pas ce qu'il est censé faire?
  • Le code vous pose-t-il des problèmes lors de la maintenance du logiciel?
  • Le code est-il complètement autonome?
  • Avez-vous l'intention de mettre à jour ou de remplacer le code à tout moment dans un avenir prévisible?
  • Existe-t-il une bonne analyse de rentabilisation que vous pouvez faire pour mettre à jour le code qui vous intéresse?

S'il y a une chose que j'ai apprise au fil des ans, c'est que vous ne pouvez pas vous permettre de deviner vous-même après coup. Chaque fois que vous résolvez un problème dans le code, vous apprenez quelque chose et vous verrez probablement en quoi votre solution - ou quelque chose de similaire - aurait pu être une meilleure solution à un problème que vous avez résolu différemment il y a des années. C'est une bonne chose, car cela vous montre que vous avez appris de vos expériences. Cependant, la vraie question est de savoir si le code que vous avez écrit auparavant deviendra probablement un problème hérité qui deviendra plus difficile à gérer avec le temps.

Ce dont nous parlons vraiment ici est de savoir si le code qui vous gêne est facile ou difficile à maintenir, et combien cet entretien coûtera probablement avec le temps. C’est essentiellement une question de dette technique et de savoir s’il vaut la peine de rembourser cette dette avec un peu d’entretien maintenant chirurgical, ou si la dette est suffisamment petite pour que vous puissiez la laisser glisser pendant un moment.

Ce sont des questions que vous devez vraiment peser par rapport à votre charge de travail actuelle et future, et qui devraient être longuement discutées avec votre direction et votre équipe afin de mieux comprendre où investir vos ressources et si votre ancien code en vaut la peine. le temps que vous devrez peut-être y consacrer - voire pas du tout. Si vous pouvez faire une bonne analyse de rentabilisation pour introduire un changement, alors certainement, mais si vous faites face à l'envie de bricoler avec du code parce que vous vous sentez embarrassé de la façon dont vous l'avez écrit, alors je suggère qu'il n'y ait pas place pour la fierté personnelle quand il s'agit de maintenir l'ancien code. Cela fonctionne ou non, et il est soit facile à entretenir, soit coûteux, et ce n'est jamais bon ou mauvais simplement parce que l'expérience d'aujourd'hui ne vous a pas été offerte hier.


5

Ne l'améliorez certainement pas juste pour l'améliorer. Comme d’autres l’ont dit (et selon le bon sens), nous nous améliorons tous (avec une certaine valeur de «meilleur») avec le temps. Cela étant dit, la révision du code (formelle ou informelle) éclaire souvent ces éléments que nous souhaitons probablement ne jamais voir la lumière du jour.

Bien que je ne pense pas que nous ayons la responsabilité de revenir en arrière et d'améliorer un code qui ne soit pas fondamentalement cassé, non sécurisé, ou qui dépend de fonctionnalités figurant sur une liste obsolète / EOL, voici certaines choses que j'ai faites dans le passé dans cette situation :

  • Identifiez les membres de l'équipe qui aiment vraiment améliorer le code, en tant que sorte de nettoyage du cerveau ou de tâche mordante qui donne un sentiment d'accomplissement, et trouvez du temps dans leur emploi du temps pour le faire régulièrement. J'ai toujours eu au moins un de ces types de personnes dans une équipe, et cette approche peut également remonter le moral (ou du moins l'humeur) si nous sommes tous dans une période d'immobilisation ou de ralentissement.

  • Utilisez-le comme base pour un exercice d'apprentissage. Pour les stagiaires, les étudiants ou les membres débutants / débutants de l’équipe, la refactorisation de l’ancien code avec les conseils des membres expérimentés de l’équipe leur donne l’occasion de communiquer avec les nouveaux membres de l’équipe, de mieux comprendre le système et de prendre l'habitude d'écrire / mise à jour des tests unitaires et utilisation de l'intégration continue. Il est important de noter que cet exercice est fait avec des directives et clairement défini comme un exercice visant à améliorer le code, car il n'est pas conforme aux normes actuelles.

Donc, aucune responsabilité pour le réparer, mais ce vieux truc peut être vraiment utile. Et les tests unitaires et CI sont tes amis!


4
Donner du mauvais code à un débutant est le pire anti-modèle de gestion de projet qui existe, ils le voient et pensent que c'est correct et le dupliquent, le mauvais code se répand comme un cancer à cause d'un mauvais conseil comme celui-ci.

1
@JarrodRoberson Merci d'avoir signalé ce que j'aurais dû rendre plus évident; J'ai modifié ma réponse pour noter que je le fais très spécifiquement dans le cadre d'une expérience d'apprentissage et qu'ils travaillent avec un mentor. Ce n'est pas une situation où il est difficile de se lancer.
jcmeloni

Je pense toujours qu'il est libellé de manière à ce que les gens puissent lire "Donnez-le au débutant - aux stagiaires et aux étudiants, en particulier". et arrêtez de lire pour comprendre juste là. Si le libellé commence par un membre senior et un membre junior programmant le style XP ou quelque chose du genre, ce ne serait peut-être pas si grave. J'ai des problèmes avec les aspects de placage à l' or et le risque supplémentaire de changer des choses dans le but de les changer de la première puce aussi.

1
Les revues de code servent à empêcher le mauvais code d'entrer dans le contrôle de version, pas à identifier le code faible après coup, il est trop tard.

@JarrodRoberson Merci d'avoir signalé les problèmes que vous aviez avec mon langage vague et malheureusement potentiellement trompeur; J'ai apporté plus de modifications et je reste fidèle à ce qu'il y a maintenant.
jcmeloni

2

Pas nécessairement. Toutefois, si vous effectuez la maintenance du code et tombez sur quelque chose qui pourrait être amélioré, vous pouvez le modifier à condition que vous disposiez des tests unitaires appropriés pour vous assurer que vous n'avez pas créé de régression.

Si de tels tests n'existent pas et que vous ne pouvez pas être sûr qu'il se comportera exactement comme il se doit, vous feriez mieux de le laisser seul.


4
J'ajouterais "et si cela ne change pas le temps prévu, cela ne prendra pas beaucoup de temps"
HLGEM

2

Du point de vue d'un ingénieur, j'aimerais bien travailler sur l'ancien code jusqu'à ce qu'il ne puisse plus être amélioré. Mais existe-t-il une analyse de rentabilisation? En fin de compte, le code est là pour contribuer à la rentabilité de votre lieu de travail. Si ce n'est pas le cas, laissez-le.

Il y a une grosse mise en garde, si en améliorant le code, vous éviterez un bug (en pensant aux grosses balles de l'an 2000 ici), je le ferais sûrement avec quelqu'un de plus haut placé, peut-être votre responsable d'unité commerciale, et discuter des conséquences de l'amélioration du code.


2

Quant à moi, la question peut être reformulée et généralisée: "Pourquoi quelqu'un devrait-il dépenser des ressources supplémentaires (temps, argent, mental, etc.) si ce code concret fonctionne bien maintenant? N'est-ce pas un gaspillage de ressources? ? "

Chaque fois que je trouve un code hérité, je pense à plusieurs choses qui semblent être importantes.

  1. Qu'est-ce que je vais faire des changements?
  2. Est-ce que je devrai supporter ce code? Combien de temps cela peut-il arriver (futur proche / lointain)?
  3. Ce code est-il assez confortable pour travailler? (Maintenant)
  4. Puis-je être sûr que tous les changements que je fais sont en sécurité? Différents tests aident généralement à répondre à cette question.
  5. Quelles conséquences puis-je subir si je commets des erreurs lors de la modification du code? Est-il possible de revenir rapidement sur mes modifications? Sera-ce une perte de temps?
  6. ...

En fait, vous devriez vous poser beaucoup de questions. Il n'y a pas une liste complète et finale d'entre eux. Seuls vous et probablement vos coéquipiers peuvent trouver la réponse.

PS J'ai remarqué que j'ai tendance à réécrire le code très souvent, alors que mon ami et mon coéquipier ont tendance à le laisser intact. C'est parce que nous répondons aux questions mentionnées différemment. Et je dois dire que nous leur répondons très souvent mal parce que nous ne pouvons prédire l'avenir.


2

Microsoft a-t-il besoin de mettre à jour Windows? Est-ce que tous les * nix Distros doivent continuer à évoluer? Ou un exemple plus pratique, est-ce que tout le monde conduit encore des voitures des années 70?


1

Vous pouvez normalement mieux écrire le code la deuxième fois. Vous en avez appris davantage sur le domaine en l'écrivant initialement.

Il n'y a pas de réponse simple à la question de savoir si cela vaut la peine de procéder à une réfraction. Généralement, vous ne devriez pas, sauf si a) c'est un bon exercice d'apprentissage pour vous ou b) vous gagneriez du temps à long terme avec un meilleur code. Rappelez-vous chaque changement risque des bugs.

En remarque, je préconise fortement les tests unitaires. Il est très facile d’abandonner la réfrigération, surtout si le comportement actuel n’est pas clairement défini par des silences automatisés.


1

Je crois que nous avons la responsabilité d'écrire le meilleur code possible que nous pouvons aujourd'hui. Cela signifie utiliser tout ce que nous avons appris par le passé et refuser de prendre des raccourcis dans notre conception. Si les contraintes de calendrier font que quelque chose se coupe, je ne crois pas que la qualité de notre logiciel devrait même être considérée, ce joli petit trombone animé, par contre ...

Maintenant, si vous travaillez et trouvez que le code avec lequel vous devez interagir n’est pas écrit au niveau que vous êtes actuellement capable d’écrire, il est raisonnable de le réparer SI vous êtes capable de le faire de manière méthodique et contrôlée. Personnellement, j’ai très peu d’expérience dans ce type de refactoring, comme tout le monde (presque tout le monde?), J’ai essayé de "changer tout et de prier pour que ça marche" et je me suis fait mordre assez fort. Je suggérerais d'examiner les discussions de Martin Fowler ( son livre ou l' un des nombreux articles ) sur le sujet. Il semble avoir inspiré l'essentiel de la pensée actuelle sur le processus.

Bien sûr, vous ne pourrez parfois pas nettoyer le code à votre guise. Joel Spolsky a écrit un article sur les raisons pour lesquelles vous pourriez vouloir consacrer quelques semaines à simplement refactoriser votre code. Lisez-le ici et oui, il est un peu vieux, mais je pense que l'information est toujours pertinente.

J'espère que ça aide


1

Je pense que le refactoring / l’amélioration de l’ancien code définit le programmeur lui-même. Vouloir améliorer le code que vous avez écrit il y a un an ne montre que vos progrès, et si cela améliore l'application et que vous avez la capacité, le temps et l'approbation pour l'améliorer, faites-le.


1

Mieux / amélioré est une comparaison multi-axes. Pensez-vous pouvoir rendre les informations plus rapides, plus petites, plus économes en ressources, plus lisibles, plus utiles, des résultats plus précis, plus souples, plus générales, capables de fonctionner sur plus de systèmes, d'éliminer la dépendance à un produit séparé?

Pourquoi votre entreprise devrait-elle vous payer pour passer du temps à réécrire ce code au lieu d'écrire un nouveau code ou de réécrire un autre élément de code?

Vous devez apporter des améliorations à mesure que les opportunités se présentent, mais cela signifie que vous travaillez déjà sur le code ou que vous avez identifié un motif commercial pour effectuer le changement.

Pousser un changement de production introduit une chance non-nulle de casser des choses (les tests unitaires et fonctionnels ne font que réduire cette chance, ils ne l'éliminent pas), et ne devraient être effectués que lorsque le bénéfice escompté l'emporte sur le risque.

Quel est un autre point à considérer - avez-vous l'intention de pousser ce changement à la production, ou simplement à la branche de développement? La barre pour les deux scénarios est complètement différente. Si cela se produit uniquement dans la branche de développement et que la production n’est peut-être jamais lancée, une opportunité signifie essentiellement que vous examinez le code pour une raison quelconque et que cela ne prend pas beaucoup de temps. Il peut être revu si nécessaire si un coup de pouce devait avoir lieu, et laissé de côté si cela est considéré comme injustifié à ce moment - là. Si, en revanche, la production est en cours de production, comme je l’ai dit plus haut, vous devez vous demander si ce changement en vaut la peine: en termes de temps consacré à la mise en place et d’avantages liés à l’utilisation du nouveau code.


Des changements de code de production qui ne sont pas destinés à être poussés dans la production? Mais sont conservés dans la branche de développement? hmm. Ne pense pas que j'accepterais ça. Cela ne servira qu'à confondre et à aggraver les développements ultérieurs, car personne ne saura avec certitude s'il doit être modifié (à nouveau) ou s'il ne doit pas être conforme à d'autres changements destinés à la production.
Marjan Venema

@MarjanVenema: lorsque le développement est arrêté, toutes les branches doivent être identiques. Si par la suite vous voyez quelque chose qui peut être amélioré, mais ne DOIT PAS l’être, améliorez-le dans la branche développement, et attendez que le développement reprenne et qu’un nouvel élan soit fait.
jmoreno

Ah, d'accord, je vois. Pour moi, cela signifie qu'il est toujours destiné à la production, juste après. Et le risque est tout aussi grand, à moins que vous ne vous assuriez que votre système de suivi des problèmes soulève un problème connexe de sorte que le service des testeurs / responsable de la qualité soit également récompensé pour vos «améliorations». Sinon, la production ne sera pas testée car elle évoluera avec d'autres changements.
Marjan Venema

@MarjanVenema: J'aurais peut-être dû dire que j'avais l'intention de le faire passer immédiatement à la production. Si vous êtes convaincu que le changement ne sera jamais poussé à la prod, ne faites pas le changement. Si OTOH, vous êtes incertain, mais le changement se fait facilement et vous êtes déjà là ... faites le changement. En ce qui concerne le suivi et les tests, ceux-ci devaient être couverts par «examinés au besoin».
jmoreno

hmm, je suppose que je choisirais de ne pas faire le changement à moins que cela soit directement lié à ce sur quoi je travaille. Et, comme nous avons une branche par numéro, je sais toujours quand (quelle version) quelque chose entrera en production. De plus, j'estime vraiment que tout changement apporté doit être testé, et non "simplement" révisé selon les besoins. Les évaluations des personnes sur ce qui constitue un risque diffèrent et une deuxième paire d'yeux ne s'égare jamais. Là encore, je travaille principalement sur le code côté serveur où les modifications peuvent affecter de manière subtile les résultats renvoyés aux clients. L'évaluation des risques de modification du code côté client est peut-être beaucoup plus simple.
Marjan Venema

1

Une bonne règle est que si vous avez mis du temps à comprendre ce que fait le code, et si vous pouvez réduire ce temps par des modifications bien choisies, vous répondez aux besoins de l'entreprise et de votre équipe en: prendre ces mesures.

Si le code ne profite pas de votre analyse, si les noms de champ ne sont pas devenus l'expression de l'intention du code et si les méthodes n'ont pas été décomposées en fragments lisibles, l'entreprise a perdu quelque chose de précieux: votre état de compréhension. Avec des outils tels que Visual Studio et ReSharper, ces types de refactorisation sont sûrs, neutres sur le plan logique et peuvent apporter une grande valeur pour la productivité et la confiance futures des développeurs.

Comme le dit l'oncle Bob Martin, "Laissez toujours le terrain de camping plus propre que vous ne l'avez trouvé."


1

C'est une question à poser à la direction de votre entreprise.

Avez-vous le temps et les ressources nécessaires pour revenir en arrière et apporter des modifications à l'ancien code?

Avez-vous le temps et les ressources nécessaires pour qu'une équipe d'assurance qualité vérifie ce que vous avez modifié pour vous assurer qu'elle n'est pas endommagée?

Je suis déjà tombé dans ce piège où je me trouvais dans un module corrigeant un bogue et voyant le code que moi-même ou quelqu'un d'autre écrivait qui était inefficace ou inélégant, changez-le et finissez par avoir plus de problèmes à traiter que si je venais de corriger le bug que je devais corriger.


0

Ça dépend.

Si le code en question est vraiment cassé, de sorte qu'il contienne des bogues qui apparaîtront inévitablement à un moment donné (par exemple, un compteur qui débordera à un moment donné et causera de vilains problèmes), la résolution de ceux-ci peut en valoir la peine - mais si vous faites, mettez d'abord toutes les protections possibles en place pour éviter d'introduire de nouveaux bogues: assurez-vous de disposer de tests unitaires significatifs couvrant tout ce que vous touchez, faites réviser tous vos changements par une personne compétente, insistez pour que les tests soient soigneusement testés, assurez-vous de pouvoir revenir aux anciens version à tout moment, sauvegardez toutes les données avant de commencer la production, déployez-les d'abord dans un environnement d'acceptation et faites-les tester par les utilisateurs réels, etc. Vous voudrez également obtenir l'approbation avant d'aller de l'avant: si le bogue est vraiment une bombe à retardement et votre manager est un peu compétent,vous pourrez le convaincre de vous laisser régler le problème (et si vous n'obtenez pas l'approbation, alors c'est peut-être un signe que vous vous trompez).

OTOH, si votre plainte est un simple manque d'élégance de code, n'osez pas y toucher. Cela fait un bon moment que nous produisons un service fidèle dans la production. Changer le code ne ferait que vous satisfaire, mais n'apporterait aucune valeur ajoutée, et comme tout changement, il y a un risque que vous cassiez quelque chose. Même si vous ne le faites pas, votre temps est précieux (littéralement: vous êtes payé pour ce que vous faites, donc chaque minute de votre temps coûte de l'argent), et comme vous n'apportez aucune valeur réelle, un tel changement serait: une perte nette pour l'entreprise et le projet.

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.