Softwareprozesse

So langsam verstehe ich, was der Sinn von “Schnell funktionierenen Code erzeugen” und “Falls nötig, refaktorisieren” in Softwareprozessen wie XP ist. Erst, wenn man man mit einem (selbst geschriebenen) Grundgerüst eines Frameworks eine (funktionierende) Anwendung geschrieben hat, weiß man, was im Framework fehlt. Und zwar sieht man dies daran, wo der Code der Anwendung Redundanzen enthält, die man dadurch beseitigen kann, daß man im Framework geeignete Abstraktionen zur Verfügung stellt.

IMO kann man das auch nicht vorausplanen. Man weiß eben nicht vorher, welche Abstraktionen sinnvoll sind. Versucht man es dennoch, erhält man im Regelfall ein Framework, das entweder nicht zu durchschauen ist, weil es eine enorm komplexe Schnittstelle hat, so daß man eine weitere Schicht darüber braucht, um diese Komplexität zu handlen (beliebtes Anti-Pattern: Add an extra layer of indirection), oder es bietet nicht die richtigen Funktionen, so daß die Anwendung schließlich ein einziger Workaround ist (oder man wieder mal eine zusätzliche Schicht eingefügt hat).

Das Ganze formalisieren zu wollen, ist meines Erachtens zum Scheitern verurteilt. Um die nötigen Abstraktionen bestimmen zu können, muß erstmal etwas Konkretes da sein. Das nötige Fingerspitzengefühl, um zu wissen, wieviel Konkretes da sein muß, ist wohl ein wichtiger Schritt in der Entwicklung jedes Programmierers.

Unnötig zu sagen, daß man sowas in einer Vorlesung (Softwaretechnik) ganz sicher nicht lernt – die bis jetzt knapp 140 Stunden Programmier-Hiwi-Job haben da deutlich mehr gebracht.

Achja, das “Standard”-V-Modell mit Entwurfsphase und Programmierern, die stur nur das ihnen zugewiesene Modul betrachten, stelle ich mir doch arg langweilig vor. So möchte ich nicht arbeiten müssen.

Hinterlasse eine Antwort

Deine E-Mail-Adresse wird nicht veröffentlicht.

Du kannst folgende HTML-Tags benutzen: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>