Vielleicht hat Ihre Firma ein kleines Vermögen in ein solches »Enterprise«-System investiert. Falls ja, haben Sie mein Beileid. Sie sollten aus diplomatischen Gründen wahrscheinlich lieber nicht herumlaufen und allen erzählen: »Uncle Bob sagt, damit solle man nicht arbeiten.« Doch es gibt eine einfache Lösung.

Sie können Ihren Quellcode am Ende jeder Iteration ins »Enterprise«-System einchecken (etwa alle 14 Tage) und in der Mitte jeder Iteration dann mit einem der Open Source-Systeme arbeiten. So sind alle glücklich und zufrieden, es werden keine Firmenregeln verletzt, und Ihre Produktivität bleibt konstant hoch.

In den 1980ern schien pessimistisches Locking eine prima Idee zu sein. Schließlich ist der einfachste Weg, um die Aktualisierungsprobleme beim gleichzeitigen Zugriff zu verwalten, sie zu serialisieren. Wenn ich eine Datei bearbeite, lassen Sie also besser die Finger davon. Tatsächlich war das von mir eingesetzte System der farbigen Nadeln Ende der 1970er eine Form des pessimistischen Lockings. Wenn eine Nadel neben der Datei steckte, dann lassen alle anderen sie in Ruhe.

Natürlich bringt auch pessimistisches Locking Probleme. Wenn ich eine Datei sperre und in Urlaub gehe, sitzen alle auf dem Trocknen, die diese Datei bearbeiten wollen. Auch wenn ich eine Datei nur ein oder zwei Tage sperre, sorge ich unter Umständen bei anderen für Verzögerungen, die an der gleichen Datei etwas ändern müssen.

Unsere Tools sind beim Zusammenführen von gleichzeitig bearbeiteten Quellcodedateien weitaus besser geworden. Eigentlich ist das wirklich erstaunlich, wenn man sich das mal genau überlegt: Die Tools nehmen sich beide Dateien und deren Vorgänger vor und finden anhand mehrerer Strategien heraus, wie man diese gleichzeitigen Änderungen integriert. Und dabei erledigen sie ihre Aufgabe sehr gut.

Also ist die Ära des pessimistischen Lockings vorüber. Wir müssen Dateien nicht mehr sperren, wenn wir sie auschecken. Tatsächlich brauchen wir nicht einmal mehr einzelne Dateien auszuchecken, sondern gleich das ganze System und bearbeiten alle erforderlichen Dateien.

Wenn dann unsere Änderungen eingecheckt werden sollen, führen wir eine »Update«-Operation durch. So wissen wir, ob jemand vor uns Code eingecheckt hat. Diese Operation führt automatisch die meisten Änderungen zusammen, findet Konflikte und hilft, den Rest einzufügen. Dann committen wir den zusammengeführten Code.

Ich werde mich weiter hinten im Kapitel noch ausführlich über die Rolle verbreiten, die automatisierte Tests und die fortlaufende Integration bei diesem Prozess spielen. Hier soll nur erwähnt werden, dass niemals Code eingecheckt wird, der nicht alle Tests bestanden hat. Absolut nie!

Damals war CVS das bewährte einsatzbereite Quellcodekontrollsystem. Es war zu damaligen Zeiten gut, ist aber für heutige Projekte nun etwas in die Jahre gekommen. Obwohl es sehr gut mit einzelnen Dateien und Verzeichnissen umgehen kann, kann es nicht gut Dateien umbenennen und Verzeichnisse löschen. Und der Attic ... Tja, je weniger man darüber sagt, desto besser.

Subversion hingegen funktioniert wirklich sehr schön. Damit kann man das gesamte System in einem Durchgang auschecken. Updaten, Mergen und Committen gehen ganz leicht. Solange Sie keine Verzweigungen brauchen, kann man mit SVN-Systemen ziemlich einfach umgehen.

Ich arbeite seit Ende 2008 mit git​, und es hat komplett die Art und Weise verändert, wie ich mit Quellcodekontrolle umgehe. Es sprengt den Rahmen dieses Buches zu beschreiben, warum dieses Tool alles aufgemischt hat. Aber wenn man Abbildung A.1 mit Abbildung A.2 vergleicht, könnte man dazu eine Menge ausführlich erklären, was ich aber hier nicht machen werde.

