Test-first Codierung
$17.50
Minimal-Preis
$24.50
Empfohlener Preis

Test-first Codierung

Programming with Ease - Teil 1

Über das Buch

Clean Code bedeutet wandlungsfähiger Code. Wandlungsfähigkeit setzt voraus, dass du keine Angst hast, Code zu verändern. Du willst ihn ja nicht unwissentlich verschlimmbessern und das nicht bemerken. Stabilen Code liefern und sofort wissen, wann er reif zur Lieferung ist, sind Grundpfeiler, auf denen deine langfristig hohe Produktivität ruht.

Automatisierte Tests sind seit langem unverzichtbar, wenn es um nachweisbare und nachvollziehbare Korrektheit von Software geht. Leider haben sich automatisierte Tests trotz hervorragender Werkzeugunterstützung und methodischer Empfehlungen wie Test-Driven Development (TDD) und Behavior-Driven Development (BDD) noch nicht als Selbstverständlichkeit durchgesetzt. Die Testabdeckung ist daher in vielen Codebasen, auch frischen, nicht ausreichend, um regressionsfreiheit sicherzustellen. Das Sicherheitsnetz, das automatisierte Tests spannen sollen, damit du darüber angstfrei Codieren kannst, ist weit und/oder löchrig. Woran mag das liegen?

Die Gründe sind sicher vielfältig für dünne Testabdeckung. Einer sticht für mich jedoch heraus: mangelnde Systematik. Es fehlt eine Guideline, wie du als Entwickler, der du mit einem Programmierproblem konfrontiert bist, geradlinig zu testabgedecktem und auch noch ordentlichem Code kommst.

Der red-green-refactor Prozess in TDD ist eine gute Idee - die allerdings in der Praxis von vielen Entwicklern als zu wenig unterstützend erlebt wird. Sie versuchen sich daran zu halten, fühlen sich jedoch schnell entweder allein gelassen oder überfordert bei ihrem Praxisproblem. Aus Frustrations wird dann das Kind mit dem Bade ausgeschüttet und ganz auf automatisierte Tests verzichtet. Oder es wird in der Community nach Hilfe gesucht, die Literatur gewälzt - doch als Antwort wird vor allem "Du musst es eben nochmal und genauer nach den Regeln probieren!" gegeben. Beides ist nicht hilfreich.

Automatisierte Tests sind heute nicht mehr nice to have, sondern gehören zu fachgerechter Arbeitsweise, wenn du professioneller Softwareentwickler sein willst. Sie nicht zu schreiben, sich nicht darum zu bemühen, ist keine Option.

Und mit TDD einfach nochmal und nochmal gegen die Problemwand zu rennen, bringt auch nicht unbedingt die Lösung, sondern erzeugt Frust und Kopfschmerzen. Denn wenn es mit TDD nicht recht klappen will, dann liegt das nicht unbedingt daran, dass du als Entwickler TDD nicht begreifst. Es kann auch daran liegen, dass der TDD Prozess einfach nicht zu deinem Problem passt.

An TDD ist deshalb nichts falsch. Es greift nur schlicht in der Praxis zu kurz. Die Welt der Programmierprobleme ist größer und bunter als das, was in TDD Coding Dojos an kleinen Problemen behandelt wird.

In mehr als 10 Jahren Beschäftigung mit Clean Code Development habe ich mich daher bemüht, ein Vorgehen zu entwickeln, das umfassender und systematischer unterstützt, Probleme in der Codierung zu lösen. Das Motto ist sozusagen: "Keine Angst vor dem blinkenden Cursor in deiner IDE!"

Test-first Codierung als Teil meines Programming with Ease Konzeptes für Clean Code Development nimmt dich an die Hand bei der Bewältigung von Programmierproblemen, die es in fünf Kategorien einteilt:

  • trivial
  • einfach
  • kompliziert
  • komplex
  • chaotisch

Diese Kategorisierung ist an das Cynefin Framework von IBM angelehnt, das Führungskräfte situationsgerecht bei Entscheidungen unterstützen soll.

In der test-first Codierung wird diesen Kategorien aber jeweils ein anderer Problemlösungsansatz zugeordnet. Triviale Probleme gehst du anders an als komplizierte oder komplexe. Klingt logisch, oder? TDD - genauer: classical TDD - hat darin auch seinen Anwendungsfall; doch der ist begrenzt auf nur einen der Problemschwierigkeitsgrade. Und komplexe Probleme sind das nicht.

