Preliminary Remarks on the English Version

This blog is addressed primarily to a German-speaking audience. The blog post „Was ist TCR?“ („What is TCR?“) was also very often clicked from countries that are not German-speaking. That’s why I make an exception and offer an English translation. Since I am a German native speaker, it is likely that the translation is not perfect.

History of Test Driven Development

Kent Beck

is a legendary software pioneer. He is one of the authors and first signatories of the Agile Software Development Manifesto. He is the founder of Extreme Programming (XP) and a rediscoverer of Test Driven Development (TDD).

Beck once read the following in an ancient book about programming:

„Tape“ here does not mean magnetic tapes. These are the tapes that were used to send the output to a teleprinter as a printer.

As an assert() method, the two perforated strips were probably placed on top of each other and held against the light to be checked.

Kent Beck wrote the first xUnit framework in Smalltalk and is considered to be the founder of the modern TDD.

History of Test && Commit || Revert

Now he has discovered a whole new workflow. He calls it TCR and many believe the technique will soon replace TDD. Again the spark came from the outside. Kent Beck had just introduced the programming technique „test && commit“. Here the code is checked in immediately each time after the tests have been successfully executed. The programmer „Oddmund Strømmer“ had the criticism that for reasons of symmetry in failing tests the code had to be removed again (revert), i.e. – „test && commit || revert“. Beck hated this idea, but he was obsessed with trying it out. That’s how TCR came into existence.

So the idea of TCR is that the changes are committed as soon as a new test is green. However, if the test fails, the code is restored to its original state. On September 28, 2018 the article „test && commit || revert“ was published. Thus introduced the new programming technique officially for the first time.

Of course, the idea of deleting code that has just been written is absurd. But for me it’s also absurd to check in a tiny piece of code every time. How do such ideas emerge?

To answer that question, you have to do a little more research.

Birth of a New Idea

During the time on Facebook, which lasted until February 2018, Beck began to think about how 100,000 developers could work simultaneously on the same system. Facebook’s processes were very complex and resulted in unpredictable delays. After leaving Facebook, he returned to Smalltalk. In a project about the syntax tree for the bytecode compiler, he realized that tree transformations were very closely related to scaling issues.

Conways Game of Life inspired him to think that information could spread in a similar way. What if every pixel was a programmer and every change to a pixel was a change to a program? How are these state changes related to the transformations of a syntax tree?

Some years ago Beck worked with Thiago Hirai on the code editor Prune. Surprisingly, it was found that about 100 operations are sufficient to cover all common modification variants that are syntactically correct. A few transformations should therefore be sufficient to keep a program in a „correct“ state. Merge conflicts, such as renaming the same variables to different names, are thus easy to recognize.

Limbo

This is how the idea of Limbo was born. Limbo is also associated in the English language with keeping something floating. Limbo is live, shared programming in which the focus of the following two principles is constantly kept in balance:

1. Everyone works on the same executable program, which is represented by a syntax tree.
2. No one is allowed to cause problems for others (including the users).

Tiny changes to the code base spread permanently along the syntax tree, as in Conway’s Game of Life and like living organisms.

Many questions are still open and there is still no tool that couples directly to the syntax tree. Changes would then only be possible as tree conversions. Limbo is currently still a thought experiment – a learning exercise.

To get practical experience, Beck encouraged his fans to experiment with GIT and source editors. He just wanted to see what Limbo feels like and what incentives it creates. He created Limbo on the cheap tour. He describes the use of GIT in the article „Limbo on the Cheap“ with the pun „(ab)using GIT

Rather than have tree transformations zipping around modifying the program, we chose to use Git. Both pairs cloned the same remote repository. Then we ran the following shell script:

while(true);
do
git pull –rebase;
git push;
done;

How would we make sure we didn’t break each others’ code? We wouldn’t propagate changes unless all the tests pass. After every change, we ran this script:

test && git commit -am working

The “test” script builds the system, runs the tests, and only returns 0 if all the tests pass. (We actually reverted if the tests failed, but that is a tale for a different article.)

Kent Beck – Limbo on the Cheap

TCR vs. TDD

That brings me back to the beginning of the story. The idea of the programmer Oddmund Strømmer led to the GIT command being changed to „test && commit || revert“. That’s how TCR was born. If a test is not successful, the just written code will be deleted. Thus all tests remain permanently green. By the way, Beck thinks that activating the undo function is cheating.

For TDD a test is always written first and then productive code. The first test must always be a failing test. Syntax errors are also included. For example, a function that does not yet exist is already used as an assert parameter. This state is called „red“. The next step is to implement exactly enough productive code for the test to run successfully. It is therefore a change of state to „green“. If necessary, a code „refactor“ for clean code follows. The rule is: „First make it work then make it right“. Such a cycle should only last a few minutes.

A typical beginner’s misconception with TDD is that the tests are formulated in such a way that a large amount of productive code has to be written to fulfill them. You do too many steps at once. This goes beyond the recommended time frame for a cycle. But even worse, the intermediate steps are untested. If the resulting productive code does not turn green unexpectedly during testing, you don’t know which intermediate step caused it. You have to work with the debugger again. The use of a debugger is always a symptom of not having understood the TDD technique properly.

Unlike TDD, TCR forces small steps. Who wants to risk the loss of a large amount of code? As an educational approach this is very welcome.

TDD has no instructions or recommendations for checking in code. A software developer who checks in code with syntax errors is considered as a codebreaker. A codebreaker causes problems for others in the team. This is especially the case, if the codebreaker checks in code shortly before the end of the workday, and is then no longer available. In order to be able to continue working, a solution must be found very quickly. This is often solved with a revert. At TDD you are already a codebreaker if any test becomes red. Therefore a local build run should always be executed before checking in, which recompiles all test suites and executes all tests.

This usually takes as long as there is time to drink a cup of coffee.

Typically, merging code (merging) leads to conflicts that lead to errors or cannot be resolved. The larger the amount of code and the less often the main branch is checked in, the larger and more problematic these conflicts become. With TCR, this problem can practically no longer occur. I cannot accept the excuse that it takes too long to run all the tests. Only the tests that are affected by the code changes have to be executed. Otherwise a nightly build is adequate.

TDD Is Dead, Long Live TCR

Is TCR now the new TDD? Should you learn TDD at all, or should you switch to TCR immediately? In a French blog I already read the headline „TDD est mort longue vie TCR?“. (Google translation: „TDD is dead, long life TCR?“ sic!).

No, TCR, unlike TDD, will not have any practical relevance. At least not in the currently practiced form. TCR is only an experiment for the future Limbo. The misuse of GIT causes many practical problems. GIT was never designed to check in code in tiny pieces. The commit protocols can hardly be used to document a code history.

Even without GIT, the TCR workflow currently performs even worse than TDD. Two benefits mentioned above are currently in contrast to serious problems. The main downside of pure TCR is that you can no longer see what mistakes you have made.

A Test-First method at TDD, with an initial failing test, guides the programmer like a guide beam to the target. Of course TDD is not an automatism to solve problems, as sometimes the impression is given. However, TDD is very helpful in focusing to the problem. You always have the next step to the solution in mind. TDD is directed towards the future solution. TCR, on the other hand, is always oriented towards the present.

Another downside of TCR compared to TDD is that it tempts you to do the tests after implementing the productive code. As long as you don’t do tests and as long as you don’t make syntax errors, everything is checked in. If you do the tests beforehand, they are the ones that destroy the code. If, on the other hand, you later write the test for buggy production code, the test is deleted instead of the bad implementation.

False Negative

This leads directly to the most serious downside of TCR. What if at the beginning of a TDD cycle, instead of the expected failing test, a green signal suddenly appears?

Then something goes terribly wrong. Red alert! The test threatens to derail. The worst mistake you can make with TDD are defective tests with false negative results.

To reduce this danger, we follow the advice of Kent Beck: „Never write a single line of code unless you have a failing automated test.“ ( Highlighting by me.)

I strongly recommend: Do not use TCR for commercial software development.

Hybrid TDD/TCR

