Direkt zum Hauptbereich

Gibt's da nicht auch was von...

Dank der unzähligen Frameworks und Bibliotheken, die angetreten sind um für jedes Problem die passende Lösung zu bieten, komm ich mir ab und an vor wie in der Werbung eines Medikamentenherstellers.

Kaum habe ich ein zu lösendes Problem / eine Programmieraufgabe gehustet, da stehen auch schon die engagierten Kollegenzwillinge da und Fragen: "Gibt's da nicht auch was von..." und überbieten sich mit der Nennug von Frameworks und Bibliotheken, über welche sie vor kurzem gelesen haben und die GENAU das Problem lösen.




Leider ist es mit  Frameworks ganz genau wie mit den Medikamenten. Bewusst und richtig dosiert eingesetzt können sie dem Projekt helfen. Zu viele oder in der falschen Kombination schaden sie dem Projekt auf dauer.

Deshalb schaue ich nicht nur wegen der Lizenzfrage ganz genau hin ob das Framework wirklich nur mein Problem löst und ob mein Problem es wirklich Wert ist, sich eine weitere Abhängigkeit ins Projekt zu holen. Im Zweifel nehme ich lieber eins weniger als eins mehr.

Denn jedes Framework ist nicht nur eine Abhängigkeit mehr, welche über Jahre hinweg gepflegt werden will, sondern wie der Name schon sagt, ein Rahmenwerk welches Vorgaben an unseren Code macht.

Während der ersten Umsetzung mag es schneller und einfacher sein die Bibliothek / das Framework einzusetzen und die Vorgaben welche durch diese gemacht werden sind grad allen bekannt. Aber wenn ich neu in ein bestehendes Projekt komme oder einfach nur eine Weile nicht mit dem Projekt zu tun hatte sieht das schon ganz anders aus. Auf einmal kostet es mich viel Aufwand herauszufinden warum etwas auf den ersten Blick seltsam umgesetzt ist oder wie es überhaupt funktionieren soll. Bis ich dann aus der ewig langen Abhängigkeiten Liste heraus gefunden habe welches Framework hier zur Problemlösung eingesetzt wurde und wie es in der (vermutlich veralteten Version) funktioniert hat. Mit Glück ist es ein größeres gewesen und es existiert noch und damit auch die Dokumentation. Mit Pech war es ein verflogener Hype und ich muss hoffen, noch einen alten Kollegen zu finden, welcher weiß wie und was das Framework gemacht hat.

Hinzu kommen dann noch die ganzen "Krücken" die gebaut wurden um verschiedene Frameworks miteinander nutzen zu können. Mal abgesehen von den Versionsdschungeln. Habe ich schon die selbst angepassten Frameworks erwähnt, welche doch nicht genau das Problem gelöst haben nun aber schonmal da waren?

Da ja bekanntermaßen die Zeit nach der Erstentwicklung länger ist, sollte man sich also genau überlegen, ob der Einsatz der Bibliothek / des Frameworks mehr Vorteile als langfristige Nachteile bringt.
Das gilt auch für SubFrameworks wie z.B. die unzähligen Erweiterungen von Spring. Ist Spring erstmal im Projekt sind die Erweiterungen oft leichtfertig hinzugefügt.

Grundsätzlich ist es nicht verkehrt fertige Lösungen zu verwenden, wenn der Einsatz durchdacht und der Nutzen gegeben ist.

Kommentare

Beliebte Posts aus diesem Blog

Eine Retro im Kreis

Für die letzte Retro habe ich die Tische und Stühle alle beseite gestellt um dann mit Klebeband (Malercrep) drei unterschiedlich große Kreise um einen Mittelpunkt zu kleben. Der innerste Ring war groß genug, dass das gesamte Team da drin Platz finden konnte. Für die erste Phase der Retro habe ich Kärtchen mit den Zahlen 50, 40, 30, 20 in den Ringen ve rteilt. Die 50 in der Mitte und dann absteigend nach außen. Um so eine Zielscheibe anzudeuten.

Mit dem Rücken am Tellerrand

Es ist gut auch mal über den Tellerrand zu schauen. Manchmal sind wir so in "unserer Welt" gefangen, dass wir den Rest gar nicht mehr wahr nehmen. Zum Beispiel muss ich mich immer wieder daran erinnern, dass nicht alle Menschen mindestens ein Smartphone haben. Oder das agile noch lange nicht Mainstream ist. Nur weil wir uns in einem Umfeld bewegen, in dem die Dinge so scheinen wie sie sind, heißt das noch lange nicht, dass dem auch so ist. Ein Typisches Beispiel für den Unterschied von Realität und Wahrnehmung der Realität. Aber auch um neuen Ideen eine Chance zu geben, welche scheinbar nicht funktionieren können, weil sie nicht in unsere Gedankenwelt passen ist es sinnvoll ab und an über den Tellerrand zu schauen. Heute habe ich noch einen Tweet, welcher darauf hinweist gesehen: Wenn uns das einmal bewusst geworden ist, dann neigen wir (oder zumindest geht es mir so) dazu möglichst oft über diesen Tellerrand zu schauen. Dabei kann es aber passieren, dass wir so

Der Wasserfall ist immer noch vorherrschend in der Softwareentwicklung

In den letzten Jahren sind viele "neue" Bewegungen auf der Bildfläche des Mainstream-Bewusstseins der Softwareentwicklung erschienen. Und viele aktuelle Studien berichten, dass die Agilität den Wasserfall abgelöst hat. In allen Softwareunternehmen und viele der Entwickler die ich treffe reden zumindest viel über Agilität. Wenn aber mal einen Schritt zurück macht sieht das (ideal) Bild eher so aus: Die neue Lösung wird mit Design Thinking gefunden und definiert. In der Entwicklung ist dann eher die Rede von agile (meist Scrum) und selten SoftwareCraftsmanship. Von der Betriebsseite heißt es nun DevOps. Aber dazwischen gibt es immer noch Brüche und es existiert keine Ganzheitlichkeit. Jahrzehnte lang haben wir in der Softwareentwicklung geglaubt und es so auch allen Kunden beigebracht, dass die "Cost of Change Curve" gilt und daher der Wasserfall als Vorgehen perfekt ist. (Was nun was bedingt, lass ich mal dahingestellt) Dadurch haben sich natürlich auch di