Pseudo-Code-Programmierung Prozess vs. Test Driven Development

Mit Test Driven Development sollten Sie noch eine gewisse Planung am Anfang tun. Es sollte zunächst ein hohes Niveau Blick sein, was Sie zu tun versuchen. Kommen Sie nicht mit allen Details, aber eine Idee in einfachem Englisch bekommen, wie das Problem zu lösen.

Dann starten Sie das Problem zu testen. Sobald Sie den Test an Ort und Stelle haben, beginnen sie Pass. Wenn es nicht einfach zu tun ist, müssen Sie Ihren ursprünglichen Plan zu überarbeiten. Wenn es revidieren Probleme nur. Der Test ist es nicht die Lösung zu definieren, es gibt es, damit Sie Änderungen vornehmen, so dass Sie eine bessere Lösung haben können, während die Stabilität zu gewährleisten.

Ich würde sagen, die beste Wette ist TDD zu verwenden. Der Schlüssel ist, zu erkennen, dass TDD bedeutet nicht „überspringt die Planung“. TDD bedeutet ein wenig Planung tun, um gut zu beginnen, und nach Bedarf anpassen. Sie können nicht einmal einstellen müssen.

Im Allgemeinen finde ich Pseudo-Code nur wirklich relevant wird, wenn der Code erforderlich, um das Problem zu lösen, viel komplizierter ist, dass der Code die Lösung testen erforderlich. Ist dies nicht der Fall ist, führe ich nicht in die Schwierigkeiten, die Sie als die einfachste Sache zu beschreiben, die möglicherweise funktionieren könnte, ist in der Regel eine akzeptable Lösung für die Zeit wert auf das Problem zu verbringen.

Wenn auf der anderen Seite das Problem ist kompliziert, ich brauche zu durchdenken , wie es zu nähern , bevor ich selbst eine anfänglichen naiven Lösung schreiben kann - ich noch bevor ich Code planen; Daher verwende ich eine Kombination beider Ansätze: eine englische Beschreibung dessen , was ich ursprünglich schreiben, dann wird ein Test - Harnisch, dann naive Lösungscode, dann Verfeinerung.

Ich verwendet habe, beide zusammen mit Big Upfront Entwicklung, alle drei haben ihre Plätze je nach Themen wie Sprache, Teamdynamik und Programmgröße / Komplexität.

In dynamischen Sprachen (vor allem Rubin), empfehle ich TDD hoch, wird es Ihnen helfen, Fehler zu fangen, dass andere Sprachen würden bei der Kompilierung gefangen haben.

In einem großen, komplexen System, desto mehr entwerfen Sie im Voraus, desto besser werden Sie. Es scheint so, als ich für ein großes Projekt entworfen, jedes Gebiet, das gäbe ich gewellte und sagte: „Das nach vorne ziemlich gerade sein sollte“ wurde später in dem Projekt einen Stolper Punkt.

Wenn Sie allein auf etwas Kleines in einem staticly typisierte Sprache entfernt ist, ist die Liste Ansatz sinnvoll und werden Ihnen eine Menge Zeit über TDD (Test Wartung sparen ist nicht frei, obwohl in erster Linie die das Schreiben von Tests nicht zu ist schlecht) - Wenn es keine Tests im System sind auf dem Sie arbeiten, in Tests Zugabe ist nicht immer bewundert und Sie vielleicht sogar einige unerwünschte Aufmerksamkeit auf sich ziehen.

Nur weil der Test bestanden wird, bedeutet nicht, du bist fertig.

TDD ist am besten gekennzeichnet durch Rot - Grün - Umgestalten .

einen Test zu haben bietet eine (von zwei) Torlinien. Es ist nur die erste, minimale Menge von Anforderungen. Das eigentliche Ziel ist das gleiche Ziel wie „Pseudocode Programmierung Process“ oder jede Design-Disziplin.

Außerdem wird die TDD angetrieben durch Tests, aber das bedeutet nicht blind getrieben durch Tests. Sie können Ihre Prüfung auf die gleiche Weise Sie Ihren Code iterieren iterieren. Es gibt keinen Platz für dogmatische Festhalten an einem stummen Plan hier. Dies ist eine eine Agile - Technik - die es für Ihr Team und Ihre Umstände bedeutet anzupassen.

