Tooling

Werkzeuge oder Tools ... auch die Maus, Tastatur und Monitor, sind nichts weiter als Werkzeuge, um mit dem Computer und der darauf installierten Software arbeiten zu können. Bei uns bezeichnen wir als Tools fast alles, was wir nutzen können, um uns das Leben leichter zu machen. Egal ob Hard-, Software oder Methodik.

Als Softwareentwickler hat man eigentlich schon immer repetitive Aufgaben gehasst. Und um sich dieser unliebsamen Arbeit zu entledigen, wurden diese Aufgaben oft einzeln abgekapselt und automatisiert durch meist selbst geschriebene kleinere Tools. Diese wurden früher meist für die einzelnen Projekte separat programmiert und auch nur in eigenen Projekten verwendet. Manche Softwareentwickler haben sich so über die Jahre ganze Sammlungen dieser Tools erstellt und nutzten sie bei Bedarf immer wieder.

Zum Glück für alle gibt es heute viele Open-Source-Tools, die von jedem verwendet werden können und auch stetig weiterentwickelt werden. So können sich Entwickler hauptsächlich auf die Nutzung der Tools konzentrieren und nicht auf deren Wartung und Erweiterung. Und wer Fehler findet, hat meist die Chance, diese zu beheben und vielleicht auch fehlende Features beizusteuern. Auf dieses Volumen an Tools zuzugreifen und sie zu verstehen kostet mitunter einiges an Mühe, Zeit und Verständnis. Wir nutzen einen Teil unserer Zeit, um uns immer wieder mit neuen Tools zu beschäftigen und zu entscheiden, ob sie unseren Kunden oder uns einen Mehrwert bringen.

Bei der Auswahl der Tools schauen wir vor allem auf (unsortiert) Schnittstellen zur Automatisierung, Klarheit der Ausgaben, Korrektheit ... Manche sind schlicht zu kompliziert in der Nutzung, passen nicht zu unseren bestehenden Toolchains oder sie sind zu alt und werden nicht mehr gepflegt. Die ganze Analyse kostet Zeit und Geld und nicht jedes von uns angeschaute Tool kommt dann auch zum Einsatz.

Unsere Erfahrung zeigt, dass nicht in allen Fällen sofort ein unternehmensweiter Erfolg durch den Einsatz eines Tools erzielt wird. Der Einsatz von Tools gehört oft zur persönlichen Entwicklungsmethode, und diese zu verändern dauert. Das Beste, was man hier machen kann, ist die Nutzung vorzumachen. Wenn die Erfolge sichtbar sind, gelingt die Weiterverbreitung. Es ist allerdings der Mühe wert. Wer kann, soll an die Zeiten ohne IDEs zurückdenken ... Keiner von uns möchte auf das eine oder andere Tool verzichten. Manche sind heute so selbstverständlich wie die Maus.

Bestimmte Tools zu nutzen ist sinnvoll, der wirkliche Mehrwert kommt aber in der Kombination von verschiedenen Tools und der Automatisierung der Abläufe. Ein Tool kann nützlich sein, aber mit einer automatisierten Toolchain zu arbeiten macht einfach nur Spaß.

Werkzeugkasten

In der Entwicklung kommen bei uns verschiedene Linter zur statischen Codeanalyse zum Einsatz.
Dies soll uns helfen, den Sourcecode sauberer zu halten und potenzielle Fehler früher zu erkennen. Um sinnvoll damit zu arbeiten, sollte man allerdings etwas in die Konfiguration investieren. Vor allem in einer Gruppe von Entwicklern, die einen unterschiedlichen Entwicklungsstil und Erfahrungslevel haben, kann das von Nutzen sein.

Zur internen Kommunikation haben wir uns für Mattermost entschieden und sind bisher sehr zufrieden. Es ermöglicht uns, recht einfach und unabhängig von unserem aktuellen Arbeitsplatz in Kontakt zu bleiben. Zur internen Dokumentation nutzen wir – noch recht oldschool – ein Wiki und Redmine.

Bei allen Open-Source-Tools ohne kommerzielle Unterstützung sind wir bisher mit unserem Grundsatz "möglichst Vanilla" recht gut gefahren. Da Probleme bei Migrationen oder Updates weniger häufig auftreten, als wenn ich noch ein seit mehreren Jahren nicht mehr gepflegtes Plugin im Einsatz habe.

