Software Engineering Blog

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ß.

Woher das Wort Schnelligkeit kommt weiß ich leider nicht. Auch ein Blick in den Kluge konnte mir nicht weiterhelfen. Für eine Entwicklunglandschaft bedeutet Schnelligkeit aber etwas ähnliches wie für den Sportler. Im Sport wird Schnelligkeit in zwei Arten aufgeteilt:

• Aktionsschnelligkeit und
• Reaktionsschnelligkeit

Aktionsschnell ist jemand, der etwas in kürzerer Zeit machen kann als andere, zum Beispiel Laufen. Reaktionsschnell ist jemand, der sich in kurzer Zeit auf Signale und Reize reagieren kann.

Auch Entwicklungsumgebungen kennen solche zwei Arten der Schnelligkeit. Die Aktionsschnelligkeit einer Entwicklungumgebung ist die Fähigkeit Entwicklungsaufgaben in möglichst kurzer Zeit effizient durchführen zu können.

Eine gute Build-Umgebung erlaubt es uns schnell überprüfen zu können, ob unser Code gebaut werden kann. Eine gute Testumgebung schafft uns die Möglichkeit unsere Änderungen schnell überprüfen zu können. Habe ich etwas kaputt gemacht?

Eine Entwicklungslandschaft kann zwar nicht reaktionsschnell sein, zumindest nicht direkt, aber sie kann eine hohe Änderungsschnelligkeit haben. Das heißt nichts anderes, als daß sich Änderungen in der Entwicklungslandschaft schnell vornehmen lassen.

Bis hier wird jeder sicherlich zustimmen können und jeder wird wohl auch ein Build-Script haben, daß seinen Code baut oder zumindest etwas ähnliches. Doch gehört dazu noch mehr als das, was in den meisten Entwicklungsumgebungen zu finden ist. Uns geht die Aktionsschnelligkeit verloren, wenn wir bei häufigen Tätigkeiten immer manuell eingreifen müssen. Wir sind zwar bei den einzelnen Schritten schnell, verlieren dann aber Zeit beispielsweise mit Kopieren von Dateien oder ähnlichem.

Aber wozu brauchen wir diese Schnelligkeit eigentlich? Sicher will keiner lange auf irgendetwas warten. Das ist klar. Wir brauchen diese Schnelligkeit vorallem für eins: um flexibel zu bleiben. Wir alle sind in der einen oder anderen Art faul und sobald bestimmte Aufgaben uns zu aufwendig erscheinen, versuchen wir sie zu umgehen. Wir bauen oder testen weniger und ab dem Punkte sind wir auf dem absteigenden Ast...

Und wie kommen wir zu einer schnellen Entwicklungsumgebung:

• Analysieren Sie die Abhängigkeiten in ihrer Entwicklungsumgebung und durchtrennen sie sie dort, wo sie nicht notwendig sind.
• Cachen Sie Zwischenergebnisse wo immer möglich. Nicht alles muß immer wieder erzeugt oder generiert werden.
• Wählen sie die richtigen Tools aus.

Um wirklich schnell zu sein, braucht es aber auch einen hohen Automatisierunggrad. Aber das ist ein anderes Thema...

Von Eclipse als Entwicklungsumgebung war ich noch nie begeistert. Eclipse war mir immer zu groß, langsam und schwerfällig. Wohl auch berechtigt, wenn man im Vergleich dazu Intellij IDEA von Jetbrains aus St. Petersburg benutzt.

Daher hat mich "I stopped using Eclipse..." Artikel im Blog von Gernot Starke richtig aufrichtig gefreut.

Dazu passend hier noch ein Ausschnitt von der XING-Seite eines ehemaligen Kollegen:

Herzliche Grüße nach Bonn und Köln!

Softwareentwickler verbringen die meiste Zeit ihrer Arbeit mit ihrer Entwicklungsumgebung. Daher bin ich oft überrascht, auf welch schlecht aufgebauten Entwicklungsumgebungen ich in Software-Projekten stoße.

