TDD oder Test-Last? Eine Sache nach der anderen

Dieser Beitrag ist Teil einer Serie, die Sie hier finden können.

Verwalten der vielen Bedenken bei der Programmierung

Programmieren ist eine anspruchsvolle Tätigkeit. Ein Hauptgrund dafür ist die schiere Menge an Bällen, die wir in der Luft halten müssen. Zu jedem Zeitpunkt müssen wir:

• Verstehen Sie das Problem und seinen Kontext
• Entwickeln Sie Lösungen
• Lösungen im Code festhalten
• Verstehen Sie den umgebenden Code
• (Höchstwahrscheinlich) neuen Code in bestehenden Code einfügen
• Machen Sie die Lösung wartbar
• Stellen Sie sicher, dass der Code tut, was er tun soll
• Kommunizieren Sie Ihre Ideen mit anderen Und diese Liste ist nicht vollständig, es gibt wahrscheinlich noch mehr. Wie Sie sehen, ist es eine Menge, die Sie auf einmal im Kopf haben.

Früher habe ich so gearbeitet und mich mit all diesen Problemen gleichzeitig beschäftigt. Ich hatte das Gefühl, in der Komplexität zu ertrinken und war oft überfordert. Es war unangenehm. Irgendwann habe ich das fast akzeptiert - anscheinend ist es das, was es bedeutet, zu programmieren.

[caption id="attachment_79724" align="aligncenter" width="1280"] Kognitive Belastung beim Programmieren[/caption]

Zum Glück muss das nicht sein. Wir können uns von diesen Sorgen befreien und sie einzeln angehen.

Entflechtung von Programmierungsbelangen

Auf den ersten Blick scheinen all die genannten Aktivitäten untrennbar miteinander verbunden zu sein, wie ein großer Klumpen Spaghetti-Code. Aber wenn Sie genauer hinsehen, aus einem anderen Blickwinkel, erkennen Sie die Bruchlinien, an denen die Aktivitäten getrennt werden können. Das Programmieren beginnt, wie verschiedene Aktivitäten auszusehen:

• Das Problem verstehen. Um ein Problem zu lösen, müssen wir es erst einmal richtig begreifen. Was wollen wir mit dem Code, den wir erstellen, erreichen? Wie soll er sich verhalten? Unter welchen Bedingungen? Gibt es Dinge, die er nicht tun soll?
• Lösen Sie das Problem. Hier müssen wir kreativ sein und uns mit den Werkzeugen auskennen, die wir verwenden. Wir müssen sie in den bestehenden Kontext einfügen, was ein Verständnis für den größeren Zusammenhang erfordert. Aber einfach nur das Problem zu lösen, reicht nicht aus. Wir sind noch nicht fertig.
• Entwerfen einer wartbaren Lösung. In den meisten Fällen müssen wir in der Lage sein, den Code weiterzuentwickeln. Das bedeutet, dass wir eine Struktur anwenden und die Lösung für uns und andere verständlich machen müssen. Wir führen Design in unsere Software ein.

Nach dieser Erkenntnis ist es sinnvoll, die Aktivitäten zu trennen. Genau dabei hilft TDD.

TDD zur Trennung von Konzernen

Der Kern von TDD ist sein Mantra: rot, grün, refaktorisieren. Sie gehen von einer Phase zur nächsten in winzigen Iterationen im Umfang von nur Sekunden oder Minuten. Jede Phase zwingt uns dazu, das Problem "mit einem anderen Hut" zu betrachten.

• In Rot bringen wir unser Verständnis des Problems in einem fehlgeschlagenen Test zum Ausdruck, Stück für Stück. Wir konkretisieren das Problem Stück für Stück und legen das gewünschte Verhalten des Systems fest. Hier tragen wir den Hut des Testers.
• Grün ist der Moment, in dem wir die Knöchel knacken und die Tastatur singen lassen. Alles, was uns interessiert, ist die Lösung des kleinen Teils des Puzzles, das wir gerade verstanden haben. Es spielt keine Rolle, wie das Ergebnis aussieht. Wir versuchen nur, die Ziellinie zu erreichen - den Test zu bestehen. Einfach ausgedrückt, wir tragen hier die verschmierte Baseballkappe des Hackers.
• Beim Refactor zoomen wir heraus und schmieden aus dem potenziellen Chaos, das wir im vorherigen Schritt angerichtet haben, etwas, mit dem wir arbeiten können. Hier setzen wir unseren richtigen Ingenieurshut auf.

Ich erkläre den Zyklus gerne so:

Zuerst müssen wir sicherstellen, dass wir das Richtige bauen, dann die Sache bauen und schließlich die Sache richtig bauen.

[caption id="attachment_79723" align="aligncenter" width="1280"] Die kognitive Belastung wird durch die Trennung von Aktivitäten reduziert[/caption]

Wie Sie sehen können, haben diese verschiedenen Phasen unterschiedliche Ziele. Anstatt mit allen drei Anliegen gleichzeitig zu "jonglieren", drängt uns TDD dazu, sie in einer Abfolge von Schritten abzugrenzen. Es ist, als würden wir nicht mehr drei Bälle in der Luft halten, sondern nur noch einen, während wir die anderen in der Hand halten.

Fazit

Brauchen Sie dafür TDD?

Nicht unbedingt, aber wie ich bereits erwähnt habe, gibt TDD Ihnen einen Anstoß in die richtige Richtung.

TDD kann dabei helfen, die Probleme beim Programmieren zu trennen. Es hat mir dabei geholfen und das Programmieren zu einer angenehmeren Erfahrung gemacht. Es hat die kognitive Belastung, mit der ich umgehen musste, drastisch gesenkt. TDD hat die Art und Weise, wie ich das Programmieren betrachte, dauerhaft verändert - es gibt verschiedene Aspekte, die durchlaufen werden müssen.