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,
O(my God)-complexity
si rien d'autre ne m'a fait rire!