Duševně upřímný programátor

Rád hledám charakteristiky, které popisují dobrého programátora nezávisle na konkrétních technologiích a programovacích jazycích. V knize Code Complete od Steva McConnella jsem narazil na skvělou pasáž, která se věnuje povahovým vlastnostem dobrého vývojáře. Rád bych se zastavil u jedné z nich. U duševní upřímnosti. Musím uznat, že jsem si během své vývojářské praxe prošel většinou nešvarů pramenících z jejího nedostatku. Některé odstraňuji dokonce doteď. :)

Nebuďte falešný expert

Pokud máte dostatek duševní upřímnosti, nesnažíte se působit jako expert, pokud jím v dané oblasti nejste. Jedná se o jakousi intelektuální skromnost, díky které se budete lépe rozvíjet. Je vhodnější přiznat, že s danou technologií nemáte dostatek zkušeností, že danou část frameworku neznáte, že si nejste jistí určitou definicí. Pokud přistupujete k problému s vědomím, že umíte spíše méně, je pro vás přirozenější naslouchat ostatním a tím se více učit.

Zkuste si kvantifikovat při každé otázce, jakou úroveň jistoty v ní máte. Pozor, pokud často dosahujete ve svých očích 100%, zbystřete. Může se jednat o narcismus! :)

Přiznejte se k chybě

Duševně upřímný programátor se k chybě přizná rychle a rozhodně. Postaví se k ní chlapsky (programátorky prominou) čelem. Kroutit se a obhajovat chybu je zbabělé. Někdo si dokonce myslí, že když chybu nepřizná, okolí si bude myslet, že není jeho. :) Nefér přístup k řešení chyby může dojít až tak daleko, že dotyčný získá pověst pyšného a přezíravého programátora. A takové pověsti je pak těžké se zbavit.

Udělat chybu není ostuda. Pokud však není způsobena nedůsledností. Každopádně je nutné se vždy z chyby poučit a přijmout opatření, aby se neopakovala.

Neignorujte varování

Oblíbeným sportem je ignorování warningů při sestavování aplikace. Přehlížíme varování, která mohou způsobit v budoucnu velké problémy. Častokrát hledáme přičiny problémů v aplikaci a přehlížíme, že nám překladač mává signalizačními tyčemi přímo před očima. Nedostatek duševní upřímnosti se zde projevuje naší bohorovností v přehlížení varování. "To neděláš dobře s těmi sirkami, Jaromíre!" :)

Snažte se dobře porozumět svému programu

"Zkusím si spustit program, abych vůbec pochopil, jak to tam dělám." A metodou pokusů a omylů a s využitím debuggeru zjišťujeme, jak náš vlastní program pracuje. Prostě mu nerozumíme. Přičin může být mnoho - nečitelný kód s vysokým stupněm složitosti, chybějící jednotkové testy s dokumentační funkcí, výpadky paměti, apod.

Pokud si připustíte, že programu nerozumíte a je potřeba zahájit nápravná opatření, jste na dobré cestě. Pusťte se do vylepšení návrhu, zlepšení čitelnosti, pokrytí testy. Prostě zvyšujte jednotlivá kritéria vnitřní kvality kódu. Jedině s tímto přístupem napíšete příští kód v lepší kvalitě již napoprvé.

Informujte reálně o aktuálním stavu

Nestíháte, ale nechcete to přiznat? Říkáte vedoucímu raději to, co by chtěl slyšet, místo objektivní skutečnosti? Pak dostáváte do problémů nejen sebe, ale právě i vedoucího. Jeho zodpovědností je řídit projekt a pokud je informován špatně, dělá špatná rozhodnutí. Pokud byste včas přiznali, že máte problémy, například že vám z objektivních příčin klesá produktivita, dobrý projekťák se vám vždy bude snažit pomoci.

Většina agilních vývojových metodologií napomáhá tomu, aby se informace o problémech a překážkách v postupu projektu dostaly co nejefektivněji od členů týmu k vedoucímu. Informujte o problémech na denních scrum schůzkách nebo i dříve. Buďte aktivní v řešení vyvstalých problémů. Vaše upřímnost bude oceněna a získáte v očích ostatních větší kredit.

Dávejte realistické časové odhady a buďte neústupní

Představte si, že jste požádáni o odhad pracnosti nové funkcionality. Pohovoříte s kolegy, sečtete jednotlivé odhady a dodáte celkové číslo. Vedení se vyleká a přitlačí vás, abyste udělali "lepší" a hlavně nižší odhad. Pokud půjdete přes svoje přesvědčení a magicky snížíte odhad, aniž byste definovali jaké ústupky musíte udělat, je to zle. Lžete opět sami sobě a necháváte se přitlačit do kouta. V případě realizace byste se zřejmě dostali do časového presu, následného stresu a včasné dokončení projektu může být ohroženo.

