Où la refactorisation et l'optimisation du code devraient-elles s'inscrire dans un calendrier de processus agile et en cascade?

Il semble y avoir cette notion parmi l'équipe de gestion de projet selon laquelle «ça marche» signifie qu'elle devrait alors être considérée comme terminée à 100%. La plupart des programmeurs savent que ce n'est pas toujours le cas. Si j'essaie d'autres approches pour faire fonctionner une fonctionnalité, cela ne signifie pas nécessairement que j'ai trouvé la meilleure solution, ou cela ne nécessitera pas de retouches après avoir été examiné avec d'autres développeurs. Je vais souvent en finir avec quelque chose, prendre du recul, puis me demander ce que je peux faire de mieux une fois que les règles commerciales sont satisfaites. Est-ce que ce temps «je peux faire mieux» devrait en fait s'inscrire quelque part dans la chronologie? Je suis d'avis que la meilleure approche est que vous laissez toujours le code mieux que lorsque vous l'avez trouvé (dans une certaine mesure), ce qui pourrait signifier une refactorisation après le lancement. cependant,

Il y a un principe général qui régit le besoin de refactoriser et d'optimiser, à la fois en cascade et en Agile: YAGNI (You Ain't Gonna Need It). Un deuxième principe est le corollaire du premier: "L'optimisation prématurée est la racine de tout mal", l'équivalent codant du proverbe général "l'ennemi de l'excellence est la perfection".

Prenons les principes et appliquons-les. Vous devez créer un algorithme ETL qui prend un fichier d'un type particulier, extrait ses informations, puis place ces informations dans une base de données. Votre objectif pour cette semaine (pour nous, peu importe que vous soyez dans une boutique Agile ou SDLC) est de le faire.

Vous êtes un homme intelligent et vous avez eu un aperçu de la situation dans son ensemble. Vous savez que ce n'est pas le seul type de fichier pour lequel le projet aura besoin d'un ETL. Vous envisagez donc d'implémenter cet algorithme ETL pour travailler également sur un autre type de fichier, qui ne présente que des différences mineures. Cela violerait YAGNI. Votre travail n'est pas de développer l'algorithme pour cet autre fichier; c'est de développer l'algorithme pour le fichier qui est nécessaire d'ici la fin de la semaine. Pour atteindre cet objectif et réussir les tests d'acceptation, vous devez développer cet algorithme et le faire fonctionner correctement. Vous "n'aurez pas besoin" du code supplémentaire pour le faire fonctionner avec l'autre fichier. Vous pensez peut-être que cela vous fera gagner du temps pour l'incorporer maintenant, et vous avez peut-être raison, mais vous pouvez aussi avoir terriblement tort; l'algorithme de l'autre fichier devra peut-être être utilisé dans une zone du système que votre code ne peut pas être utilisé, ou les exigences pour le nouveau fichier peuvent être différentes de la vôtre d'une manière que vous ne connaissez pas (dans Agile, celles peut-être pas encore). En attendant, vous avez perdu du temps et augmenté inutilement la complexité de votre algorithme.

Maintenant, c'est la semaine prochaine, et en récompense douteuse de votre excellent travail sur le premier algorithme, vous avez été chargé de créer les algorithmes pour deux nouveaux types de fichiers. Maintenant, vous avez besoin de code supplémentaire pour que votre algorithme fonctionne avec plus de fichiers. Vous pouvez étendre votre algorithme existant à l'aide d'un modèle de méthode de modèle qui utilisera un modèle de base avec des étapes individuelles spécifiques au fichier, ou vous pouvez simplement dériver une interface commune à partir de votre algorithme existant, en développer deux nouvelles qui suivent l'interface et les connecter à un objet qui peut choisir l'algorithme à utiliser.

Pendant le développement, vous savez que vous avez besoin que le système puisse traiter 10 Ko de données brutes par seconde. Vous effectuez un test de charge et trouvez que votre projet d'algorithme initial gère 8 Ko / s. Eh bien, cela ne va pas passer les AAT. Vous regardez et voyez qu'il y a une structure de boucle de complexité O (mon Dieu) dans votre algorithme; vous le rationalisez et obtenez 12 Ko / s. "Assez bien", pensez-vous, "mais si j'avais une mauvaise boucle dans le code, que puis-je raser?". buzz Vous venez de violer la règle de "l'optimisation prématurée". Votre code fonctionne et répond à toutes les exigences. Vous avez terminé, jusqu'à ce que les exigences soient mises à jour pour exiger 15 Ko / s. Si et quand cela se produit, ALORS vous remontez le code et cherchez des choses à améliorer.