I don’t know how GIT can help you to keep the „rules of the game“ and avoid the risk of false negative tests. My idea to solve these problems is a kind of hybrid TCR. A combination of TDD and TCR.

The developers work as usual with their local repository and run TDD. Each time a TDD test turns green, this triggers a TCR background process on the shared code. Almost always these tests would have to turn green just as successfully and thus lead to a final commit. At the same time, this background process ensures that the repository on the local workstation is synchronized with the current shared code.

In exceptional cases, a test fails even though it was successful locally. This can only occur if a conflict has occurred in the meantime. Developers receive a signal saying: „An immediate conflict resolution is required!“

A positive educational effect of TCR is thus also present, because conflict prevention is the fundamental aim. The conflict frequency is the lower and the conflict solutions are the easier the smaller the TDD cycles are.

Such a hybrid solution cannot simply be implemented via a GIT command. However, the effort required to implement it is much less than the effort required to implement Limbo.

The Forthcoming Limbo

Limbo’s a great idea. But a lot of effort is needed to make it a reality. Since each programming language has its own syntax, a separate Limbo must be created for each supported programming language. Actually, even a specially tailored development system is required, which supports collaborative editing to create graphical user interfaces. It would be easier to create a new programming language and development environment especially for Limbo. But then you have an acceptance problem.

I assume Kent Beck’s Limbo will be realized one day. TCR does not have to be included. An optimal Limbo development system only offers tree transformations that are syntactically and semantically correct. Tests and productive code are thus created practically in parallel.

The idea of Limbo should then also consider other requirements such as code reviews. Suppose we had a tool similar to Google Docs and we used it to collaboratively write a story in natural language. Suppose there was a group of proofreaders in addition to the group of text writers. They prevent a text from containing syntactic or semantic errors and becoming visible to everyone in this tool. Is the final text really good? Actually there should be another group. Editors who, on another level, only allow the satisfactory text to pass through. This corresponds to a code review. In addition, there could be another group that decides at the next level which parts of the story are so good that you can earn money by publishing them.

n my opinion Limbo should implement such a pipeline for different code layers. In a metaphorical sense this would be a kind of three-dimensional Game of Life.

Limbo has a promising future, but it doesn’t start tomorrow.

Update from 22 February 2019

There is a very interesting contribution by Thomas Deniffel, who also showed a presentation about TCR on 21. February at the Munich Meetup. In the medium article „All Downsides and Open Questions of TCR“ which is still open, downsides and open questions are listed which he encountered in his workshops and discussions. He does not do this because he wants to discredit TCR. On the contrary, he is committed and very open-minded towards TCR and Limbo. I also think it is very constructive to address problems openly. Some of the downsides mentioned there have already been mentioned in this blog post. But most of it is new or differently presented. IMHO: It’s worth looking for solutions. Limbo has the potential to trigger a second revolution in sustainable software development and TCR is the avantgarde.

Original article: Was ist TCR?

Der Beitrag What Is TCR? erschien zuerst auf Software Sunshine Blog.

TCR wurde von Kent Beck vor Kurzem als neue Programmiertechnik vorgestellt. TCR wird derzeit als Nachfolger von Test Driven Development (TDD) gehandelt. Dieser Artikel beschreibt wie TCR entstanden ist und was der Unterschied zwischen TCR und TDD ist. Es werden die Vorteile und Nachteile der beiden Arbeitstechniken gegenübergestellt und es werden eigene Ideen zur Diskussion gestellt.

Entstehung von Test Driven Development

Kent Beck

ist ein legendärer Software-Pionier. Er ist einer der Autoren und Erstunterzeichner des Manifests für agile Software-Entwicklung. Er ist Begründer von Extreme Programming (XP) und er ist Wiederentdecker von Test Driven Development (TDD).

In einem uralten Buch über Programmierung las Beck einst das Folgende:

… you take the input tape, manually type in the output tape you expect, then program until the actual output tape matches the expected output.

Unbekannte Quelle

Mit „tape” sind hier nicht etwa Magnetbänder gemeint. Es sind die Lochstreifenbänder, die dazu dienten die Ausgabe an einen Fernschreiber als Drucker zu leiten.

Als Assert-Methode legte man vermutlich die beiden Lochstreifen übereinander und hielt sie zur Überprüfung gegen das Licht.

Kent Beck schrieb das erste xUnit-Framework in Smalltalk und gilt damit als der Gründer des modernen TDD.

Entstehung von test && commit || revert

Jetzt hat er einen ganz neuen Workflow entdeckt. Er nennt ihn TCR und viele glauben diese Technik wird TDD bald ersetzen. Wieder kam der zündende Funken von außen. Kent Beck hatte gerade die Programmiermethode „test && commit“ eingeführt. Hierbei wird der Code jedes Mal sofort eingecheckt nachdem die Tests erfolgreich ausgeführt worden sind. Der Programmierer „Oddmund Strømmer” hatte den Einwand, dass man aus Gründen der Symmetrie bei Failing-Tests den Code dann wieder entfernen müsse (revert), also -„test && commit || revert“. Beck hasste diese Idee, trotzdem war er versessen darauf es auszuprobieren. So entstand TCR.

Die Idee von TCR ist also, sobald ein neuer Test grün ist, werden die Änderungen committed. Schlägt aber der Test fehl, wird der Code wieder in den Ausgangszustand zurückversetzt. Am 28. September 2018 erschien der Artikel „test && commit || revert”.  Darin wurde die neue Programmiermethode erstmals offiziell vorgestellt.

Natürlich ist die Vorstellung, gerade eben geschriebenen Code wieder zu löschen absurd. Für mich ist aber ebenso absurd, bei einem winzigen Stückchen Code jedes Mal einzuchecken. Wie entstehen solche Ideen?

Um diese Frage zu beantworten, muss man etwas weiter ausholen.

Anfänge einer neuen Idee

Während der Zeit bei Facebook, die bis Februar 2018 ging, begann Beck darüber nachzudenken, wie 100.000 Entwickler gleichzeitig am selben System zusammenarbeiten könnten. Die Prozesse bei Facebook waren sehr umständlich und führten zu unvorhersehbaren Verzögerungen. Nach seinem Ausscheiden bei Facebook  konzentrierte er sich wieder auf Smalltalk. Bei einem Projekt, bei dem es um den Syntaxbaum für den Bytecode-Compiler ging, erkannte er, dass Baumtransformationen sehr eng mit den Fragen zur Skalierung zusammenhängen.

Conways Game of Life inspirierten ihn zu dem Gedanken, dass sich auf ähnliche Weise Informationen ausbreiten können. Was ist wenn jeder Pixel ein Programmierer wäre und wenn jede Änderung eines Pixels eine Änderung eines Programms wäre? Wie hängen diese Zustandsänderungen mit den Transformationen eines Syntaxbaumes zusammen?

Beck arbeitete vor einigen Jahren mit Thiago Hirai an dem Code Editor Prune. Es zeigte sich überraschenderweise, dass das circa 100 Operationen ausreichen, um alle gängigen Änderungsvarianten, die syntaktisch korrekt sind,  abzudecken. Wenige Transformationen sollten also genügen, um ein Programm in einem „korrekten” Zustand zu belassen. Merge-Konflikte wie zum Beispiel das Umbenennen derselben Variablen in verschiedenen Namen sind damit leicht zu erkennen.

Limbo

Es entstand so die Idee von Limbo. Limbo wird in der englischen Sprache auch damit assoziiert, ewas in der Schwebe zu halten. Limbo ist live, shared programming, bei dem der Schwerpunkt der beiden folgenden Prinzipien ständig im Gleichgewicht gehalten wird:

1. Jeder arbeitet an dem selben lauffähigen Programm, welches durch einen Syntaxbaum repräsentiert wird.
2. Niemand darf anderen (einschließlich der Anwender) Probleme bereiten.

Winzige Änderungen der Codebasis verbreiten sich permanent entlang des Syntaxbaumes, so wie bei Conways Game of Life und wie bei einem lebenden Organismus.

