«Développement piloté par les tests» Refactoring Design Complexity

Question

J'étudie actuellement le développement piloté par les tests. Je m'interroge sur une amélioration de la conception si nous refactorisons après le développement de chaque couple d'unités par opposition à des sessions de refactoring dédiées qui sont plus espacées dans le temps. Je suis conscient que la dette technique sera plus importante. Mais je me demande quels autres impacts. Peut-être que le processus de refactoring n'est pas aussi efficace quand il y a un intervalle de temps plus long parce que ...?

Merci ..

Answer 1

Un effet collatéral bénéfique de l'application TDD est que votre design a tendance à être plus mince et plus sain. Donc, les refactorings majeurs deviennent inutiles. À mon avis, c'est l'effet de la conception du système par des tests, de «top» à «down» (où «top» sont les interfaces externes, contraintes et exigences, et «down» sont les implémentations internes et les contrats). Parfois, je suis même confus par TDD signifiant "test conduit design" au lieu de "développement".

Ainsi, les réaménagements sont entraînés par des changements de contraintes et d'exigences, et non par des dettes techniques, qui sont atténuées aux interfaces les plus internes. La portée des changements déterminera l'étendue du refactoring - si cela est vrai, les refactorisations "majeures" ne sont attendues que lorsque les interfaces les plus hautes changent.

Vous avez mentionné les refactorisations planifiées comme une étape d'un cycle de développement à plus long terme. Je pense que c'est une stratégie fragile, non pas parce que nous ne devrions pas nettoyer la dette technique - nous devrions le faire le plus tôt possible, et c'est une pratique au cœur de TDD -, mais parce que c'est risqué . Pour illustrer ceci: comment planifier votre refactoring, comment évalueriez-vous la taille de la dette technique? Que faire si le temps de refactoring estimé n'est pas suffisant? Le système sera-t-il sain si vous supprimez le refactoring pour faire d'autres choses importantes? Ce sont des questions importantes, et pas les seules concernant la gestion technique de la dette. Du point de vue de la gestion des risques, TDD signifie un meilleur contrôle.

Answer 2

J'ai trouvé que itérations courtes combinées avec TDD/intégration continue qui fonctionne le mieux.

itérations longues ont les inconvénients de:

1) Vous perdez la trace de ce que vous travaillez sur 2) Il est difficile d'estimer ce que vous pouvez faire en deux mois vs dire 1 semaine 3) Il donne l'entreprise les détenteurs ont moins de temps pour redonner la priorité aux tâches de développement.

Les cycles courts sont plus faciles: "Je dois faire a et b cette semaine". Vous restez concentré. Vous avez des réunions plus courtes. Votre TDD et l'intégration continue vous tiennent au courant de l'état de votre code.

Par rapport à votre question de refactoring, je pense que vous devriez probablement refactoring au fur et à mesure. Vous ne faites pas les choses dans le mauvais sens pendant quelques semaines avant de vous lancer dans le refactoring. Avec vos tests en place, vous pourrez rapidement voir où votre refactoring brise les choses.

modifier - un autre inconvénient à des cycles de développement plus est que les gens se complaisant: « eh, j'ai 4 semaines font mal tout ça plus tard ... »

Answer 3

Pour la définition de base de TDD, vous écrivez un test d'échec, écrivez la quantité minimale de code qui fera passer le test, refactor, répétez. Il n'y a pas beaucoup de place pour reporter le refactoring.;)

Je pense que c'est pour de nombreuses raisons, principalement pour que les gens comme mon patron ne puissent pas supposer que le mot "refactor" est un mot de code geek-speek pour réécrire. Il est beaucoup plus facile d'écrire une méthode, c'est-à-dire d'obtenir des informations sur le Web. Vous écrivez votre test, le faites passer, puis dites: "Ok, prenez maintenant cette URL codée en dur et déplacez-la en haut de la classe, ou un fichier de propriétés." Combien plus difficile à faire une fois que vous aurez terminé votre cours et pesé plusieurs centaines de lignes de code. Là où la partie design intervient, c'est moins dans la grande dimension "D", au moins dans ma compréhension et dans l'utilisation de TDD, que dans les bonnes pratiques qu'elle encourage et/ou exige. Pour en revenir à mon cas d'utilisation, ok, j'ai ma méthode écrite pour récupérer mes données, maintenant je dois faire quelque chose avec ça, puis-je revenir en arrière et commencer à ajouter du code à ma méthode getData? Non, bien sûr que non, c'est "fait". Je continue et écris une nouvelle méthode ou trois pour faire quelque chose avec les données. Toutes les méthodes sont courtes, à la tâche, testables, bref, un design bien meilleur pour le code.

Je pense que c'est là que la confusion entre en jeu. TDD produit un CODE mieux conçu, qui produira probablement de meilleurs logiciels, mais si la conception globale du SYSTÈME n'est pas bonne, les meilleures pratiques de codage de l'univers ne vont pas un bon produit/système.

YMMV bien sûr.