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

JIRA 4 ist da und wartet mit einer Vielzahl von neuen Features auf, wobei ich mir auch manches langbestehende Manko (JRA-9, JRA-1549) behoben gewünscht hätte. Trotzdem beeindrucken mich auch die neuen Funktionen wie ein neues Dashboards, Activity Streams, die OpenSocial-Integration sowie das allgemein verbesserte UI. Einen Überblick über die neuen Features gibt es bei Atlassian-TV.

Das Killerfeature an sich ist für mich aber die SQL-ähnliche Jira Query Language, mit der sich jetzt endlich auch komplizierte Anfragen bauen lassen, die über das bisherige Interface nicht möglich waren. So kann jetzt beispielsweise nach leeren Feldern gesucht werden, um zu herauszufinden, welchen Issues noch notwendige Felder fehlen. Auto-Completion und Syntaxcheck im Webeditor – was will man mehr? Mehr zur JQL gibt es hier in diesem Atlassian-TV-Beitrag oder in der JIRA-Dokumentation.

Böse Zungen könnten natürlich behaupten, daß es sich bei der JQL nur um eine Query-Translation nach SQL handelt. Vielleicht nicht falsch, aber: "Na und?"

Aus Vertriebssicht ist JIRA 4 auch interessant, da Atlassian das Preismodell für seine Produkte geändert hat und jetzt eine Mischung aus Penetrationsstrategie und Hochpreispolitik (im Vergleich zu den vorherigen Preisen) fährt. Früher gab es drei Versionen mit unterschiedlichen Funktionsumfang: Standard, Professional und Enterprise, wobei die Entprise-Version bei 4.800 Dollar lag. Seit JIRA 4 wird jetzt nur noch der Anzahl der existierenden Benutzern lizensiert. Der Einstieg liegt jetzt bei 10 Benutzern für 10 Dollar. In Hinsicht auf sein Preis-Leistungsverhältnis ein fast unschlagbares Angebot. Auf der anderen Seite muß man für mehr als 100 Benutzer jetzt 8.000 Dollar zahlen und 100 Benutzer sind nicht viel. Wie gesagt, es wird für existierende Benutzer gezahlt und selbst in kleinen Firmen sind 100 Benutzer nicht viel. Man denke nur an Praktikanten und die natürliche Flukturation. Insofern eine doch schon sehr drastische Preiserhöhung.

Mit einem Einstiegsspreis von 10 Dollar sollen ganz klar weitere Marktanteile erobert werden. Gerade kleinere Firmen werden hier sicherlich einsteigen und bei entsprechender Zufriedenheit aufrüsten (müssen). Abgesehen von Opensource-Produkten wie Bugzilla, wird diese Preispolitik anderen Anbietern das Leben in den unteren Preissegmenten erschweren, auch wenn das richtige Geld in den oberen verdient wird. Das Positive daran ist aber auch, daß auch in der kleinsten Ausbaustufe der komplette Funktionsumfang bereit steht und bei Bedarf nur die Anzahl der Benutzer erhöht werden muß.

Mein Fazit: Trotz des effektiv erhöhten Preises ist es das beste JIRA bis jetzt, da es nicht nur kosmetische Änderungen gab, sondern neue interessante Features, die die Arbeit erleichtern und angenehmer machen.

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

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