Gemeinsam ist den Ansätzen für alle Schwierigkeitsgrade, dass du die Codierung mit mindestens einem Test beginnst: dem Akzeptanztest. Deshalb test-first im Titel. Die Begründung ist zwiefach: 1. Wenn du nicht zuerst einen Test schreibst, ist die Wahrscheinlichkeit groß, dass du keinen schreibst. 2. Wenn du dein Denken zuerst auf einen Test richtest, also auf die Außenansicht deiner Lösung, nimmst du die Perspektive eines Benutzers an. Das führt tendenziell zu einer besseren Schnittstelle für deinen Code und zu höherer Testbarkeit.

Test-first Codierung ist aber nicht alles. Es ist nur die letzte Phase eines mehrschrittigen Prozesses, in dem du Anforderungen in hochqualitativen Code umsetzt. Diesen Prozess fasse ich unter dem Titel Programming with Ease zusammen, weil die Programmierung "von Anfang bis Ende" durch mehr Systematik einfacher werden soll.

Allerdings ist Test-first Codierung der erste Band in meiner Programming with Ease Buchreihe. Codierung ist schlicht das, was dir als Softwareentwickler am nächsten liegt und jeden Tag im wahrsten Sinne des Wortes unter den Nägeln brennt. Deshalb will ich dich dabei abholen und unterstützen. Deine Motivation wird bei der Codierung am höchsten sein, etwas Neues zu lernen und deine Gewohnheiten zu verändern. Zumindest hoffe ich das.

Was erwartet dich konkret in diesem Band? Ich habe meine Vorstellung von einem test-first Vorgehen in mehrere Lektionen/Kapitel eingeteilt, die ich auch in Trainings vermittle. Schau dir einfach mal das Inhaltsverzeichnis an. Jedes Kapitel besteht aus einem Erklärungsteil und Übungsaufgaben. Der Text ist mit vielen Codebeispielen und Abbildungen aufgelockert. Insgesamt sollte das Buch dir ca. 8+ Stunden Lesespaß geben. Und zur Bearbeitung der Übungsaufgaben kannst du auch nochmal 12-16 Stunden rechnen. Das meine ich nicht zur Abschreckung, sondern will dir zeigen, dass du hier einiges Material hast, um dich als Software Craftsman solide mit der Thematik Clean Code Development auseinander zu setzen. Das Buch ist ernsthafte Lektüre für deine Weiterbildung.

Schau dir am besten einmal die Probekapitel an; oder stelle Fragen in der Community zum Buch und rund um Clean Code Development. Dann bist du hoffentlich entschlossen, es damit zu versuchen: für mehr Stabilität und Ordnung in deiner Software.

Ich wünsche dir viel Freude bei der Programmierung!

-Ralf Westphal, info@ralfw.de

PS: Wenn du Lust hast, findest du auch einen Überblick darüber, was ich mit Test-first Codierung meine, in einem Youtube-Interview, das David Tielke mit mir geführt hat. In knapp 30 Minuten reiße ich darin die wesentlichen Aspekte des Ansatzes an.

Ver. 1.2.4.20201129

Über den Autor

ralfw
Ralf Westphal

Hallo! Mein Name ist Ralf Westphal und ich bin Autor, Trainer, Coach, Berater, Vortragender in Sachen Clean Code Development seit mehr als 10 Jahren. Das Thema nachhaltige Softwareentwicklung hat mich einfach gepackt. Deshalb habe ich 2008/9 die Clean Code Developer Initiative mitgegründet und engagiere mich seitdem dafür, die Programmierung systematischer und einfacher zu machen. Technologien sind nicht mehr mein Ding; mit denen habe ich mich früher stark auseinander gesetzt, auch als ich noch eine Softwarefirma hatte. Seit mehr als 20 Jahren ist mir das Konzeptionelle und Grundlegende immer wichtiger geworden. Nachdenken über Softwareentwicklung, Neues ausprobieren, Bekanntes zu hinterfragen: daran habe ich Spaß. Deshalb heißt meine Firma auch One Man Think Tank.

Bundles that include this book

$73.50
Suggested Price
$42.50
Paket Preis

