Refactor parallel zur Entwicklung: unsere Erfahrung und zwei Checklisten

Refactoring ist für viele Teams ein Schmerz. Denn wenn Sie Refactoring durchführen, entwickeln Sie das Hauptprodukt nicht, und wenn Sie es nicht tun, wächst die technische Verschuldung des Projekts. Irgendwann kommen die Teams zu dem Gedanken: „Lassen Sie uns zwischen Refactoring und Entwicklung unterscheiden und beispielsweise 20% unserer Arbeitsstunden zuweisen, und den Rest der Zeit werden wir uns weiter mit der Entwicklung befassen!“ Diese Idee ist nicht schlecht, das einzige ist, dass Sie pro 100 Entwicklungsstunden niemals 20 reine Stunden Refactoring erhalten. Denn „Entwicklung“ funktioniert nicht nur mit Code.

Wenn es sich um reife Teams handelt und nicht um Miniteams, die für 3-5 Personen zu einem wesentlichen Punkt komprimiert wurden, umfasst „Entwicklung“ neben dem Schreiben von Code eine ganze Reihe verschiedener Teamaktivitäten. In der „Entwicklung“ können Sie Besprechungen aufschreiben, die von vielen so ungeliebt sind, mit Dokumentation arbeiten, Berichte in Task-Managern verwalten usw. All dies verschlingt etwa 30% unserer für die Entwicklung bereitgestellten Uhren. Und irgendwie stellt sich unbemerkt heraus, dass anstelle des Bildes „80 Stunden Code, 20 Stunden Refactoring“ direkt für das Refactoring selbst eine unansehnliche Zahl von ~ 13 Stunden angezeigt wird, da alles andere von anderen Aktivitäten absorbiert wurde.

Im Folgenden erfahren Sie, wie Sie Entwicklung mit Refactoring kombinieren, damit die technische Verschuldung des Projekts nicht wie ein Schneeball wächst, sondern auch über die korrekte Verteilung von Zeit und Priorisierung sprechen.

Warum verursacht Refactoring so viele Probleme? Erstens aufgrund der Tatsache, dass Teams ihre eigenen Ressourcen nicht angemessen bewerten und diesen Prozess mit der Entwicklung kombinieren können. Es scheint den Menschen, dass wenn ihr Arbeitstag 8 Stunden pro Tag beträgt (40 pro Woche), alle 40 Stunden angeblich mit der Entwicklung beschäftigt sind. Es ist nicht so.
Der gesamte Entwicklungsprozess kann in zwei Teile unterteilt werden: Dies sind Nebenaktivitäten und alles, was in direktem Zusammenhang mit dem Code steht.


So sieht die Zeitverteilung eines unserer Entwicklungsteams aus.

Der Leser hat möglicherweise eine vernünftige Frage: "Wie haben Sie dieses Diagramm erstellt?" und jetzt werden wir versuchen, eine Antwort zu geben. Die Daten wurden nicht von der Obergrenze übernommen, sondern basieren auf unseren internen Statistiken. Unsere Entwickler verfolgen ihre Aktivitäten in Jira. Jedes dieser persönlichen Arbeitsprotokolle besteht aus vier Abschnitten: Codeüberprüfung, technische Diskussionen, spezifische Tickets und „alles andere“. Dank dieser relativ einfachen und transparenten Klassifizierung haben wir eine Analyse erstellt, wie viel Zeit wir in den einzelnen Teams für die einzelnen Aspekte der Entwicklung aufwenden. Wenn ein Drittel der gesamten Arbeitszeit auf Besprechungen, Stand-Ups und Überprüfungen entfällt, liegt alles im normalen Bereich. Wenn mehr als 33% für diese Aktivitäten ausgegeben werden, hat das Team Probleme und muss angegangen werden.

Es scheint, dass es keinen Haken gibt und alles logisch ist, aber wie passen wir Refactoring in diese Geschichte? Einen "Monat des Refactorings" deklarieren und bei der Entwicklung punkten? Jedes kommerzielle Produkt hat jedoch einen eigenen Zeitplan, aus dem es äußerst unerwünscht ist, herauszukommen. Refactoring ist immer noch wie ein Sumpf: Wenn Sie damit angefangen haben, dann ist es schwer aufzuhören, Sie sind von diesem Grund angezogen. Refactoring verlagert den Fokus der Aufmerksamkeit des Teams auf sich selbst und wir bekommen eine ungeheure Tendenz, die Ordnung im bereits geschriebenen Code wiederherzustellen, anstatt das Projekt in eine bessere Zukunft zu verschieben. Wie verteilt man die Zeit?

Die folgende Folie gibt einige Antworten:


Führen Sie Zeitprotokolle, es ist äußerst nützlich