Suivez ce processus simple lors du développement, que ce soit en Agile ou dans des SDLC traditionnels: "Au premier passage, faites-le fonctionner. Au deuxième passage, faites-le joli. Au troisième passage, rendez-le SOLIDE." Cela signifie que, lorsque vous créez une ligne de code pour la première fois, faites en sorte que ce code fasse son travail correctement et sans bogue, mais ne prêtez pas trop d'attention aux règles de conception dans ce code, comme pour tout ce que vous savez en ce moment, vous ' Je ne toucherai plus jamais cette zone. La prochaine fois que vous visiterez cette ligne de code, vous aurez juste fait vos preuves; ce n'est plus une pièce unique du système. Refactorisez-le pour la lisibilité, la concision du code et / ou les principes DRY (vous pouvez avoir copié-collé du code pour faire quelque chose cinq fois; refactorisez-le en une boucle et / ou un appel de méthode). La troisième fois que vous travaillez dans ou autour de cette ligne de code,

si cela fonctionne et a été testé, alors pourquoi le réparer?

Cela peut aller à l'encontre de votre tempérament personnel en tant qu'ingénieur / programmeur, mais si cela fonctionne, quelle valeur commerciale avez-vous pour continuer à l'affiner? Sera-t-il plus facile à entretenir avec le temps? Si c'est le cas, alors en travaillant selon la méthodologie agile, vous devriez être en mesure de créer de nouveaux éléments dans votre backlog pour affiner et refactoriser votre code existant, et ceux-ci seraient priorisés avec les autres éléments du backlog. Cela fait partie de la valeur du processus agile: l'équipe décide ensemble de ce qui est le plus important et de ce qui sera fait ensuite.

Notre équipe suit également ce que nous appelons la «dette technique», donc si vous faites fonctionner quelque chose mais que vous savez que cela pourrait être mieux fait, vous l'enregistrez comme dette technique. Nous utilisons la mêlée, et parfois vous finirez tout le travail dans un sprint tôt (vous devriez terminer un peu tôt environ la moitié du temps si vous êtes assez proche des estimations), mais vous n'avez pas assez de temps pour tirer une toute nouvelle histoire d'utilisateur, nous passons donc le temps supplémentaire à revenir en arrière et à réduire notre dette technique. Il n'est pas suivi officiellement comme nos histoires d'utilisateurs dans notre backlog, et nous pouvons à peu près y travailler chaque fois que nous avons du temps.

C'est aussi plus ou moins un appel au jugement de votre part lorsque vous appelez la tâche "terminée"; si vous n'êtes pas à l'aise avec l'état dans lequel se trouve votre code, ne marquez pas la tâche comme terminée.

Est-ce que ce temps «je peux faire mieux» devrait en fait se situer quelque part dans la chronologie?

Oui.

Juste avant de commencer à coder la prochaine version.

Ne refactorisez pas basé sur "l'intuition".

Refactor basé sur les histoires réelles du prochain sprint.

Ne marquez pas le code comme terminé à 100% tant que vous n'êtes pas satisfait de la refactorisation. Il vous suffit d'évaluer constamment le rapport coût / bénéfice de la refactorisation du code, car si vous étudiez suffisamment, vous verrez toujours des moyens d'améliorer le code.

J'utilise la méthode de refactorisation rouge vert de TDD. Mon refactoring est donc intégré à mon développement. Pour les grands refactorings comme le changement du modèle sous-jacent ou quelque chose de similaire, je demanderais à la direction d'accepter de passer le temps en premier.

La «refactorisation après le lancement» a un coût caché dans les tests de régression et le temps de contrôle qualité que vous ignorez, en plus elle comporte le coût d'opportunité de ne pas travailler sur les bogues signalés et les fonctionnalités et modifications nouvelles / demandées. TANSTAAFL

Si cela en vaut la peine, cela vaut la peine de faire une tâche pour obtenir la priorité via votre processus normal et non comme une exception spéciale. Vous faites partie d'une équipe, après tout, et travaillez sur des objectifs communs et étendez arbitrairement votre horaire pour s'adapter à la correction du code de travail.

