Xebianer arbeiten gemeinsam an der Entwicklung interner Tools

Bei Xebia führen wir zahlreiche interne Initiativen durch. Eine dieser Initiativen umfasst die Entwicklung eines Toolsets zur Beurteilung der Situation eines Kunden. Dieses Toolset (Arbeitstitel: Truffleswine) ermöglicht es uns, relevante Daten schnell aus den Systemen abzurufen, was uns wiederum hilft, früher die richtigen Fragen zu stellen und Business Cases für Verbesserungen anhand konkreter Daten zu klären. Eine ausführlichere Beschreibung finden Sie hier. In diesem Blog geht es jedoch nicht nur um die Beschreibung des Toolsets, sondern auch um unseren Entwicklungsansatz und einige wertvolle Lektionen, die ich auf diesem Weg (wieder) gelernt habe.

Unser Entwicklungsansatz

Hier finden Sie einen Überblick darüber, wie wir neue Funktionen in das Tool einführen:

1. Entdeckung

Wir beginnen in der Regel mit einem konkreten Kundenbedarf, z. B. bestimmte Daten oder eine Visualisierung. Wir beginnen oft in einem Jupyter-Notizbuch und konzentrieren uns dabei weniger auf Wiederverwendbarkeit und Testbarkeit als vielmehr darauf, die Aufgabe für diesen einen Anwendungsfall schnell zu erledigen, um seinen Nutzen zu entdecken.

2. Verbindlichkeit

Sobald wir uns sicher sind, überlegen wir, wie wir die Funktion in das System integrieren können. Ohne ein klares Design verwenden wir Paarprogrammierung und testgetriebene Entwicklung (TDD), bis wir zufrieden sind, wobei wir uns zunächst auf die gewünschte API konzentrieren. Dies endet in der Regel mit der Entfernung des ursprünglichen Codes.

3. Integration

Wir versuchen, häufig zu integrieren, so dass Funktionen in Discovery auch in unseren Hauptzweig eingebunden werden. Es ist erwähnenswert, dass wir mit Pull Requests arbeiten, aber wir haben uns entschieden, Peer Reviews optional zu machen, weil:

• Wir haben strenge automatisierte Kontrollen mit Tests, Codierungsstil, Abhängigkeitsüberprüfungen und Abdeckung.
• Jeder von uns neigt dazu, Änderungen, die von Interesse sind, asynchron zum Pull Request zu überprüfen. Wir sind nicht Vollzeit mit der Entwicklung des Tools beschäftigt, und die Mitwirkenden können den Code zusammenführen, ohne warten zu müssen.
• Wenn möglich, paaren wir Programme (Überprüfung in Echtzeit)
• Das Tool ist ein Innovationsprojekt. Änderungen sind einfach zu machen und Fehler werden leicht verziehen. Wir brauchen zu diesem Zeitpunkt keine 100%ige Verfügbarkeit.

Gelernte Lektionen

Das Aufschieben von Entscheidungen ist großartig

• Ein Tool zu einem Produkt zu machen (von einem 'einfachen Skript' zu etwas, das jeder potenziell leicht verwenden kann), ist eine erhebliche Investition. Die begrenzten Ressourcen und Mitarbeiter halfen uns jedoch, uns zunächst auf die wichtigsten Dinge zu konzentrieren.
• Anstatt zu analysieren, wie das Design aussehen könnte oder sollte, habe ich gelernt zu fragen: "Muss ich diese Entscheidung wirklich jetzt treffen?" - Die Antwort lautet oft "Nein". So kann ich mich auf das konzentrieren, was wichtig ist - wenn die Designentscheidung wichtig ist, wird sie später wieder auftauchen.

Overengineering verlangsamt

In einigen Fällen haben wir die Dinge zu sehr verkompliziert, so dass wir uns später entschlossen haben, sie zu entfernen. Die wichtigsten davon sind:

• Wir brauchten kein React-Frontend: Anfangs versuchten wir, unsere Jupyter-Notebooks durch ein React-Frontend zu ersetzen, das mit einer OpenAPI-Spezifikation auf dem Server verbunden ist. Wir merkten schnell, dass dies mehr Arbeit erforderte, um die gleiche Flexibilität und weitere Erweiterungen zu erreichen, was auf Kosten der Innovationskraft und der Entwicklungskapazität ging. Außerdem hatten wir keine "Nicht-Experten" als Benutzer.
• Wir brauchten keine Datenbank: Eine frühere Version nutzte ein ORM, da wir davon ausgingen, dass wir irgendwann eine Datenbank benötigen würden. Wir begannen mit SQLite, mit der Absicht, später zu etwas anderem zu wechseln. Da wir das Tool jedoch lokal betreiben, schienen uns einfache CSV-Dateien (einzeln bis zu 1 GB) gut genug und bequemer zu sein. Wir haben die Datenbank und das ORM verworfen, obwohl wir diese Entscheidung vielleicht später noch einmal überdenken werden.
• Wir brauchten nicht überall Typsicherheit: Zum Teil aufgrund der Entscheidung für ein ORM waren unsere Datenklassen robust und typsicher. Als wir uns jedoch auf die Analyse (und Umwandlung) der Daten konzentrierten, begannen wir, die generischen Pandas DataFrames unseren eigenen Datenklassen vorzuziehen.

Kleine Projekte sind großartig für die persönliche Entwicklung und das Experimentieren

• Diese Art von internen Projekten sind ein sicherer Ort für die Zusammenarbeit - wir sind alle hart arbeitende Menschen und wir geben niemandem die Schuld, wenn etwas schief geht oder langsam läuft.
• Wir probieren neue Entwicklungstools aus, die wir bei unserem Einsatz bei einem Kunden nicht immer verwenden können. Der GitHub Copilot ist zum Beispiel unglaublich hilfreich beim Schreiben von Code. Wenn ich die genaue Syntax oder API (für Bibliotheken wie'plotly' oder'pandas') nicht kenne, fange ich an zu tippen (oft als Kommentar) und sehe, welchen Code Copilot vorschlägt. Oft ergibt sich daraus der richtige Code, und wenn nicht, weiß ich, wonach ich in der Dokumentation suchen muss.
• Ich finde TDD-ing Code und Code, der TDD-ed wurde, nach wie vor sehr wertvoll.
  • Nichts anderes bietet den gleichen Fokus, sofortiges Feedback, Speicherpunkte und die Möglichkeit, nicht alle Entscheidungen auf einmal zu treffen.
  • Wenn Änderungen einfach zu machen sind, fühlen sich nicht alle Entscheidungen wie eine Verpflichtung an. Das gibt mir die Möglichkeit, Dinge auszuprobieren und zu lernen, was meine Hauptmotivation für die Arbeit an diesem Projekt ist.

Letzte Worte

Manchmal vergisst man leicht, wie befriedigend und unterhaltsam das Schreiben von Code sein kann. Besonders in komplexen Organisationen, in denen die Dinge leicht an internen Prozessen und Abhängigkeiten hängen bleiben. Diese kleinen Projekte helfen dabei, zu hinterfragen, welche Art von Komplexität wirklich notwendig ist. Die Dinge werden viel unkomplizierter, wenn Sie Ihr eigenes Leben oder das der Menschen in Ihrem direkten Umfeld verbessern.

In meinem Fall sind es Peer-Berater, und ich schätze, der offizielle Begriff ist"ConEx".