Aus dem Blog

Golo & Götz (03)

von Götz Martinek

"Golo & Götz ist eine gemeinsame Serie von Golo Roden und Götz Martinek. Der eine ist CTO der the native web GmbH, der andere Geschäftsführer der sodge IT GmbH. Was die beiden vereint, ist ihre große Leidenschaft für die Entwicklung von Software. Seit September 2019 nehmen sie sich monatlich ein Thema vor, zu dem dann jeder seine individuelle Perspektive beschreibt, ohne den Artikel des jeweils anderen im Vorfeld zu kennen. Der zugehörige Artikel von Golo findet sich in seinem Blog auf heise.de/developer.

Die Fragestellung zu diesem Beitrag lautete: "Welche Tools nutzt ihr und warum?"

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 OpenSource 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 vormachen. Wenn die Erfolge sichtbar sind, gelingt die Weiterverbreitung.
Es ist allerdings die Mühe Wert, wer kann soll an die Zeiten ohne IDEs zurückdenken ...
Keiner von uns möchte auf das ein 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 Source Code sauberer zu halten und potentielle 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 old school, 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 auf den 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 OpenSource Libraries und Projekte benutzen wir, abhängig von der Entwicklungssprache, einen
Packagemanager, der automatisch die passenden Versionen holt, die im Projekt verwendet
werden, sowie auf den einzelnen Entwicklerrechnern automatisch installiert bzw. abgelegt.
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 zugrunde liegende Workflow ist wunderbar in der Weboberfläche abgebildet. GitlabCI, 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 Potential 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 Projekte auf andere Projekte umziehen, da sie sich mit den bereits verwendeten Toolchains auskennen und somit nicht immer wieder von neuem lernen müssen, 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.

Zurück