Noch sind viele Fragen offen und noch gibt es kein Tool, welches fix an den Syntaxbaum ankoppelt. Änderungen wären dann nur noch als Baumumwandlungen möglich. Limbo ist derzeit noch ein Gedankenexperiment – eine Lernübung.

Um praktische Erfahrungen zu sammeln, ermutigte Beck seine Fans mit GIT und Quelltexteditor zu experimentieren. Eigentlich wollte er nur sehen, wie Limbo sich anfühlt und welche Anreize es schafft. Er schuf Limbo auf die billige Tour. Die Verwendung von GIT beschreibt er im Artikel „Limbo on the Cheap“ mit dem Wortspiel „(ab)using GIT”

Rather than have tree transformations zipping around modifying the program, we chose to use Git. Both pairs cloned the same remote repository. Then we ran the following shell script:

while(true);
do
git pull –rebase;
git push;
done;

How would we make sure we didn’t break each others’ code? We wouldn’t propagate changes unless all the tests pass. After every change, we ran this script:

test && git commit -am working

The “test” script builds the system, runs the tests, and only returns 0 if all the tests pass. (We actually reverted if the tests failed, but that is a tale for a different article.)

Kent Beck – Limbo on the Cheap

TCR vs. TDD

Damit bin ich wieder am Anfang der Geschichte. Die Idee des Programmierers Oddmund Strømmer führte nämlich dazu, dass das GIT Kommando abgeändert wurde zu „test && commit || revert”. So entstand TCR. Ist ein Test nicht erfolgreich, so führt dies zum Löschen des gerade eben geschriebenen Codes. Somit bleiben alle Tests permanent grün. Das Betätigen der Undo-Funktion hält Beck übrigens für Schummeln.

Bei TDD wird immer zuerst ein Test geschrieben und dann erst produktiver Code. Der erste Test muss immer ein Failing-Test sein. Auch Syntaxfehler zählen dazu. Beispielsweise wird eine noch nicht vorhandene Funktion bereits als Assert-Parameter verwendet. Dieser Zustand heißt „red”. Als nächstes wird genau soviel Produktivcode implementiert, dass der Test erfolgreich durchläuft. Es ist also eine Zustandsänderung auf „green”. Falls nötig folgt nun ein Code „refactor“ für Clean Code. Das Motto lautet: „First make it work then make it right”. Solch ein Zyklus sollte nur wenige Minuten dauern.

Ein typischer Anfängerfehler bei TDD ist, dass man die Tests so formuliert, dass für ihre Erfüllung eine große Menge produktiver Code geschrieben werden muss. Man macht dabei zuviele Schritte auf einmal. Das sprengt den empfohlenen Zeitrahmen für einen Zyklus. Aber noch schlimmer ist dabei, dass die Zwischenschritte ungetestet sind. Falls so entstandener produktiver Code dann unerwartet beim Test nicht grün wird, weiß man nicht, an welchem Zwischenschritt das lag. Man muss wieder mit dem Debugger arbeiten. Das Verwenden eines Debuggers ist immer ein Symptom dafür, dass man die TDD-Technik noch nicht richtig beherrscht.

TCR zwingt im Unterschied zu TDD zu kleinen Schritten. Wer will schon den Verlust eines größeren Happen Codes riskieren. Als erzieherischer Ansatz ist dies sehr begrüßenswert.

TDD macht keine Vorschriften oder Empfehlungen zum Einchecken von Code. Wer als Softwareentwickler Code mit Syntaxfehlern eincheckt, der gilt als Codebreaker. Ein Codebreaker bereitet anderen im Team Probleme. Das gilt erst recht, wenn er kurz vor Feierabend eincheckt und dann nicht mehr erreichbar ist. Um überhaupt weiterarbeiten zu können, muss kurzfristig eine Löung gefunden werden. Das geschieht dann häufig über einen Revert. Bei TDD ist man auch schon ein Codebreaker, wenn irgendein Test rot wird. Daher sollte vor dem Einchecken ein lokaler Build-Lauf ausgeführt werden, der alle Test-Suites erneut compiliert und alle Tests ausführt.

Das dauert in der Regel solange, dass die Zeit dafür reicht, einen Kaffee zu trinken.

Typischerweise kommt es beim Zusammenführen von Code (Merge) zu Konflikten, die zu Fehlern führen oder nicht mehr aufgelöst werden können. Je größer die Menge Code ist und je je seltener in den Haupt-Branch eingecheckt wird, desto größer und problematischer sind diese Konflikte. Durch TCR kann dieses Problem praktisch nicht mehr entstehen. Den Einwand, es dauert zu lange, bis die Tests alle ausgeführt werden, kann ich nicht gelten lassen. Es müssen ja immer nur die Tests ausgeführt werden, die von den Codeänderungen betroffen sind. Ansonsten reicht ein Nightly Build.

„TDD ist tot, lang lebe TCR“

Ist TCR nun das neue TDD? Soll man überhaupt noch TDD lernen, oder soll man gleich auf TCR umsteigen? In einem französischen Blog las ich schon die Schlagzeile „TDD est mort longue vie TCR?“. (Google Übersetzung: „TDD ist tot, lang lebe TCR“).

Nein, TCR wird im Unterschied zu TDD keine praktische Relevanz erhalten. Zumindest nicht in der gegenwärtig praktizierten Form. TCR ist lediglich ein Experiment für das zukünftige Limbo. Die missbräuchliche Verwendung von GIT verursacht viele praktische Probleme. GIT war nie dafür ausgelegt, Code in winzigen Häppchen einzuchecken. Die Commit-Protokolle lassen sich so kaum noch zur Dokumentation einer Code-Historie nutzen.

Auch ohne GIT schneidet der TCR Workflow im Vergleich zu TDD momentan noch schlechter ab. Den beiden o.g. Vorteilen stehen derzeit noch gravierende Nachteile entgegen. Der Hauptnachteil von reinem TCR ist, dass man nicht mehr sieht, welche Fehler man gemacht hat.

Die Test-First-Methode bei TDD, mit einem anfänglichen Failing-Test, führt den Programmierer wie ein Leitstrahl zum Ziel. Natürlich ist TDD kein Automatismus zum Lösen von Problemen, wie manchmal der Eindruck erweckt wird. TDD ist jedoch sehr hilfreich beim Fokussieren auf das Problem. Ständig hat man den nächsten Schritt zur Lösung vor Augen. TDD ist auf die künftige Lösung gerichtet. TCR ist dagegen immer nur auf die Gegenwart bezogen.

Ein weiterer Nachteil von TCR im Unterschied zu TDD ist, dass es einen dazu verführt, die Tests nach der Implementierung des produktiven Codes zu machen. Solange man keine Tests macht und solange man keine Syntaxfehler macht, wird alles eingecheckt. Macht man die Tests vorher, wie es sich gehört, dann sind sie es die den Code zerstören. Macht man dagegen im nachhinein einen richtigen Test für fehlerhaften produktiven Code, dann wird der Test anstatt der fehlerhaften Implementierung gelöscht.

Falsch negativ

Das führt nun direkt zum gravierendsten Nachteil von TCR. Was ist, wenn bei Beginn von einem TDD-Zyklus, statt des erwarteten Failing-Tests, plötzlich grün signalisiert wird?

Dann läuft etwas ganz entsetzlich schief. Alarmstufe rot! Der Test droht zu entgleisen. Der schlimmste Fehler, den man bei TDD machen kann, sind fehlerhafte Tests mit falsch negativen Resultaten.

Um diese Gefahr zu reduzieren, befolgen wir den Ratschlag von Kent Beck: „Never write a single line of code unless you have a failing automated test.“ (Hervorhebung von mir.)

Ich empfehle daher, bei kommerzieller Softwareentwicklung TCR vorerst nicht einzusetzen.

Hybrides TDD/TCR

Ich weiß nicht, wie man es mit GIT schaffen will, die „Spielregeln“ einzuhalten und die Gefahr von falsch negativen Tests zu vermeiden. Meine Idee zur Lösung dieser Probleme ist eine Art hybrides TCR. Eine Kombination aus TDD und TCR.

