DenkZEIT

Schonmal angefangen ein kleines Programm zu schreiben, um irgendein kleines Problem zu lösen, und dann recht bald auf ein interessantes Problem im Design (bzw. der Architektur) gestoßen? Ein Entwurfsmuster hier, ein raffinierter Algorithmus dort und schwupps ist aus dem kleinen Problem eine große Architekturbaustelle geworden. Es gilt also, dem Drang nach früher Optimierung (PrematureOptimization) bzw. großer Umsichtigkeit” entgegenzuwirken, damit die Gefahr des Sich-verrennens minimiert wird..

Nun gibt es Leute, die gehen nur mit großer Umsichtigkeit” an ein Problem ran. JoelSpolsky nennt solche Leute in einem seiner Artikel ArchitectureAstronauts:

When you go too far up, abstraction-wise, you run out of oxygen. Sometimes smart thinkers just don’t know when to stop, and they create these absurd, all-encompassing, high-level pictures of the universe that are all good and fine, but don’t actually mean anything at all.

These are the people I call Architecture Astronauts. It’s very hard to get them to write code or design programs, because they won’t stop thinking about Architecture. They’re astronauts because they are above the oxygen level, I don’t know how they’re breathing. They tend to work for really big companies that can afford to have lots of unproductive people with really advanced degrees that don’t contribute to the bottom line.

Ein einfaches Beispiel

In Unittesten von regulären Ausdrücken habe ich beschrieben, wie ich seit kurzem reguläre Ausdrücke (RE) mit UnitTests auf Korrektheit und bei Änderungen auf Rückwärtskompatibilität teste. Solche Tests sind besonders gut, wenn man die RE öfter mal abändert (ReFactoring) oder neue Funktionalität hinzufügt: Man kann sicher sein, dass Altes weiterhin funktioniert. Diese Gewissheit macht es wesentlich einfacher, neue Funktionalität hinzuzufügen. Man traut es sich. So kann man schrittweise an die Lösung eines Problems herangehen. Konkret ist das so, dass ich erst einen einfachen RE zusammensetze, der ein einfaches Testbeispiel korrekt matcht. Dann ändere ich den RE solange ab, bis er alle Testbeispiele richtig matcht. Fertig!

Was ist hier nun der Unterschied zum Architekturastronauten? Er würde hier nicht aufhören, sondern alle möglichen Sonderfälle, auf die er irgendwann einmal stossen könnte ebenfalls abzudecken versuchen. Das ist ein Fehler, eine PrematureOptimization (PO). PO sehe ich nicht nur als Problem im Zusammenhang mit Geschwindigkeitsoptimierungen, sondern immer dann, wenn versucht wird Eventualitäten abzudecken, von denen man nicht sicher ist, ob sie überhaupt auftreten werden oder können. Natürlich muss man in seinen Programmen mögliche Fehler abfangen. Darum geht es nicht. Es geht um Entscheidungen im Design (auch im Design von Regulären Ausdrücken, beispielsweise) und in der Architektur. Wenn hier eine Änderung oder Erweiterung nicht absolut notwendig ist, sollte man sie nicht machen. Durch UnitTests wird generell ein späteres Ändern bzw. ReFactoring, wenn es notwendig wird, wesentlich erleichtert.

Dies ist auch der Ansatz im ExtremeProgramming:

Always implement things when you actually need them, never when you just foresee that you need them.

Ein Weg zu diesem Ansatz, den ich oben schon angerissen habe ist:

Do the simplest thing that could possibly work.

Also: ganz einfache reguläre Ausdrücke. Nur soviel, dass das, was man machen möchte funktioniert. Neue Funktionalität später hinzufügen. Mögen dann UnitTests mit dir sein!

Architekturastronauten missachten diesen Rat. Sie haben größeres im Sinn. Sie schweben über den Wolken und haben kaum den Nerv, die tatsächlichen Probleme zu lösen, die gelöst werden müssen. Jetzt.