Wenn wir mit anderen zusammenarbeiten besteht immer die Gefahr sich gegenseitig zu stören. Wir arbeiten im gleichen Projekt, bearbeiten die selben Klassen, schreiben in die selbe Datenbank, gegen die der Kollege seine Tests fährt, machen Änderungen, die sich gegenseitig ausschließen. Oft stellt das kein Problem dar, wenn es koordiniert oder zumindest mit dem Wissen der Kollegen geschieht. Was ist aber, wenn wir genau das nicht wollen? Wenn wir in Ruhe die nächsten zwei Wochen an einem ganz besonderen Feature arbeiten wollen oder ein größeres experimentelles Refactoring vornehmen wollen? Es geht aber nicht nur um die großen Aufgaben. Auch in unserer alltäglichen Arbeit, sollte die Gefahr mit der Arbeit Anderer zu kollidieren möglichst gering sein.
Wir müssen uns also isolieren können und unsere Entwicklungslandschaft muß das unterstützten, uns dafür die technischen Möglichkeiten geben. Solange es für ein gesamtes Team nur eine Datenbank, auf der alle arbeiten, oder nur einen Application Server gibt, gelingt das nicht. Solche Systeme nenne ich immer scherzhaft Synchronisationssingularitäten, also Punkte, an denen alle Arbeiten zusammenlaufen laufen. Aber was bedeutet jetzt Isolation für eine Entwicklungslandschaft?
Hier meine Definition:
Isolation ist die Fähigkeit einer Entwicklungslandschaft an dem SUD (System Under Development) Änderungen vorzunehmen, ohne dabei von Anderen ungewollt beeinflußt zu werden oder Andere ungewollt zu beeinflußen.
Ein sehr gutes praktisches Beispiel für Isolation unterstützende Werkzeuge in einer Entwicklungslandschaft sind Versionsverwaltungssysteme wie Subversion oder Git, das die Isolation durch seinen dezentralen Ansatz noch weiter vorantreibt als früher CVS oder jetzt Subversion. Aber der Einsatz eines Versionskontrollsystems kann nur ein erster Schritt sein. Abgesehen davon: zeitgemäße Softwareentwicklung ohne Versionskontrollsystem ist ein Widerspruch in sich.
Heute lassen sich die meisten Systeme, die wir für Entwicklung und Test benötigen ohne Probleme für jeden Entwickler bereitstellen. Eine eigene Datenbank auf dem Laptop, ein lokaler FTP- oder Mailserver oder auch Applikation-Server sind immer möglich. Manche dieser Systeme müssen sogar nicht festinstalliert werden, sondern können im Rahmen eines Builds installiert und konfiguriert werden. JBoss, GlassFish und Apache Tomcat können aus ZIP-Archiven vollständig installiert und angepaßte Konfigurationsdateien anschließend generiert werden. Wird eine saubere Installation gebraucht, wird die alte gelöscht und eine neue automatisch installiert. Mit etwas Ehrgeiz ist das durchaus möglich.
Aber Isolation bringt noch weitere Vorteile für die Software-Entwicklung:
- Ruhe und Ungestörtheit, weil es nicht ungewollt zu Konflikten mit den Arbeiten von anderen Entwicklern im Team kommt. Änderungen werden nur noch gewollt zusammengeführt.
- Verbesserung der Reproduzierbarkeit, weil alle positiven und negativen Effekte nur durch mich selber verursacht wurden und beispielsweise Testergebnisse so nicht verfälscht werden.
- Besseres Konfigurationsmanagement und Setup, weil Isolation als Ziel besondere Maßnahmen erfordert, die zwangsläufig auch zu Zielen wie besserer Modularisierung und Konfigurierbarkeit führen.
Wenn wir beim Aufbau unserer Entwicklungslandschaft Isolation konsequent von Anfang an verfolgen und beachten, erhalten wir die Chance besser im Team zusammenarbeiten zu können, weil wir es dann geschafft haben gegenseitige Abhängigkeiten weiter aufzulösen. Gerade für agil arbeitende Teams sollte Isolation immer ein zu erreichendes Ziel sein, den deren Fehlen stört den Arbeitsfluß.
