Stellt einem Softwareentwickler mal die Frage, ob der Code den er vor ein oder zwei Jahren geschrieben hat immer noch gut findet. Meistens ist die Antwort: Würde ich heute anders machen.
Diesen Prozess habe ich sowohl in dienstlichen Projekten als auch in Privatprojekten mehr als einmal festgestellt. In die Liste der größeren Privatprojekte gehören ShoppingMap von 2007, ReadYou von 2008, DieSachsen.de von 2009 und BizzBingo.com von 2011.
Bei jedem Projektstart geht einem daher immer wieder dasselbe durch den Kopf:
(Bildquelle – schaut euch auch mal die anderen Comics an, sind einige Gute dabei)
Der Weg ist nicht immer das Ziel
Man lernt recht schnell, dass es nicht den richtigen Weg gibt um Software zu entwickeln. Es gibt dutzende Programmiersprachen, Frameworks und Konzepte. D.h. es gibt zwangläufig auch mehrere Wege das Ziel zu erreichen. Man muss sich im klaren werden:
Was ist das Ziel?
Möchte man einfach nur in eine Technologie reinschauen, dann kann man bauen was man möchte. Hat man jedoch ein konkretes Ziel im Auge, sollte man sich überlegen: Was bringt mich meinem Ziel näher? Brauch ich eine 5 Schichten Architektur, mit Response/Request Gedöns und muss ich streng gläubig nach TDD vorgehen? Muss ich mein Loginsystem jetzt mit der Windows-Identity Foundation ausstatten? Oder möchte ich einfach nur ein paar ganz triviale Daten so einfach wie möglich abspeichern?
Und wie verhindert man das Chaos?
Meist kommt das Chaos zustande, weil man zu viele Sachen gleichzeitig haben will. Man hat dutzende Ideen oder dutzende Feature Requests vom Kunden und natürlich muss alles bereits von Version 1, aber mindestens ab Version 2 dabei sein. Das heißt natürlich, man muss sich für alle Eventualitäten sichern.
Meistens endet sowas in einer völlig aufgeblasenen Architektur: Kanonen auf Spatzen oder die Kanone zielt wo ganz anders hin.
Die Software in kleinen Schritten entwickeln und immer wieder prüfen ob das Gebilde immer noch “in Takt” ist hilft dem Chaos Herr zu werden.
(Quelle)
Meine Empfehlung:
Wenn man ein Projekt entwickelt, was irgendwann einmal etwas sinnvolles tun möchte (!= Lernprojekte zum Rumspielen), dann geht in winzigen Schritten voran. Continuous Delivery kann ein Weg sein um schnell Antworten zu bekommen. Viele der Anforderung an die Software werden sich im Projektverlauf ohnehin noch ändern. Bei anderen Sachen gilt: YAGNI.
Konzentration aufs Wesentliche:
Welchen Zweck soll die Software erfüllen und wie kann man dies am einfachsten erreichen – ganz ohne Mondraketen-Architektur. Software baut man nicht “weil man es kann”, sondern weil man ein Bedürfnis/Zweck erfüllen möchte. Den richtigen Weg das zu tun gibt es nicht und solange der Zweck erfüllt ist, ist doch alles andere auch egal.