Besprechungen und Überprüfungen bleiben unberührt, da wir der Ansicht sind, dass diese Aktivitäten so weit wie möglich optimiert und auf ein angemessenes Minimum beschränkt werden (diejenigen, die in Teams gearbeitet haben, in denen Besprechungen und Codeüberprüfungen 70% der Zeit in Anspruch nahmen, werden unsere Worte bestätigen). Wir nehmen uns also die Zeit, um den Code und die Fehlerbehebungen aus der Entwicklung zu überarbeiten. Und hier wenden wir wieder den Ansatz „ein und zwei Drittel“ an und teilen die von uns erhaltenen Arbeitsstunden in „Refactoring“ und „Bugs“ auf, wobei diese Konzepte klar voneinander getrennt werden. Ein solches Modell ist realisierbar und ermöglicht es Ihnen, die Zeit zu finden, um die Ordnung im Projekt wiederherzustellen, zumindest ohne die technische Verschuldung zu erhöhen. Wenn wir zu viele Entwicklungsstunden abbeißen, wird das Projekt zum Stillstand kommen.

Wir gehen den Refactoring-Prozess korrekt an

Angenommen, Sie entscheiden sich für eine Umgestaltung, anstatt ein Projekt von Grund auf neu zu schreiben. Aber hier kann man sich nicht den ersten schnappen und wie in der Armee umgestalten, "von hier bis zum Mittagessen". Da unsere Ressourcen begrenzt sind und unser Ziel darin besteht, das Wachstum der technischen Verschuldung zu stoppen (und im Idealfall eine Verringerung ihrer Größe zu erreichen), müssen wir diese Aufgabe vernünftig angehen.

Die beste Lösung scheint es dem Teamleiter oder einem anderen Entwicklungsmanager zu ermöglichen, den Arbeitsumfang zu bestimmen, Aufgaben zuzuweisen und mit dem Refactoring fortzufahren. Diese Option weist jedoch einen schwerwiegenden Fehler auf. Timlid ist der Dirigent unseres Teams, aber die Probleme lokaler Musiker sind für den Dirigenten nicht immer offensichtlich. Wenn Sie ein Anhänger einer starren Vertikalen und ein Modell sind, in dem eine Person entscheidet, wie das Refactoring stattfinden soll, dann sitzen Sie freiwillig im brennenden KAMAZ, das mit gebrochenen Bremsen vom Berg in den Abgrund stürzt.

Unsere Erfahrung zeigt, dass eine robuste Version der Entwicklung von Ereignissen eine kollektive Definition verschiedener Refactoring-Richtungen ist, dh Entwickler sollten an der Erstellung einer Liste zukünftiger Arbeiten teilnehmen. Nur der unmittelbare Verfasser des Codes kann ehrlich zugeben, ob dieser Abschnitt angemessen geschlossen wurde oder aus Zeitgründen verschiedene Krücken aufgeschichtet wurden. Darüber hinaus sind es die Entwickler, die auf dem neuesten Stand der Technik sind und vernünftig beurteilen können, welche Elemente eines Projekts überarbeitet werden müssen und welche nicht berührt werden sollten.

Wir haben uns diesen Ansatz ausgedacht: Jeder Entwickler erinnert sich an die dünnen Stellen im Projekt und schreibt eine Karte darüber, was getan werden muss, um es besser zu machen. Auf diesen Karten werden dann Aufgaben festgelegt. Es stimmt, es gibt eine Nuance: Nachdem die allererste Karte im „Do Well“ -Stil ohne Kontext empfangen wurde, haben wir begonnen, diesen Kontext in komprimierter Form zu fordern.


Die gleichen Karten

Das Definieren einer Aufgabe reicht jedoch nicht aus, um mit der Implementierung zu beginnen. Daher sollte für jede dieser Karten eine Checkliste erstellt werden, die eine Reihe einfacher Fragen wie „Müssen wir etwas parallel tun?“ Beantwortet. oder "Gibt es Faktoren, die uns daran hindern, diese Aufgabe zu erfüllen?" Nach dem Ausfüllen einer solchen Checkliste erhält der Entwickler eine spezifische Liste aller möglichen Probleme und Blocker, die in der Vorbereitungsphase gelöst werden müssen.

Ein weiterer obligatorischer Schritt besteht darin, festzustellen, wer sich in welchen Bereichen des Projekts befindet und wer es am besten weiß. Dies optimiert den Refactoring-Prozess und bietet Teammitgliedern Aufgaben in den Bereichen, in denen sie sich am besten beweisen können. Zwar waren wir eines Tages mit einer Situation konfrontiert, in der anderthalb Menschen normalerweise einen Aspekt des Projekts verstanden, aber selbst dieses Problem kann gelöst werden. Um das Informationsvakuum zu beseitigen, sollten Entwickler, die immer noch in dem Bereich „stöbern“, in dem der Rest des Teams vorbeikommt, ihr Wissen teilen. Dies kann eine Dokumentation sein, eine Art Mini-Präsentation, sogar ein Video mit Erläuterungen zum Code. Es ist wichtig, Informationen an Kollegen weiterzugeben und sicherzustellen, dass möglichst wenige dunkle Flecken vorhanden sind.

