Od začátku roku 2018 zastávám pozici vedoucího/šéfa/hlavního vývojáře v týmu — říkejte tomu, jak chcete, ale podstata je ta, že jsem plně zodpovědný za jeden z modulů a za všechny vývojáře, kteří na něm pracují. Tato pozice mi otevírá nový pohled na proces vývoje, protože jsem zapojen do většího počtu projektů a aktivněji se podílím na rozhodování. Nedávno jsem díky těmto dvěma okolnostem neočekávaně pochopil, jak silně měra porozumění ovlivňuje kód a aplikaci.
Myšlenka, kterou chci vyjádřit, spočívá v tom, že kvalita kódu (a konečného produktu) úzce souvisí s tím, jak si lidé, kteří se podílejí na návrhu a píší kód, uvědomují, co vlastně dělají.
Možná si nyní říkáte: «Děkuji, kapitáne. Samozřejmě by nebylo špatné rozumět tomu, co vlastně píšete. Jinak bychom mohli stejně tak najmout skupinu opic, aby mlátili do náhodných kláves a tím to ukončili.» A máte zcela pravdu. Přijímám tedy jako samozřejmost, že si uvědomujete, že mít obecné povědomí o tom, co děláte, je nezbytné. To bychom mohli nazvat nulovou úrovní porozumění a tu nebudeme podrobně rozebírat. Podrobně se budeme věnovat tomu, co je potřeba chápat a jak se to odráží na rozhodnutích, která každý den přijímáte. Kdybych tyto věci znal předem, ušetřilo by mi to spoustu času a nejistého kódu.
I když níže neuvidíte ani jeden řádek kódu, stále si myslím, že vše, co zde bylo řečeno, má velký význam pro psaní kvalitního, výstižného kódu.
První úroveň porozumění: Proč to nefunguje?
Na tuto úroveň obvykle vývojáři přicházejí na samém počátku své kariéry, někdy dokonce i bez jakékoli pomoci z okolí — alespoň podle mých pozorování. Představte si, že jste dostali zprávu o chybě: nějaká funkce v aplikaci nefunguje, je třeba ji opravit. Jak budete postupovat?
Standardní schéma vypadá takto:
- Najít fragment kódu, který způsobuje problém (jak se to dělá — to je samostatné téma, které rozebírám ve své knize o zastaralém kódu)
- Provést změny v tomto fragmentu
- Ujistěte se, že chyba byla opravena a nevznikly žádné regresní chyby.
Nyní se zaměříme na druhý bod - provedení změn v kódu. Existují dva přístupy k tomuto procesu. První: pochopit, co přesně se děje v aktuálním kódu, identifikovat chybu a opravit ji. Druhý: postupovat metodou pokusu a omylu - přidat třeba +1 do podmínkového příkazu nebo cyklu, podívat se, jestli funkce nefunguje ve správném scénáři, pak zkusit něco dalšího a tak dále do nekonečna.
Správný přístup je první. Jak vysvětluje ve své knize Code Complete Steve McConnell (mimochodem, velmi ji doporučuji), každýkrát, když něco měníme v kódu, musíme být schopni s jistotou předpovědět, jak to ovlivní aplikaci. Cituji z paměti, ale pokud oprava chyby nefunguje tak, jak očekáváte, mělo by vás to velmi znepokojit, měli byste zpochybnit celý svůj plán.
Shrneme-li, k tomu, abychom provedli kvalitní opravu chyby, která nezhorší kvalitu kódu, musíme rozumět nejen celé struktuře kódu, ale i zdroji konkrétního problému.
Druhý stupeň porozumění: Proč to funguje?
Tento stupeň se dosahuje mnohem méně intuitivně než předchozí. Když jsem byl ještě začínajícím vývojářem, osvojil jsem si ho díky svému vedoucímu a později jsem opakovaně vysvětloval podstatu věci nováčkům.
Tentokrát si představte, že vám dorazily najednou dva bug reporty: v prvním se jedná o scénář A, ve druhém - o scénář B. V obou scénářích se něco neděje tak, jak má. Odpovídajícím způsobem se nejprve pustíte do prvního bugu. Řídíte se principy, které jsme vyvodili pro první úroveň porozumění, a pečlivě se zabýváte kódem souvisejícím s problémem, zjišťujete, proč způsobuje, že se aplikace chová tak v scénáři A, a provádíte rozumné úpravy, které přinesou ten výsledek, který očekáváte. Všechno jde skvěle.
Poté se přesuňte k scénáři B. Opakujete scénář, abyste se pokusili vyvolat chybu, ale - překvapení! - nyní všechno funguje, jak má. Abychom potvrdili svou domněnku, vrátíte zpět změny provedené během práce na chybě A, a chyba B se znovu objeví. Vaše oprava chyby vyřešila oba problémy. Měli jste štěstí!
Toto rozhodně nebylo něco, na co jste spoléhal. Vymysleli jste způsob, jak opravit chybu ve scénáři A, a nemáte tušení, proč fungoval i pro scénář B. V této fázi je velmi silné pokušení rozhodnout se, že obě úlohy byly úspěšně splněny. To dává smysl: cílem bylo přece odstranit chyby, že? Ale práce ještě není hotová: musíte se ještě vypořádat s tím, proč vaše akce opravily chybu ve scénáři B. Proč? Protože možná funguje na nesprávných principech, a pak budete muset hledat jiné řešení. Tady je pár příkladů takových případů:
- protože řešení nebylo cíleně přizpůsobeno chybě B se zohledněním všech faktorů, možná jste, aniž byste to tušili, rozbili funkci C.
- nelze vyloučit, že někde se skrývá ještě třetí chyba související se stejnou funkcí, a vaše opravy chyby způsobují, že systém ve scénáři B funguje na ní. Teď to vypadá dobře, ale jednoho dne si této třetí chyby někdo všimne a opraví ji. Pak ve scénáři B opět vznikne chyba, a to by bylo dobré jen tam.
To vše vnáší do kódu chaotičnost a jednoho dne vám to spadne na hlavu — pravděpodobně v nejméně vhodnou chvíli. Budete muset sebrat odvahu, abyste si dali čas na pochopení toho, proč vše na první pohled funguje, ale stojí to za to.
Třetí úroveň porozumění: Proč to funguje?
Moje nedávné osvětlení souvisí právě s touto úrovní a pravděpodobně by mi přineslo nejvíce výhod, kdybych na tuto myšlenku přišel dříve.
Aby to bylo jasnější, podívejme se na příklad: váš modul musí být kompatibilní s funkcí X. Nejste s funkcí X příliš blízko seznámeni, ale bylo vám řečeno, že pro kompatibilitu s ní musíte používat rámec F. Ostatní moduly, které se integrují s X, přesně s ním pracují.
Váš kód od prvního dne své existence vůbec nekomunikoval s rámcem F, a proto jeho implementace nebude vůbec jednoduchá. To povede k vážným důsledkům pro některé komponenty modulu. Nicméně, ponořujete se do vývoje: týdny píšete kód, testujete, vydáváte pilotní verze, získáváte zpětnou vazbu, opravujete regresní chyby, objevujete neplánované komplikace, nestíháte původně stanovené termíny, píšete další kód, testujete, získáváte zpětnou vazbu, opravujete regresní chyby — to vše za účelem implementace rámce F.
A v jednu chvíli si najednou uvědomíte — nebo možná slyšíte od někoho — že rámec F vám možná vůbec neposkytne kompatibilitu s funkcí X. Možná, že veškerý váš čas a úsilí byly věnovány zcela něčemu jinému.
Něco podobného se jednou stalo během práce na projektu, za který jsem byl odpovědný. Proč k tomu došlo? Protože jsem špatně chápal, v čem spočívá funkce X a jak souvisí s rámcem F. Jak jsem měl postupovat? Požádat osobu, která zadává úkol do vývoje, aby srozumitelně vysvětlila, jak plánované kroky vedou k žádoucímu výsledku, místo aby se jen opakovalo to, co bylo děláno pro jiné moduly, nebo věřilo na slovo, že to tak musí být pro funkci X.
Zkušenost tohoto projektu mě naučila odmítat začínat proces vývoje, dokud nemáme jasné porozumění tomu, proč nás žádají o určité úkony. O odmítání přímo a bez obalu. Když dostanete úkol, prvním impulsem je okamžitě se do něj pustit, abyste neztráceli čas. Ale politika "zmrazit projekt, dokud se neprozkoumá všechno do detailů" může ušetřit čas, který by jinak byl promrhán, o celé řády.
I když na vás někdo tlačí a snaží se vás přimět, abyste začali pracovat, přestože nechápete, na čem to je založeno — odolávejte. Nejprve si ujasněte, s jakým cílem vám tento úkol dávají, a rozhodněte se, zda je to správná cesta k cíli. Musel jsem se to všechno naučit na hořkých zkušenostech — doufám, že mému příkladu zpřístupní život těm, kteří to čtou.
Čtvrtá úroveň porozumění: ???
V programování se vždy je co naučit, a domnívám se, že jsem se dotkl jen nejzákladnějších vrstev tématu porozumění. Jaké další úrovně porozumění jste objevili za roky práce s kódem? Jaká rozhodnutí měla pozitivní dopad na kvalitu kódu a aplikace? Která rozhodnutí se ukázala jako chybná a dala vám cennou lekci? Podělte se o své zkušenosti v komentářích.
Zdroj: habr.com
