Code Ownership (IV)

Bild: Unsplash / Kelly Sikkema - Lizenz

Wie viele andere Begriffe hat auch der der Code Ownership verschiedene Bedeutungsaspekte, je nachdem aus welchem Blickwinkel man ihn betrachtet. Auf der anderen Seite verbirgt sich dahinter eine Art von Besitzanspruch im Sinne von "dieser Code gehört mir" (warum das ein Problem ist kann man hier, hier und hier nachlesen). Es lässt sich aber auch eine zweite Deutung formulieren: sich den Code zu eigen machen. Auch die ist von grosser Wichtigkeit.

Unter dem "sich zu eigen machen" können sich wiederum verschiedene Bedeutungen verbergen, die aber alle einen verwandten Inhalt haben - es geht darum das Objekt (in diesem Fall den Code) zu studieren, zu verstehen, zu erlernen oder zu verinnerlichen, bis zu dem Punkt an dem bei neuen Problemen und Herausforderungen sofort eine Idee entsteht wo und wie diese zu lösen sein könnten. Sie muss noch nicht perfekt sein, aber einen ersten Anhaltspunkt bieten.

Der Nutzen eines solchen Wissens ist offensichtlich: wann immer die genannten Problemen und Herausforderungen auftreten ist es nicht nötig, sich zuerst in die Dokumentation einzulesen, Code Reviews zu machen oder Reverse Engineering zu betreiben, stattdessen kann schneller mit der eigentlichen Arbeit begonnen werden. Und bedingt durch die gegebene Vertrautheit dürfte auch deren Ergebnis besser sein.

Um ein Code Ownership in diesem Sinn zu erreichen ist es nicht ausreichend ihn geschrieben oder einmalig verstanden zu haben, schon gar nicht wenn das nur durch eine Person geschieht. Idealerweise ist es eine ganze Gruppe die sich regelmässig mit ihm beschäftigt, um so das Wissen nicht nur zu verteilen sondern durch ständige Kommunikation am Leben zu halten. Am Ende sollte dabei ein kollektives Gedächtnis des gemeinsam verinnerlichten Codes stehen.

An dieser Stelle beginnen in vielen Organisationen die Herausforderungen. Nicht etwa in erster Linie wegen der Herstellung von Collective Code Ownership (obwohl auch das schon ein Problem sein kann), sondern vielmehr weil eine regelmässige Beschäftigung eines Teams mit einem bestimmten Anwendungsteil oft nicht vorgesehen ist. Modifizierungen finden vor allem im Rahmen von Projekten statt, zwischen denen Monate oder sogar Jahre liegen können.

Von diesem Muster wegzukommen und sich in Richtung einer "Continuous Code Ownership" zu bewegen kann grössere und aufwändige Umstellungen erfordern, es ist aber eine der Voraussetzungen um im Zweifel schnell lieferfähig zu sein.