Ursprünglich nutzten wir noch VMs zur Entwicklung, basierend auf OpenStack zur Provisionierung von Entwicklungssystemen für einzelne Entwickler. Manche Tools klingen gut, passen dann aber nicht zum Anwendungszweck und man muss sich einfach wieder von ihnen trennen. Seit einigen Jahren nutzen wir Docker für fast alle Projekte – sehr viel einfacher und übersichtlicher, was den Verwaltungsaufwand angeht, und es passt zu unserer Größe.

Für etwaige externe Open-Source-Librarys und Projekte benutzen wir, abhängig von der Entwicklungssprache, einen Packagemanager, der automatisch die passenden Versionen holt, die im Projekt verwendet sowie auf den einzelnen Entwicklerrechnern automatisch installiert bzw. abgelegt werden. Der Entwickler kann sich hier dann um wichtigere Dinge kümmern, und veraltete Versionen werden automatisch aktualisiert.

Der Sourcecode wird bei uns in ein Codeverwaltungssystem eingecheckt. Das klingt selbstverständlich, aber selbst heute gibt es noch Unternehmen, die ohne entwickeln, sollten sie aber nicht. Dazu nutzen wir Git, vor allem weil jeder entspannt und auch ohne Verbindung zu einem zentralen Server weiterentwickeln kann. Als Zusatz für uns haben wir uns schon seit Langem für GitLab on Premise entschieden, je nach Projekt kommt aber auch die GitLab-Cloud-Version zum Einsatz – ein wirklich sehr gutes Tool: Der zugrundeliegende Workflow ist wunderbar in der Weboberfläche abgebildet. GitLab CI, der entsprechende Continuous-Integration-Dienst, ist auch sehr gut integriert. Es macht Spaß, damit zu arbeiten und seine Verbesserungen an Code oder Ähnlichem den Teamkollegen bereitzustellen. Die Roadmap der noch geplanten Features liest sich sehr interessant. Wir sind gespannt.

Zusätzlich nutzen wir noch Jenkins, da vor allem bei den älteren Projekten die Integration hier schon steht.

Gerade mit Continuous-Integration-Diensten können die ausgewählten Tools das volle Potenzial ausspielen. Allein der Vorteil in der Reproduzierbarkeit und Nachvollziehbarkeit ist enorm. Jede Codeänderung durchläuft die komplette Toolchain und liefert jedes Mal ein vergleichbares nachvollziehbares Ergebnis. Lieber 10-mal den gleichen Fehler automatisiert über die Toolchain als 5 verschiedene durch einen manuellen Prozess verursachte Fehler. Wobei in einer Toolchain selbst natürlich auch Fehler auftreten können. Das ist dann ein Teil des Preises, den man zahlt.

Da unsere Toolchain für die von uns genutzten Sprachen meist einheitlich bzw. sehr ähnlich ist, können wir auch schneller Entwickler von den einzelnen Projekten auf andere Projekte umziehen. Sie kennen sich mit den bereits verwendeten Toolchains aus und müssen somit nicht immer wieder von Neuem lernen, wie ein Projekt aufgebaut ist.

Die Auswahl und Pflege von Tools, die Installation und Pflege sowie der Einsatz der Toolchain kostet Zeit. Zeit, die es in vielen Projekten "nicht zu geben scheint", jedoch ist es eine Investition, die im späteren Projektverlauf zum Tragen kommt. Diese Investition hilft nicht nur eine vergleichsweise gleichmäßige Entwicklungsgeschwindigkeit über die Projektlaufzeit beizubehalten, sondern sichert auch den "Geisteszustand" und die Motivation der Entwickler.

Eine Toolchain gehört zur sinnvollen Entwicklungsumgebung. Nicht umsonst hat Joel Spolsky vor mehr als 10 Jahren in "The Joel Test: 12 Steps to Better Code" geschrieben "[...] best tools money can buy [...]". Wobei es nicht unbedingt kostenpflichtige Tools sein müssen.

tl;dr

Der Einsatz von Tools mindert die unliebsamen manuellen Arbeiten für Entwickler und macht die Projekte effizienter. Durch die Kombination mit Continuous-Integration-Diensten bekommen wir ein "schnelles" Feedback, und das ist es, was wir Entwickler wollen.