Abbildung A.1 zeigt das Ergebnis von einigen Wochen Arbeit am FitNesse-Projekt unter Verwendung von SVN. Sie sehen die Auswirkungen meiner strengen Regel, die Verzweigungen zu vermeiden. Wir bauten einfach keine Verzweigungen ein. Stattdessen arbeiteten wir mit häufigen Updates, Zusammenführungen und Commits für den Hauptstrang.

Abbildung A.2 zeigt ein paar Wochen Entwicklungsarbeit am gleichen Projekt unter git. Leicht erkennen Sie, wie wir an den verschiedenen Stellen verzweigen und wieder zusammenführen. Nun habe ich aber nicht die Zügel bei meiner Keine-Verzweigungen-Politik fahren lassen, sondern es war einfach ganz naheliegend und völlig praktisch, so zu arbeiten. Jeder Entwickler kann individuell sehr kurzlebige Branches erstellen und sie dann auf Wunsch auch wieder zusammenführen.

Beachten Sie, dass kein Hauptstrang erkennbar ist. Das liegt daran, dass es keinen gibt. Bei git braucht man so etwas wie ein zentrales Repository oder einen Hauptstrang nicht. Jeder Entwickler führt seine eigene Kopie der gesamten Projekt-History auf seinem lokalen Rechner. Er checkt aus dieser lokalen Kopie aus und wieder ein und führt seinen Code mit anderen bei Bedarf zusammen.

Es stimmt, dass ich ein spezielles goldenes Repository führe, in das ich alle Releases und zwischenzeitigen Builds verschiebe. Aber dieses Repository als Hauptstrang zu bezeichnen, wäre etwas daneben. Es ist wirklich nur ein praktischer Snapshot der gesamten History, die jeder Entwickler bei sich lokal führt.

Wenn Sie das nicht begreifen, ist es nicht schlimm. git ist anfangs schon recht knifflig. Man muss sich bei dessen Arbeitsweise eingewöhnen. Aber ich will Ihnen was sagen: In git und anderen ähnlichen Tools sehen wir die Zukunft der Quellcodekontrolle.

Man könnte annehmen, die Tage von vi als primärem Entwicklungseditor seien lange vorüber. Heutzutage gibt es Tools, die vi (und andere, einfache Texteditoren) um Längen deklassieren. Aber in Wahrheit findet vi jetzt wieder sehr viel Anklang, weil es so einfach zu verwenden, schnell und flexibel ist. vi ist vielleicht nicht so leistungsfähig wie Emacs oder Eclipse, aber immer noch ein schneller und leistungsfähiger Editor.

Aber nun muss ich doch gestehen, dass ich bei vi kein Power-User mehr bin. Es gab mal Zeiten, da war ich als »vi-Gott« bekannt – das ist lange vorbei. Gelegentlich hole ich vi mal hervor, wenn ich schnell eine Textdatei bearbeiten will. Ich habe es sogar kürzlich noch benutzt, um schnell an einer Java-Quellcodedatei in einer entfernten Umgebung etwas zu ändern. Aber wirklich mit vi programmiert habe ich in den vergangenen zehn Jahren kaum.

Emacs ist immer noch einer der leistungsfähigsten Editoren überhaupt und wird das wahrscheinlich auch in den nächsten Dekaden sein – das interne Lisp-Modell garantiert das. Emacs ist ein vielseitiges Allzweck-Tool, dem nichts das Wasser reichen kann. Andererseits finde ich, dass Emacs nicht wirklich mit den spezialisierten IDEs mithalten kann, die jetzt den Markt beherrschen. Und Code zu bearbeiten, ist eben kein Allzweck -Job.

In den 1990ern war ich Emacs-Fanatiker. Ich zog anderes nicht einmal in Betracht. Die damaligen Point-and-Click-Editoren waren ein lachhaftes Spielzeug, das kein Entwickler wirklich ernst nehmen konnte. Doch Anfang des Jahres 2000 lernte ich IntelliJ kennen, meine aktuelle IDE der Wahl, und habe nie mehr zurückgeschaut.

