Wie wir programmieren

In einem Start-up liegt es in der Natur der Sache, dass wir uns und unsere Lösungen immer wieder an den Bedarf unserer Kunden anpassen müssen. Wie unser Team aus Software Developern das schafft und welche Lösungswege sie gefunden haben, um trotzdem alles gut zu dokumentieren, erfahren Sie in diesem Beitrag unseres Kollegen Thiago Garcia Da Silva.

Wir sind ein schnelles Unternehmen und damit meine ich, dass wir unseren Kunden sehr schnell einen Mehrwert bieten können. Damit meine ich nicht, dass wir die Dinge überstürzen oder zu viel arbeiten. Ganz im Gegenteil, wir nehmen uns die nötige Zeit, um das Richtige zu tun. Der Haken an der Sache ist, dass wir Agilität über Schnelligkeit stellen und ein großer Teil davon ist in der Art, wie wir programmieren, verwurzelt. Unser Code muss es uns ermöglichen, agil zu sein, d. h. er muss leicht zu ändern sein und zwar für alle im Team, nicht nur für diejenigen, die ihn erstellt haben. Wir tun einiges, um das zu erreichen.

Erstens: Kein Code ist immer besser als irgendein Code. Da wir uns auf die Lösung eines Problems konzentrieren, ist es nicht ungewöhnlich, dass wir beschließen, keinen Code zu schreiben und das Problem auf eine andere Weise zu lösen.

Programmieren ist ein Werkzeug zur Lösung von Problemen und wie jedes andere Werkzeug sollten wir nicht für alle Probleme, auf die wir stoßen, dasselbe verwenden. Wir ziehen es häufig vor, Zeit damit zu verbringen, das Problem zu verstehen, um es mit möglichst wenig Code zu lösen.

Die Erweiterung von Bibliotheken, anstatt alles zu ändern, ist ein wichtiger Teil davon. Wir haben auf der DjangoCon Europe 2021 einen Vortrag darüber gehalten. In diesem Vortrag zeigen wir, wie wir einen Excel-Renderer in einer unserer Ansichten verwenden. Das Exportieren von Daten in verschiedene Formate ist keine große Sache, aber hier geht es um die Diskussionen, die uns dazu gebracht haben.

Eines der Features, die wir anbieten, ist eine Liste von Warnungen für Geräte. So eine Liste ist für unsere Kunden ziemlich interessant und war ihnen ein großes Anliegen. Wir hätten einfach anfangen können, Filter für jede Spalte hinzuzufügen, Ordnungen, Vergleiche und so weiter. Wir sind ein gutes Team, keine dieser Aufgaben ist eine Herausforderung für uns. Aber das war nur eine der Möglichkeiten, das Problem zu lösen, und wir fanden heraus, dass dies nicht einmal die beste Lösung war.

Unseren Kunden eine Excel-Datei zu geben, war eine viel bessere Lösung. Seien wir realistisch, wir haben keine Chance, mit den Funktionen von Excel zu konkurrieren, warum sollten wir es ihnen also nicht zur Verfügung stellen? Und das war unsere Lösung. Das Problem der Datenanalyse war gelöst und es ging nur darum, einen neuen Renderer hinzuzufügen. Um diese Entscheidungen treffen zu können, stützen wir uns auf viele gut geschriebene Problembeschreibungen, die in der Zukunft die Dokumentation für diese Funktion bilden. Wir haben einen Beitrag darüber verfasst, wie die Arbeit aus dem Homeoffice dabei einen großen Einfluss hatte.

Unsere Issues auf GitHub werden nicht als sehr technische Issues geboren, sondern als gute Problembeschreibung, die wir gemeinsam verfeinern. Wobei wir uns immer noch auf das Problem konzentrieren, nicht auf die Lösung. Wir wollen überprüfen, ob wir alle das Problem verstehen und ob es wirklich die Wurzel ist und nicht nur ein Symptom von etwas Größerem. Erst dann können wir damit beginnen, gemeinsam eine mögliche Lösung zu erarbeiten. Später unterhält sich das Team, das an dem Problem arbeitet, eingehender mit dem Product Owner. Und während der technischen Arbeit stoßen sie sogar oft auf neue Lösungen, denn durch die Arbeit an dem Problem, ändert sich häufig auch die Sichtweise darauf. So können wir uns auf das Problem konzentrieren und die sehr kurzen Feedback-Zyklen mit dem Product Owner sind der Schlüssel, um zu vermeiden, dass wir in die falsche Richtung arbeiten.

Das Excel-Beispiel, das ich zuvor erwähnt habe, ist ein gutes Beispiel hierfür. Indem wir ein klar definiertes Problem und keine vordefinierte Lösung haben, vermeiden wir, dass wir uns zu sehr mit der falschen Funktion beschäftigen. So schaffen wir Raum für kreative Lösungen. All dies ist später im GitHub-Issue zu finden, damit jeder verstehen kann, warum diese Entscheidung damals getroffen wurde.

