Ideál­ní frekvence: půl hodiny. Pro­ti kon­flik­tům i zbytečné dřině fun­gu­je trunk-based development

Běž­nou praxí ve vývo­ji je, že když pro­gramá­tor začíná novou fea­ture, jako první pro ni vytvoří takz­vanou fea­ture větev, tedy jak­ousi alter­na­tivní časovou linii kódu. Důvo­dem je bezpečnost – v této sep­a­ré větvi si může dělat, co chce, aniž by to ovlivni­lo hlavní kód. Velice čas­to se ten­to příst­up používá u open-source soft­waru, který něko­lik lidí udržu­je a bezpočet lidí z celého svě­ta do něj přispívá.

Tyto pro­gramá­to­ry neznáte, pro­to je výhod­né, aby své příspěvky vytvářeli odd­ěleně, a když svou funkcional­i­tu chtějí při­dat, vytvoří takz­vaný pull request, tedy poža­dav­ek na připo­jení vytvořeného kódu do hlavního. Proběhne kon­tro­la, připomínkování. U open-source to fun­gu­je skvěle, pro­tože do něj může přis­pí­vat kdokoli.

Horší je to ale u aplikací vyví­jených in-house. Pokud se na vývo­ji podílí větší počet pro­gramá­torů, vzniká takových alter­na­tivních realit mno­ho najed­nou. A každý dobrý pro­gramá­tor si do své alter­na­tivní real­i­ty kon­tin­uál­ně přibírá tu hlavní větev, aby měl neustále aktuál­ní novinky.

Pokud to však tak­to fun­gu­je něko­lik týd­nů, vytratí se přehled o tom, co se v jed­notlivých větvích vyvíjí. A ve chvíli, kdy se fea­ture do hlavního kódu při­pustí, hrozí, že se celá řada věcí rozsype. Dlouho to trvá a dochází ke kon­flik­tům – napřík­lad se na tomtéž řád­ku sej­dou dva pro­gramá­toři a musí se dohod­nout, který z jejich dvou kódů se použi­je, pro­tože oba pra­co­v­ali na tomtéž posled­ní dva týd­ny. A dalších deset lidí pra­co­v­a­lo odd­ěleně dva týd­ny. To skýtá obrovský pros­tor k chao­su a chybám.

Přit­om je to zcela zbytečné. Stačí všech­ny tyto alter­na­tivní real­i­ty do hlavního kódu přidá­vat čas­to, tře­ba kaž­dou půl­hod­inu či hodinu.

Jiný­mi slovy, alter­na­tivní kód leží pro­gramá­torovi v jeho počí­tači, kde se o něm nikdo další nedozví, poměrně krátk­ou dobu. A když se potká víc pro­gramá­torů nad ste­j­nou obra­zovk­ou, tří­dou, tab­ulk­ou nebo funkčnos­tí, což je napros­to běžné, všich­ni se o tom dozvědí okamžitě. Jistě, v tu chvíli to člově­ka zdržu­je, pro­tože se musí zved­nout ze židle, druhého pro­gramá­to­ra najít a vyřešit to s ním. Ovšem je to daleko efek­tivnější, než když se potkáme jed­nou za dva týd­ny a alter­na­tivních kódů je tam celá hro­ma­da, kter­ou něko­lik pro­gramá­torů vytvoři­lo za deset dnů práce.

Řešit kon­flik­ty jed­nou za takhle dlouhý čas je neskonale náročnější a zdlouhavější. A právě tohle je trunk-based devel­op­ment. Označení pochází od toho, že hlavní větvi kódu se dříve říka­lo trunk, tedy kmen.

Jed­ná se o meto­du tech­nicko-sociál­ní. Tech­nická strán­ka spočívá v tom, že se člověk musí naučit pro­gramo­vat tak, aby si mohl dovolit svůj kód nabízet v tak­to krátkých (půl­hodi­nových, hodi­nových) časových inter­valech. Sociál­ní prvek před­stavu­je nut­nost osob­ního setkávání pro­gramá­torů nad část­mi kódu, jimž se aktuál­ně věnují.

Ale co když daná fea­ture není hotová – přece do hlavního kódu nemůžeme dávat nedodělané věci? K tomu slouží pra­porky neboli fea­ture flags, které se použí­va­jí jako varování pro ostat­ní: pozor, tady ještě není hotovo.

Jak­mile se daný kus dokončí, pouze se pra­porek přep­ne a kód je vidět. V trunk-based devel­op­men­tu stačí větši­nou jeden pra­porek. Velké firmy jako Apple, Spo­ti­fy či Net­flix jich ale použí­va­jí celou řadu, jelikož něk­terým svým zákazníkům dají v jed­nu chvíli k testování jed­nu fea­ture, jiným zákazníkům jinou a pak měří jejich zapo­jení, kon­verze, jak čas­to danou funkcional­i­tu použí­va­jí a podobně.

Trunk-based devel­op­ment použí­va­jí všech­ny velké firmy, takže pokud máte na svém tele­fonu aplikaci Spo­ti­fy, jistě v jejím hlavním kódu máte i funkcional­i­ty, které ještě nej­sou úplně hotové, ještě se na nich pracu­je, už ale fig­u­ru­jí v hlavní větvi kódu. Je to výhod­né pro­to, že pokud na ně narazí něk­do z jiného týmu Spo­ti­fy, ví o nich, vidí, na čem něk­do jiný pracu­je, a nečeká, až je něk­do dodělá a uvol­ní – a až za pár týd­nů dojde ke konfliktu.

U velkých soft­warových firem je ten­to příst­up zcela běžný, pro­tože výz­nam­ně šetří čas. Vyžadu­je ovšem vysok­ou autom­a­ti­zaci testování. Kdy­by se inten­zivně netesto­va­lo, jak­mile se do hlavní větve přidá část kódu, nikdo by se nemusel dozvědět o tom, že se něco roz­bi­lo. To platí i pro ty nedodělané části – i ty muse­jí být pokry­ty auto­mat­ick­ý­mi testy. To je jeden před­pok­lad. Druhým je pak schop­nost psát kód tak, aby snesl neho­tové věci. Pokud jsou tyto dva před­pok­la­dy splněny, meto­da všem zúčast­něným výz­nam­ně šetří práci. 

Něco se do kódu v posled­ní (půl)hodině při­da­lo a nefun­gu­je to? Můžeme to vyřešit okamžitě, což je jistě lev­nější než se k tomu dostat za dva týd­ny nebo měsíc. Důvod, proč tato meto­da zatím není moc rozšířená, tkví právě v testech. Pokud má fir­ma velké množství kódu, který není pokry­tý auto­mat­ick­ý­mi testy, celkem oprávněně je k trunk-based devel­op­men­tu skeptická.

Závěrem ještě jed­na výho­da této metody: Pro­gramá­toři čas­to říka­jí, že pull request jim slouží i jako revize nově napro­gramovaného kódu. To se ale dá dělat jinak. Opět je nut­né zved­nout se ze židle, sed­nout si k druhé­mu pro­gramá­torovi a společně pro­jít, co nového udělal. Rov­nou se to zapracu­je, vyladí, oba si řeknou připomínky a shod­nou se na řešení. Je to lep­ší než si tam a zpět pinkat komen­táře v pull reques­tu. Navíc se jeden od druhého učí, jak kód psát lépe.