Rolle
Softwareentwickler
Wie lange dauert es, bis eine neue Person im Team ihre erste nennenswerte Änderung macht? Diese Zahl sagt mehr über Ihren Code und Ihre Dokumentation als jede Qualitätskennzahl.
Erstgespräch
Vier Fragen, mit denen wir beginnen würden
Wie lange dauert es, bis eine neue Person ihre erste Änderung macht?
Wenn Wochen, zahlen Sie die Einarbeitungskosten bei jeder Fluktuation - und Fluktuation ist in diesem Beruf eine Tatsache.
Was schieben Sie als Erstes auf, wenn ein Termin nah ist?
Meist Tests und das Aufräumen des Codes - und daraus werden die Schulden, die das nächste Quartal abträgt.
Wo landet das Wissen darüber, warum etwas so gemacht wurde?
Wenn in einem Gespräch im Code-Review, weiß in einem halben Jahr niemand mehr, ob es eine Wahl war oder ein Zufall.
Welche Art von Aufgabe wiederholt sich am häufigsten?
Meist drei oder vier Muster - und meist hat sie niemand gezählt.
Wir übernehmen die repetitive Arbeit, Sie behalten den Entwurf und das Urteil
Den Kontext des Codes zu erfassen, repetitive Änderungen zu entwerfen, Tests vorzubereiten und ein Vorab-Review zu machen, lässt sich vom Schreibtisch nehmen. Entwurfsentscheidungen und das abschließende Urteil über den Code bleiben bei einem Menschen.
- Der Kontext kommt schneller als durch Lesen. - Was dieses Modul tut, wer es geändert hat und welche Änderungen damit zusammenhängen - bevor der Entwickler Zeile für Zeile zu lesen beginnt.
- Das Review beginnt bei dem, was Linter und CI nicht fangen. - Formatierung und Tests haben Sie mit großer Sicherheit längst im Griff. Das hier ist die Schicht darüber: ob die Änderung Stellen berührt, die der Autor vielleicht nicht bemerkt hat, und ob sie eine vor einem halben Jahr verworfene Lösung wiederholt.
- Schulden sind sichtbar statt spürbar. - Die am häufigsten geänderten Stellen und die mit der höchsten Komplexität werden aufgezeigt, damit das Gespräch über Refactoring eine Grundlage hat.
Umfang
Was sich aus einem Entwicklungsteam herausnehmen lässt
Neunzehn Aufgaben als Beispiel. Jede hat einen Punkt menschlicher Freigabe. Unten eine Auswahl; den Umfang passen wir an Ihren Stack und Prozess an.
Den Code und seinen Kontext verstehen
- Eine Beschreibung dessen, was ein Modul tut, auf Basis des Codes (Prüfung: der Entwickler)
- Hinweis auf Stellen, die mit dem geänderten Abschnitt zusammenhängen
- Die Änderungshistorie des Bereichs mit den Gründen
- Hinweis auf die Dokumentation, die den Bereich abdeckt
Die Änderung schreiben
- Ein Änderungsentwurf für repetitive Muster (Urteil und Korrektur: der Entwickler)
- Ein Vorschlag von Tests für die geschriebene Änderung
- Hinweis auf Stellen, die nach der Änderung aktualisiert werden müssen
- Ein Signal, wenn eine Änderung die vereinbarten Konventionen bricht
Code-Review
- Ein Vorab-Review vor dem menschlichen Review
- Hinweis auf fehlende Tests
- Hinweis auf Änderungen, die zusammenhängende Stellen berühren, von denen der Autor nichts wusste
- Zu prüfende Änderungen nach Risiko geordnet (Entscheidung: der Reviewer)
- Eine Erinnerung an ein wartendes Review
Tests und Release
- Ein Vorschlag von Fällen, die die bestehenden Tests nicht abdecken
- Hinweis auf Tests, die nicht mehr bestehen, und den Grund der Verhaltensänderung
- Verknüpfung der Änderung mit der Aufgabe und dem Release
Technische Schulden
- Hinweis auf die am häufigsten geänderten Bereiche
- Eine Übersicht der Stellen größter Komplexität
- Verknüpfung von Produktionsfehlern mit Codebereichen
Ein Arbeitstag
Heute
- Vor einer Änderung lesen Sie das Modul, um überhaupt zu verstehen, was es tut
- Die zusammenhängenden Stellen finden Sie über Suche und das Gedächtnis des Teams
- Die repetitive Arbeit schreiben Sie von Hand, obwohl sie jedes Mal gleich aussieht
- Der Reviewer klärt selbst, was diese Änderung sonst noch berührt
- Ein Review wartet ein, zwei Tage, weil niemand weiß, dass es wartet
- Über technische Schulden sprechen Sie in der Retrospektive, ohne Daten
Mit AI-Unterstützung
- Sie haben die Modulbeschreibung und die zusammenhängenden Stellen, bevor Sie den Code lesen
- Eine repetitive Änderung hat einen Entwurf, Sie beurteilen und korrigieren ihn
- Die Tests für die Änderung haben einen Vorschlag
- Zusammenhängende Stellen werden mit der Änderung aufgezeigt statt gesucht
- Ein wartendes Review erinnert an sich selbst
- Technische Schulden werden mit Zahlen aufgezeigt, nicht mit einem Eindruck
- Zeit bis zur ersten Änderung
eine neue Person kommt früher in den Code
der Kontext eines Moduls ist verfügbar, ohne alles zu lesen
- Wartezeit auf ein Review
Änderungen liegen nicht unbemerkt in der Warteschlange
Erinnerungen und eine Reihenfolge nach Risiko
- Review-Qualität
der Reviewer sieht die Reichweite der Änderung, nicht nur den Diff
die zusammenhängenden Stellen und die Entscheidungshistorie liegen bei der Änderung
- Sichtbare Schulden
das Gespräch über Refactoring hat eine Grundlage in Zahlen
die oft geänderten und die komplexen Bereiche werden aufgezeigt
Wir beginnen mit Kontext und Review, weil das am wenigsten riskant ist und sich am schnellsten bemerkbar macht.
- Schritt 1
Code-Kontext und Zusammenhänge
Modulbeschreibungen, die Änderungshistorie, zusammenhängende Stellen.
- Schritt 2
Vorab-Review und Tests vor dem menschlichen Review
Konventionen, fehlende Tests, offensichtliche Fehler vor dem Auge eines Menschen.
- Schritt 3
Entwürfe repetitiver Änderungen
Nur die Muster, die sich wirklich wiederholen, und immer mit dem Urteil des Entwicklers.
- Schritt 4
Sichtbare Schulden
Die am häufigsten geänderten Bereiche, verknüpft mit Produktionsfehlern. Zuletzt, weil es Historie voraussetzt.
Häufige Fragen
Fragen, die beim ersten Treffen aufkommen
Und Code, den wir nirgendwohin schicken dürfen?
Das ist eine häufige Bedingung und sie wird im Architekturstadium geklärt, nicht im Inhalt. Lösungen, die in Ihrer eigenen Infrastruktur laufen, sind real; wenn nicht, verengt sich der Umfang auf das, was sich ohne Versand von Code nach außen tun lässt. Dieses Gespräch lohnt sich vorher, nicht hinterher.
Das ist die Frage, die heute der ganze Markt stellt: Wird AI Programmierer ersetzen?
Die ehrliche Antwort: nicht im hier beschriebenen Umfang, und wir geben nicht vor, eine Antwort auf die ganze Frage zu haben. Was wir vorschlagen, betrifft den Kontext des Codes, repetitive Muster und das Vorab-Review, also die Arbeit, die ein Entwickler ohnehin für die am wenigsten interessante hält. Entwurfsentscheidungen, das Abwägen von Trade-offs und die Verantwortung für das, was in die Produktion gelangt, bleiben beim Team. Wenn wir mehr übernehmen, verlieren Sie dabei, nicht wir - und deshalb lohnt es sich, die Grenze mit dem Team zu ziehen und nicht für das Team.
Fällt das unter die KI-Verordnung?
Software herzustellen ist keine Hochrisiko-Anwendung. Der einzige Punkt, der Sorgfalt braucht, ist, dass Daten über Codeänderungen nicht zum Vergleich der Produktivität einzelner Entwickler genutzt werden - wir führen die Übersichten nach Codebereich und nicht nach Autor.
Ihre Frage steht nicht dabei? Gespräch vereinbaren
Nächster Schritt
Wie viel Zeit verbringt Ihr Team damit, Code zu lesen, bevor es ihn ändert?
Wir zeigen Ihnen, wie die Arbeit eines Teams aussieht, wenn der Kontext früher ankommt und das Code-Review bei den Entwurfsentscheidungen beginnt.