Trvat na svém se musí každý vývojář naučit. Málokdo to umí už od začátku. S postupným získáváním praxe se přesnost odhadů zlepšuje. Vysvětlete vedení, že fyzikální zákony (konkrétně časové) ještě měnit nedokážete a případné kompromisy by byly podobně špatné. Pokud je projekt pro vaši firmu zajímavý, můžete dát zákazníkovi samozřejmě nižší cenu, aby do projektu šel. Ale interně si v týmu nic nenalhávejte. Neupřímnost ničí pracovní vztahy.

Společné vlastnictví kódu

... nejvyšší forma týmové spolupráce

Franta je na dovolené, proto si musí zákazník počkat tři týdny na opravu komponenty.
Vím, že je kód této třídy ve špatné kvalitě, ale není to můj problém. Obrať se na autora!
Už teď se mi při pomyšlení na refaktoring Robertova kódu dělá špatně! Tohle po mně vážně nechtěj!
Jsem specialista na UI a nebudu zasahovat Martinovi do kódování middleware.
Ludva se otrávil methylalkoholem a oslepl. Bude trvat týdny, než to někdo převezme.

Pokud se váš vývojový tým dostává do podobných situací, zřejmě by vám pomohlo praktikování společného vlastnictví kódu (Collective Code Ownership). Jedná se o jednu z technik metodiky extrémního programování (XP). Jednoduše by se dalo CCO definovat takto:

"Všichni sdílí zodpovědnost za kvalitu kódu. Každý může udělat změnu v jakékoli části kódu. Od všech se očekává, že odstraní problémy, na které v kódu narazí."

Pojďme se podívat, jakou přidanou hodnotu nám společné vlastnictví přináší.

Vyšší kvalita kódu

V socialismu se kolektivní vlastnictví příliš neosvědčilo. Ve výsledku všechno patřilo všem a nikomu a stav věcí podle toho vypadal. Vývojový tým je však specifická struktura, která při správném vedení a správných charakterových vlastnostech jejich členů, dosahuje spoluprácí vyšší výkonnosti. Skupinová zodpovědnost vede k tomu, že vývojáři usilují společně o vysokou kvalitu kódu. Špatný kód napsaný kolegou je i můj špatný kód. Kolega by měl pod závazkem společného kódu cítit větší zodpovědnost a snažit se o potřebnou kvalitu. Já bych naopak měl na nekvalitní kód upozornit a nebo jej přímo zlepšit. Třeba refaktoringem nebo vylepšením návrhu.

Pokud je váš kód zveřejňován a běžně posuzován jinými lidmi, zvyšuje se vaše motivace ke kvalitnější práci. Profesionální vývoj software je o osvojení správných návyků. Nad návyky nepřemýšlíte, děláte je automaticky. Pokud jste junior vývojář, bude pro vás práce v týmu s CCO obrovskou školou. Na druhou stranu někteří senior vývojáři mohou mít problém s tím, že někdo jiný jim vidí do kódu a navíc si ho dovoluje měnit! Považují svůj kód za natolik intimní záležitost, že si ji brání jako poklad. Někdy je to také z důvodu, že jejich kód je nečitelný, tedy špatný a sami to vědí.

Poznámka: Mezi atributy externí kvality kódu patří bezchybnost, použitelnost, efektivita, spolehlivost, integrita, přizpůsobivost, přesnost a robustnost. Mezi atributy interní kvality kódu patří udržovatelnost, flexibilita, přenositelnost, znovupoužitelnost, čitelnost, testovatelnost, srozumitelnost.

Vzájemná zastupitelnost

Tradičním problémem vývojových týmů je koncentrace znalostí pouze u konkrétních lidí. Autor komponenty je jediný, kdo zná její kód a pro ostatní se jedná o černou skříňku. Někomu pocit nepostradatelnosti může dělat dobře, ale pro flexibilitu vývoje je to špatně. Dovolená, nemoc nebo jiná absence zablokuje práce na komponentě na dlouhou dobu. Úplná ztráta člena týmu pak může způsobit katastrofu.

Společné vlastnictví kódu tyto problémy řeší poměrně efektivně. Dobrá znalost codebase je dovedností každého člena týmu. Oprava chyby, doplnění funkcionality nebo jiný zásah do kódu někým jiným než autorem? Není problém. Ty máš čas, tak to prosím udělej.

Co vlastně potřebujeme?

