Od začiatku roka 2018 som hlavným vývojárom tímu – nazvite to ako chcete, ale podstata je, že som výlučne zodpovedný za jeden modul a všetkých vývojárov, ktorí na ňom pracujú. Táto pozícia mi dáva nový pohľad na proces vývoja, keďže sa zapájam do viacerých projektov a aktívnejšie sa podieľam na rozhodovaní. Nedávno som si vďaka týmto dvom okolnostiam zrazu uvedomil, aký veľký vplyv majú poznatky na kód a aplikáciu.
Snažím sa zdôrazniť, že kvalita kódu (a konečného produktu) úzko súvisí s tým, ako dobre ľudia, ktorí kód navrhujú a píšu, rozumejú tomu, čo robia.
Pravdepodobne si myslíte: „Ďakujem, kapitán. Samozrejme, je dobré rozumieť tomu, čo vlastne píšete. Inak si rovno najmete kopu opíc, aby stláčali náhodné klávesy a skončili.“ A máte úplnú pravdu. Preto súhlasím s tým, že chápete, že základné pochopenie toho, čo robíte, je nevyhnutné. Toto by sa dalo nazvať pochopením na nulovej úrovni a nebudeme sa tým podrobne zaoberať. Budeme sa venovať detailom toho, čo presne potrebujete pochopiť a ako to ovplyvňuje rozhodnutia, ktoré robíte každý deň. Keby som tieto veci vedel vopred, ušetrilo by mi to veľa strateného času a pochybného kódu.
Aj keď nižšie neuvidíte ani jeden riadok kódu, stále si myslím, že všetko, čo som tu povedal, je dôležité pre písanie kvalitného a expresívneho kódu.
Prvá úroveň porozumenia: Prečo to nefunguje?
Vývojári zvyčajne dosiahnu túto úroveň veľmi skoro vo svojej kariére, niekedy dokonca bez akejkoľvek pomoci od iných – aspoň podľa mojej skúsenosti. Predstavte si, že ste dostali hlásenie o chybe: nejaká funkcia v aplikácii nefunguje a je potrebné ju opraviť. Čo by ste urobili?
Štandardný diagram vyzerá takto:
- Nájdite časť kódu, ktorá spôsobuje problém (ako to urobiť, je samostatná téma, ktorej sa venujem vo svojej knihe o staršiom kóde).
- Vykonajte zmeny v tomto fragmente
- Uistite sa, že chyba je opravená a že sa nevyskytujú žiadne chyby regresie
Teraz sa zamerajme na druhý bod – vykonávanie zmien v kóde. K tomuto procesu existujú dva prístupy. Prvým je ponoriť sa do toho, čo sa deje v aktuálnom kóde, identifikovať chybu a opraviť ju. Druhým je postupovať podľa pocitu – pridať napríklad +1 k podmienenému príkazu alebo slučke, zistiť, či táto funkcia funguje v požadovanom scenári, potom vyskúšať niečo iné a tak ďalej donekonečna.
Prvý prístup je správny. Ako vysvetľuje Steve McConnell vo svojej knihe Code Complete (ktorú mimochodom vrelo odporúčam), vždy, keď v kóde niečo zmeníme, mali by sme byť schopní s istotou predpovedať, ako to ovplyvní aplikáciu. Citujem z pamäte, ale ak oprava chyby nefunguje podľa očakávaní, mali by ste byť veľmi opatrní a spochybniť celý svoj plán.
Stručne povedané, na implementáciu dobrej opravy chyby, ktorá nezníži kvalitu kódu, musíte pochopiť celú štruktúru kódu aj zdroj konkrétneho problému.
Druhá úroveň porozumenia: Prečo to funguje?
Táto úroveň je oveľa menej intuitívna na pochopenie ako predchádzajúca. Ako začínajúci vývojár som sa ju naučil od svojho šéfa a následne som ju nováčikom pri mnohých príležitostiach sám vysvetľoval.
Tentoraz si predstavme, že ste dostali dve hlásenia o chybách: prvé sa zaoberá scenárom A, druhé scenárom B. V oboch scenároch sa niečo pokazí. Takže najprv riešite prvú chybu. Pomocou princípov, ktoré sme načrtli pre úroveň 1 porozumenia, sa ponoríte hlbšie do príslušného kódu, zistíte, prečo spôsobuje, že sa aplikácia správa tak, ako sa správa v scenári A, a vykonáte primerané úpravy, ktoré vedú k požadovaným výsledkom. Všetko ide dobre.
Potom prejdete na scenár B. Zopakujete scenár v snahe spustiť chybu, ale – prekvapenie! – všetko teraz funguje podľa očakávania. Aby ste potvrdili svoju domnienku, vrátite späť zmeny, ktoré ste urobili pri práci na chybe A, a chyba B sa vráti. Vaša oprava chyby vyriešila oba problémy. Máte šťastie!
S týmto ste vôbec nepočítali. Prišli ste na spôsob, ako opraviť chybu v scenári A, a netušíte, prečo to fungovalo aj v scenári B. V tomto bode je lákavé predpokladať, že obe úlohy sú úspešne dokončené. Dáva to dokonalý zmysel: cieľom bolo opraviť chyby, však? Ale práca ešte nekončí: stále musíte zistiť, prečo vaše kroky opravili chybu v scenári B. Prečo? Pretože by mohol fungovať na nesprávnych princípoch a potom budete musieť nájsť iné riešenie. Tu je niekoľko príkladov:
- Keďže riešenie nebolo špecificky prispôsobené chybe B, berúc do úvahy všetky faktory, je možné, že ste nevedomky porušili funkciu C.
- Je možné, že niekde sa skrýva tretia chyba súvisiaca s tou istou funkciou a vaša oprava chyby bráni systému v správnom fungovaní v scenári B. Teraz vyzerá všetko v poriadku, ale jedného dňa si túto tretiu chybu všimnú a opravia. Potom sa chyba znova objaví v scenári B a dúfajme, že už len tam.
Toto všetko vnáša do kódu chaos a nakoniec vám to spadne na hlavu – s najväčšou pravdepodobnosťou v tej najnevhodnejšej chvíli. Budete musieť zozbierať silu vôle, aby ste sa prinútili venovať čas pochopeniu toho, prečo sa zdá, že všetko funguje, ale stojí to za to.
Tretia úroveň porozumenia: Prečo to funguje?
Môj nedávny vhľad súvisí práve s touto úrovňou a pravdepodobne je to práve táto úroveň, ktorá by mi poskytla najviac výhod, keby som na túto myšlienku prišiel skôr.
Aby sme to objasnili, pozrime sa na príklad: váš modul musí byť kompatibilný s funkciou X. Nie ste s funkciou X veľmi oboznámení, ale bolo vám povedané, že na to, aby ste s ňou boli kompatibilní, musíte použiť framework F. Ostatné moduly, ktoré sa integrujú s X, fungujú s frameworkom F.
Váš kód nemal od prvého dňa žiadny kontakt s F-frameworkom, takže jeho implementácia nebude jednoduchá. To bude mať vážne následky pre niektoré komponenty modulu. Napriek tomu sa vrhnete do vývoja: kódujete celé týždne, testujete, zavádzate pilotné verzie, získavate spätnú väzbu, opravujete regresie, objavujete neočakávané komplikácie, zmeškáte pôvodný termín, píšete ďalší kód, testujete, získavate spätnú väzbu, opravujete regresie – to všetko kvôli implementácii F-frameworku.
A v určitom okamihu si zrazu uvedomíte – alebo možno sa o tom dozviete od niekoho – že framework F vám možno nakoniec neposkytne kompatibilitu s funkciou X. Možno všetok ten čas a úsilie ste vynaložili na nesprávnu vec.
Niečo podobné sa raz stalo pri práci na projekte, za ktorý som bol zodpovedný. Prečo? Pretože som mal slabé znalosti o funkcii X a o tom, ako súvisí s frameworkom F. Čo som mal urobiť? Požiadajte osobu, ktorá zadávala úlohu vývoja, aby jasne vysvetlila, ako navrhovaný postup vedie k požadovanému výsledku, namiesto toho, aby ste jednoducho opakovali to, čo sa urobilo pre iné moduly, alebo aby ste im verili, že je to nevyhnutné pre fungovanie funkcie X.
Skúsenosť s týmto projektom ma naučila odmietnuť začať proces vývoja, kým nebudeme mať jasnú predstavu o tom, prečo sa od nás žiada, aby sme vykonali určité akcie. Okamžite odmietnite. Keď dostanete úlohu, vaším prvým impulzom je okamžite sa jej pustiť, aby ste nestrácali čas. Ale politika „zmrazenia projektu, kým nepochopíme všetky detaily“ môže znížiť stratený čas o rády.
Aj keď sa vás snažia presvedčiť, aby ste začali pracovať, aj keď nerozumiete dôvodu, odolajte. Najprv zistite, prečo vám dávajú takúto úlohu, a rozhodnite sa, či je to správna cesta k jej dosiahnutiu. Toto všetko som sa naučil tvrdo – dúfam, že môj príklad uľahčí život tým, ktorí toto čítajú.
Štvrtá úroveň porozumenia: ???
V programovaní sa vždy niečo učí a myslím si, že som len poškriabal povrch pochopenia. Aké ďalšie vrstvy pochopenia ste objavili počas rokov programovania? Aké rozhodnutia ste urobili, ktoré mali pozitívny vplyv na kvalitu vášho kódu a aplikácie? Ktoré rozhodnutia sa ukázali ako nesprávne a naučili vás cenné lekcie? Podeľte sa o svoje skúsenosti v komentároch.
Zdroj: hab.com