Ich bin absolut überzeugter IntelliJ-User und liebe es. Ich schreibe damit Java, Ruby, Clojure, Scala, JavaScript und vieles andere. Dieses Tool wurde von Programmierern erstellt, die begreifen, was Programmierer brauchen, wenn sie Code schreiben. Im Laufe der Jahre hat es mich selten enttäuscht und fast immer erfreut.

Eclipse gleicht in Leistung und Umfang IntelliJ. Die beiden sind einfach um Längen besser als Emacs, wenn’s ums Bearbeiten von Java-Code geht. Es gibt andere IDEs in dieser Kategorie, aber ich stelle sie hier nicht vor, weil ich keine direkte Erfahrung mit ihnen habe.

Diese IDEs hängen Tools wie Emacs ab, weil sie so extrem leistungsfähige Features zur Manipulation von Code enthalten. Bei IntelliJ können Sie beispielsweise mit einem einzigen Befehl aus einer Klasse eine Superklasse extrahieren. Neben vielen weiteren hervorragenden Features können Sie Variablen umbenennen, Methoden extrahieren und Vererbung in Komposition konvertieren.

Mit diesen Tools geht es bei der Bearbeitung von Code nicht mehr länger um Zeilen und Zeichen, sondern um komplexe Manipulationen. Anstatt über die nächsten paar einzutippenden Zeichen und Zeilen nachzudenken, denken Sie an die bevorstehenden Transformationen. Kurz gesagt: Das Programmiermodell ist bemerkenswert anders und höchst produktiv.

Natürlich gibt es diese Leistungsfähigkeit nicht umsonst: Die Lernkurve ist steil, und die Einrichtungszeit für Projekte ist nicht unwesentlich. Diese Tools sind nicht leichtgewichtig, sondern brauchen im Betrieb viele Rechnerressourcen.

TextMate ist leistungsfähig und leichtgewichtig. Es vollbringt keine solch wundervollen Manipulationen wie IntelliJ und Eclipse und hat auch nicht die leistungsfähige Lisp-Engine und Library wie Emacs. Es ist nicht so flott und flüssig wie vi. Doch die Lernkurve ist flach und die Bedienung intuitiv.

Ich arbeite hier und da mal mit TextMate, vor allem gelegentlich bei C++. Ich würde Emacs für ein großes C++-Projekt nehmen, aber ich bin etwas aus der Übung, um für die kurzen, kleinen C++-Aufgaben Emacs einzusetzen.

Entwicklerteams brauchen definitiv eine Auflistung aller anstehenden Aufgaben. Dazu gehören sowohl neue Tasks und Features als auch zu behebende Bugs. Für jedes Team in vernünftiger Größe (fünf bis zwölf Entwickler) sollte diese Liste Dutzende bis Hunderte von Einträgen umfassen. Keine dreistelligen Einträge!

Wenn Sie Tausende von Bugs haben oder auch Tausende von Features und/oder Tasks, läuft irgendetwas schief. Generell sollte die Liste der zu klärenden Themen relativ klein und von daher mit einem leichtgewichtigen Tool wie Lighthouse, Tracker oder einem Wiki zu verwalten sein.

Dafür sind auch kommerzielle Tools erhältlich, die recht anständig zu sein scheinen. Ich habe Kunden erlebt, die damit arbeiten, aber selbst hatte ich noch keine Gelegenheit dazu. Ich stehe diesen Tools nicht ablehnend gegenüber, solange die Zahl der Fälle klein und verwaltbar bleibt. Wenn mit solchen Tools Tausende von Fällen nachverfolgt werden müssen, dann verliert das Wort »Nachverfolgung« seinen Sinn. Sie werden zu Müllhalden voller Aufgaben (und stinken oft auch genauso).

