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

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?

À 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.

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.

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. :-)

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.

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!

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.

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.

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.

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?

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.

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

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.

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.

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é."

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.

Ç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.