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

Ver. 1.1.2.20200705