Leicht zu pflegende Unternehmenskultur in Worten. Allerdings erforschen nur wenige Unternehmen aktiv die wenigen Merkmale der Unternehmenskultur, die einen erheblichen Einfluss auf die Produktivität haben - weil dies am schwierigsten ist.
Für Software-Teams ist der Besitz von Code ein entscheidender Faktor für das Wohlbefinden der Ingenieure. In diesem praktischen Leitfaden analysieren wir genau, wie Sie dieses Prinzip in die tägliche Arbeit Ihres Entwicklungsteams integrieren, damit das Wohl Ihrer Codebasis von selbst gewahrt bleibt.
Ich hatte das Glück, einige der besten Entwickler der Welt zu treffen - bei Stepsize arbeite ich jeden Tag mit ihnen. Und während Diskussionen darüber, wie technische Schulden entstehen, mit führenden Entwicklern von Unternehmen wie Skyscanner, Spotify, Palantir und anderen, wird immer eine Frage aufgeworfen: Eigentum.
In eng zusammenarbeitenden, sich schnell entwickelnden Teams (also in modernen Teams), in denen Entwickler sich auf einen beliebigen Teil der Codebasis festlegen können, ist der Code leicht überladen und wird zu einem Monster, das Frankenstein ähnelt. Und wenn es schlimm genug wird, sollte jemand wie Captain Marvel eingreifen und alles mit einem großen Refactoring reparieren.
Um dies zu vermeiden, versuchen die Entwicklungsteams, einen der vielen tollen Tipps von Robert S. Martin („Onkel Bob“) zu befolgen, nämlich die „ Pfadfinderregeln “: Halten Sie den Code in einem besseren Zustand als vor Ihnen . Hier ist eine kostenlose Erweiterung für VSCode, mit der Sie dies erheblich vereinfachen können .
Trotz des Könnens und der besten Anreize der Entwickler scheint das unveränderliche Gesetz der Softwareentwicklung zu sein, dass sich die technischen Schulden ansammeln - bis es zu viel wird und wir uns dann Zeit für viele Umgestaltungen nehmen müssen . Wir haben uns gezögert, dies als Teil des Lebenszyklus der Softwareentwicklung zu akzeptieren.
Vielleicht liegt es an mangelnder Disziplin?
Also habe ich vorher gedacht. Und dann traf ich Gareth Vizaji , den Chefarchitekten von Snyk.io , und er schlug mich mit folgendem Satz:
Eigenverantwortung ist der Hauptindikator für das Wohlbefinden der Ingenieure.
Was meinte er Und wie konnte er eine solche Erklärung abgeben?
Es gibt eine Menge Untersuchungen, die zeigen, dass, wenn Teammitglieder die Früchte ihrer Arbeit besitzen, gegenüber Managern rechenschaftspflichtig sind und Verantwortung für Erfolg und Misserfolg übernehmen, alle möglichen guten Dinge passieren.
Leider ist es in der Praxis nicht einfach, dies zu erreichen. Dies liegt zum Teil daran, dass die Produktivität der Entwicklung offenbar nicht gemessen werden kann und moderne Entwicklungspraktiken unter allen Umständen einen schlechten Code-Besitz fördern. Die Wahrheit ist, dass es bis jetzt unglaublich schwierig war, die Eigentümerschaft in Entwicklungsteams richtig zu messen. Wir wussten also nicht einmal, wie „gut“ dieser Indikator aussah.
Glücklicherweise haben neuere wissenschaftliche Untersuchungen gezeigt, dass die Code-Inhaberschaft - das beste indirekte Maß für den vagen Begriff der "Inhaberschaft" in Entwicklungsteams - anhand der Git-Commit-Aktivität gemessen werden kann. Und dies ist ein wunderbarer Frühindikator für das Wohlergehen Ihrer Codebasis.
Die Teile der Codebasis, an denen viele Entwickler Änderungen vornehmen, sind mit der Zeit überfüllt, und diejenigen, mit denen weniger Menschen arbeiten, sind normalerweise in einem besseren Zustand. Nehmen Sie nicht mein Wort - gute Leute von Microsoft haben dies anhand ihres eigenen Beispiels studiert.
Quelle: Microsoft-Studie
Ich kann einige von Ihnen fast schreien hören, dass Sie keine Situation wollen, in der nur ein Entwickler als Einziger Code anfassen darf - dieser Ansatz hat schreckliche Nebenwirkungen. Ich verstehe dich, und das bieten wir nicht an.
Hör mir zu bis zum Ende.
Es gibt verschiedene Formen der Code-Inhaberschaft, die für unterschiedliche Umstände geeignet sind.
Kollektives Eigentum und mangelndes Eigentum
Kollektives Eigentum ist Eigentum, [...] an dem der Kodex gemeinsam ist, aber Verantwortlichkeiten und Zeitpläne sind klar definiert. Jedes Teammitglied kann bei Bedarf an einem beliebigen Subsystem oder Dienst arbeiten.
Non-Ownership - eine Situation, [...] in der mehrere Entwickler Änderungen am selben Subsystem vornehmen, die Koordination von Aktionen, die Verantwortung für die Qualität oder die Kommunikation innerhalb des Teams jedoch minimal ist. In solchen Systemen sollte man keine qualitativ hochwertige Arbeit erwarten.
Quelle: Microsoft-Studie
Sie können diese Partition weiter fortsetzen, indem Sie dem Heap auch den eigentümerlosen Code und den Alleineigentum hinzufügen, aber ich möchte die Hauptsache nicht missen, deshalb ist hier eine Grafik, die das Spektrum der Eigentumsformen des Codes zeigt:
Kollektives Eigentum sollte Ihre Standardwahl sein und die Form des Eigentums, die Sie anstreben sollten. Beachten Sie, dass dies nicht bedeutet, dass nur ein Entwickler in Ihrem Team berechtigt ist, den Code zu ändern, oder dass eine Änderung des Codes dessen Genehmigung erfordert. Dies bedeutet nur, dass es für jeden im Team völlig klar ist, mit wem er Fragen besprechen sollte, und dass der Eigentümer des Codes höchstwahrscheinlich mit der Überprüfung des Codes fertig wird (Codeüberprüfung). Auf diese Weise kann jeder im Team die Standards für das Schreiben von Code verbessern und feststellen, wie der eigene Code geändert wurde.
Der Eigentümer ist für den Zustand seines Codes verantwortlich, und Manager sollten dies von ihm verlangen. Dies bedeutet nicht, dass er für jeden Fehler, der in seinen Code eingedrungen ist, auf den Kopf geschlagen werden muss. Dies bedeutet, dass die Eigentümer befugt sind, Entscheidungen hinsichtlich der Codequalität und der technischen Verschuldung zu treffen. Sie werden für diese Entscheidungen mit zusätzlichen unterstützenden Messgrößen wie Kohäsion und wiederkehrende Aktivitäten (Abwanderung) zur Rechenschaft gezogen (weitere Einzelheiten finden Sie in unserem Artikel über technische Verschuldungsmessgrößen ).
Fehlendes oder schwaches Eigentum ist das Gegenteil von kollektivem Eigentum, und in den meisten Fällen sollte diese Form des Eigentums vermieden werden. Wie bereits erwähnt (und dies mag offensichtlich klingen), ist es für Dateien wie package.json normal, keinen klar definierten Eigentümer zu haben. Es ist nicht notwendig, ins Extreme zu gehen.
Verwaister Code
Die unangenehmste Form des Eigentumsmangels ist einer der Ränder des Spektrums der Eigentumsformen des Kodex. Sie brauchen diese Form des Eigentums definitiv nicht. Vermeiden Sie es auf jeden Fall ... es sei denn, es ist natürlich ein Code, den Sie nie wieder berühren werden. Ein solcher Code ist jedoch sehr selten.
Der Code wird als inhaberlos angesehen, wenn der Hauptentwickler keine Änderungen an der Codebasis vorgenommen hat. Vielleicht hat er die Organisation verlassen oder ist von Entwicklern zu Managern gewechselt. In jedem Fall haben Sie ernsthafte Probleme - und auch Ihre Codebasis.
Es gibt jedoch eine Lösung. Sie müssen den Quellcode in eine andere Form des Eigentums umwandeln, die für ihn am besten geeignet ist. Um zu vermeiden, dass in Ihrer Codebasis ein Code ohne Eigentümer erscheint, stellen Sie sicher, dass in Ihren Plänen für den Fall der Entlassung oder Verweisung von Fällen die Einführung neuer Eigentümer des Codes in den Geschäftsgang des alten Eigentümers vorgesehen ist. Sie können es ihnen erleichtern, indem Sie ihnen automatisch zuweisen, dass sie Pull-Anforderungen für Codeänderungen anzeigen. Ist dies nicht der Fall, können Sie einfach die Eigentümer des Codes bestimmen, wie Sie es für richtig halten.
Lassen Sie den inhaberlosen Code nicht in Ihrer Codebasis hängen, unabhängig davon, für welche Methode Sie sich entscheiden. Sie wissen nie, was mit ihm geschehen wird, wenn Sie ihn dem Schicksal überlassen.
Alleineigentum (absolutes Eigentum)
Dies ist das andere Ende des Spektrums der Code-Inhaberschaft. Bei ihm kann alles sowohl wunderbar als auch sehr schwierig sein.
Der Code gilt als alleiniges Eigentum, wenn der Eigentümer der einzige Entwickler ist, der Änderungen am Code vornehmen oder genehmigen kann, oder wenn der Eigentümer im Wesentlichen die einzige Person ist, die jemals Änderungen am Code vorgenommen hat.
Kleine Startups stoßen in ihrer Arbeit häufig auf ähnliche Praktiken. Jeder Entwickler ist in der Regel für den gesamten Verlauf einer einzelnen Datei verantwortlich, und es wird erwartet, dass das Eigentum an dieser Datei erhalten bleibt. Dies ist nicht das Ende der Welt; Startups haben schließlich nur begrenzte Ressourcen, und Sie müssen bestimmte Opfer bringen. Aber wenn der Entwickler eines Tages den Bus bewegt, wird dieser Teil des Codes inhaberlos sein. Für solche Situationen sollten Sie einen Sicherungsplan haben.
In größeren Ingenieurbüros kann ein niedriger „ Busfaktor “ ein echtes Problem sein, insbesondere wenn es um kritische Teile der Codebasis geht, die Fluktuation hoch ist und die vom Unternehmen eingestellten technischen Schulden zu hoch sind. Wenn beispielsweise der Entwickler, der Ihr gesamtes manuell konfiguriertes Zahlungssystem verpfuscht hat, kündigt, werden Sie große Kopfschmerzen haben - falls Sie Ihr Preismodell ändern möchten oder wenn Sie einen Fehler in der Codebasis finden, der Sie dazu veranlasst Viele Monate lang erhielten sie weniger Geld von ihren größten Kunden. Dann muss sich entweder jemand zusammensetzen und versuchen, den Code zu verstehen, um Änderungen daran vorzunehmen, oder Sie müssen die technische Insolvenz Ihres Zahlungssystems anmelden und neu schreiben (aber bevor Sie dies tun, lesen Sie dies bitte).
Lass dir das nicht passieren.
Es gibt jedoch Situationen, in denen der alleinige Besitz des Codes akzeptiert oder sogar empfohlen wird. Möglicherweise möchten Sie diese Eigentumsform für diejenigen Teile der Codebasis einrichten, für die die Aussage "Wenn dieser Teil kaputt geht, können wir aussteigen, weil das Unternehmen uns dann keine Gehälter zahlen kann oder wir ins Gefängnis gehen".
Selbst wenn Sie in solchen Fällen das Wissen über den kritischen Teil des Codes unter mehreren Entwicklern verbreiten möchten, um einen ausreichend hohen Busfaktor aufrechtzuerhalten, möchten Sie wahrscheinlich auch Regeln festlegen, die das Einfügen von Pull-Anforderungen ohne die Zustimmung des alleinigen Eigentümers des entsprechenden Codes verbieten.
Zusammenfassung
Streben Sie eine kollektive Inhaberschaft der meisten Dateien in Ihrer Codebasis an (50% –90% der Inhaberschaft des Codes für eine bestimmte Datei) und erhöhen Sie bei Bedarf disziplinierter die Inhaberschaft des Codes und verringern Sie die technische Verschuldung.
Die Vorteile sind wie folgt:
- Höhere und ordnungsgemäß gewartete Standards für das Schreiben von Code. In einer kleinen, gut informierten Gruppe ist es einfacher, hohe Standards einzuhalten. Dies gilt nicht nur für Entwickler, die ihren eigenen Code ändern, sondern auch für Code-Reviews, die von ihren Kollegen geschrieben wurden und sich auf die Teile auswirken, die sie besitzen.
- Kommunikation erleichtern. Explizite und klare Eigentümerschaft bedeutet, dass jeder Entwickler im Team weiß, wer seine Frage am besten beantwortet.
- Fokussierteres und effektiveres Refactoring. Wenn Sie sich entschließen, einen Teil der technischen Schulden zu begleichen, sind starke Entwickler, die den entsprechenden Code besitzen, am besten für diese Arbeit geeignet. Verwenden Sie Besitz-, Konnektivitäts- und wiederkehrende Aktivitätsmetriken, um Problembereiche in Ihrer Codebasis zu skizzieren. Ihre Entwickler werden ihr Budget für technische Schulden mit Bedacht einsetzen und nie wieder Zeit für die Tilgung von technischen Schulden aufwenden, die sich nicht lohnen.
- Der Busfaktor wird niemals außer Kontrolle geraten. Sie können die Code-Inhaberschaft verwenden, um den Wissensaustausch in Ihrer Organisation zu organisieren. Wenn der Grad der Inhaberschaft zu hoch ist, weisen Sie andere Entwickler an, den Code und die damit verbundenen Aufgaben zu überprüfen. Sie werden Ihre Eigentümerindikatoren schrittweise verbessern, was zu einer Verbesserung der Codequalität und zu einem Rückgang der technischen Schulden führen wird.
Wie alles, was sich wirklich lohnt, erfordert die Schaffung einer Ingenieurskultur für Code-Besitz (und das Befolgen derselben!) Zeit und Mühe, die sich jedoch mit Zinsen auszahlt. Dieser Faktor wirkt sich direkt auf nahezu jedes Wohlbefinden der KPI-Technik aus, das Sie sich vorstellen können. Integrieren Sie es in die Kultur Ihres Unternehmens und langfristig wird es zu Ihrem enormen Wettbewerbsvorteil.