Über die Wahl der richtigen Werkzeuge

Egal ob Website, Webapplikation oder Microservice mit API: Im Normalfall beginnt die Entwicklung heute nicht mehr bei Null, sondern man setzt auf bereits vorhandene, weit verbreitete und getestete Werkzeuge und Tools, welche sich zudem leicht anpassen und erweitern lassen.

Wichtig ist hierbei natürlich der jeweilige Anwendungsfall und die daraus resultierenden Anforderungen. Das reine Anzeigen von Informationen im Web erfordert andere Tools, als eine große Webapplikation, die einen komplexen Geschäftsprozess abbildet und täglich von mehreren hundert Personen aktiv verwendet wird.

Auch haben sich in den letzten Jahren die Ansprüche der Endnutzer (zurecht!) verändert. War es früher vielleicht in Ordnung, schnell mal ein paar halbwegs funktionierende Formulare irgendwie „zusammenzubauen“, rückt heute das Nutzererlebnis in den Vordergrund.

Websites und Webapplikationen müssen intuitiv verstanden werden können, sollen unkompliziert verwendbar sein, schnell reagieren und idealerweise auch noch problemlos mit Mobilgeräten bedienbar sein. Und das sind nur ein paar der wichtigsten, zu beachtenden Punkte!

Dem Endnutzer ist es natürlich vollkommen egal welche Technologien im Hintergrund für die Entwicklung verwendet wurden, Hauptsache das Ding funktioniert! Anders verhält es sich aber, wenn man die Entwicklung dieses „Dings“ zu bezahlen hat. Dann möchte man nicht nur, dass es wie gewünscht funktioniert, sondern auch, dass es möglichst effizient und somit kostengünstig entwickelt wurde! Um dies sicherzustellen braucht es mächtige Werkzeuge!

Ich möchte in diesem Artikel erklären, auf welcher Basis ich mich für oder gegen mögliche Tools entscheide (bzw. entschieden habe) und auch aufzeigen, warum das in der Software- und Webentwicklung etwas anders funktioniert, als in anderen Bereichen.

 

Der Unterschied zum Schreiner

Wenn Sie heute zwei voneinander unabhängige Schreiner fragen, welche Werkzeuge sie im Arbeitsalltag einsetzen, werden Sie feststellen, dass sich die gegebenen Antworten nicht grundsätzlich voneinander unterscheiden. Klar, vielleicht hat einer der Schreiner bessere und neuere Maschinen oder teurere Werkzeuge als der andere, aber trotzdem werden beide z. B. Meterstab, Säge, Hammer, Stechbeitel und Hobel auflisten. Das ist praktisch und schlau, denn so kann jeder Schreiner auch mit den Werkzeugen eines Kollegen etwas anfangen - die Zusammenarbeit wird vereinfacht.

Ganz anders verhält es sich hingegen im Bereich der Software- und somit auch der Webentwicklung. Wenn Sie heute also zwei Webentwickler nach deren eingesetzen Werkzeugen fragen, bekommen Sie mit recht großer Wahrscheinlichkeit ganz unterschiedliche Antworten.

Nun werden Sie vielleicht fragen: „Warum ist das so? Warum gibt es im Bereich der Webentwicklung nicht auch einheitliche Werkzeuge mit denen jeder arbeitet?“ Das sind absolut berechtige Fragen, die Antwort dazu hat unter anderem etwas mit dem Alter der jeweiligen Disziplinen zu tun.

Sehen wir uns also nochmal das Schreinerhandwerk an. Sie haben es dort mit einer jahrhundertelangen Tradition zu tun und im Laufe dieser Zeit hat sich eben herauskristallisiert, welche Werkzeuge die richtigen für die zu erledigenden Arbeiten sind.
Auf der anderen Seite haben Sie das Internet, das erst im Laufe der 90er Jahre einer breiteren Öffentlichkeit bekannt wurde. Entsprechend neu (und divers) sind auch alle Werkzeuge und Tools die sich seitdem für den dortigen Einsatz entwickelt haben.

Aber, es tut sich etwas, es wird besser!

