Ein Faktor für Architekturverfall ist Kompromisse beim Entwicklungsaufwand
Categories:
Merkmale einer verfallenen Architektur sind: viele Sondersonderbehandlungen, Kompatibilitätsbehandlungen, starke Kopplung, schwer rückgängig zu machen. Architekturen verfallen allmählich. Eine verfallene Architektur macht es schwer, neue Funktionen zu entwickeln, Bugs schwer zu beheben, alles hängt zusammen, was auch Tests und QA erschwert. Ich habe einmal einen Hobbyentwickler aus einem anderen Bereich posten sehen, der sagte, man solle das Abstraktionsverhalten des Modells beim Coden einschränken, damit der Code leichter verständlich ist. Code, den Menschen leichter verstehen, versteht auch ein LLM leichter, wodurch schneller entwickelt und Fehler reduziert werden können. Ich denke, Hobbyentwickler haben wohl eher kleine Projekte und sind an Fließbandlogik gewöhnt. Wenn man eine Skalierung erwartet, darf man nicht im Fließbanddenken verharren, sondern braucht die Denkweise eines Bauarbeiters. Wenn man ein 30-stöckiges Gebäude bauen will, braucht man ein 10 Meter tiefes Fundament; wenn man Wasser und Strom erwartet, muss man Schächte für Wasser und Strom vorsehen. Das ist ein zielklares Design. Es gibt auch zielunklares Design, z. B. man weiß, dass irgendwo im Haus später ein Gerät stehen soll, aber nicht welches – da reicht eine Steckdose vorzusehen. Die Softwareentwicklung kennt bereits die SOLID-Prinzipien zur Leitlinie des Designs. Oft wirkt es so, dass das Befolgen der SOLID-Prinzipien für dieselbe Funktion mehr Dateien und mehr Code bedeutet. Kurzfristig betrachtet sieht Chef/Test und Nutzer kaum einen Unterschied zwischen Design oder Nicht-Design; der Nutzen des Designs zeigt sich erst langfristig. Eine gute Architektur erleichtert das Hinzufügen, Ändern von Funktionen und das Beheben von Bugs bei weniger neuen Problemen. Das Nachdenken über Design erfordert oft mehr als das direkte Loslegen mit der Entwicklung. Man muss die Granularität bedenken. Das gesamte Haus mit Steckdosenpanels wie mit Fliesen zuzukleben, ist eine andere absurde Vorgehensweise. Früher habe ich bei der Entwicklung den Zeitrahmen beachtet und Kompromisse gemacht: bei knapper Zeit kein Design, einfach ein paar Funktionen hinzufügen, die Zukunft auf später verschieben. Heute mit KI können wir die Designgranularität feiner wählen; der generierte Code ist für Menschen schlechter lesbar, aber die Software leichter wartbar. Mehr Abstraktion kann schwächere Modelle überfordern – am besten das aktuell beste Modell nutzen. Bei reinen Skripten sind die Fähigkeitsunterschiede zwischen Modellen vielleicht weniger deutlich. Ob KI die Einstiegshürde für Entwickler gesenkt hat? Ich bezweifle das, da der Lernweg neuer Entwickler sich stark vom früheren unterscheidet. Über die Höhe der Hürde zu diskutieren ist vielleicht sinnlos, weil wir nicht wissen, wohin die Hürde verschoben wurde.
