Preskočiť na hlavný obsah

← Všetky články

„Nehrab mi do kódu" nie je problém ľudí

Práve upravujete kus kódu. Celý modul máte v hlave: každú funkciu, každú hraničnú podmienku, aj dôvod, prečo je retry logika napísaná práve tak. Potom otvoríte súbor a niekto vám doň medzitým zasiahol. Vyzerá inak. Vaša predstava ako veci sú sa už so skutočným kódom nezhoduje.

Jeden vývojár to v štúdii z roku 2016 vystihol presne:

"Niekto iný vám preruší tok myšlienok, programujete a už máte v hlave predstavu, čo sa stane, každú funkciu, každý atribút, a keď to potom niekto zmení, vyvedie vás to z pohody."

Pozná to každý vývojár. Bežná diagnóza znie: problém je v ľuďoch. Jeden je príliš majetnícky, druhý nedbalý, tímu chýba disciplína. Manažéri preto siahnu po praktikách. Code review. Pair programming. Dohoda o shared ownershipe, podľa ktorej kód nepatrí nikomu.

Praktiky to nevyriešia. Nemôžu. Ten konflikt nevytvárajú praktiky. Vytvára ho štruktúra.

Každý sa najprv opýta, nech pravidlo hovorí čokoľvek

Štúdia Monteira vychádza z rozhovorov o shared code ownershipe (spoločnom vlastníctve kódu) s 19 vývojármi v troch firmách. Firmy mali rôzne oficiálne pravidlá, no vývojári opisovali ten istý zvyk: vo všetkých troch sa pred zásahom do kódu zakaždým poradili s tým, kto ho napísal alebo spravuje.

V jednej z firiem nariadil collective ownership sám majiteľ. Slovami jedného z vývojárov: „Sme nútení pracovať s collective code ownershipom." Na papieri nepotreboval nikto povolenie čokoľvek meniť. Tamojší vývojári však opisovali, že sa pýtali aj tak.

Výskumníci to vysvetľovali ako prispôsobenie sa pre menej skúsených vývojárov: ľudí, ktorí si pri neznámom kóde nie sú istí a radšej sa uistia, než ho zmenia. Tento výklad rozhovorom zodpovedá. No zodpovedá im aj iný.

Vývojári stále poukazujú na to isté: na riziko, že zmenia kód, ktorému úplne nerozumejú. Štúdia toto riziko spája s medzerou v znalostiach a práve takú medzeru vytvára komponentová štruktúra. Štúdia nedokáže označiť štruktúru za príčinu, prinajmenšom nie z 19 rozhovorov, a ani sa o to nepokúša. No vzorec, ktorý z nich vystupuje, je presne ten, ktorý štrukturálny výklad predpovedá: tam, kde sú znalosti uzavreté v komponentoch, sa vývojár radí s ownerom, lebo tak zvláda riziko zmeny. Urobí to aj vtedy, keď mu oficiálne pravidlo hovorí, že nemusí. Pravidlo hovorí, že ownership je spoločný. Správajú sa však, akoby nebol, lebo znalosti spoločné nie sú.

Prečo lepšie praktiky nepomáhajú

Code review, pair programming, povinná dokumentácia, rotácie ľudí: každá z týchto praktík rieši riziko, že niekto zmení kód, ktorému nerozumie. Každá je odpoveďou na príznak. Neznalosť berú ako danosť a snažia sa len obmedziť jej škody.

Ani jedna sa nepýta na otázku, ktorá tomu predchádza: prečo je ten kód vôbec neznámy?

Neznámy je pre spôsob, akým je práca rozdelená. Keď sú tímy zostavené podľa technického komponentu (API tím, databázový tím, mobilný tím, platobný tím), každý vidí len svoj výsek. Zákaznícka funkcia, ktorá tieto výseky pretína, naraz prekračuje hranice znalostí viacerých tímov. Hranica znalostí je hranicou organizácie. Nikto si nesadol a nerozhodol, že platbám budú rozumieť len ľudia z platobného tímu. Rozhodla o tom štruktúra.

Owner chráni systém, nie teritórium

Znalosti sa sústreďujú dvakrát. Najprv na hranici komponentu: jeden tím vlastní platobnú službu a nikto zvonku nemá dôvod učiť sa, ako to vnútri funguje. Potom vnútri tímu, u jedného vývojára, ktorý sa kódu dotýkal najviac. Nazvite ho owner a znie to ako teritórium. Nie je. Je jediný, kto vidí, ako sa zmena šíri komponentom a ďalej do častí, ktoré od neho závisia. To z neho robí jediného človeka, ktorý ho vie zmeniť bezpečne. A on to vie.

Keď teda niekto upraví modul bez opýtania, jeho obrana nie je ego. Je to presné vyhodnotenie rizika: on vie vystopovať, kam zmena dopadne, oni nie. Organizácia z neho spravila single point of failure (jediný bod zlyhania). Preto kód stráži. Jeho inštinkt chrániť ho je obranou systému: systém sa bráni cez jediného človeka, ktorý to má v rukách.