Und schließlich muss das Team die Frage "Wie hoch ist unsere technische Verschuldung?" Klar beantworten. Noten wie „C-Note“, „akzeptabel“, „fünf von zehn“, „du kannst leben“ funktionieren nicht mehr. Zuvor beantworteten wir eine ähnliche Frage von der Tankstelle für eines der Projekte mit „fünf von zehn“, und als wir die Größe der technischen Schulden in Zahlen umwandelten, erhielten wir 650 Stunden. Es war unangenehm. Nur eine klare Antwort auf diese Frage hilft, den Umfang der anstehenden Arbeiten sinnvoll einzuschätzen. Dies ist auch deshalb wichtig, weil die „endlosen“ Aufgaben die Motivation der Teammitglieder zerstören und das Geschäft verärgern: Sowohl Entwickler als auch Management sollten einen konkreten Endpunkt sehen, den das Team anstreben wird.

Priorisierung

Nachdem wir die Front der Arbeit definiert haben, müssen wir Refactoring mit Entwicklung kombinieren. Natürlich können wir das Feature-Sägen in verschiedenen Teilen des Projekts nicht beenden oder diesem Ereignis eine besondere Zeit zuweisen.

Hier beginnt der schwierigste Teil. Das Entwicklungsteam sollte vernünftigerweise bestimmen, in welchen Momenten die Entwicklung wichtiger ist und in welchen Umgestaltungen wichtig ist, insbesondere wenn an dieser Stelle im Code eine Funktion gesägt wird. Vielleicht wird die Weiterentwicklung nach dem Refactoring einfacher, und in einigen Fällen können wir unser Feature beenden und erst dann den Refactor durchführen. Wir kommunizieren mit dem Produkt, diskutieren die Entscheidung und vereinbaren die Bestellung. Zum Beispiel: „Lassen Sie uns zuerst umgestalten - nicht nur, weil wir Lust dazu haben, sondern weil die Gesamtlaufzeit am Ende kürzer sein wird.“

Das Wichtigste ist, nicht zu vergessen, dass unser Ziel darin besteht, ein Produkt zu entwickeln und nicht den perfekten Code zu schreiben, um den perfekten Code oder die vollständige Beseitigung technischer Schulden zu erreichen. Die Entwicklung sollte in dieser Hinsicht völlig angemessen sein: Wenn das Refactoring gerade unsere Geschäftsentwicklungsaufgabe beeinträchtigt, schreiben wir einen neuen Code fertig und korrigieren erst dann den alten. Wenn die Umstände besagen, dass es für das Projekt rentabler ist, diesen Abschnitt umzugestalten (egal wie ungeheuerlich die Vorderseite der Arbeit aussieht), da weitere Arbeiten einfacher und unterhaltsamer sein werden, müssen wir umgestalten.

Dieser Ansatz passt äußerst schlecht in das vertikale Managementmodell, und manchmal treten Situationen auf, in denen Sie Ihre Entscheidungen vor dem Kunden verteidigen müssen. Sonst aber nichts.

Was bekommen wir als Ergebnis

Mit dem beschriebenen Ansatz integrieren wir Refactoring-Prozesse organisch in die aktuelle Entwicklung, reduzieren die Größe (oder stoppen das Wachstum) der technischen Schulden und dies alles ohne größere Verluste.

Ja, um das Refactoring zu vereinfachen, müssen Sie die Zeit für die Entwicklung neuer Funktionen verkürzen, was die Zeit verlängert. Die Auswahl ist jedoch gering: Sie können entweder parallel zur Entwicklung refactorisieren oder früher oder später auf einen solchen Haufen von Krücken, Problemen und Fehlern stoßen, dass es einfacher ist, das Projekt von Grund auf neu zu schreiben. Wenn Sie also die Arbeit Ihres Teams schätzen, sollten Sie immer noch über Refactoring nachdenken, anstatt es in Zukunft neu zu schreiben.

Nützliche Materialien:

1. Alexey Kataevs Bericht über das Refactoring: weitere praktische Beispiele sowie eine erstaunliche Geschichte von Manager Gleb, der noch kein Refactoring durchführen wollte ...



2. Unsere Vorschriften zur Erörterung von Aufgaben

3. Unsere Überprüfung des Checklistencodes