Pseudocode processus de programmation par opposition au développement piloté par les tests

Avec le développement piloté par les tests que vous devriez toujours être en train de faire une planification au début. Il doit d'abord être un regard de haut niveau à ce que vous essayez de faire. Ne pas venir avec tous les détails, mais avoir une idée en anglais plaine de la façon de résoudre le problème.

Puis commencer à tester le problème. Une fois que vous avez le test en place, commencer à faire passer. S'il est pas facile à faire, vous devrez peut-être réviser votre plan initial. S'il y a des problèmes réviser juste. Le test n'est pas là pour définir la solution, il est là pour vous permettre de faire des changements afin que vous puissiez avoir une meilleure solution tout en assurant la stabilité.

Je dirais que le mieux est d'utiliser TDD. La clé est de se rendre compte que TDD ne signifie pas « sauter la planification ». TDD signifie faire un peu de planification pour commencer bien, et ajuster au besoin. Vous pouvez même pas besoin d'ajuster.

En général, je trouve que devient vraiment pseudocode pertinent lorsque le code nécessaire pour résoudre le problème est beaucoup plus compliqué que le code nécessaire pour tester la solution. Si ce n'est pas le cas, je ne lance pas dans les difficultés que vous décrivez comme la chose la plus simple qui pourrait éventuellement travailler est généralement une solution acceptable pour la quantité de temps utile de dépenser sur le problème.

Si, d'autre part, le problème est compliqué, je dois réfléchir à la façon de l'aborder avant que je puisse écrire même une solution naïve initiale - je dois encore planifier avant de code; Par conséquent, j'utilise une combinaison des deux approches: une description anglaise de ce que je vais écrire d' abord, puis un harnais de test, puis le code de la solution naïve, puis raffinement.

Je l'ai utilisé à la fois avec Big Upfront développement, tous les trois ont leur place en fonction de questions telles que la langue, la dynamique de l'équipe et la taille du programme / complexité.

Dans les langages dynamiques (en particulier) Ruby, je recommande fortement TDD, il vous aidera à repérer les erreurs que d'autres langues auraient pris au moment de la compilation.

Dans un grand système complexe, plus vous concevez-Upfront mieux vous serez. Il semble que lorsque j'ai conçu pour un grand projet, tous les domaines que je la main Agité et dit: « cela devrait être assez simple » était un point d'achoppement plus tard dans le projet.

Si vous travaillez seul sur un petit quelque chose dans une langue typé statiquement, l'approche de la liste est raisonnable et vous permettra d'économiser beaucoup de temps sur TDD (entretien de test n'est pas gratuit, bien que l'écriture des tests en premier lieu n'est pas trop mauvais) - Quand il n'y a pas de tests dans le système sur lequel vous travaillez, en ajoutant dans les tests ne sont pas toujours admirés et vous pourriez même attirer une attention non désirée.

Tout simplement parce que le test passe, ne signifie pas que vous avez terminé.

TDD est mieux caractérisée par Rouge - Vert - Refactor .

Avoir un test d'une offre (de deux) lignes de but. Il est juste le premier, ensemble d'exigences minimales. Le véritable objectif est le même objectif que « processus de programmation pseudocode » ou toute discipline de conception.

En outre, le TDD est entraînée par des tests, mais cela ne signifie pas conduit aveuglément par des tests. Vous pouvez itérer votre test de la même manière que vous itérer votre code. Il n'y a pas de place pour l' adhésion dogmatique à un plan muet ici. Cette technique d'une Agile - qui signifie l' adapter à votre équipe et votre situation.

Concevoir un code suffisant pour avoir une interface testable. Concevoir suffisamment de tests pour être sûr de l'interface fonctionnera. Concevoir d'autres tests et une mise en œuvre plus jusqu'à ce que la nécessité de revoir la conception.

Le but réel est le bon logiciel. TDD ne peut pas exclure la « bonté ».

Une technique n'est pas un mandat restrictif. Une des techniques devraient être considérées comme une béquille pour vous aider à produit du bon code. Si j'étais plus intelligent, plus riche et plus beau, je ne aurais pas besoin TDD. Mais depuis que je suis aussi stupide que je suis, je besoin d'une béquille pour me aider refactoring.

Pour moi TDD a un pseudocoding as juste ne peut pas rivaliser avec - à la fois vous aider à planifier abstrait et le développement, mais une fois que vous avez terminé le développement dans les terres TDD vous avez encore les tests unitaires .

une approche que CC2 décrit pseudocoding est, il ne peut pas correspondre aussi utile que. TDD est seulement la moitié sur la conception, il est également fournir un échafaudage rigoureux, vous pouvez faire évoluer le projet avant de. Cependant, je ne vois aucune raison pour laquelle vous ne pouvez pas pseudocode pour résoudre les problèmes ensembles TDD.

Je ne dois pas développer organiquement.
Est le pseudocode tue l'esprit.
Il est la petite mort qui apporte l' oubli de la mémoire du projet.
Je face à ma 90 méthodologie de.
Je permettrai de passer sur moi et à travers moi.
Et quand il est allé passé , je vais tourner l'œil intérieur pour voir son chemin.
Lorsque le pseudocode est allé il sera TDD.
Seuls les tests unitaires restent.

(S'il vous plaît ne me flamme pas, je suis seulement la moitié sérieux: P)

Mon équipe mélange les deux approches et il est un moyen génial de développer (au moins pour nous). Nous avons besoin de tests unitaires parce que nous avons un système logiciel vaste et complexe. Mais le processus de programmation est pseudocode mains vers le bas la meilleure approche pour la conception de logiciels que je suis venu à travers. Pour les faire travailler ensemble:

• Nous commençons par écrire nos cours et remplir avec des talons de méthode entièrement commentée, avec des entrées et des sorties.
• Nous utilisons le codage paire et examen par les pairs comme un dialogue pour affiner et valider la conception, encore que les talons de méthode.
• À ce stade, nous avons maintenant à la fois conçu notre système et ont un code testable. Donc, nous allons de l'avant et écrire nos tests unitaires.
• Nous allons revenir et commencer à remplir les méthodes avec des commentaires pour la logique qui doit être écrit.
• Nous écrire du code; passer les tests.

La beauté de c'est qu'au moment où nous écrivons en fait le code, la plupart des travaux de mise en œuvre est déjà fait, parce qu'il ya tellement de ce que nous pensons que la mise en œuvre est en fait la conception de code. De plus, le processus précoce remplace la nécessité d'UML - talons de classe et de méthode sont tout aussi descriptive, plus il va effectivement être utilisé. Et nous restons toujours au niveau approprié d'abstraction.

Il est évident que le processus est jamais vraiment tout à fait aussi linéaire que je viens de décrire - une bizarrerie de la mise en œuvre peut vouloir dire que nous devons revoir la conception de haut niveau. Mais en général, au moment où nous écrivons l'unité teste la conception est vraiment très stable (au niveau de la méthode), donc pas besoin de beaucoup de ré-écriture de test.