Die Entwickler arbeiten wie gewohnt mit ihrem lokalen Repository und betreiben TDD. Jedes Mal, wenn ein TDD-Test grün wird, startet automatisch ein Hintergrundprozess, der TCR auf dem shared Code durchführt. Fast immer müssten dann auch diese Tests ebenso erfolgreich grün werden und dadurch zu einem endgültigen Commit bewirken. Gleichzeitig sorgt dieser Hintergrundprozess dafür, dass das Repository auf dem lokalen Arbeitsplatz mit dem aktuellen shared Code synchronisiert wird.

In Ausnahmefällen schlägt ein Test fehl, obwohl er lokal erfolgreich war. Das kann nur bei einem zwischenzeitlich entstandenen Konflikt vorkommen. Der Entwickler bekommt signalisiert: „Es ist eine sofortige Konfliktlösung erforderlich.“

Der vorteilhafte erzieherische Effekt von TCR ist damit ebenfalls vorhanden, weil grundsätzlich eine Konfliktvermeidung angestrebt wird. Die Konflikthäufigkeit ist um so geringer und die Konfliktlösungen sind umso einfacher je kleiner die TDD-Zyklen sind.

Eine derartige hybride Lösung lässt sich nicht einfach über ein GIT-Kommando realisieren. Der Aufwand zur Umsetzung ist aber sehr viel geringer als die Realisierung von Limbo.

Das zukünftige Limbo

Limbo ist eine großartige Idee. Zur Verwirklichung sind aber noch viele Anstrengungen erforderlich. Da jede Programmiersprache ihre eigene Syntax hat, muss auch für jede unterstützte Programmiersprache ein eigenes Limbo geschaffen werden. Eigentlich ist sogar ein speziell zugeschnittenes Entwicklungssystem erforderlich, welches das kollaborative Bearbeiten zum Erstellen von grafischen Benutzeroberflächen unterstützt. Einfacher wäre es, eine neue Programmiersprache samt Entwicklungsumgebung speziell für Limbo zu schaffen. Dann hat man aber ein Akzeptanzproblem.

Ich gehe davon aus, dass Kent Becks Limbo eines Tages realisiert wird. TCR muss darin nicht enthalten sein. Ein optimales Limbo-Entwicklungssystem bietet nur die Baumtransformationen an, die syntaktisch und semantisch korrekt sind. Tests und produktiver Code entstehen dadurch praktisch parallel.

Die Idee von Limbo sollte dann auch noch weitere Anforderungen wie z.B. Code-Reviews berücksichtigen. Angenommen, wir hätten ein Tool ähnlich wie Google Docs und wir würden es dazu verwenden, um kollaborativ eine Geschichte in natürlicher Sprache zu schreiben. Angenommen, es gäbe neben der Gruppe der Texterfasser auch eine Gruppe von Korrektoren. Sie verhindern, dass ein Text der syntaktische oder semantische Fehler enthält und in diesem Tool für alle sichtbar wird. Ist dann der so entstandene Text auch wirklich gut? Eigentlich müsste es dann eine weitere Gruppe geben. Lektoren, die auf einer anderen Ebene nur den zufriedenstellenden Text durchlassen. Das entspricht einem Code-Review. Darüber hinaus könnte es eine weitere Gruppe geben, die auf der nächsten Ebene entscheidet, welche Bestandteile der Story so gut sind, dass man damit auch Geld verdienen kann, wenn man sie veröffentlicht.

Limbo sollte meiner Meinung nach eine solche Pipeline für unterschiedliche Code-Schichten implementieren. Im metaphorischen Sinne wäre das dann eine Art dreidimensionales Game of Life.

Limbo hat Zukunft, aber die beginnt noch nicht morgen.

Update vom 22.02.2019

Es gibt einen sehr interessanten Beitrag von Thomas Deniffel, der am 21.02 auch eine Präsentation beim Münchner Meetup zum Thema TCR zeigte. In dem jetzt noch offenen Medium-Artikel „All Downsides and Open Questions of TCR“ werden Nachteile und offene Fragen aufgelistet, die ihm bei seinen Workshops und Diskussionen begegnet sind. Er macht das nicht, weil er TCR schlechtreden will. Im Gegenteil er ist engagagiert und gegenüber TCR und Limbo sehr aufgeschlossen eingestellt. Ich halte es auch für sehr konstruktiv, Probleme offen anzusprechen. Manche dort genannten Nachteile sind auch bereits in diesem Blog-Post angesprochen worden. Das meiste ist aber neu oder anders dargestellt. IMHO: Es lohnt sich, nach Lösungen zu suchen. Limbo hat das Potential, eine zweite Revolution für nachhaltige Softwareentwicklung auszulösen und TCR ist hierbei die Avantgarde.

Vorheriger Beitrag: Besserer Clean Code mit nachhaltiger Softwareentwicklung

Der Beitrag Was ist TCR? erschien zuerst auf Software Sunshine Blog.

Mein erster Blogbeitrag

Nun ist es endlich soweit. Mein Blog ist Online. Es kann schon mal losgehen. Es geht in diesem Blog um das Thema nachhaltige Softwareentwicklung. Aber warum der Name „Software Sunshine Blog“? Das bleibt zunächst noch mein Geheimnis.

Nachhaltige Softwareentwicklung ist nicht das gleiche wie nachhaltige Software

Bei dem Begriff „Nachhaltige Softwareentwicklung“ ist die Nachhaltigkeit bei der Entwicklung der Software gemeint. Also nicht etwa die Nachhaltigkeit der Software selbst. Somit möchte ich mich eindeutig vom Begriff „nachhaltiger Software“ (ohne das zweite Substantiv „Entwicklung“) abgrenzen. Unter diesem Begriff versteht man so eine Art „grüne“ Software. Damit will man vermeiden, den Prozessor zum Heizelement zu machen.

Es geht also um die Nachhaltigkeit bei der Entwicklung von Software und dessen Ergebnis, dem Programm-Quellcode. Es ist der Sourcecode, der nachhaltig sein soll. Er soll auch im weiteren Entwicklungsprozess nachhaltig bleiben. Nachhaltig ist nicht etwa der Uralt-COBOL-Code, für dessen Wartung die Entwickler buchstäblich aus dem Altersheim geholt werden müssen. Das ist das genaue Gegenteil von Nachhaltigkeit, denn hier wurde die längst überfällige Modernisierung versäumt.

Unter Nachhaltigkeit wird allgemein verstanden, dass nicht weniger verbraucht wird wie jeweils nachwachsen kann. Ursprünglich stammt der Begriff aus der Forstwirtschaft. Im Laufe der Softwareentwicklung entsteht normalerweise eine zunehmende Komplexität. Es ist die Ressource „Einfachheit und Klarheit“ (engl. Simplicity), die durch Änderungen und Erweiterungen normalerweise  verbraucht wird. Genau diese Simplicity soll nachhaltig erhalten bleiben.

Irgendwo habe ich einmal eine sehr treffende Beschreibung für Simplicity gelesen: „Ein System ist nicht dann einfach, wenn man nichts mehr hinzufügen kann, sondern dann, wenn man nichts mehr weglassen kann.„ (Das Original ist von Antoine de Saint-Exupéry und lautet: „Perfektion ist nicht dann erreicht, wenn es nichts mehr hinzuzufügen gibt, sondern wenn man nichts mehr weglassen kann.“ – , Terre des Hommes, III: L’Avion, p. 60 (1939))

Ohne TDD ist nachhaltige Softwareentwicklung nicht möglich

Man spricht von einer Anhäufung von „Technical Dept“ also eine technische Verschuldung, die jede Weiterentwicklung der Software immer schwieriger macht. Die Symptome dieses Problems nennt man Rigidität und Fragilität. Rigidität heißt, dass Änderungen übermäßig aufwändig sind. Selbst für kleinste Änderungen werden oft utopisch hohe Aufwandsschätzungen abgegeben. Fragilität, das bedeutet, dass bei Änderungen sehr leicht Fehler entstehen. Meist in Bereichen, die mit der eigentlichen Änderung gar nichts zu tun haben und somit auch nicht getestet werden. Unter Nachhaltigkeit bei Softwareentwicklung wird somit die Bemühung verstanden, Änderungen der Software ohne technische Schulden zu machen. Die Ressource Simplicity bleibt dabei gemäß dem KISS-Prinzip zu erhalten. Künftige Erweiterungen der Software sollen genauso einfach sein, wie am ersten Tag.

