J'essaie généralement de faire TDD avec peu d'analyse (pas de diagrammes) avant de commencer le codage. Habituellement, je me retrouve à diviser une classe en d'autres classes pour séparer les préoccupations. Je me demande si une analyse plus approfondie empêcherait cela. Je pense qu'une grande partie de l'analyse OO ne peut pas prédire certains de ces cas. Qu'est-ce que tu penses?Analyse orientée objet et différences OOP réelles
"Habituellement, je trouve que je divise une classe en d'autres classes pour dissocier des préoccupations.Je me demande si une analyse plus approfondie empêcherait cela.Je pense qu'une grande partie de l'analyse OO ne peut pas prédire certains de ces cas."
J'ai une expérience similaire à cet égard. TDD ne vous aide pas à concevoir des classes mieux que je n'obtiens pas dans A & D.
Cependant, j'ai trouvé une analyse préalable autant utile. C'est comme poser des fondations avec analyse, puis vous obtenez une conception détaillée pendant le codage.
Certaines choses doivent juste être regardées d'un point de vue plus large.
Je pense que la pré-planification d'une grande partie de la structure de votre classe (et de toutes les différentes interfaces) est extrêmement importante dans la conception/programmation orientée objet. Vous ne trouverez pratiquement pas de livres sur le sujet qui n'exploreront pas d'abord le design en utilisant UML et d'autres méthodes de modélisation avant de plonger dans le code.
Pour moi, la division des classes fait généralement partie d'un processus d'apprentissage. Soit sur le domaine du problème ou le processus de codage. Et d'habitude je le fais en codant. Parfois, j'amène un collègue ou deux à un tableau blanc pour discuter de certaines choses. TDD devrait vous permettre de vous concentrer sur le problème que vous essayez de résoudre.
Le fait que vous apprenez sur la structure du problème lorsque vous le résolvez est une partie intrinsèque de TDD. N'entrez pas dans de grands processus d'analyse/de conception.
La plupart du temps, quand je démarre un projet de programmation/conception, j'ai une bonne idée non seulement de ce que je veux qu'il fasse au début, mais aussi de certaines directions que les exigences sont susceptibles d'évoluer. Cela conduit au choix des fonctionnalités initiales (qui pilotent Test Driven Development) et peut me donner une excuse pour scinder les classes dans une direction qui, je pense, sera utile plus tard.
Si vous commencez simplement à choisir des cas de test de façon aléatoire parmi la vaste liste de fonctionnalités que vous envisagez, la direction de développement de vos classes initiales sera également quelque peu aléatoire. Donc je pense que le fait d'être un développeur expérimenté consiste à choisir les directions avec soin - pas nécessairement avec beaucoup d'analyse formelle, mais au moins par instinct sur les caractéristiques qui vont avoir une importance architecturale au fur et à mesure que le projet grandit. L'un des principaux points de XP et TDD est que vous ne voulez pas passer trop de temps sur les fonctions et les directions qui ne sont pas demandées par vos exigences initiales, puisque le client changera d'avis quand il verra ce que vous avez fait jusqu'ici, alors vous ne voulez pas passer trop de temps à le penser. Mais une partie du développement de vos compétences et de votre instinct en tant que développeur consiste à faire de l'exercice et à accroître votre capacité à prédire quelles informations non divulguées pourraient s'avérer importantes plus tard.
OTOH, la promesse de XP et de refactoring est que vous pouvez résoudre les problèmes dans la factorisation initiale du problème lorsque les exigences vous poussent dans cette direction. Je pense que c'est vrai, mais vous serez toujours un contributeur plus précieux dans la mesure où vous pouvez prendre ces décisions correctement la première fois. Et le faire ressembler à de la chance - "Les tests m'ont forcé à le prendre en compte de cette façon" fait partie de la compétence.