Softwareentwicklung in C++ - ASC

1.2 Motivation 7
über die Hälfte der Gesamtentwicklungszeit hinaus keine Zeile Code produziert.
Danach allerdings scheint sich die Arbeit von außen gesehen enorm
zu beschleunigen. In sehr kurzer Zeit wird sehr viel implementiert und die
Implementation ist üblicherweise auch relativ fehlerfrei.
Wenn man im Gegensatz dazu den Projektfortschritt bei einer Hacklösung
ansieht, bei der die Arbeit gleich von Beginn an am Computer stattfindet, ohne
zuerst ein vollständiges (!!) und schlüssiges (!!) Design zu erstellen, dann
beobachtet man als Außenstehender im Prinzip das Gegenteil: Zu Beginn
passiert in kurzer Zeit sehr viel und es gibt sehr schnell einen Prototypen zu
sehen, der einen Teil der geforderten Funktionalität mehr oder weniger gut
implementiert. Gewisse Fehler werden natürlich toleriert, denn man steckt
ja noch mitten in der Entwicklung. Mit jedem zusätzlichen Feature, das die
Software dem Endprodukt näher bringt, geht die Arbeit schleppender voran.
Nach einer gewissen Zeit bedeuten auch die kleinsten Erweiterungen des
halbfertigen Pakets bereits immensen Implementationsaufwand. Außerdem
steigt die Fehlerhäufigkeit auf ein unerträglich hohes Maß. Das Beheben von
Fehlern wird immer mehr zum Spießrutenlauf, denn mit jeder Änderung in
einem Teil der Software passieren ungeahnte Dinge in anderen Teilen der
Software. Mit Glück ist das geforderte Produkt vom Funktionsumfang her
klein genug, dass man dessen Fertigstellung noch irgendwie mehr schlecht als
recht über die Runden bringt. Sehr oft allerdings muss man den Kunden erklären,
dass gewisse Features “aus technischen Gründen gar nicht realisierbar
sind” und hoffen, dass diese das akzeptieren.
Noch viel dramatischer wird das Bild, wenn Erweiterungen oder Änderungen
eines existenten Softwarepakets gefordert sind. Bei der sauberen Entwicklung
ist die Erweiterbarkeit ein Teil des Konzepts und im Regelfall sind
neue Features relativ einfach realisierbar. Sollte durch neue Features das
Ursprungskonzept verändert werden müssen, so ist auch das im Normalfall
möglich, wenn auch mit einigem Aufwand verbunden. Das Endprodukt bleibt
trotzdem sauber.
Ganz im Gegensatz dazu steht die Erweiterbarkeit der Hacklösung. Schon
die kleinsten Änderungen dauern enorm lang und destabilisieren die gesamte
Software. Sehr oft beobachtet man den Fall, dass in sogenannten Bugfix-
Releases zwar einige bekannte schwere Fehler behoben wurden, dafür aber
mindestens genau so viele neue Fehler eingebaut wurden, da die Auswirkungen
von Programmänderungen nicht mehr überschaubar sind.
Vollkommen katastrophal wird es, wenn man die Menge an Source-Code
eines sauberen Projekts mit der einer Hacklösung vergleicht. Im Normalfall
ist die Hacklösung bei gleicher Funktionalität gleich x-Mal so groß wie die
saubere Lösung. Nicht nur, dass die Codemenge ungleich größer ist, auch die
Komplexität des Codes ist durch Seiteneffekte enorm.
Es gibt einen ganz bestimmten Grund, warum ich mich über saubere
und Hacklösungen so ausführlich auslasse: Zur Zeit, zu der OO-Sprachen,
insbesondere C ++, ihren Eingang in die Industrie fanden, war die Euphorie