Table of Contents

  •  
    • Motivation
      • Programming with Ease
      • Das Softwareuniversum
    • Einleitung
      • Anforderungskategorien
      • It’s the productivity, stupid!
      • Produktivitätskiller
        • Fehlende Korrekheit
        • Fehlender Wert
        • Fehlende Ordnung
      • Zusammenfassung
  • Die Methode
    • 01 - Die Anforderung-Logik Lücke
      • Logik - Der Stoff aus dem Verhalten entsteht
        • Funktionalität
        • Effizienz I - Effizienz durch Algorithmen und Datenstrukturen
        • Effizienz II - Effizienz durch Verteilung
        • Zusammenfassung
      • Von den Anforderungen zur Logik
        • Logik schwer definierbar
        • Die Phasen der Programmierung
        • Zusammenfassung
      • Übungsaufgaben
    • 02 - Vorläufig codieren im Chaos
      • Das Nein der Codierung
      • Prototyping to the Rescue
      • Die Schwierigkeit der Umsetzung einstufen
      • Zusammenfassung
    • 03 - Sofort codieren in der Trivialität
      • Trivialität als Gegenteil von Chaos
      • Vorsicht vor Selbstüberschätzung!
    • 04 - Schrittweise codieren in der Einfachheit
      • Trittsteine legen
        • Pear Programming
      • Die Kunst der Problemskalierung
        • Sichtbarkeit von Variationsdimensionen
        • Variationen ordnen
      • Am Beispiel
      • Zusammenfassung
      • Übungsaufgaben
    • 05 - Komplementär codieren in der Kompliziertheit
      • Zerlegung in komplementäre Teilprobleme
        • Funktionen repräsentieren Lösungen
      • Integration Operation Segregation Principle
      • Zerlegungsbeispiel I
        • Leitfragen für die Zerlegung
        • Analyse & Entwurf
        • Codierung
        • Reflexion
      • Buddelschiff Programmierung
      • Zerlegungsbeispiel II
        • Bottom-up Codierung
        • Reflexion
      • Zusammenfassung
      • Übungsaufgaben
    • 06 - Tests als Treiber der Modularisierung
      • Akzeptanztests
        • Triviale Probleme
        • Einfache Probleme
        • Komplizierte Probleme
      • Gerüsttests
        • Gerüsttestfälle erhalten I - Akzeptanztests
        • Gerüsttestfälle erhalten II - Modultests
      • Zusammenfassung
      • Übungsaufgaben
    • 07 - Testbarkeit steigern mit Surrogaten
      • Logik dynamisch binden
        • Statische Bindung
        • Dynamische Bindung mit Funktionszeigern
        • Dynamische Bindung mit Objekten
        • Zusammenfassung
      • Surrogate in Tests einsetzen
        • Extraktion einer Klasse und Abstraktion mit Interface
        • Injektion einer Objektfabrik
        • Surrogate unterschieben
        • Reflexion
      • IOSP over Surrogates
        • Extraktion eines Belangs
        • Refactoring to Functional Core
        • Schritte in die Objektorientierung
      • Zusammenfassung
      • Übungsaufgaben
    • 08 - Experimentell codieren in der Komplexität
      • Experimentelles Vorgehen im Testcode
        • TDD as if you meant it (TDDaiymi)
      • Beispiel #1: FromRoman revisted
        • Inkrement 1
        • Inkrement 2
        • Inkrement 3
        • Inkrement 4
        • Inkrement 5
        • Inkrement 6
        • Reflexion
      • Beispiel #2: Eine ruhige Bowlingkugel schieben
        • Analyse
        • Codierung
        • Reflexion
      • Zusammenfassung
      • Übungsaufgaben
    • 09 - Test-first refaktorisieren
      • Frustrierende Lektüre
        • Fehlende Bedeutung
        • Fehlende Zusammenhänge
        • Fehlende Testbarkeit
      • Warum refaktorisieren?
        • Softwarewartung erhält Ordnung proaktiv
      • Schrittweise aufräumen I
        • Bestimme das System-to-Refactor (S2R)
        • Refactor to Test-First
      • Schrittweise aufräumen II
        • Refactor to IOSP
        • Refactor to Modules
        • Dokumentieren
        • Reflexion
      • Zusammenfassung
      • Übungsaufgaben
    • 10 - Finale mit Testmatrix
  • Anhang - Musterlösungen
    • Musterlösung: 01 - Die Anforderung-Logik Lücke
      • Aufgabe 1 - Gründe für automatisiertes Testen
        • Beispielhafte Gründe für die Testautomatisierung
        • Beispielhafte Gründe für test-first Testautomatisierung
      • Aufgabe 2 - Eine Anwendung test-first entwickeln
        • Analyse
        • Entwurf der Persistenz
        • Codierung
    • Musterlösung: 04 - Schrittweise codieren in der Einfachheit
      • Aufgabe 1 - Einschätzung des Schwierigkeitsgrades
        • Mathematischen Ausdruck berechnen
        • Game-of-Life
        • NQueen
        • Binärzahlenkonvertierung
      • Aufgabe 2 - Römische Zahlen in Dezimalzahlen wandeln
        • Verständnis dokumentieren
        • Inkrementelle Testfälle definieren
        • Test-first codieren
      • Reflexion
    • Musterlösung: 05 - Komplementär codieren in der Kompliziertheit
      • Aufgabe 1 - Römische Zahlen kompliziert wandeln
        • Zerlegung für Lösungsansatz 1
        • Zerlegung für Lösungsansatz 2
        • Reflexion
      • Aufgabe 2 - Game of Life
        • Verständnis dokumentieren
        • Schrittweise zerlegen
        • Akzeptanztests
        • Teilprobleme bottom-up lösen
        • Reflexion
    • Musterlösung: 06 - Tests als Treiber der Modularisierung
      • Analyse
        • Inkrementelle Teilprobleme
      • Zerlegung der Inkremente inkl. Codierung
        • Akzeptanztest
        • Inkrement I
        • Inkrement II
        • Inkrement III
        • Inkrement IV
        • Inkrement V
        • Reflexion
      • Refaktorisierung mit nachträglicher Modularisierung
      • Zusammenfassung
    • Musterlösung: 07 - Testbarkeit steigern mit Surrogaten
      • Aufgabe 1 - CSV-Daten tabellieren
        • Analyse
        • Planung
        • Umsetzung
        • Reflexion
      • Aufgabe 2 - Game-of-Life
        • Analyse
        • Planung
        • Umsetzung
        • Reflexion
      • Zusammenfassung
    • Musterlösung: 08 - Experimentell codieren in der Komplexität
      • Analyse
      • Planung
        • Zerlegung in Teilprobleme
        • Inkrementelle Testfälle für die komplexen Probleme
      • Codierung
        • Akzeptanztests
        • TDDaiymi - Lange Worte zerschneiden
        • TDDaiymi - Zeilen zusammensetzen
        • Triviale Probleme lösen
        • Integration
        • Refaktorisierung in Module
      • Reflexion
        • Zurückhaltung als Tugend
    • Musterlösung: 09 - Test-first refaktorisieren
      • Abgrenzung des System to Refactor (S2R)
      • Characterization Test
        • S2R Entry Point testbar machen
        • Console kapseln
        • Characterization Test aufsetzen
      • Verantwortlichkeiten identifizieren
      • Entwurf der neuen Codestruktur
      • Funktionen extrahieren
        • Kommandozeilenanalyse
        • HexDump I - Entzerrung der Logik
        • HexDump II - Refactor to IOSP
      • Refactor to Modules
      • Bonus Verbesserungen
        • Auflösung einer logischen Abhängigkeit
        • Fehlerkorrektur in der Ausgabe
      • Zusammenfassung
  • Anmerkungen