Donc, pour une vraie réponse: si vous savez que vous voudrez refactoriser alors planifier ce temps dans le cadre de la tâche. Si vous faites de la mêlée / agile, définissez une tâche de nettoyage. Si vous êtes en cascade / en spirale, faites en sorte que le refactorisateur fasse partie du processus pour réviser le code et accepter les modules.

Si j'essaie d'autres approches pour faire fonctionner une fonctionnalité, cela ne signifie pas nécessairement que j'ai trouvé la meilleure solution,

... Dans ce cas, vous n'avez pas encore terminé à 100% ...

ou cela ne nécessitera pas de retouches après avoir revu avec d'autres développeurs.

Si les révisions de code et les retouches ultérieures font partie de votre cycle de vie de développement, encore une fois, la fonctionnalité n'est pas exécutée tant que toutes ces opérations ne sont pas terminées.

Je vais souvent en finir avec quelque chose, prendre du recul, puis me demander ce que je peux faire de mieux une fois que les règles commerciales sont satisfaites. Est-ce que ce temps «je peux faire mieux» devrait en fait se situer quelque part dans la chronologie?

Ça dépend. Si cela signifie une refactorisation, cela devrait faire partie de la tâche de développement d'origine. Si cela signifie expérimenter avec un algorithme potentiellement meilleur, cela pourrait être une tâche distincte.

Je suis d'avis que la meilleure approche est que vous laissez toujours le code mieux que lorsque vous l'avez trouvé (dans une certaine mesure), ce qui pourrait signifier une refactorisation après le lancement. Cependant, les équipes de projet sont souvent extrêmement mal à l'aise avec cette approche, car là encore, si elle fonctionne et a été testée, pourquoi la corriger?

En bref, car le code peut être cassé à plusieurs niveaux.

C'est une chose que cela fonctionne en ce moment. C'est une chose entièrement différente, qu'elle soit propre, extensible et maintenable à long terme.

Pour des réponses plus détaillées, consultez ce fil .

Pour autant que je puisse voir et lire, c'est une question non résolue. Par conséquent, les réponses d'évitement comme «YAGNI» et les réponses «faites-le bien la première fois». Le fait est qu'il n'y a pas de place dans Agile pour la refactorisation - mais je dirais qu'il devrait y en avoir.

La meilleure réponse jusqu'à présent mentionne la dette technique. Ceci, malheureusement, est une triste réalité des logiciels dans de nombreuses entreprises, où la précipitation à faire avancer les choses, que ce soit dans une méthodologie agile ou non agile est tout à fait commune - mais sous Agile les solutions rapides et sales sont rationalisés comme étant quelque chose de bien: "répond aux exigences commerciales minimales" et "YAGNI" (en ce qui concerne la propreté du code).

Ce serait génial si tout le monde faisait TDD, et ce serait génial si tous les développeurs refactorisaient la deuxième ou la troisième fois comme suggéré par une réponse. Mais cela ne se produit tout simplement pas dans le monde réel. Les développeurs de différents niveaux de compétence ont presque toujours trouvé des coins ronds dans la recherche de solutions rapides. En conséquence, le code se désintègre en montagnes de code incontrôlable qui prend des jours aux nouveaux développeurs juste à déchiffrer, ce qui nuit à la productivité et retarde les délais. Par "non maintenable", j'entends des solutions de copier-coller, 5000 classes de ligne, etc. Et tout ce code et ces correctifs sont tous au cœur de l'entreprise! - Dans ces cas de solutions additives, je dirais, il n'y a rien de tel que YAGNI! Vous allez avoir besoin d'un code propre - TOUJOURS. Si le code n'est pas propre, vous n'en aurez certainement pas besoin - voyez la prophétie auto-réalisatrice? Les développeurs se donneraient beaucoup de mal pour ne pas utiliser ce code du tout parce que c'est trop pénible à regarder. Et le cercle vicieux continue indéfiniment jusqu'à ce que toute la grosse boule de boue doive être jetée et réécrite.

Donc je dis - bien que le refactoring de code ne soit pas un concept Agile de type propre, distinct, digne de sa propre histoire - nous devrions prendre le temps de refactoriser. Certains magasins demandent désormais aux équipes de consacrer 20% de leurs sprints à l'endettement technique. Espérons que les partisans agiles changeront d'avis à propos de YAGNI et feront un lieu de refactorisation en tant qu'activité distincte allouée. Et s'ils l'ont déjà fait et que je n'en ai pas entendu parler, veuillez indiquer où cela est décrit, car je suis très intéressé de savoir.