Společné vlastnictví kódu nelze efektivně aplikovat bez dalších podpůrných technik XP. Jinak se výsledek může významně lišit od našeho očekávání.

Vývojáři si musejí rozumět. Jejich kód musí být vzájemně snadno pochopitelný. Je nutné zavést jednotný kódovací styl (Coding style). Měly by se ctít zásady čistého kódu (Clean Code) a jednoduchého návrhu (Simple Design). Vysoká čitelnost kódu je zásadní požadavek na práci profesionálního vývojáře. V případě CCO je jeho důležitost ještě umocněna.

Kvalita existujícího kódu je přírůstkově vylepšována postupným refaktoringem (Refactoring). Refaktoring úzce souvisí s pokrytím kódu pomocí testů. XP aplikuje metodiku testy řízeného vývoje (Test-Driven Development). Bez správného pokrytí kódu jednotkovými testy se nedá CCO použít. Vycházíme-li z definice CCO, kdy každý má právo a povinnost kód vylepšit (refaktorovat) a rozšířit, je regresní funkce jednotkových testů nenahraditelná. Pokud by testy nad kódem nebyly, každý by se bál do stávajícího kódu zasáhnout.

Další úrovní zajištění je technika postupné integrace (Continuous Integration). Po každém promítnutí změny v kódu do společného prostoru je proveden kontrolní serverový integritní build, jehož součástí by mělo být i spuštění jednotkových testů. V případě zanesení problémů je autor změny ihned vyzván k opravě. Touto technikou je zajištěna integrační validita kódu na týmovém serveru.

Tým by měl používat verzovací systém (Version Control) pro správu zdrojového kódu s podporou vícenásobného checkoutu. Při CCO dochází častěji k situaci, kdy více uživatelů v jednom období edituje lokálně stejný objekt. Systém by měl mít kvalitní nástroj pro následné slučování změn. Doporučuje se u existujícího kódu dělat úpravy menšího rozsahu a tím pádem častěji vracet změny na server.

Efektivní podpůrnou technikou je párové programování (Pair Programming). Programování ve dvojicích zlepšuje komunikaci, urychluje šíření znalostí v týmu, díky online revizím návrhu a kódu zvyšuje výslednou kvalitu. Většina kombinací [nováček|pokročilý|expert]{2} je ve výsledku efektivní, kromě nováček + nováček - mentor. Páry by se měly měnit a je nutné vytvořit unifikované programové prostředí u všech párovačů. Není nutno párovat po celou dobu práce.

Rizika

Nedostatečná znalost problematiky jednoho z členů týmu může způsobit problematický zásah do existujícího kódu. Jako pojistky máme jednotkové testy, které by zároveň měly dokumentovat návrh příslušné části systému. V případě, že znalosti člena týmu jsou špatné, mohlo by zabrat nasazení párového programování.

Nikdo se nehlásí k zodpovědnosti za daný kód (No Code Ownership). Takového rizika se mohou obávat především projektoví manažeři. Všem zúčastněným musí být zřejmé, že zodpovědnost za každou část leží na celém týmu. Postoje typu "Já mám svůj kód v pořádku a tento mě nezajímá" je potřeba eliminovat.

Nedodržení souvisejících agilních technik oslabí výhody CCO a možná jej úplně zabije. Je na zodpovědnosti vedoucího týmu, aby zajistil vytvoření a provoz správně nastaveného agilního prostředí.

Alternativy

Pokud se codebase striktně rozdělí podle členů týmu a vzájemně si do kódu nezasahují, mluvíme o silném vlastnictví (Strong Code Ownership). Méně striktní je slabé vlastnictví (Weak Code Ownership). Kód je stále rozdělen podle správců jednotlivých komponent, ale jiný člen týmu může po svolení od správce kód změnit.

Závěrem

Pro malé a agilně řízené týmy se jeví CCO jako přirozené řešení požadavků na kvalitu a zastupitelnost. U korporátních neagilně řízených týmů by se na propagátora CCO mohli dívat jako na Marťana, můžete to zkusit. :) Pokud pro vás není agilita sprosté slovo, určitě stojí za to se nad dopady CCO zamyslet.

Rád bych článek doplnil o nějaké praktické postřehy, ale ve firmě se nám zatím nepodařilo vytvořit dostatečné prostředí pro provozování společného vlastnictví kódu. Výhody jsou zřejmé a rádi bychom stávající slabé vlastnictví přetransformovali na společné. Pokud máte vlastní zkušenost, prosím o připojení komentáře. Děkuji.

Zdroje

The Art of Agile Development: Collective Code Ownership - můžete si přečíst odpovědi na otázky, které zřejmě vznese každý, kdo o přechodu na CCO uvažuje.