Die wichtigste Hilfstechnik dabei ist das sogenannte Test Driven Development (TDD). Abgesichert durch sogenannte Unit-Tests, wird der Programmierer dabei in die Lage versetzt, jederzeit Refactorings machen zu können. Das ist Grundvoraussetzung, um überhaupt Clean Code erzeugen zu können. Nach dem Prinzip „First make it work then make it right“ verwandelt der Code sich sukzessive in Clean Code. Durch Unit-Tests verliert der beliebte Programmierspruch „Never change a running system“ erstmals seine Gültigkeit. Das genaue Gegenteil wird nun gefordert. Perfekter Code entsteht nicht durch Planung sondern durch unzählige kleine Verbesserungen. Das ist auch die Arbeitsweise von Malern, Komponisten, Schriftstellern, Steinmetzen, Töpfern, Holzschnitzern, usw. Beim herkömmlichen Programmieren existiert immer die Gefahr, dass mit jeder kleinen „Verbesserung“ neue Fehler eingebaut werden. Mit den Unit-Tests wird nun aber ein Sicherheitsnetz aufgespannt,  welches diese Gefahr bannt. Für die traditionelle Rolle des Software-Architekten hat Martin in seinen „Uncle Bob“-Trainingsvideos häufig nur Spott übrig. 

Um TDD zu erlernen brauchen Sie einen erfahrenen Coach. Hier kann man vieles falsch machen und hinterher ist die Enttäuschung groß. Sie sollten ihr System so aufsetzen, dass bei jedem Build-Lauf auch alle Unit-Tests kompiliert und ausgeführt werden. Da auf Dauer sehr viele Tests entstehen, ist gute Performance extrem wichtig. Das Ausführen aller Tests sollte insgesamt weniger Zeit kosten als der komplette Build-Lauf. Ansonsten wird TDD sehr schnell als lästig empfunden. Es dürfen keine Implementierungsdetails und keine privaten Methoden getestet werden. Hält man sich nicht daran, dann machen Refactorings auch immer wieder Änderungen an den Tests notwendig. Das wäre dann völlig am Ziel vorbeigeschossen. Genau das muss man vermeiden. Nur wenn man das Programmverhalten ändert, sollen auch die Tests verändert werden.

Clean Code ist fast das Gleiche wie nachhaltige Softwareentwicklung

Es gibt mittlerweile ausgereifte Techniken, um in diesem Sinne nachhaltige Softwareentwicklung zu betreiben. Der Autor Robert C. Martin nennt das Clean Code.

Clean Code ist ein Überbegriff für alles, was hilft technische Schulden zu vermeiden. Ein Programmierer verwendet sehr viel mehr Zeit damit, Code zu lesen als zu schreiben. Dabei ist es immer schwierig, fremden Code zu verstehen. Manche verstehen den eigenen Code nicht mehr, wenn sie ihn eine Weile nicht mehr gesehen haben. Wenn Programmcode sicht nicht aus sich selbst heraus verständlich erklärt, wenn es dazu unzähliger Kommentare bedarf, dann ist er auch nicht clean.

Es geht los mit sauberer Code-Formatierung. Ich hasse es, horizontal scrollen zu müssen. Wenn man beim Lesen das Ende einer Codezeile erreicht hat, weiß und sieht man nicht mehr was am Anfang stand. Zur Einhaltung von Formatierungsregeln, auf die sich das ganze Team geeinigt hat, verwendet man am besten ein Tool. Dieses muss sich in die eigene Entwicklungsumgebung integrieren lassen. Und dann nur Mut, um damit gnadenlos die kunstvollen alten Formatierungen zu zerstören.

Weiter geht es mit der richtigen Namensfindung für Klassen, Methoden, Variablen, etc. Der Code wird dadurch gut lesbar und Kommentare werden überflüssig. Ein Kommentar ist nur dann wirklich notwendig, wenn es ein Defizit im Code gibt.

Methoden und Funktionen sollten auch nur eine einzige Aufgabe erledigen, und sie sollen sie gut erledigen. Dazu reichen in der Regel 3-5 Codezeilen

Nachdem Robert C. Martin die formalen Kriterien für Clean Code abgehandelt hat, geht er ans Eingemachte. Was macht nun inhaltlich guten Clean Code aus? Das wichtigste ist die Einhaltung der SOLID-Prinzipien. Es würde zu weit führen, diese im Einzelnen zu erläutern. Jeder gute Programmierer sollte sie eigentlich sowieso schon kennen und befolgen.

Wenn Sie also nachhaltige Softwareentwicklung betreiben wollen, dann schreiben Sie Clean Code und erzeugen ihn mit TDD. 

Alle Prinzipien von Clean Code außer TDD kann man recht sehr gut autodidaktisch erlernen mithilfe der Video-Reihe „Uncle Bob“. Die Videos sind sehr unterhaltsam und das Englisch von Robert C. Martin ist sehr gut zu verstehen. Schauen Sie doch einfach mal in das erste Trainingsvideo rein, es ist kostenlos.

Ist nachhaltige Softwareentwicklung nun das Gleiche wie das Erstellen von Clean Code? Fast, aber nicht ganz!

„Clean Code“ – ein unsauberer Begriff 

Mir persönlich gefällt der Begriff „Clean Code“ nicht besonders gut. „Clean“, das klingt nach Wachmittelreklame. Das Wort enthält im Vergleich zu „nachhaltig“ nicht den eigentlichen Zweck. Sehr alt und daher sehr bekannt ist der Begriff „quick and dirty“, wenn in Programmen eine schnelle Lösung eingebaut wird. Eine schnelle Lösung, von der man genau weiß, dass sie die Codequalität verschlechtert. Mit „clean“ assoziiert man also das Gegenteil von „quick and dirty“. Folglich glaubt man, dass gute Codequalität nicht „quick“ zu programieren ist und dass man sehr viel Zeit für die Programmierung benötigt. Das ist falsch. Es gibt etliche Studien, die beweisen, dass mit TDD erstellter Clean Code genauso schnell zu schreiben ist, wie auf konventionelle Weise erzeugter Code.

Ich bin überzeugt davon, dass bei einem Programmierwettbewerb ein Team gut eingespielter TDD-ler jedes andere Team schlagen würde. Das liegt daran, dass sich bei konventioneller Programmierung kleine Fehler einschleichen, die erst mühsam mit dem Debugger gefunden werden müssen. Bei so einem Wettbewerb würde der Schiedsrichter sehr genau die Korrektheit überprüfen, und wenn er Fehler finden würde, dann müsste das jeweilige Team nacharbeiten. Spätestens dann würde das Team TDD in Führung gehen.

Das zweite Wort bei „Clean Code“ gefällt mir nicht wirklich. Es geht nicht um das Ergebnis „Code“ sondern um den Prozess, und der enthält mehr als nur den Code. Man findet höchst selten den Begriff „Clean Coding“. Häufig wird stattdessen der Begriff „Extreme Programming“ (XP) verwendet, was meiner Meinung nach ein abscheuliches Wording ist.

Der Begriff „nachhaltige Softwareentwicklung“ in genau dem Kontext wie er hier verwendet wird, wurde erstmalig im Jahr 2005 in dem großartigen Buch „Sustainable Software Development: An Agile Perspective“ von Kevin Tate erwähnt. Frühere Erwähnungen in genau diesem Sinn sind mir zumindest nicht bekannt. Knapp 3 Jahre später erschien das berühmte Buch „Clean Code: A Handbook of Agile Software Craftsmanship“ von Robert C. Martin. Martins Idealvorstellungen von gutem Code sind fast identisch mit denen von Tate. Diese Übereinstimmung ist erklärbar, weil beide Anhänger von XP und agiler Entwicklung sind. Martin hatte Tates Buch zuvor vermutlich nicht gelesen, denn sonst hätte er Tate zitiert. Im Literaturanhang ist Tate jedenfalls nicht erwähnt. Es ist wirklich schade, dass Tate nicht mehr prägenden Einfluss hatte, und sich somit der Begriff „Sustainable Software Development“ nicht durchgesetzt hat.