Vor allem im Laufe der letzten 10-15 Jahre haben sich, auch durch die immer stärker zunehmende Adaption und Verbreitung von Open Source, gewisse Standards herausgebildet.
So wurde z. B. Wordpress das weltweit erfolgreichste Content Management System (CMS) mit einem riesigen Ökosystem aus verfügbaren Themes, Plugins und sonstigen Erweiterungen. Aber auch die Browserhersteller haben mittlerweile weitestgehend verstanden, dass Webstandards eine gute Idee sind, von der alle profitieren können.

 

Meine Auswahlkriterien

Grundsätzlich bin ich großer Verfechter von „Use the right tool for the job“. Bedeutet: Ich greife nicht für jeden Anwendungsfall immer auf das gleiche Werkzeug zurück. Stattdessen wähle ich, abhängig von den gegebenen Anforderungen, das was sich am besten eignet.
Damit vermeide ich, was Abraham Maslow mit seinem Zitat „I suppose it is tempting, if the only tool you have is a hammer, to treat everything as if it were a nail.“ schön beschreibt. Siehe hierzu: Law of the instrument

Lassen Sie mich an dieser Stelle bitte noch eines klarstellen: Ich habe definitiv keine Lebenszeit zu verschenken und die tiefe technische Einarbeitung in nahezu jedes der von mir verwendeten Tools betrug in der Regel mehrere Wochen bis Monate. Daher musste ich mir immer sehr gut überlegen in welchem Bereich ich Zeit investieren wollte und die nachfolgende Liste war (und ist auch weiterhin) mein Ausgangspunkt für diese Entscheidungen.

1. Fokus auf Webentwicklung

Schon ein kurzer Blick auf die Liste von Programmiersprachen macht klar, wie unübersichtlich das Feld der Softwareentwicklung mittlerweile geworden ist. Programmiersprachen entstehen allerdings nicht einfach so. Jede einzelne wurde zur Lösung ganz bestimmter Probleme geschaffen und hat somit ihre Daseinsberechtigung.

Die Wahl der zu nutzenden Programmiersprache hängt in der Regel davon ab, wie das Ökosystem um diese Sprache herum aussieht und womit der Entwickler bereits Erfahrung hat. Gibt es z. B. ein sehr gut geeignetes Webframework das für ein Projekt benutzt werden soll, hat sich die Frage nach der richtigen Sprache im Prinzip schon von selbst erledigt. Es wird die Sprache verwendet, in der das Webframework geschrieben wurde.

Es ist also wichtig, dass ich mir als Webentwickler Werkzeuge suche, die extra für diesen Bereich entwickelt wurden und sich dementsprechend gut eignen.

2. Open Source

Musste man vor 20 Jahren schon allein für Datenbanksysteme noch viel Geld bezahlen und lange Zeit entwickeln, um überhaupt auch nur die Grundfunktionen von etwas komplexeren Websites oder Webapplikationen zu realisieren, hat sich das heute dank Open Source Software nahezu komplett verändert.

Open Source bedeutet, dass es sich um quelloffene Software handelt. Es ist also möglich den Quellcode einzusehen, diesen zu ändern und kostenlos zu nutzen.

Somit ist es nicht notwendig das Rad immer wieder neu zu erfinden. Stattdessen kann man auf Software zurückgreifen, die in einigen Fällen durch die Zusammenarbeit mehrerer tausend Entwicklern über viele Jahre hinweg entstand. Beispiel: Rails - Mehr als 4500 Mitentwickler, erstes Release im Jahr 2004. Klar ist: Selbst der ambitionierteste und talentierteste Webentwickler wird nie imstande sein, diese massive Geistes- und Arbeitsleistung allein zu erbringen. Open Source ist großartig!

Eine kleine Zusammenfassung der Vorteile:

• Kostenlose Nutzung, es fallen keine Lizenzgebühren an
• Größere Projekte haben in der Regel eine weite Verbreitung und große Nutzerbasis
• Sehr schnelle und gute Hilfe bei Problemen durch die große Nutzerbasis
• Unabhängigkeit von einzelnen, kommerziellen Herstellern, kein Lock-in-Effekt

3. Aktive Weiterentwicklung durch die Community und starke Verbreitung

