Webseite als Jekyll-Projekt https://software-berater.net/
You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
 
 
 
 
 
 

5.5 KiB

layout title date category references
post Frameworkeritis 2021-11-12 08:36 +0100 IT Management [_posts/2021-09-26-wann-bist-du-senior.md _posts/2019-11-24-software-standards.md]

Wenn Kollegen mir erzählen, dass sie etwas generisch umsetzen wollen, gar ein Framework schreiben, was anderen dann als Template dienen soll, dann regt sich in mir Widerstand. Die Leute leiden ganz klar an Frameworkeritis, dem zwanghaften Verlangen, ein Framework zu schreiben. Es ist schwer, sie davon zu heilen. Nicht, weil ich den Kollegen den Ruhm nicht gönne, oder sie allgemein für zu blöd halte. Aber diese "Framework"-Geschichte geht meistens nicht gut aus.

Natürlich gibt es gute Frameworks. Spring (Java) oder Laravel (PHP) oder Ruby on Rails (Ruby) oder Django (Python) sind alle wertvolle Werkzeuge, um Webanwendungen zu entwickeln, und es gibt zahllose weitere. Bootstrap entstand bei Twitter, React hat seinen Ursprung bei Facebook. So viele Beispiele, und dennoch: Warum sollte dein Framework also wahrscheinlich unnötig sein?

Standing on the shoulders of giants

Ich liebe das Bild: Man "steht auf den Schultern des Riesen", weil (manchmal sehr viel) Quelltext von anderen Autoren getestet und fertig nutzbar bereitgestellt wird. Wer ein Framework verwendet, kann sich auf die eigentliche fachliche Anforderung konzentrieren, weil viele kleine Details bereits vorgegeben und nutzbar sind.

Das bedeutet aber auch: Ich muss weniger Code schreiben, weil andere bereits mehr Code geschrieben haben. Und getestet. Und Bugs gefixt.

Wenn ich jetzt also eine Software entwickle und dabei auch ein Framework herauskommen soll, dann muss ich mein Projekt coden, und das Framework noch dazu. Zwangsläufig mehr Code.

Erste Erkenntnis: Ein Framework zu schreiben ist aufwendig.

KISS: Keep it simple, stupid!

Wenn die Zeit knapp und die Disziplin eher so lala ist, dann erliegt man vielleicht der Versuchung und trennt fachliche Anforderung des Projektes nicht sauber von der (vermeintlich wiederverwendbaren) Framework-Basis. Manchmal ist auch Mangel an Erfahrung dafür verantwortlich. Das Ergebnis: Unübersichtliche Anwendung, schlechte Wiederverwendbarkeit. Wie Suppentöpfe, die immer nach Tomatensauce schmecken: Gut für Bolognese, für Pudding eher nicht.

Damit Frameworks verwendbar werden, ist saubere Modularisierung wichtig und ganz disziplinierte Trennung von "Projekt" und "Framework". Im Grund schreibt man zwei Projekt gleichzeitig, das erfordert aber ganz viel handwerkliche Sorgfalt.

Zweite Erkenntnis: Nur makellos entworfene Frameworks sind verwendbar.

Wiederverwendbarkeit allein reicht nicht

Viel Arbeit wird investiert, damit Ergebnisse des einen Entwicklers potentiell durch andere wiederverwendet werden können. Was an sich eine gute Sache ist. Aber: Nur wenn das effektiv passiert, können wir von Wiederverwendung sprechen, bis dahin ist das nur eine fixe Idee.

Ob etwas aber tatsächlich wieder verwendet wird, hängt davon ab, ob Projekt 2 zu dem Schluss kommt, dass das Artefakt aus Projekt 1 ihnen tatsächlich das Leben erleichtert, indem es die Umsetzungsdauer reduziert und die Qualität verbessert. Fehlt auch nur eines der Kriterien, dann wird sich Projekt 2 gegen die Wiederverwendung entscheiden.

(Es sei denn, Projekt 2 wird durch nach Aufwand bezahlte Kräfte umgesetzt, die stumpf dem Willen des Auftraggebers folgen. Aber das ist eine andere Geschichte.)

Daraus folgt die dritte Erkenntnis: Ob dein Framework den gewünschten Wert hat, entscheidet deine Umwelt, nicht du als Autor.

Eine Bürde für die Zukunft

Mal angenommen, bisher hat alles funktioniert: Du hast den Mehraufwand erfolgreich in deinem Projekt integriert, keine Designfehler gemacht, und ein erstes weiteres Projekt nimmt deine Arbeit dankend an. Herzlichen Glückwunsch, das meine ich sehr ernst. Du hast viel erreicht.

Ob du es aber willst oder nicht: Mit deinem Beitrag zu Projekt 2 übernimmst du ein Stück weit Verantwortung. Wirst du weiterhin am Ball bleiben, dein Framework erweitern, verbessern und Fehler ausmerzen? Kannst du bei Änderungen zB in der verwendeten Programmiersprache nachziehen? Es gibt heute schon zahllose Opensource-Projekte, die nicht weiter gepflegt werden, siehe zB diese Suche bei distrowatch.com oder hier bei sourcegraph.com. Allein Sourcegraph ermittelt so mehr als 87.000 als "archiviert" gekennzeichnete Repositories, die keine Forks sind. Willst du dich dort einreihen? Was würde das für deine Nutzer bedeuten?

Erkenntnis daraus: Die Wahrscheinlichkeit ist hoch, dass dein Framework früher oder später nicht mehr gepflegt wird.

Fazit: Ich verstehe die Motivation gut, etwas schaffen zu wollen, was über die eigene Tätigkeit hinaus Relevanz hat. Da steckt ein wenig "sich selbst ein Denkmal bauen" drin, und das ist sicher menschlich. Mit wachsender Erfahrung kommt aber die Erkenntnis, dass es zumeist nicht sinnvoll ist, ein eigenes Framework zu begründen. Als Senior Developer muss ich dann meine jüngeren Kollegen von Zeit zu Zeit etwas bremsen.