Der Unterschied von nachhaltiger Softwareentwicklung und Clean Code

Ist nun nachhaltiger Code, so wie ich ihn mir wünsche, das Gleiche wie Robert C. Martins Clean Code? Verwendet dieser Blog nur ein anderes Wording? Nein, es gibt wichtige Unterschiede im Detail.

Ich möchte zunächst die folgende einfache Formel aufstellen:

Nachhaltiger Code = Clean Code + X

Was beinhaltet nun dieses X? Was unterscheidet nachhaltigen Code von Uncle Bobs Clean Code?

Besserer Clean Code ist mit nachhaltiger Softwareentwicklung machbar.

Die Ideale in Bezug auf Design und Architektur sind geringfügig unterschiedlich. Ich habe andere Vorstellungen davon, wie gutes Moduldesign aus der Mikroperspektive zu entwickeln ist. Aus der Makroperspektive setze ich andere Schwerpunkte bezüglich der Systemarchitektur.

Nachhaltige Softwareentwicklung aus der Mikroperspektive

Man hat bei Robert C. Martin manchmal den Eindruck, dass er glaubt, ein Algorithmus entsteht ganz von allein. Alles, was man dazu braucht ist TDD und die Beachtung von bestimmten Refactoring-Regeln. Exemplarisch dafür ist das Lehrbeispiel bei Uncle Bob zur Primfaktorzerlegung. Er möchte das Publikum von TDD überzeugen und zeigt, dass alleine die konsequente Anwendung von TDD quasi automatisch zum Algorithmus „Sieb des Eratosthenes“ führt. Das Ergebnis ist zwar zugegebenermaßen in Bezug auf Performance noch nicht optimal. Es ist auch nicht genau das, was oben im verlinkten Wikipedia-Beitrag beschrieben ist. Das Erstaunliche ist jedoch, dass alleine aufgrund der Anwendung von Prinzipien ein Algorithmus entstanden ist.

Uncle Bob zeigt dieses Beispiel, nein diesen Zaubertrick, gleich in zwei Videos. Ich war bei einem Code-Dojo dabei, bei dem die Primfaktorzerlegung Gegenstand der Übungsaufgabe war. Es wurde mit Entwicklern durchgeführt, die sehr erfahren bei TDD sind. Sie setzen TDD beinahe alltäglich ein. Bei dieser Übung kam das Team schnell auf Abwege. Über einen längeren Zeitraum entfernten wir uns eher von der Lösung, als dass wir ihr näher kamen. Es entstand ein Phänomen, welches Uncle Bob „Stuck“ nennt. Das ist, wenn man sich festgefressen hat. Wie ein Auto, das im Schlamm festsitzt.

Zugegeben, wir haben aus Unkenntnis auch nicht ganz genau das umfangreiche Regelwerk für gutes Refactoring angewendet, welches Robert C. Martin vorgibt. Ich persönlich glaube, dass TDD extrem hilfreich bei der Entwicklung von Lösungen ist. Sie stellen sich aber nicht von alleine ein. Wenn das so wäre, dann könnte man auch ein Programm schreiben, welches für beliebige Probleme automatisch eine Lösung findet.

Die Mehrzahl aller Programmieraufgaben beinhaltet einfache Probleme, bei denen man einen Lösungsansatz schon im Kopf hat, wenn man mit der Implementierung beginnt. Anders bei sehr schwierigen Problemen: Angenommen Sie bekommen die Aufgabe, den Zeitpunkt von Sonnenauf- und untergang zu berechnen. Als Input bekommen Sie geographischen Koordinaten und ein Tagesdatum. Sie werden sich bei dieser Aufgabe die Zähne ausbeißen, wenn Sie das alleine mit TDD und Refactoring lösen wollen. Selbst, wenn Sie alle zugrundeliegenden astrophysikalischen Gesetze und Konstanten kennen würden, würden Sie mit TDD nicht auf den richtigen Algorithmus kommen. Zumindest nicht in vertretbarer Zeit.

Wie löst man derartige Aufgaben in der Praxis? Man sucht im Internet oder in der wissenschaftlichen Literatur nach einem Algorithmus oder man konsultiert einen Experten. Später, wenn einmal der Algorithmus gefunden ist, wird man bei der Implementierung selbstverständlich TDD einsetzen.

Den überwiegenden Zeitanteil zum Entwickeln von Lösungen, benötigt man in der Praxis weder bei sehr schwierigen Problemen noch bei sehr einfachen Problemen. Das Herausfinden geeigneter Lösungsansätze, das Software-Design ist am aufwändigsten bei mittelschweren Problemen. Gibt es zugleich mehrere Lösungsalternativen, dann kostet die Entscheidungsfindung ebenfalls viel Zeit. Nachhaltige Softwareentwicklung heißt dabei, dass man sich jeweils immer für die einfachste Lösung (Simplicity) entscheidet. Das herauszufinden ist aber meistens nicht einfach (easy). (Wir haben im Deutschen leider keine unterschiedlichen Worte für „simple“ und „easy“.)

Evolutionäres oder geplantes Design

Nachhaltige Softwareentwicklung betont diesen Moment sehr viel stärker als Clean Code nach Robert C. Martin. Er denkt nur einen kurzen Augenblick über das Design nach und beginnt dann gleich mit TDD. Ich glaube nicht, dass sich gutes und vor allem nachhaltiges Design alleine dadurch einstellt. Auch nicht, wenn dabei alle SOLID-Prinzipien penibel eingehalten werden.

In dem sehr lesenswerten Artikel „Is Design Dead?“ befasst sich Martin Fowler mit der Frage ob wir überhaupt noch Software-Design benötigen. Fowler ist Mitunterzeichner des agilen Manifests, überzeugter Anhänger von Clean Code und als Chefentwickler beim Consulting-Unternehmen ThoughtWorks. Er hat somit jede Menge praktische Erfahrung. Trotzdem oder gerade deswegen outet er sich als Anhänger geplanten Designs.

Im Gegensatz zu Fowler und damit wieder in einer Linie mit Robert C. Martin halte ich sehr wenig von UML. Bei der konkreten Design-Planung, vor allem, wenn sie im Team stattfindet, sind grafische Aufzeichnungen sehr hilfreich. Ein Bild sagt mehr als tausend Worte. Vor allem ist es ein ausgezeichnetes Instrument um die Gehirne aller Diskussionsteilnehmer zu synchronisieren. UML ist hierfür aber viel zu umständlich und zu zeitaufwändig.

Das beste Planungsinstrument ist meiner Meinung nach eine Schultafel. Sie bietet genügend Platz und Korrekturen sind schnell und einfach machbar. Schultafeln sind in Besprechungsräumen eher selten anzutreffen. Man muss sich dann eben mit Whiteboard, Flipcharts oder notfalls mit einem Blatt Papier behelfen. Es geht darum, anderen die eigene Vorstellungswelt mitzuteilen. Jede Kritzelei ist hierbei erlaubt. Verboten sind lange Monologe, weil genaues Zuhören und das Entwickeln von Ideen in der eigenen Gedankenwelt sich gegenseitig ausschließen. Diese Art von Planung lebt im hier und jetzt. Für die Dokumentation und Archivierung kann man zum Schluss ein Foto des Tafelbildes machen. Weitere Aufzeichnungen sind nicht notwendig. Es geht darum ein kohärentes Bild in den Köpfen zu hinterlassen.

Entwurfsmuster

