Man sagt ja immer, dass man nicht jedes mal das Rad neu erfinden soll. Das ist auch gar nicht verkehrt, denn das Rad neu erfinden birgt viele Risiken.
Jedes mal, wenn man eine gewisse Funktion neu implementiert kann es zu Fehlern kommen. Nicht umsonst gibt es bei Sicherheitskritischer Software (z.B. Bibliotheken zur Verschlüsselung) die Regel: Benutzt „abgehangene“ Bibliotheken, schreibt keine eigenen!
Wenn man jedes mal eine neue Implementation anfertigt, ist auch fraglich ob die Performance, Code-Qualität oder Anzahl an Features einer langjährig gepflegten Bibliothek das Wasser reichen kann.
Es kann allerdings auch zum gegenteiligen Effekt kommen: Software, die lange abhängt, ist ggf. in veralteter Technologie geschrieben und vielleicht nicht so effizient wie neuere Bibliotheken, Frameworks, …
Simplicity vs. Complexity
Frameworks zu verstehen und zu beherrschen braucht manchmal etwas Durchhaltevermögen.
Fraglich ist an dieser Stelle was passiert, wenn seit Jahren (oder gar Jahrzehnten) an einer Bibliothek, einem Werkzeug, einem Server, etc. entwickelt wird. Beobachten kann man das an vielen Beispielen, aber man kann sich ja einfach mal Java anschauen.
Java ist eine Sprache mit Softwarebibliotheken, die durch Weiterentwicklung einen Spagat zwischen Kompatibilität und Funktionalität machen. Dadurch kommen Konstrukte, wie z.B. Wrapper-Klassen für primitive Typen, Interfaces für Lambda Ausdrücke und zwei parallele Implementationen für Ein-/Ausgabe (java.io und java.nio). Keiner kann behaupten, dass mit jedem Update von Java die Sprache und die Bibliotheken leichter zu handhaben sind. Eher im Gegenteil.
Ein weiteres Beispiel ist der HTTP Server von Apache. Dieser wird seit 1995 entwickelt und betrieben, die Funktionalität ist enorm, ebenso die Verbreitung. Leider wächst die Komplexität solcher Software ins schier Unermessliche. Die Standardfunktionalität vom Apache HTTP Server ist schnell konfiguriert (dank der mitgelieferten Konfigurations-Dateien), aber spezielle Bedürfnisse benötigen einen erhöhten Aufwand an Konfiguration.
Das Rad 2.0
Ich habe selbst mit dem Apache HTTP Server gekämpft, als ich ihn als reverse Proxy mit Caching konfigurieren wollte. Einige Zeit (so ca. drei Stunden) später ist es mir leider nicht geglückt.
Da die Komplexität der Konfiguration und die wahrscheinlich sehr große Code-Basis für mich in so kurzer Zeit nicht durchdringbar ist, habe ich mich dazu entschlossen das Rad neu zu erfinden und einen solchen proxy selbst du schreiben. Die Features, die für mich relevant waren, sind weder komplex, kompliziert oder umfangreich, sodass die Entwicklung des Proxies nur ca. zwei Stunden gedauert hat.
Der Code liegt nun in meiner Hand, ich weiß genau was die Software kann und wie ich sie zu konfigurieren habe und falls ich speziellere Features haben möchte, weiß ich, wo ich sie einbauen kann. Zudem spielt manchmal ja noch ein psychologischer Aspekt mit: Ich muss mich nicht mit dieser Konfigurationssch**** auseinandersetzen 😉
Da der Apache HTTP Server gefühlt alles kann, braucht er auch gefühlt alles an Ressourcen. Die Standardausführung unter Windows mit XAMPP braucht schon so seine 180 bis 200MB RAM. Mein kleiner Server ist nun genau auf einen speziellen Problemfall zugeschnitten und braucht daher für seine Tätigkeit lediglich um die 13MB RAM. Performance kann somit natürlich auch ein Grund für eine Eigenentwicklung sein.
Just saying …
Natürlich soll das nicht heißen, dass man ab jetzt alles selbst schreibt. Ich möchte nur sagen, dass man ab und zu vielleicht nicht immer für jede Kleinigkeit das große Framework rausholt, ggf. den Code an das Framework anpasst und so unnötige Abhängigkeiten aufbaut. Man sollte einen gesunden Grad finden zwischen Abhängigkeiten zu Frameworks und Entwicklungsaufwand bei Eigenentwicklungen.