Mehr als mit jedem anderen Tool sind diese Komponententesttools der Weg, um die »Definition of Done« festzulegen. Wenn Business-Analysten und die Leute von der Qualitätssicherung gemeinsam eine Spezifikation erstellen, die das Verhalten einer Komponente definiert, und wenn diese Spezifikation dann als Test-Suite ausgeführt werden kann, die entweder bestanden wird oder misslingt, dann nimmt »done« eine sehr unzweideutige Bedeutung an: »Alle Tests wurden erfolgreich bestanden.«

Mein Favorit bei den Tools für Komponententests ist FitNesse. Ich habe einen Großteil davon selbst geschrieben und bin der Hauptentwickler. Also ist es mein Baby.

Das System von FitNesse basiert auf Wikis, mit denen Business-Analysten und die Spezialisten für die Qualitätssicherung Tests in einem sehr einfachen tabellarischen Format schreiben. Diese Tabellen gleichen Parnas-Tabellen sowohl in der Form als auch dem Zweck. Damit kann man Tests schnell zu Suites zusammenstellen, und diese können dann jederzeit durchgeführt werden.

FitNesse ist in Java geschrieben, kann aber auch Systeme in allen möglichen Sprachen testen, weil es mit einem zugrundeliegenden Testsystem kommuniziert, das in einer beliebigen anderen Sprache geschrieben sein kann. Zu den unterstützten Sprachen gehören Java, C#/.NET, C, C++, Python, Ruby, PHP, Delphi und andere.

FitNesse baut auf den beiden Testsystemen Fit und Slim auf. Fit wurde von Ward Cunningham geschrieben und war die ursprüngliche Inspiration für FitNesse und seinesgleichen. Slim ist ein weitaus einfacheres und portableres Testsystem, das heutzutage von den FitNesse-Usern bevorzugt wird.

Ich kenne mehrere andere Tools, die sich auch für Komponententests eignen.

• RobotFX​ wurde von Nokia-Ingenieuren entwickelt. Dieses Tool arbeitet mit einem ähnlichen Tabellenformat wie FitNesse, basiert aber nicht auf Wikis, sondern arbeitet mit ganz einfachen Textdateien, die mit Excel o.Ä. vorbereitet wurden. Das Tool ist in Python geschrieben und kann über entsprechende Brücken auch Systeme in allen möglichen anderen Sprachen testen.

• Green Pepper​ ist ein kommerzielles Tool, das FitNesse in mancherlei Hinsicht gleicht. Es basiert auf dem populären Confluence-Wiki.

• Cucumber​ ist ein einfaches Text-Tool und wird von einer Ruby-Engine gesteuert, kann aber viele unterschiedliche Plattformen testen. Cucumber ist sprachlich im beliebten Gegeben/Wenn/Dann-Stil geschrieben.

• JBehave​ ähnelt Cucumber und ist das logische Elternteil zu Cucumber. Geschrieben wurde es in Java.

Programmierer sind Verwalter der Details. Das ist unsere Aufgabe. Wir legen das Verhalten von Systemen bis in die kleinsten Kleinigkeiten fest. Dafür nehmen wir zufällig textliche Sprachen (Code), weil die bemerkenswert komfortabel sind (denken wir beispielsweise an Englisch).

Welche Art von Details managen wir?

Kennen Sie den Unterschied zwischen den Zeichen \n und \r? Das erste ist ein Zeilenvorschub und das zweite ein Wagenrücklauf. Welcher Wagen ist hier gemeint?

In den 1960er und Anfang der 1970er Jahre war die Teletype eines der häufig verwendeten Ausgabegeräte für Computer. Das Modell ASR33 ^[2] war am weitesten verbreitet.

Dieses Gerät enthielt einen Druckkopf, der zehn Zeichen pro Sekunde drucken konnte. Der Druckkopf bestand aus einem kleinen Zylinder, auf dem sich die erhabenen Zeichen befanden. Der Zylinder rotierte, hob und senkte sich, sodass sich vor dem Papier jeweils das richtige Zeichen befand, und dann schlug ein kleiner Hammer den Zylinder gegen das Papier. Zwischen Zylinder und Papier befand sich ein Farbband, und die Tinte darauf wurde in Form des Zeichens aufs Papier übertragen.

