Collective Code Ownership: Ein Anti-Pattern?
Gemeinsame Verantwortung für Code hört sich nach einer gute Idee an. Aber sie ignoriert wichtige Konzepte der Softwareentwicklung.
- Eberhard Wolff
Gemeinsame Verantwortung für Code hört sich nach einer gute Idee an. Aber sie ignoriert wichtige Konzepte der Softwareentwicklung.
Collective Code Ownership stammt aus dem Extreme Programming (XP), einer frühen agilen Methode. Es bedeutet, dass alle Entwickler jedes Problem beheben müssen, das sie im Code finden. Gemeinsam die Verantwortung für ein System zu übernehmen, sorgt dafür, das Probleme beseitigt werden, statt sie einfach hinzunehmen. Moderne Ansätze für Projektarbeit setzten auf eigenverantwortliche Teams. Dafür ist bei Softwareentwicklung die Verantwortung für den Code sicherlich zentral.
Woher wissen die Entwickler, was verbessert werden muss und wie das geschehen soll? Im Buch "Extreme Programming Explained" von Kent Beck steht, dass nicht alle Entwickler Experten für jeden Codeteil sein können, aber sie müssen zumindest ein grundlegendes Verständnis für den gesamten Code haben.
Information Hiding
Wissen über den gesamten Code widerspricht dem Information Hiding, das schon in einem anderen Beitrag eine Rolle gespielt hat. Information Hiding bedeutet, dass Nutzer eines Moduls nur die Schnittstelle kennen, aber nicht die Interna. Das erleichtert die Nutzung des Modul, weil Nutzer weniger über das Modul wissen muss. Das Modul ist auch einfacher änderbar. Änderungen sind ohne Beeinträchtigung der Nutzer des Moduls möglich, so lange die Schnittstelle unverändert bleibt.
Collective Code Ownership fordert aber mehr als nur Wissen über die Schnittstelle. Jeder muss die Interna aller Module zumindest oberflächlich verstehen. Welche Alternativen gibt es?
Alternativen
Für jedes Modul könnte ein Entwickler verantwortlich sein. Das hat entscheidende Nachteile. Wenn die zuständigen Entwickler Urlaub haben oder krank werden, wird es schwierig, das Modul zu ändern, weil nur sie das Modul verstehen.
Eine Lösung ist, dass mehrere Entwickler jedes Modul kennen, aber nicht alle Entwickler jedes Modul kennen. Die Organisation spielt dabei eine wichtige Rolle: Das Gesetz von Conway besagt, dass die Softwarearchitektur den Kommunikationsbeziehungen unter den Entwicklern entspricht. Die These: Entwickler sind jeweils für ein oder mehrere Module zuständig und müssen miteinander reden, wenn sie Module anderer Entwickler nutzen wollen. Auch das widerspricht dem Collective Code Ownership, weil nicht jeder Entwickler jeden Code versteht oder gar ändern kann
Kommunikation innerhalb eines Teams ist einfacher. Sie arbeiten oft in denselben Räumlichkeiten und haben gemeinsame Meetings. Das erleichtert die Kommunikation. Bessere Kommunikation kann nach dem Gesetz von Conway Auswirkungen auf die Architektur haben. Wenn Entwickler aus einem Team den Code anderer Teammitglieder kennen, kann das ein Zeichen guter Zusammenarbeit im Team sein. Wenn die Entwickler die Module anderer Teams kennen müssen, dann ist dazu aufwendige Kommunikation wie während extra organisierter Meetings notwendig. Also sollte Collective Code Ownership auf Teams beschränkt sein und nicht die gesamte Organisation umfassen.
tl;dr
Collective Code Ownership bedeutet, Verantwortung für Code zu übernehmen und Code zu verbessern. Das ist ein gute Sache. Den gesamten Code zu verstehen, ist dank Modularisierung zum Glück nicht notwendig. ()