Damit wir uns auf das Wesentliche konzentrieren können, programmieren wir zu zweit. Die meiste Zeit arbeiten wir mit jemand anderem zusammen. Jemanden bei der Programmierung dabei zu haben, kann eine ganz andere Erfahrung sein und ist nicht immer die angenehmste, denn man muss mehr teilen und den Schmerz der gemeinsamen Problemlösung durchstehen, was nicht immer einfach ist.

Aber da unser ganzer Prozess darauf basiert, haben wir genug Raum geschaffen, um die zusätzlich benötigte Zeit unterzubringen. Das wäre etwa die Zeit,

• in der beide ihre Arbeitsweise aneinander anpassen,
• die sie brauchen, um Ihr Wissen miteinander zu teilen,
• oder sogar die Zeit, in der Sie über andere Themen sprechen, weil Sie beide zu erschöpft vom Programmieren sind.

Das Pair Programming ist ein wesentlicher Bestandteil unserer Code-Kultur und die Vorteile sind größer als der zusätzliche Zeitaufwand, den es verursacht. Es ermöglicht uns viel schnellere Iterationen und einen schnelleren Austausch. So können wichtige Entscheidungen mit Hilfe eines zweiten Paares von Augen getroffen werden, um sicherzustellen, dass wir die richtige Lösung wählen.

Sie möchten keine Neuigkeiten mehr verpassen?

Ein weiterer wichtiger Bestandteil unserer Entwicklung ist TDD (test-driven development = testgetriebene Entwicklung). Die Tests treiben unsere Entwicklung wirklich voran. Auch wenn alle unsere Anwendungen Hunderte von Tests haben und unsere Testabdeckung hervorragend ist, ist das nur eine Folge von TDD.

Tests sind für uns nicht nur etwas, das vor dem Deployment in der KI läuft und zehn Minuten dauert, um zu versuchen, etwas nicht kaputt zu machen. Wir schreiben Tests, bevor wir die Lösung programmieren, sie sind das Werkzeug, das uns hilft zu verstehen, was wir tun, welches Problem wir lösen und das uns in die beste Richtung führt.

Es ist sehr hilfreich, über die APIs der Funktionen und Klassen nachzudenken, bevor man sie programmiert. Aber TDD erfordert viel Übung, und um uns dabei zu helfen, machen wir mindestens einmal im Monat ein Coding Dojo, um unsere Fähigkeiten zu trainieren und zu verbessern. Nicht selten liest man, dass man durch TDD dazu neigt, einen sehr charakteristischen Code zu produzieren und ich stimme dem zu. Meistens zwingt es einen dazu, die Belange besser zu trennen und Kopplungen zu vermeiden. Man sieht die wirklichen Vorteile davon, wenn man selbst oder jemand aus dem Team etwas ändern muss. Wir haben so viele Commits, die nur aus einem neuen Test und einer neuen Zeile an einer bestimmten Stelle bestehen. Letztendlich ist es das Codierungstool, das uns hilft, agil zu bleiben und zu vermeiden, dass wir Legacy-Code erstellen.

Schließlich gibt es noch etwas, das von Entwicklern oft übersehen wird: Git-Commits. Wir haben in anderen Beiträgen darüber gesprochen, dass Commits ein zentraler Teil unserer Entwicklung sind. Ich möchte ein konkretes Beispiel geben, wie Commits bei metr aussehen können:

Dies ist einer der extremeren Fälle von Commits. Wir haben auch Commits, die einfach nur gute Titel sind. Aber wir haben viele Commits mit ausführlichen Beschreibungen. Vor allem dann, wenn die Änderung in der Zukunft Verwirrung stiften könnte. Das reicht von der gezeigten, bis hin zu kleinen Absätzen.

Programmierung ist für uns in gewisser Weise eine Form der Kommunikation und besonders mit Python kann man auf extrem ausdrucksstarke Weise kodieren. Warum also dort aufhören und dies nicht auf den Rest unserer Kommunikation übertragen? Natürlich gibt es kein Patentrezept und nicht immer können wir alles befolgen – dafür haben wir einen letzten Trumpf im Ärmel: Anpassung.

Wir haben regelmäßige Meetings, bei denen wir besprechen, wie wir besser werden können, wie wir uns anpassen können. Was für uns gut funktionierte, als wir nur 2 Leute waren, funktionierte nicht mehr, als wir bereits 6 waren. Ein Beispiel dafür ist, wie viel mehr Dokumentation wir jetzt brauchen. Es reicht nicht aus, Informationen nur bei denjenigen zu speichern, die eine Aufgabe erledigt haben, sondern sie müssen für alle im Team zugänglich sein. Mehr darüber erfahren Sie in diesem Blog-Beitrag über die Arbeit im Homeoffice. Wir mussten uns anpassen, unsere Annahmen überprüfen und neue Lösungen entwickeln, um das Ziel der Agilität zu erreichen und weiterhin einen Mehrwert zu liefern, ohne uns zu überarbeiten.