Der Druckkopf fuhr auf einem Wagen hin und her. Nach jedem Zeichen rückte der Wagen eine Stelle nach rechts und nahm den Druckkopf mit. Wenn der Wagen ans Ende der Zeile mit 72 Zeichen angekommen war, musste man den Wagen explizit zurückfahren lassen, indem man die Zeichen (\r = 0 x 0D) für den Wagenrücklauf sendete. Anderenfalls hätte der Druckkopf mit dem Drucken der Zeichen in der 72. Spalte weitergemacht und ein hässliches schwarzes Rechteck dort gemalt.

Natürlich reichte das noch nicht: Der Wagenrücklauf schob das Papier nicht bis in die nächste Zeile. Wenn man den Wagen zurückschickte aber kein Zeichen für den Zeilenvorschub (\n = 0 x 0A) sendete, wurde die neue Zeile über die alte gedruckt.

Somit lautete die Zeilenendsequenz für einen ASR33-Fernschreiber »\r\n«. Tatsächlich musste man dabei vorsichtig sein, weil der Wagen für den Rücklauf vielleicht länger als 100 ms brauchte. Wenn man »\n\r« sendete, wurde das nächste Zeichen vielleicht direkt beim Rücklauf gedruckt und produzierte dann ein verschmiertes Zeichen in der Zeilenmitte. Um auf Nummer sicher zu gehen, polsterten wir die Zeilenendsequenz oft mit ein oder zwei Ausradierzeichen^[3] (0 x FF) aus.

Als in den 1970ern immer weniger Teletypes zum Einsatz kamen, verkürzten Betriebssysteme wie UNIX diese Sequenz einfach auf »\n«. Doch andere wie DOS arbeiteten weiterhin entsprechend der Konvention »\r\n«.

Wann haben Sie das letzte Mal mit Textdateien zu tun gehabt, die nach der »falschen« Konvention arbeiteten? Auf dieses Problem stoße ich mindestens einmal jährlich. Zwei identische Quellcodedateien sind nicht vergleichbar und generieren unterschiedliche Prüfsummen, weil sie verschiedene Zeilenenden verwenden. Bei Texteditoren funktioniert der Wortumbruch nicht korrekt oder sie fügen doppelte Leerzeichen in den Text ein, weil die Zeilenenden »verkehrt« sind. Programme stürzen ab, die nicht mit Leerzeichen umgehen können, weil sie »\r\n« als zwei Zeilen interpretieren. Manche Programme erkennen »\r\n«, aber »\n\r« nicht usw.

Das meine ich mit Details. Probieren Sie mal, in UML die grässliche Logik zu programmieren, um mit Zeilenenden umzugehen.

Die Hoffnung der MDA-Bewegung bestand darin, dass ein Großteil dieser Details durch Verwendung von Diagrammen statt Code eliminiert werden kann. Diese Hoffnung hat sich bisher als aussichtslos erwiesen. Es stellt sich heraus, dass im Code gar nicht so viele zusätzliche Details eingebettet sind, die über Bilder eliminierbar wären. Bilder besitzen überdies ihre eigenen zufälligen Details. Sie weisen ihre eigene Grammatik, Syntax und Regeln sowie Einschränkungen auf. Also ist der Unterschied im Detail letzten Endes nur Tünche.

Die Hoffnung der MDA war, dass Diagramme sich auf einer höheren Abstraktionsebene bewegen können als Code, so wie Java auf einer höheren Ebene liegt als Assembler. Doch auch diese Hoffnung hat sich bisher als Fehleinschätzung erwiesen. Der Unterschied im Abstraktionsgrad ist bestenfalls winzig.

Und nehmen wir schlussendlich einmal an, dass eines Tages jemand eine wirklich nützliche Diagrammsprache erfinden wird. Dann werden es nicht Architekten sein, die diese Diagramme zeichnen, sondern Programmierer. Diese Diagramme werden dann einfach zum neuen Code, und Programmierer werden diesen Code zeichnen müssen, weil es letzten Endes immer um Details geht, und es sind die Programmierer, die die Details managen.