Das beste Open Source Projekt nützt meist nichts, wenn dessen aktive Weiterentwicklung eingestellt wurde.

Deshalb ist es sinnvoll auf Projekte mit einer weiten Verbreitung und großen Nutzerbasis zu setzen, denn dort ist die Gefahr eines abrupten Endes relativ gering. Vor allem dann, wenn hinter diesen Projekten eine engagierte und aktive Community steckt, die sich um Erweiterung, Wartung und Pflege kümmert.

Ein zusätzlicher, positiver Nebeneffekt: Projekte mit einer großen Nutzerbasis haben in der Regel bereits eine gewisse Reife erreicht. Das ist gerade für einen stabil laufenden Einsatz innerhalb der Produktionsumgebung wichtig. Die allerneueste Bleeding Edge Technologie kann dies meist nicht leisten - Bugs und Sicherheitslücken sind die Folge.

4. Gute Dokumentation

Eine gute Dokumentation wird im Softwareentwicklungsbereich leider zu oft unterschätzt. Ich finde das fatal, denn je besser die vorhandene Tool-Dokumentation ist, umso leichter fällt die Einarbeitung und spätere Nutzung.

5. Erweiterbarkeit

Natürlich könnte man behaupten, dass Open Source Projekte immer erweiterbar sind, immerhin ist deren Code öffentlich einsehbar und kann verändert werden. Das meine ich aber nicht mit Erweiterbarkeit.
Es ist nämlich ein Unterschied, ob ich ein System/Projekt nur verändern kann, indem ich es „komplett zerlege“, oder ob eine Erweiterbarkeit z. B. über Plugins von Anfang an vorgesehen wurde. Letzteres ist zu bevorzugen.

6. Mächtigkeit / Erlernbarkeit / Performance

Der letzte Punkt ist ein wenig abstrakter, da hierbei eine Abwägung je nach Fall stattfinden muss.

Nutzen wir als Beispiel wieder Rails, das ich bevorzugt als Backendframework für Webapplikationen einsetze.
Rails ist ein mächtiges Werkzeug und unterstützt mich sehr bei meiner Arbeit, gleichzeitig muss der Umgang damit aber erst erlernt werden. Durch die vielen Funktionen, die Rails standardmäßig mitbringt, erscheint es im ersten Moment sehr komplex. Diese Fülle an Möglichkeiten führt aber dazu, dass erfahrene Entwickler wesentlich weniger Code neu schreiben müssen - stattdessen können sie immer wieder auf bereits Vorhandenes zurückgreifen.

Was ich damit verdeutlichen möchte: Langfristig gesehen macht es oft Sinn den Umgang mit komplexeren Tools zu erlernen, da man sich viel unnötige, weil doppelte Arbeit ersparen kann.

Ein weiterer Punkt den es zu beachten gilt ist die Performance. Rails ist mächtig und hat das Ziel, dem erfahrenen Entwickler die Arbeit zu erleichtern, um so den Entwicklungsprozess zu verkürzen. Dafür wurden aber Abstriche bei der Performance gemacht. Vergleicht man also in (leider oft etwas fragwürdigen) Benchmarks die Geschwindigkeit von Rails mit anderen, rein auf Performance optimierten Frameworks, so zieht Rails den Kürzeren. Ist das schlimm? Nein, denn eine mit Rails entwickelte Applikation arbeitet - absolut gesehen - immer noch wahnsinnig schnell und deckt die allermeisten Geschwindigkeitsanforderungen locker ab.

Einfache und schnelle Entwicklung oder Performance? Jeff Atwood hat das schon 2008 in seinem Artikel „Hardware is Cheap, Programmers are Expensive“ zusammengefasst. Sein Ansatz: Lieber auf weniger performante, dafür bessere Tools setzen. Als Ausgleich dann eben mehr Geld für Server ausgeben. Das macht Sinn, denn Entwickler kosten richtig Geld!
Jeff Atwood ist übrigens unter anderem Mitgründer von Stack Overflow, der größten Frage-Antwort-Website rund um das Thema Softwareentwicklung. Er kennt sich also aus :)