Authors have earned$9,681,050writing, publishing and selling on Leanpub, earning 80% royalties while saving up to 25 million pounds of CO2 and up to 46,000 trees.

Erfahren Sie mehr über das Schreiben mit Leanpub

Die bedingungslose Leanpub, Kein Risiko, 100% zufrieden Garantie

Innerhalb von 45 Tagen ab Kauf kannst du dein Geld zu 100% zurückverlangen, bei jedem Leanpub-Kauf, in nur zwei Klicks. Wir bearbeiten die Erstattungen manuell, daher dauert es ein paar Tage, bis der Betrag ankommt.
Lese die kompletten Bedingungen.

Free Updates. DRM Free.

If you buy a Leanpub book, you get free updates for as long as the author updates the book! Many authors use Leanpub to publish their books in-progress, while they are writing them. All readers get free updates, regardless of when they bought the book or how much they paid (including free).

Most Leanpub books are available in PDF (for computers), EPUB (for phones and tablets) and MOBI (for Kindle). The formats that a book includes are shown at the top right corner of this page.

Finally, Leanpub books don't have any DRM copy-protection nonsense, so you can easily read them on any supported device.

Learn more about Leanpub's ebook formats and where to read them

Schreiben und veröffentlichen mit Leanpub

Autoren und Verlage nutzen Leanpub, um erstaunliche Fortschritte zu veröffentlichen und ebooks zu vervollständigen. Sie können Leanpub auch schreiben, veröffentlichen und verkaufen! Leanpub ist eine leistungsstarke Plattform für ernsthafte Autoren und kombiniert einen einfachen, eleganten Schreib- und Publishing-Workflow mit einem Laden, der sich auf den Verkauf von ebooks konzentriert. Leanpub ist eine magische Schreibmaschine für Autoren: Schreiben Sie einfach in Klartext, und um Ihr ebook zu veröffentlichen, klicken Sie einfach auf eine Schaltfläche. Es ist wirklich so einfach.

Erfahren Sie mehr über das Schreiben mit Leanpub