Pseudocode Programmeringsproces vs. Test Driven Development

Met Test Driven Development je moet nog steeds moeten doen wat planning in het begin. Het moet in eerste instantie een hoog niveau kijken naar wat je probeert te doen. Niet komen met alle details, maar een idee te krijgen in gewoon Engels van hoe het probleem op te lossen.

Begin dan met het testen van het probleem. Zodra u de test op zijn plaats hebt, beginnen om het te laten passeren. Als het niet eenvoudig om te doen, moet u uw oorspronkelijke plan te herzien. Als er problemen zijn gewoon te herzien. De test is er niet om de oplossing is er te definiëren, zodat u wijzigingen aan te brengen, zodat u een betere oplossing kan hebben, terwijl het waarborgen van de stabiliteit.

Ik zou zeggen dat de beste inzet is om TDD gebruiken. De sleutel is om te beseffen dat TDD betekent niet "sla de planning". TDD betekent doe een beetje van de planning goed om te beginnen, en aan te passen als dat nodig is. Je mag niet eens moeten aanpassen.

In het algemeen vind ik pseudocode relevant wordt pas echt wanneer de code die nodig is om het probleem op te lossen is veel ingewikkelder dat de code die nodig is om de oplossing te testen. Als dit niet het geval is, weet ik niet lopen in de moeilijkheden die u beschrijven als de eenvoudigste ding dat zou kunnen werken is meestal een aanvaardbare oplossing voor de hoeveelheid tijd die de moeite waard om over het probleem.

Als, aan de andere kant, het probleem is ingewikkeld, moet ik nadenken over hoe het te benaderen voordat ik zelfs een eerste naïeve oplossing kan schrijven - ik moet nog plannen voordat ik code; Daarom gebruik ik een combinatie van beide benaderingen: een Engels beschrijving van wat ik in eerste instantie zal schrijven, dan een test harnas, dan naïef oplossing code, dan verfijning.

Ik heb zowel gebruikt samen met Big Upfront Development, hebben ze alle drie hun plaatsen, afhankelijk van zaken zoals taal, team dynamiek en programma grootte / complexiteit.

In dynamische talen (in het bijzonder robijn), ik beveel TDD, het zal u helpen om fouten op te vangen die andere talen tijdens het compileren zou hebben gevangen.

In een grote, complexe systeem, hoe meer ontwerpen je upfront hoe beter je wordt. Het lijkt erop dat wanneer ik ontworpen voor een groot project, elk gebied dat ik met de hand zwaaide en zei: "dit moet redelijk eenvoudig zijn", was een struikelblok punt later in het project.

Als je alleen werkt aan iets kleins in een staticly getypeerde taal, de lijst aanpak is redelijk en bespaart u een groot deel van de tijd over TDD (Test onderhoud is niet gratis, maar het schrijven van de tests in de eerste plaats is niet al te slecht) - Als er geen test in het systeem u werkt, het toevoegen van in tests niet altijd bewonderd en je zou zelfs een aantal ongewenste aandacht te trekken.

Juist omdat de test slaagt, betekent niet dat je klaar bent.

TDD is het best gekenmerkt door Rood - Groen - Refactor .

Het hebben van een test geeft één (of twee) doellijnen. Het is gewoon de eerste, minimale set van eisen. Het echte doel is hetzelfde doel als "Pseudocode Programming Process" of een ontwerp discipline.

Ook is de TDD gedreven door te testen, maar dat betekent niet dat blindelings gedreven door te testen. U kunt herhalen uw testen op dezelfde manier waarop je je code herhalen. Er is geen plaats voor dogmatisch vasthouden aan een domme plannen hier. Dit een een Agile-techniek - dat betekent dat het aan uw team en uw omstandigheden.

Ontwerpen genoeg code om een ​​toetsbare interface. Ontwerpen genoeg tests om zeker te zijn van de interface zal werken. Ontwerpen wat meer tests en wat meer implementatie totdat u de noodzaak om refactoren.

Het echte doel is Goede Software. TDD kan "goedheid" niet uit te sluiten.

Een techniek is niet beperkend mandaat. Een technieken moet worden gezien als een kruk om u te helpen het product goed code. Als ik slimmer waren, rijker en beter kijken, zou ik niet TDD nodig. Maar aangezien ik ben zo dom als ik ben, ik heb een kruk om me refactor helpen.

Voor mij TDD heeft een aas pseudocoding kan het gewoon niet concurreren met - zowel helpen bij het abstract en planning van de ontwikkeling, maar als je eenmaal klaar bent ontwikkeling in TDD land, je nog steeds de unit tests .

AS nuttig een aanpak zoals CC2 beschreven pseudocoding is, het is gewoon niet kan evenaren dat. TDD is slechts de helft over het ontwerpen, het is ook het verstrekken van een rigoureuze steiger kunt u het project naar voren evolueren van. Maar ik zie geen reden waarom je niet kunt pseudocode om de problemen TDD sets op te lossen.

Ik moet niet autonoom te ontwikkelen.
Pseudocode is de mening-moorden.
Het zijn de kleine dood dat project geheugen vergetelheid brengt.
Ik zal het gezicht van mijn 90-methodologie.
Ik zal het mogelijk maken om over mij en door mij.
En als het voorbij is gegaan Ik zal de innerlijke oog om het pad te zien draaien.
Wanneer de pseudocode is gegaan zal er TDD.
Alleen unit-tests zullen blijven.

(Neem me niet Vlam voor dat, ik ben slechts half serieus: P)

Mijn team combineert beide benaderingen en het is een geweldige manier om te ontwikkelen (althans voor ons). We moeten unit tests, want we hebben een grote en complexe software-systeem. Maar de Pseudocode Programming Proces is zonder twijfel de beste aanpak voor het ontwerpen van software die ik ben tegengekomen. Om ze te laten werken samen:

• We beginnen met het schrijven van onze lessen, en vul met een volledig commentaar stub, met in- en uitgangen.
• We maken gebruik van pair codering en peer review als een dialoog te verfijnen en te valideren het ontwerp, nog steeds alleen met de stub.
• Op dit punt hebben we nu beide ontworpen ons systeem en hebben een aantal toetsbare code. Dus we gaan vooruit en schrijf onze unit tests.
• We gaan terug en beginnen met het invullen van de methoden met opmerkingen voor de logica die moet worden geschreven.
• We schrijven code; de tests.

De schoonheid van het is dat tegen de tijd dat we eigenlijk code te schrijven, het grootste deel van het werk van de uitvoering is al gedaan, omdat er zo veel van wat we denken als de uitvoering is eigenlijk code design. Ook de vroege proces vervangt de noodzaak van UML - klasse en stub zijn net zo beschrijvend, plus het zal daadwerkelijk worden gebruikt. En we blijven altijd op het juiste niveau van abstractie.

Het is duidelijk dat het proces is nooit echt helemaal zo lineair als ik heb beschreven - enkele gril van de uitvoering kan betekenen dat we nodig hebben om de high-level design te herzien. Maar in het algemeen, tegen de tijd dat we schrijven unit tests het ontwerp is echt heel stabiel is (bij de methode niveau), dus geen behoefte aan veel van de test herschrijven.