Definition „Code-Verantwortung“ Was ist Code Ownership?

Anbieter zum Thema

Rittal GmbH & Co. KG

Rosenberger-OSI GmbH & Co. OHG

VON ZUR MÜHLEN'SCHE GmbH

Code Ownership oder Codeverantwortung ist ein Konzept, bei dem einzelne Entwickler oder ganze Teams die Verantwortung für bestimmte Teile einer Anwendung übernehmen. Die ausgewählten Personen sind jeweils für Qualität, Korrektheit und Wartbarkeit des Moduls oder Abschnitts zuständig.

Welche Konzepte für Code Ownership gibt es?

Konzepte für Code Ownership lassen sich danach unterteilen, wer für den Code verantwortlich ist. Die zwei Hauptansätze sehen vor, dass entweder ein einzelner Entwickler oder ein ganzes Team zuständig ist.

Einzelner Code Owner

Strong und Weak Code Ownership sind beides Konzepte, bei denen tendenziell nur eine Person für bestimmte Module oder Abschnitte zuständig ist. Sie unterscheiden sich in Details.

Strong Code Ownership

Strong Code Ownership sieht vor, dass es in der Regel nur einen Ansprechpartner gibt, der zu Änderungen an einem bestimmten Codeabschnitt oder Modul berechtigt ist. So bleibt die Gestaltung, Pflege und Qualitätssicherung dieses Codes immer in einer Hand. Die Verantwortlichkeiten sind klar geregelt. Andere Entwickler dürfen ausschließlich dann Änderungen am Code vornehmen, nachdem der Code Owner diese genehmigt. Genauso ist er die zentrale Anlaufstelle bei Fehlern, die auf diesen Code zurückzuführen sind.

Der große Nachteil an diesem Modell ist, dass durch die strikte Limitierung der Zuständigkeit Engpässe entstehen können. Änderungsanfragen können sich anstauen, wenn der Zuständige im Urlaub ist oder aktuell stark ausgelastet ist. Zudem wird Wissen tendenziell bei einer Person gebündelt, was die Zusammenarbeit erschweren kann.

Weak Code Ownership

Schwache Codeverantwortung sieht ebenfalls vor, dass es für jeden Teil einer Anwendung einen festen Verantwortlichen gibt. Allerdings dürfen bei diesem Modell auch andere Entwickler direkt am Code arbeiten, ohne den Eigentümer zu fragen. Der Verantwortliche bleibt jedoch für die Qualität und Wartung des Codes zuständig. Das bedeutet, dass er sich über Änderungen informieren sollte. Außerdem sollte er diese prüfen und abnehmen.

Weak Code Ownership ist in der Praxis oft eine beliebte Alternative zu Strong Code Ownership, weil hier auch andere Entwickler mitarbeiten können. Das macht es einfacher, Abwesenheiten auszugleichen oder die Lasten gleichmäßiger im Team zu verteilen. Allerdings muss bei diesem Ansatz stärker darauf geachtet werden, dass der Code Owner seinen Verpflichtungen nachkommt. Es muss trotz aller Freiheiten klar geregelt sein, wer letztendlich die Verantwortung für die Qualität eines jeden Abschnitts trägt.

Collective Code Ownership

Beim Modell Collective Code Ownership übernimmt das Team gemeinsame Verantwortung für den Code. Die kollektive Codeverantwortung unterstützt eine kollaborative Arbeitsweise, da das gesamte Team für den Code verantwortlich ist. Jeder sollte zumindest oberflächlich alle Bereiche der Anwendung kennen und jeder ist berechtigt dazu Änderungen vorzunehmen. Wissensaustausch innerhalb des Teams ist explizit erwünscht. Ebenso ist es für diesen Ansatz von Vorteil, wenn sich das Team zu Ideen austauscht und gemeinsam eine Lösung findet, die zum Projekt passt.

Collective Code Ownership kann dazu führen, dass Teams schneller auf neue Anforderungen oder Fehler reagieren können. In der Theorie kann jeder Entwickler an allen Teilen des Codes arbeiten, wodurch Ausfälle besser kompensiert werden können. In der Praxis besteht die Herausforderung, dass sich Entwickler vor allem in den Bereichen des Codes gut auskennen, an denen sie bereits selbst gearbeitet haben. Das kann zur Folge haben, dass die Codequalität sinkt, sobald jemand in einem für ihn bisher eher unbekannten Teil der Anwendung arbeitet. Dem kann entgegengewirkt werden, indem das Team alle Codeänderungen gegenseitig prüft, um gemeinsam für eine gleichbleibende Qualität zu sorgen.

Die kollektive Codeverantwortung kann zudem mit einem höheren Zeitaufwand verbunden sein. Das Team muss sich häufiger untereinander abstimmen, was die Anzahl an Besprechungen erhöht.

Welche Aufgaben hat ein Code Owner?

Art und Umfang der Aufgaben eines Code Owners können je nach Unternehmen und Projekt variieren. Typische Verantwortlichkeiten sind z. B.:

• Vornehmen von Änderungen und Erweiterungen am Code

• Refactoring

• Prüfen und Abnehmen von Änderungen anderer Entwickler

• Fehlerbehandlung

• Wartung

• Qualitätssicherung gemäß den Projektzielen

Welche Vorteile hat Code Ownership?

Strong / Weak Code Ownership:

• höhere Codequalität durch klare Verantwortlichkeiten

• klar geregelte Ansprechpartner für jedes Modul

Collective Code Ownership:

• geringeres Risiko von Engpässen durch Aufteilung von Zuständigkeiten

• schnellere Entwicklung durch kollaboratives Arbeiten

• bessere Qualität und Konsistenz durch gegenseitige Code Reviews

• gleichmäßigere Verteilung von Wissen über das gesamte Projekt

Welche Nachteile hat Code Ownership?

Je nach gewähltem Modell kann Codeverantwortung verschiedene Herausforderungen mit sich bringen.

Strong / Weak Code Ownership:

• Wissenssilos durch fehlenden Wissenstransfer

• Engpässe durch Urlaub, Krankheit oder Auslastung des Code Owners

Collective Code Ownership:

• Ineffizient durch häufiges Abstimmen

• Wissenssilos und Wissensinseln durch nicht gleichmäßig verteilte Aufgaben innerhalb des Teams

• Unstimmigkeiten innerhalb des Teams erschweren Zusammenarbeit

• Aufweichen des Verantwortungsgefühls durch geteilte Zuständigkeiten

Fazit

Code Ownership kann insgesamt zu einer höheren Codequalität führen und die Zusammenarbeit im Team verbessern. Allerdings hängt es vom jeweiligen Projekt und auch von der Unternehmenskultur ab, welche Variante der Codeverantwortung am besten geeignet ist – oder ob ein ganz anderer Ansatz erfolgreicher wäre.

Code Ownership kann auch partiell eingesetzt werden, um nur die wichtigsten Module abzudecken oder die schrittweise Einführung des Konzepts anzugehen. Zudem ist es eine gute Idee, die Prozesse flexibel zu halten und immer wieder auf Sinnhaftigkeit zu prüfen, z. B. wenn sich die Teamgröße oder die Projektanforderungen verändern.

(ID:49916897)