Stark auseinander gehen die Meinungen auch hinsichtlich der Verwendung von Entwurfsmustern. Hiermit sind nicht die SOLID-Prinzipien gemeint, sondern jene 23 Entwurfsmuster, die im berühmten Buch „Design Patterns. Elements of Reusable Object-Oriented Software“ der Gang of Four (GOF) beschrieben sind. Robert C. Martin ist ein unbedingter Befürworter von Entwurfsmustern.

Auch mit dem Singleton Pattern hat er keine Probleme. Für viele andere ist das ein absolutes Tabu im Clean Code. Ich persönlich habe dazu auch eine eher pragmatische Einstellung. Es macht Probleme, die man kennen sollte, aber wenn es nicht anders geht, dann darf man es auch einsetzen. Mithilfe von Factory Pattern, kann man den gewünschten Effekt, dass nur eine einzige Instanz existiert, die vielen andern Objekten bekannt sein muss, meistens ebenso gut realisieren. Womit gleich das nächste Pattern angesprochen ist: Das Factory Pattern. Es ist ein unbedingtes Muss für Clean Code. Eine Factory ist ziemlich unproblematisch, solange sie keine zusätzliche Logik bekommt.

Aus meiner Erfahrung muss ich feststellen, dass der Einsatz von Entwurfsmustern häufig dazu führt, dass der Code nicht mehr nachhaltig ist. Es entstehen häufig unnötige Verkomplizierungen. Overengineering ist schlimmer als Copy-And-Paste. Martin Fowler schreibt dazu wörtlich:

The essence of this argument is that patterns are often over-used. The world is full of the legendary programmer, fresh off his first reading of GOF who includes sixteen patterns in 32 lines of code. I remember one evening, fueled by a very nice single malt, running through with Kent a paper to be called „Not Design Patterns: 23 cheap tricks“ We were thinking of such things as use an if statement rather than a strategy. The joke had a point, patterns are often overused, but that doesn’t make them a bad idea. The question is how you use them.

Martin Fowler, Is Design Dead

Anmerkung: Mit „Kent“ ist Kent Beck gemeint, der TDD wiederentdeckt und diese Technik in der heutigen Form erschaffen hat.

Kevin Tate ist nicht grundsätzlich gegen Pattern aber er ist ebenfalls kritisch eingestellt. Er schreibt dazu unter anderem:

The use of design patterns can lead to an unhealthy emphasis on up-front design. I have been on projects where people spent too much time trying to analyze a problem so they could try to identify what design patterns would apply. If you aren’t sure, don’t use a pattern. Simplicity, as always, should be the primary goal. Chances are, if there is a pattern, there it will emerge. You can always refactor to it later, as in.

Kevin Tate, Sustainable Software Development: An Agile Perspective

Exemplarisch für diese Problematik ist Das Observer Pattern, das in vielen Fällen eine sehr elegante Lösungsmöglichkeit ist. Wichtig beim Einsatz ist, dass es keine Rückkopplung des Observers zum beobachteten Objekt gibt. Damit meine ich folgendes Szenario: Der Observer registriert eine Änderung und benachrichtigt ein anderes Objekt, welches dann eine Zustandsänderung am beobachteten Objekt vornimmt, welches dann wieder dazu führt, dass der Observer eine Veränderung registriert usw. Das ergibt bei positiver Rückkopplung eine Endlosschleife. Derartige Fehler erkennt man normalerweise sofort beim Entwickeln. Das Programm friert ein, oder es gibt im Falle rekursiver Programmierung ein Stack Overflow.

Der Bug überlebt aber häufig, wenn eine negative Rückkopplung vorliegt. In diesem Fall pendelt das System nach mehreren Änderungen irgendwann wieder in eine stabilen Zustand ein. Chaotisch wirkt das ganze, wenn man es im Debugger beobachtet. Es ist nicht der Programmcode, der in diesem Fall komplex ist, sondern das Laufzeitverhalten. Das äußerlich sichtbare Programmverhalten ist aber so wie gewünscht, ansonsten hätte man den Fehler erkannt. Das real existierende Laufzeitverhalten war aber so nie vom Programmierer beabsichtigt.

In meiner langjährigen Berufspraxis habe ich derartiges schon öfters gesehen. Normalerweise analysiere Legacy Code, der mir unbekannt ist, indem ich den Programmablauf im Debugger anschaue. Stoße ich dann auf dieses Phänomen, dann bin ich verloren. Der ursprünglich geplante Programmablauf kann nur noch erraten werden. Bugfixings in derart rückgekoppelten Systemen sind extrem schwierig.

Wie kommt so etwas zustande? In vielen Fällen ist derjenige, der das Observer Pattern eingebaut hat, unschuldig. Verbockt hat es jemand anderes, der irgendwann später und unbedacht die Rückkopplung erzeugt hat. Bei zirkulären Modulreferenzen genügt oftmals eine einzige Zuweisung. Das äußerlich sichtbare Programmverhalten ist wie gewünscht, und im Debugger schaut sich das niemand mehr an. Wie kann man das verhindern? Entweder man verzichtet auf das Observer Pattern, was wirklich schade ist, oder man achtet bei der Coderevision darauf, dass es nur hierarchische Referenzen gibt. Insbesondere in der Nähe von Observer Pattern sollten netzartige Modul- oder Objektstrukturen unbedingt vermieden werden. Ich habe mir sagen lassen, es soll tatsächlich noch Entwickler-Teams geben, die keine Coderevisionen durchführen.

Das Problem von netzartigen Strukturen führt zur Makroperspektive.

Nachhaltige Softwareentwicklung aus der Makroperspektive

In seinen Videos macht sich Uncle Bob regelmäßig über Softwarearchitekten lustig. Er verspottet sie als Wichtigtuer. Robert C. Martin fordert, dass Architekten auf jeden Fall auch programmieren sollen, weil sie sonst den Bezug zur Realität verlieren. Diese Forderung kann ich nur unterschreiben. Auch ich habe die Erfahrung gemacht, dass Softwarearchitekten sich häufig exakt so verhalten, wie sie in den Videos charakterisiert werden. Dennoch ist gute Softwarearchitektur extrem wichtig für nachhaltige Softwareentwicklung.

Das Buch „Clean Architecture A CRAFTSMAN’S GUIDE TO SOFTWARE STRUCTURE AND DESIGN“ von Robert C. Martin beschreibt gegenüber seinen vorherigen Clean Code Buch seine Sichtweise von guter Softwarearchitektur. Für ihn gibt es keinen Unterschied zwischen Design und Architektur. Gute Architektur ergibt sich dann quasi von alleine, wenn alle Prinzipien für gutes Design eingehalten werden und der Code mit TDD erzeugt wurde und somit testbar ist.

Nachhaltige Softwareentwicklung ist nach meinem Verständnis mehr. Obwohl die Grenzen fließend sind, gibt es für mich einen Unterschied zwischen Design und Architektur. Dabei halte ich es für weniger wichtig, wie die Definition formuliert wird. Bedeutend sind die Konsequenzen, die man daraus zieht. Wie schon bei meinem Plädoyer für geplantes Design vertrete ich die Meinung, dass das Architekturmodell aus einer Planung hervorgehen sollte. State of the Art ist das nachfolgend abgebildete Architekturmodell, welches aus dem „Domain-driven Design“ entstammt.

Robert C. Martin zieht einen Vergleich heran, um die Unterschiedslosigkeit von Design und Architektur zu begründen. Er sagt: Die Pläne, die ein Architekt eines Gebäudes abliefert, enthalten bereits alle möglichen Design-Details. Der genaue Ort der Lichtschalter, die mögliche Möblierung, das ist alles schon in den Plänen eingezeichnet. Das ist richtig. Nach meinem Verständnis ist Bauarchitektur im übertragenen Sinne keine Softwarearchitektur. Es ist Design. Softwarearchitektur ist weiter übergeordnet. Benutzt man die Metapher, dann ist Softwarearchitektur vergleichbar mit dem Erstellen von Flächennutzungsplänen, Raumordnungsplänen und Bebauungsplänen, bei denen es um die Versorgung und Planung von Straßen, Kanalisation, etc geht. Also: Wie muss eine Software geplant, werden damit alle Plugins harmonisch ineinander greifen können?

