Czy ten kod ma właściciela?

Ten wpis nie będzie o prawach autorskich, nie będzie o zawiłościach umów GPL ani też nie będzie nic o ACTA. Będzie o bardzo prostym pytaniu: czy fragmenty kodu aplikacji, które tworzymy lub też zmieniamy, powinny być przypisane do właścicieli.

Zacznijmy od teorii – a teorie na ten temat są bardzo różne…

Społeczności Agile’owe oraz teoria Extreme Programming promują „Collective Code Ownership” czyli wspólną własność kodu – oznacza to, iż dowolna osoba może w dowolnej chwili zmienić czy zrefaktoryzować dowolny fragment kodu.

Z drugiej strony skali jest za to metodyka Feature-Driven Development (należąca, podobnie jak XP, do grupy metodyk zwinnych), która zakłada „Individual Code Ownership” – czyli model, w którym każda klasa jest przypisana programiście odpowiedzialnemu za jej implementację i rozwój. Jedynie ten programista jest uprawniony do wprowadzania zmian w tej klasie.

A pomiędzy tymi dwiema skrajnościami jest coś, co możemy nazwać „Weak code ownership” (albo też „Code Stewardship”), czyli model w którym poszczególne moduły mają przyporządkowanych właścicieli czy opiekunów. Zmiany w tych modułów przez inne osoby są możliwe, aczkolwiek wszystkie większe zmiany lub refaktoryzacje muszą być omówione lub zaakceptowane przez właściciela danego fragmentu kodu.

No i oczywiście wszystkie strony przytaczają różne argumenty mówiące o tym, że to właśnie ich metoda jest najlepsza…

Oddajmy na początku głos zwolennikom silnej własności kodu. Twierdzą oni, że jeżeli przypiszemy różnym klasom, modułom czy funkcjom ich właścicieli, to te osoby będą czuły się odpowiedzialne za „swój” fragment i będą dbały o to, aby „ich” klasa była wolna od błędów, dobrze opisana i łatwo utrzymywalna. Motywacją do dobrej pracy dla właścicieli jest możliwość pochwalenia się, jak dobrze wyglądają i jak dobrze działają ich fragmenty oprogramowania.

Na co odzywa się teoria XP i mówi, że w dużych projektach tak pracować się nie da, ponieważ: konieczność uzgodnień zmiany z właścicielem klasy znacząco utrudnia i spowalnia proces dewelopmentu, często trudno jest podzielić duży system na logiczny zbiór modułów, trudno jest w takim modelu zrównoważyć obciążenie programistów pracą, istnieje spore ryzyko, iż programiści zamkną się w swoich boksach, a refaktoryzacja większego fragmentu kodu (tj. kodu należącego do wielu właścicieli) okazuje się koszmarem. A wspólnota kodu eliminuje wąskie gardła, pozwala na dzielenie się wiedzą oraz dobrymi pomysłami i sprawia, że cały system jest bardziej spójny. Zwłaszcza jeżeli konsekwentnie stosujemy zasadę skauta, czyli jeżeli na bieżąco poprawiamy niedostatki w pobranym kodzie.

FDD odpowiada na to radośnie, że jak coś należy do każdego, to tak naprawdę nie należy do nikogo – i finalnie nikt nie czuje się odpowiedzialny za kod. I że naturalną tendencją ludzi jest dążenie do posiadania własnego ogródka, który mogą uprawiać.

Tutaj sprawę próbuje pogodzić teoria „Weak code ownership”, mówiąc, że ona jest dobrym konsensusem pomiędzy obiema skrajnościami i że łączy dobre cechy obu modeli – ale niespodziewanie zostaje zakrzyczana przez obie pozostałe teorie, które gwałtownie argumentują, że wprowadzenie osób kontrolujących kod (stewards) albo nie jest skutecznym rozwiązaniem problemu, albo może być w praktyce zastąpione przez dobry zestaw testów jednostkowych.

Zostawmy kłócące się teorie na boku i zajmijmy się teraz praktyką. Jak to wygląda kwestia własności w firmach tworzących oprogramowanie? Widzę tutaj kilka reguł.

Po pierwsze: rzadko jest tak, że kwestia własności kodu była jasno zdefiniowaną i przestrzeganą polityką. Dużo częściej jest to zestaw niepisanych reguł czy przyzwyczajeń.

Po drugie: na politykę własności mocno wpływa charakterystyka rozwijanego systemu oraz kultura firmy. To, czy ludzie chętnie dzielą się swoim kodem, zależy od kilku czynników: od osobistych preferencji (są osoby, które preferują uprawianie własnego ogródka i są takie osoby, które chętnie poprawiają coś dookoła), od wielkości i stopnia skomplikowania systemu, od stopnia pokrycia go testami oraz wreszcie od kultury firmy – karanie za wprowadzenie błędów przy wykonywaniu refaktoryzacji sprawia, że nikt nie chce wykonywać poważnych zmian i optymalizacji.

I po trzecie: sytuacją, którą często widzę, jest „no ownership”, które jest wymuszone na skutek chęci szybkiego wykonywania zadań („musimy wykonać zadanie w module ABC, Zenek teraz nie ma nic do roboty, więc Zenek zmieni moduł ABC”). Często jest też tak, że osoba, która napisała lub zmieniła mocno dany moduł staje się ekspertem od danego modułu – ale ekspertem w znaczeniu osoby, która posiada wiedzę i może pomóc w razie potrzeby, a nie w znaczeniu osoby opiekującej się modułem.

A jak polityka własności kodu wygląda w Twojej firmie i jak się sprawdza w praktyce?