Collective Code Ownership

In traditionellen Modellen hat Code Besitzer. „Das ist Alices Modul." „Sprich mit Bob über die Datenbankschicht." Das schafft Probleme:

Engpässe: Wenn Alice im Urlaub ist, kann ihr Modul nicht geändert werden. Wenn Bob beschäftigt ist, stapelt sich die Datenbankarbeit.

Silos: Die Leute verstehen Code nicht, den sie nicht besitzen. Integration wird schmerzhaft.

Bus-Faktor: Wenn Alice geht, geht das Wissen mit ihr.

Collective Ownership bedeutet, dass jeder im Team jeden Code ändern kann. Es gibt keine persönlichen Territorien. Das Team besitzt die Codebasis gemeinsam.

Das ist anfangs beängstigend. Werden die Leute nicht Dinge kaputt machen, die sie nicht verstehen? Wird der Code nicht inkonsistent? Wird nicht Chaos ausbrechen?

Nicht, wenn man die unterstützenden Praktiken hat.

Collective Ownership erfordert unterstützende Praktiken:

Umfassende Tests: Wenn du etwas kaputt machst, fangen Tests es sofort ab. Das macht es sicher für Nicht-Experten, Code zu ändern.

Pair Programming: Wenn du unbekannten Code änderst, arbeite im Pair mit jemandem, der ihn kennt. Wissen wird übertragen und Fehler werden abgefangen.

Coding Standards: Konsistenter Stil bedeutet, dass jeder jeden Code lesen kann. Keine Übersetzung zwischen „Alices Stil" und „Bobs Stil."

Continuous Integration: Änderungen werden sofort integriert. Wenn etwas kollidiert oder kaputt geht, weißt du es schnell.

Refactoring: Jeder verbessert Code während der Arbeit. Die Codebasis wird mit der Zeit besser, nicht schlechter.

Ohne diese Praktiken ist Collective Ownership Chaos. Mit ihnen ist es befreiend.

Individuelles Eigentum hat seinen Platz. Es bietet:

• Expertise-Tiefe: Besitzer werden zu echten Experten in ihrer Domäne
• Klare Verantwortlichkeit: Eine Person ist verantwortlich
• Schnellere Entscheidungen: Kein Konsens nötig

Aber die Kosten sind hoch:

• Engpässe: Der Besitzer ist ein Single Point of Failure
• Wissenshortung: Absichtlich oder nicht, Expertise konzentriert sich
• Territoriales Verhalten: „Fass meinen Code nicht an"
• Eingeschränkte Mobilität: Leute können nicht einfach den Fokus wechseln

XP sagt, die Kosten überwiegen die Vorteile. Gemeinsames Eigentum mit unterstützenden Praktiken schlägt individuelles Eigentum.

Manche Teams nutzen einen Hybrid: primäre und sekundäre Besitzer. Der primäre kennt den Code am besten; der sekundäre lernt. Das bietet Expertise und reduziert gleichzeitig das Engpass-Risiko.

Der Wechsel zu Collective Ownership kann schwierig sein:

„Aber ich bin der Experte!" Du bist immer noch der Experte. Du wirst im Pair mit anderen arbeiten, wenn sie deinen Code ändern. Deine Expertise verbreitet sich – sie nimmt nicht ab.

„Die Leute werden meinen Code vermasseln." Tests schützen vor Vermasseln. Code Review (oder Pairing) fängt Probleme ab. Und „dein" Code ist nicht wirklich deiner – er gehört dem Team.

„Ich kann nicht mit dem ganzen Code Schritt halten." Musst du nicht. Du lernst, was du brauchst, wenn du es brauchst. Arbeite im Pair mit Experten. Lies Tests. Folge Standards.

„Unser Code ist zu komplex für Nicht-Experten." Das ist ein Code Smell, kein Eigentums-Argument. Komplexer Code sollte vereinfacht werden. Bis dahin schützt Pair Programming vor uninformierten Änderungen.

Der Wandel ist genauso kulturell wie technisch. Er erfordert Vertrauen, Transparenz und eine Wachstumsmentalität.

Schrittweiser Übergang zu Collective Ownership:

Woche 1-2: Pair domänenübergreifend. Lass Experten im Pair mit Nicht-Experten am Code des jeweils anderen arbeiten.

Woche 3-4: Entferne explizite Eigentums-Labels. Hör auf zu sagen „Alices Modul." Fang an zu sagen „das Payment-Modul."

Woche 5-6: Fördere Cross-Pollination. Wenn du Stories zuweist, setze Leute absichtlich auf unbekannten Code (mit Pairing-Unterstützung).

Laufend: Feiere Wissensaustausch. Erkenne an, wenn jemand einen neuen Bereich lernt oder wenn ein „Besitzer" erfolgreich Wissen überträgt.

Miss den Bus-Faktor: Wie viele Leute können sinnvoll an jedem Bereich der Codebasis arbeiten? Strebe mindestens 2, idealerweise 3+ an.