Entwicklungslandschaft Teil 1 – Blühende Landschaften
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...
Tags: Entwicklungslandschaft, Entwicklungslandschaft.Serie, Entwicklungsumgebung, IDE, Infrastruktur