Preto odstránenie ownera nepomôže. Nariaďte collective ownership a kontext sa neprerozdelí: zmizne len poistka. Kódu stále rozumie jeden človek. Teraz ho však smie pokaziť ktokoľvek.

Rovnakým smerom ukazujú aj dáta o chybách. V štúdii z roku 2011 o veľkých komponentoch Windowsu našli Bird a kolegovia z Microsoft Research silný vzťah medzi ownershipom a chybami: komponenty so sústredeným ownershipom ich mali menej, komponenty s mnohými drobnými prispievateľmi (ľuďmi, ktorí sa kódu dotkli len letmo) ich mali viac. Bežne sa to vykladá tak, že chyby spôsobuje zdieľaný kód. Lenže štúdia meria rozloženie ownershipu, nie organizačnú štruktúru, takže čo za koreláciou stojí, zostáva otvorené. Štrukturálny výklad číslam zodpovedá: keď veľa ľudí mení kód cez hranice znalostí, ktoré úplne neovládajú, chýb pribúda. Pri tomto výklade robí škodu hranica, nie zdieľanie.

Tá istá dynamika má aj ostrejšiu verziu. Vývojári v štúdii opisovali, ako sa kritika kódu mení na osobnú: porady, na ktorých veta „Videl som tvoj kód, [bol] veľmi zle urobený" spustila otvorený konflikt. Keď je kód váš, môže splynúť s vašou profesijnou identitou. Kritika kódu potom znie, akoby kritizovali vás. V tíme, ktorý zdieľa kontext, je tá istá poznámka len vecná: „Takto je to lepšie, poďme to zmeniť."

Čo sa zmení, keď tím vlastní celú funkciu

Craig Larman a Bas Vodde stavajú proti sebe feature tímy a komponentové tímy: feature tím je postavený okolo ucelených zákazníckych funkcií (end-to-end), nie okolo technických vrstiev. Podstatnejšie však je, čo každý tím vlastní. To mení, čo znamená zlyhanie, čo riskuje zmena a ako ďaleko siaha.

Komponentový tím vlastní časť: platobnú službu, API vrstvu. Úspech znamená, že časť drží svoj kontrakt, takže aj zlyhanie je lokálne: pokazil sa môj komponent. Zákaznícka funkcia siaha cez množstvo častí, a tak môže pre používateľa zlyhať, hoci každý komponent svojimi testami prejde. To zlyhanie potom nevlastní nikto. Riziko zmeny sa meria voči časti, nie voči zákazníkovi, a zodpovednosť udržať ho na uzde padá na jediného človeka, ktorý vidí za hranicu časti. Ownership sa zúži na neho. Bránou je „Nehrab mi do kódu".

Feature tím vlastní výsledok: celú zákaznícku funkciu od začiatku po koniec, cez všetky komponenty, ktorých sa dotkne. Zlyhanie je to, že zákazník ten výsledok nedostane, a vlastní ho tím. Nemá sa za čo schovať, nijaké „moja časť funguje". Keďže tím vlastní celú cestu, ktorou zmena prejde, vidí, kam dopadne. Ownership zostáva pri tíme a nezúži sa na jedného človeka. Potreba brány sa zmenšuje, lebo nikto nie je jediným strážcom kontextu. Konflikt zmení slová: „Poďme na to spolu, ukážem ti kontext."

Nejde o to presviedčať vývojárov, aby boli štedrejší. Nedosiahnete to culture deckom ani sľubom o shared ownershipe. Zmeníte štruktúru tak, aby bolo zdieľanie bezpečnejšie: tím má teraz kontext, vďaka ktorému je zdieľanie produktívne, a nie nebezpečné.

Späť k vyrušenému vývojárovi

Vráťme sa k vývojárovi zo štúdie, k tomu, ktorému sa zlomil tok myšlienok, keď sa mu kód zmenil pod rukami. V komponentovom tíme je také vyrušenie skutočná škoda. Niekto upravil kód, o ktorom mal predstavu, a o tú predstavu sa nedelili. On musí zrekonštruovať, čo mali na mysli oni, a oni zasa, čo mal na mysli on. Tú zrážku pripravila štruktúra.

Dajte toho istého vývojára do feature tímu a zážitok sa zmení, hoci na praktike sa nezmenilo nič. Kód, ktorý sa zmenil, nie je cudzí, lebo ho tím staval spoločne. Vyrušenie nie je trhlina, lebo kontext už bol zdieľaný. Ten istý človek. Tá istá chvíľa, keď je v kóde niekto iný. Iná štruktúra, iný výsledok.

„Nehrab mi do kódu" nie je priznanie ega. Je to meranie. Hovorí vám, koľko kontextu žije v jednom človeku a ako málo z neho je zdieľané. Riešením nikdy nebolo donútiť vývojárov, aby to hovorili menej často. Riešením je zmeniť štruktúru, ktorá im dáva dôvod to povedať.

Keď to nabudúce počujete, nepýtajte sa, kto má viac spolupracovať. Opýtajte sa, čo ich štruktúra prinútila chrániť.

Zdroje

Read in English →

Ako to vyzerá v skutočnej organizácii →

Všetky články →