Entwerfen Sie genug Code, um eine überprüfbare Schnittstelle zu haben. Entwerfen Sie genug Tests um sicherzustellen, dass die Schnittstelle funktioniert. Entwerfen Sie ein paar mehr Tests und einige weitere Implementierung, bis Sie sehen die Notwendigkeit, Refactoring.

Das eigentliche Ziel ist gute Software. TDD kann nicht ausschließen, „Güte“.

Eine Technik ist kein restriktives Mandat. Eine Technik sollte als Krücke betrachtet werden Ihnen in guten Code zu helfen. Wenn ich klüger, reicher und besser aussehende, würde ich nicht TDD brauchen. Aber da ich so dumm bin, wie ich bin, ich brauche eine Krücke, mir zu helfen Refactoring.

Für mich TDD hat ein Ass pseudocoding kann einfach nicht mithalten - sowohl Ihnen als abstraktes helfen und die Entwicklung planen, aber wenn man die Entwicklung in TDD Land fertig sind Sie noch die Unit - Tests haben .

AS unentbehrlicher Ansatz als CC2 beschrieben pseudocoding ist, kann es einfach nicht lassen. TDD ist nur die Hälfte über die Gestaltung, es ist auch ein strenges Gerüst bietet Ihnen das Projekt entwickeln können uns darauf, von. Ich sehe jedoch keinen Grund, warum Sie nicht Pseudo-Code die Probleme TDD-Sets zu lösen.

Ich darf nicht organisch entwickeln.
Pseudo - Code ist der Geist-Killer.
Es ist der kleine Tod , den Projektspeicher Vergessenheit bringt.
Ich werde meine 90 Methodik gegenüber .
Ich werde es erlauben , über mich zu überholen und durch mich.
Und wenn es vorbei gegangen Ich werde das innere Auge dreht seinen Weg zu sehen.
Wo der Pseudo - Code gegangen ist es TDD werden.
Nur Komponententests bleiben.

(Bitte nicht Flamme mich nicht für das, ich bin nur halb ernst: P)

Mein Team mischt beiden Ansätze und es ist eine wunderbare Art und Weise (zumindest für uns) zu entwickeln. Wir brauchen Unit-Tests, weil wir ein großes und komplexes Softwaresystem haben. Aber der Pseudocode-Programmierung Prozess ist zweifellos der beste Ansatz für Software-Design stoße ich auf habe. Damit sie arbeiten zusammen:

• Wir beginnen unsere Klassen zu schreiben, und füllen mit voll kommentierte Methode Stubs in, mit Ein- und Ausgängen.
• Wir verwenden Paare Codierung und Peer-Review als Dialog, den Entwurf zu verfeinern und zu validieren, nur noch mit den Methoden-Stubs.
• An dieser Stelle haben wir jetzt entwickelt, um sowohl unser System und haben einige überprüfbare Code. Also gehen wir voran und unsere Unit-Tests schreiben.
• Wir gehen zurück und starten in den Verfahren mit Kommentaren für die Logik Füllung, die geschrieben werden muss.
• Wir schreiben Code; Tests bestanden.

Das Schöne daran ist, dass wir tatsächlich durch den Zeitcode zu schreiben, wird der größte Teil der Arbeit der Umsetzung bereits getan, weil so viel von dem, was wir als Implementierung ist tatsächlich Code-Design. Auch der frühe Prozess ersetzt die Notwendigkeit für UML - Klasse und Methoden-Stubs sind nur als beschreibend, und es wird tatsächlich verwendet werden. Und wir immer auf der entsprechenden Ebene der Abstraktion bleiben.

Offensichtlich ist der Prozess ist nie wirklich ganz so linear wie ich beschrieben habe - einige Marotte der Umsetzung kann bedeuten, dass wir die High-Level-Design zu überdenken müssen. Aber im Allgemeinen, durch die Zeit, die wir schreiben Unit-Tests das Design wirklich recht stabil ist (bei der Methode Ebene), so dass keine Notwendigkeit für viele Test Umschreiben.