Zyklenfreie Architektur

Das Thema zyklenfreie Architektur wird in dem oben genannten Buch von Robert C. Martin unter dem Kapitel „The Acyclic Dependency Principle“ ADP behandelt. Er traut sich aber nicht die Vorteile von hierarchischen Architekturen anzusprechen. Beim Vorläufer der objektorientierten Programmierung, der strukturierten Programmierung aus den 70er Jahren entstand eine hierarchische Struktur ganz von alleine. Hierarchische Strukturen haben den Vorteil, dass das Gehirn die darin enthaltene Ordnung leicht erfasst. Zyklische Programmstrukturen sind sehr viel schwieriger zu verstehen. Irgendwie dreht man sich beim Versuch Verständnis darüber zu gewinnen, auch immer wieder im Kreis. Natürlich will ich nicht zurück in die 70er Jahre. Plugin-Architekturen lassen sich auch nur realisieren, wenn man die Pfeilrichtung der Abhängigkeiten durch Anwendung des „Dependency-Inversion-Prinzips“ umdreht. Hierbei kommen i.d.R. Interfaces zum Einsatz.

Zyklische Programmarchitekturen sind aus meiner Erfahrung der schlimmste Killer von Nachhaltigkeit. Im großartigen Buch „Langlebige Softwarearchitekturen“ von Carola Lilienthal zieht sich dieses Thema wie ein roter Faden durch den gesamten Text. Im Kapitel 5.3 zeigt sie, dass aus Untersuchungen hervorgeht, „dass Menschen dann Wissen gut aufnehmen, es wiedergeben und sich darin zurechtfinden können, wenn es in hierarchischen Strukturen vorliegt“ (Seite 85). Dies bestätigt exakt meine Erfahrungen aus der Berufspraxis. Man sollte also genauestens überlegen, an welchen Stellen klassische Hierarchien sinnvoller sind. Plugin-Strukturen sollten immer auf die eine oder andere Art geordnet sein. Baumartige Strukturen mit geringer Tiefe erleichtern dabei die Abbildung im Kopf.

Zyklen entstehen immer dann unabsichtlich, wenn ein Programmierer sieht, dass eine Methode einer bestimmten Klasse genau das macht, was er an einer anderen Stelle benötigt. Copy-And-Paste kommt nicht in Frage, das ist verpönt. Also wird auf diese Klasse referenziert. Die Methode wird notfalls „public“ gemacht und das Interface wird erweitert. „Problem gelöst“, denkt er. Hätte der Programmierer eine bildhafte Vorstellung der Programmarchitektur im Kopf, dann wüsste er, dass er gerade einen Zyklus geschaffen hat. Im Ergebnis ist das viel schlimmer, als wenn er die Methode mit Copy-And Paste dupliziert hätte.

Eine klare Vorstellung der vorhandenen Programmarchitektur ist das A und O nachhaltiger Softwareentwicklung. Der Programmierer erkennt dann sofort, dass er die benötigte Methode an einen klar definierten anderen Ort umziehen muss. TDD und SOLID alleine verhindern keinen Wildwuchs. Bei großen Zyklen geht die Testbarkeit verloren, und TDD ist nicht mehr möglich. Kleine Zyklen stehen aber nicht im Widerspruch zur TDD. Sie sind zwar beherrschbarer, aber aus gesamtheitlicher Sicht geht die Lesbarkeit verloren.

Jeder, der sich mit nachhaltiger Softwareentwicklung befasst, sollte dieses Buch von Carola Lilienthal gelesen haben. Sie hat über achtzig Softwaresysteme zwischen 30 000 und 15 Mio. Lines of Code (LOC) in Java, C++, C#, ABAP und PHP untersucht. Mit Werkzeugen aus der statischen Code-Analyse erstellte sie Metriken zur grafischen Darstellung von allen Architekturelementen. So entdeckte sie jede Art von Zyklen, auch wenn sie sehr versteckt sind. Mit diesen Werkzeugen ist eine Bewertung der Architektur über den sogenannte „Modularity Maturity Index“ (MMI) möglich. In 11 Geschichten aus der Praxis schildert sie die Erfahrungen bei der Wartung und Weiterentwicklung von Systemen mit unterschiedlichen MMI und LOC. Das Buch ist nicht nur sehr wertvoll für Programmierer sondern auch für Projektmanager. (Letztere können die technischen Details gerne überblättern.) Praktiker erfahren im Anhang, welche Werkzeuge benutzt wurden und wie man sie einsetzt.

Jeder Programmierer, der glaubt, dass viele Interfaces ausreichen, um eine nachhaltige Architektur errichten zu können, sollte das Kapitel 7.4 „Interfaces – das architektonische Allheilmittel?“ lesen. Carola Lilienthal erläutert, dass Interfaces oftmals nur die Abhängigkeit zwischen einzelnen Modulen verschleiern. „Eine echte Modularisierung z.B. im Sinne von fachlichen aufeinander aufbauenden Schnitten oder Microservices wird so nicht erreicht.“ (Seite 131)

Nachhaltige Softwareentwicklung ist auch ohne Agilität möglich

Möglich ja, aber mit Agilität geht es besser!

Es gibt die Ausrede, man müsse sich nicht um Clean Code bemühen, weil es im Unternehmen keine agile Vorgehensweise gibt. Das muss auch nicht unbedingt die Schuld der Geschäftsleitung sein.

Es kann sein, dass der Kunde das nicht will. Wie gewohnt aus der Welt der materiellen Produkte, ist etwas Schlüsselfertiges gewünscht. Wenn ich mir ein neues Auto kaufe, verwende ich einen Fahrzeug-Konfigurator, nachdem ich mich für eine bestimmte Marke entschieden habe. Im Endergebnis habe ich dann für mich das beste Preis/Leistungsverhältnis erzielt. Das Fahrzeug wird zu einen festgesetzten Termin geliefert, so wie von mir konfiguriert. Es ist verständlich, dass man sich das auch bei Software so wünscht. Agilität führt anfänglich zu Verunsicherung. Man muss den Kunden die Vorteile von Agilität gut erklären. Nicht jeder Kunde versteht, dass Software etwas ganz anderes als ein materielles Produkt ist. Die Geschäftsleitung möchte den Kunden nicht verlieren und zum Schluss landet man wieder beim Wasserfall-Modell.

In diesem Fall sollte das Projekt ebenfalls mit nachhaltiger Softwareentwicklung umgesetzt werden. Das ist kein Widerspruch. Die agile Vorgehensweise ist möglich und empfehlenswert bei Legacy-Software, deren Code alles andere als Clean Code ist. Agilität ist sogar außerhalb von Softwareentwicklung möglich. Umgekehrt ist Agilität keine notwendige Voraussetzung für Clean Code. Auch wenn sich Agilität und Clean Code hervorragend ergänzen, ist das eine vom anderen in keiner Weise abhängig. Im Gegenteil: Ich behaupte, das klassische Projektmanagement wird über TDD erstmals machbar. Das liegt einfach daran, dass die Reihenfolge der Entwicklung einzelner Bausteine durch TDD keine Rolle mehr spielt. Durch das Aufheben von Abhängigkeiten zwischen den Modulen wird bei der Projektplanung vieles sehr viel einfacher. So können Terminengpässe nun auch durch frühzeitige Personalaufstockung überwunden werden. Es wird auch besser sichtbar, wenn Termine gefährdet sind.

Insgesamt ist aber Agilität bei der Softwareentwicklung trotzdem sehr empfehlenswert. Der gegenwärtige Hype bei agilen Methoden kann sehr schnell wieder in sich zusammenfallen oder durch etwas ganz anderes ersetzt werden. Nachhaltige Softwareentwicklung ist auch nachhaltig an sich und somit von Modeerscheinungen unabhängig.

Nächster Beitrag: Was ist TCR?

Der Beitrag Besserer Clean Code durch nachhaltige Softwareentwicklung erschien zuerst auf Software Sunshine Blog.