Vielleicht sollte ich aber eher von Entwicklungslandschaft als von -umgebung sprechen, da für mich alles zur Entwicklungslandschaft zählt, was wir für unsere Software-Entwicklung benötigen. Das schließt alles mit ein, angefangen vom Datenbanksystem bis hin zu Issue-Tracking-System.

Schon Ian Sommerville nennt als eine zentrale Anfoderung an Software-Entwicklungsumgebungen (-landschaften), daß verschiedene Werkzeuge für unterschiedliche Phasen zur Verfügung stehen sollen, die Menge der Funktionen der Entwicklungsumgebung aber zu jeder Zeit durch neue Werkzeuge erweitern lassen muss, um neue Funktionen integrieren zu können, da wir nicht wissen, welche Funktionen später umzusetzen sind. Kurz gesagt, sie soll flexibel sein.

Oft sind Entwicklungslandschaften jedoch das ganze Gegenteil: starr und sogar hinderlich bei der Arbeit. Im einfachsten Falle kosten sie einfach nur Zeit. Die Probleme in einer Entwicklungslandschaft fangen schon an, wenn mehrere Entwickler dazu gezwungen sind auf der gleichen Datenbank parallel zu entwickeln und enden in stundenlangenen Installationen von Tools und deren Konfiguration.

Dabei muß unsere Entwicklungslandschaft genauso flexibel oder besser gesagt agil sein wie wir selber. Die gute Entwicklungsumgebung muß uns bei allen Änderungen unterstützen, uns einladen neues auszuprobieren und flexibel zu bleiben. Sobald wir eine Änderung, einen Test oder Idee verwerfen, nur weil sie nicht mit angemessenem Aufwand mit unserer Entwicklungslandschaft umzusetzen ist, ist es Zeit über sie nachzudenken.

Damit dies einfacher fällt, habe ich hier meine Kriterien für eine gute Entwicklungslandschaft zusammengestellt:

• Angemessenheit Eine Entwicklungslandschaft muß vom Entwicklungs- und Pflegeaufwand zur Projektgröße und -dauer passen. Je größer, je länger oder je mehr Entwickler an dem Projekt teilnehmen, desto mehr rentiert sich auch ein größerer Aufwand für die Entwicklungsumgebung.
• Zweckdienlichkeit Alle Komponenten der Entwicklungslandschaft sind effektiv für ihren Einsatzzweck und effizient einsetzbar.
• Isolation Jeder Entwickler muß die Möglichkeit und Sicherheit haben, Änderungen unabhängig von anderen durchführen zu können und auch nicht durch die Änderungen anderer ungewollt beeinflußt zu werden. Und hierbei denke ich nicht nur an den Einsatz eines Versionskontrollsystems.
• Automatisierung Wiederkehrende Tätigkeiten müssen automatisierbar sein. Die Entwicklungsumgebung muß hierfür die notwendige Unterstützung anbieten. Stichwörter sind hier beispielsweise Ant und Maven.
• Schnelligkeit Jede regelmäßig ausgeführte Tätigkeit muss sich in der Entwicklungslandschaft schnell ausführen lassen.
• Anpassbarkeit Jeder Entwickler muß die Möglichkeit haben seine persönliche Entwicklungslandschaft an seinen Erfordernissen entsprechend zu konfigurieren.
• Erweiterbarkeit Neue temporär und permantente Funktionen müssen sich leicht in die bestehende Entwicklungslandschaft integrieren lassen.
• Neutralität Einzelne Komponenten der Entwicklungslandschaft müssen sich leicht gegen andere Tools mit einer äquivalenten Funktionalität austauschen lassen. Funktionalität und Werkzeug müssen also so weit wie möglich orthogonal sein.

In den nächsten Tagen werde ich die einzelnen Punkte näher erläutern...