Od začiatku roka 2018 zastávam v tíme pozíciu lead/boss/lead developer - nazvite si to ako chcete, ale ide o to, že som plne zodpovedný za jeden z modulov a za všetkých vývojárov, ktorí pracujú na ňom. Táto pozícia mi dáva nový pohľad na proces rozvoja, keďže som zapojený do viacerých projektov a aktívnejšie sa zapájam do rozhodovania. Nedávno som si vďaka týmto dvom veciam zrazu uvedomil, ako veľmi miera porozumenia ovplyvňuje kód a aplikáciu.
Chcem povedať, že kvalita kódu (a konečného produktu) úzko súvisí s tým, do akej miery sú si ľudia, ktorí navrhujú a píšu kód, vedomí toho, čo robia.
Možno si práve teraz myslíte: „Ďakujem, Cap. Samozrejme, bolo by fajn pochopiť, čo píšeš vo všeobecnosti. V opačnom prípade by ste si mohli najať skupinu opíc, aby stlačili ľubovoľné klávesy a nechali to tak.“ A máš úplnú pravdu. Preto považujem za samozrejmé, že si uvedomujete, že je potrebné mať všeobecnú predstavu o tom, čo robíte. Toto možno nazvať nulovou úrovňou porozumenia a nebudeme to podrobne rozoberať. Podrobne sa pozrieme na to, č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 jediný riadok kódu, stále verím, že všetko, čo je tu uvedené, má veľký význam pre písanie kvalitného a výrazného kódu.
Prvá úroveň porozumenia: Prečo to nefunguje?
Vývojári zvyčajne dosahujú túto úroveň veľmi skoro vo svojej kariére, niekedy dokonca bez pomoci iných - aspoň podľa mojich skúseností. Predstavte si, že ste dostali hlásenie o chybe: niektorá funkcia v aplikácii nefunguje, treba ju opraviť. Ako budete postupovať?
Štandardná schéma vyzerá takto:
- Nájdite časť kódu, ktorá spôsobuje problém (ako to urobiť, je samostatná téma, venujem sa jej v knihe o starom kóde)
- Vykonajte zmeny v tomto úryvku
- Uistite sa, že chyba je opravená a nevyskytli sa žiadne regresné chyby
Teraz sa sústreďme na druhý bod – vykonávanie zmien v kóde. Existujú dva prístupy k tomuto procesu. Prvým je ponoriť sa do toho, čo sa presne deje v aktuálnom kóde, identifikovať chybu a opraviť ju. Po druhé: pohyb podľa pocitu - pridajte, povedzme, +1 k podmienenému príkazu alebo slučke, zistite, či funkcia funguje v požadovanom scenári, potom skúste 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 veľmi odporúčam), zakaždým, keď niečo v kóde zmeníme, mali by sme byť schopní s istotou predpovedať, ako to ovplyvní aplikáciu. Citujem z pamäte, ale ak oprava chyby nefunguje tak, ako ste očakávali, mali by ste byť veľmi znepokojení a mali by ste spochybniť celý svoj akčný plán.
Aby sme zhrnuli, čo bolo povedané, na vykonanie dobrej opravy chýb, ktorá nezhorší kvalitu kódu, musíte pochopiť celú štruktúru kódu a zdroj konkrétneho problému.
Druhá úroveň porozumenia: Prečo to funguje?
Táto úroveň je chápaná oveľa menej intuitívne ako predchádzajúca. Ja, ešte ako začínajúci vývojár, som sa to naučil vďaka môjmu šéfovi a následne opakovane vysvetľoval podstatu veci nováčikom.
Tentoraz si predstavme, že ste dostali dve hlásenia o chybe naraz: prvé sa týka scenára A, druhé scenára B. V oboch scenároch sa stane niečo zlé. V súlade s tým musíte najskôr vyriešiť prvú chybu. Pomocou princípov, ktoré sme vyvinuli na pochopenie úrovne XNUMX, sa ponoríte hlboko do kódu relevantného pre daný problém, zistíte, prečo sa aplikácia správa tak, ako sa správa v scenári A, a vykonáte primerané úpravy, ktoré prinesú požadovaný výsledok. . Všetko ide skvele.
Potom prejdete na scenár B. Zopakujete scenár v snahe vyvolať chybu, ale – prekvapenie! - teraz všetko funguje ako má. Aby ste potvrdili svoj odhad, zrušte zmeny, ktoré ste vykonali počas práce na chybe A, a chyba B sa vráti. Vaša oprava chyby vyriešila oba problémy. Šťastie!
S týmto si vôbec nerátal. Prišli ste na spôsob, ako opraviť chybu v scenári A a netušíte, prečo to fungovalo pre scenár B. V tejto fáze je veľmi lákavé myslieť si, že obe úlohy boli úspešne dokončené. To je celkom logické: cieľom bolo odstrániť chyby, nie? Ale práca ešte nie je dokončená: stále musíte prísť na to, prečo vaše kroky napravili chybu v scenári B. Prečo? Pretože to môže fungovať na nesprávnych princípoch a potom budete musieť hľadať iné východisko. Tu je niekoľko príkladov takýchto prípadov:
- Keďže riešenie nebolo prispôsobené chybe B, berúc do úvahy všetky faktory, možno ste nevedomky porušili funkciu C.
- Je možné, že niekde číha aj tretia chyba súvisiaca s rovnakou funkciou a vaša oprava chyby závisí od nej pre správne fungovanie systému v scenári B. Všetko teraz vyzerá dobre, ale jedného dňa si túto tretiu chybu všimneme a opravíme. Potom v scenári B sa chyba vyskytne znova a je dobré, ak len tam.
To všetko dodáva kódu chaos a jedného dňa vám spadne na hlavu – s najväčšou pravdepodobnosťou v tú najnevhodnejšiu chvíľu. Budete musieť pozbierať svoju vôľu, aby ste sa prinútili stráviť čas porozumením, prečo sa zdá, že všetko funguje, ale stojí to za to.
Tretia úroveň porozumenia: Prečo to funguje?
Môj nedávny poznatok sa týka práve tejto úrovne a je to pravdepodobne tá, ktorá by mi dala najväčší úžitok, keby som na túto myšlienku prišiel skôr.
Aby to bolo jasnejšie, pozrime sa na príklad: váš modul musí byť kompatibilný s funkciou X. Funkciu X veľmi nepoznáte, ale bolo vám povedané, že na to, aby ste s ňou boli kompatibilní, musíte použiť rámec F. Iné moduly, ktoré sa integrujú s X, pracujú presne s ním.
Váš kód nebol od prvého dňa svojej existencie vôbec v kontakte s rámcom F, takže jeho implementácia nebude taká jednoduchá. To bude mať vážne dôsledky pre niektoré časti modulu. Vrhnete sa však do vývoja: strávite týždne písaním kódu, testovaním, zavádzaním pilotných verzií, získavaním spätnej väzby, opravou regresných chýb, objavovaním nepredvídaných komplikácií, nedodržaním pôvodne dohodnutých termínov, písaním nejakého ďalšieho kódu, testovaním, získavaním spätnej väzby, oprava regresných chýb – to všetko s cieľom implementovať rámec F.
A v určitom bode si zrazu uvedomíte – alebo možno od niekoho počujete – že možno vám framework F vôbec nezabezpečí kompatibilitu s funkciou X. Možno ste do toho vložili všetok ten čas a úsilie úplne nesprávne.
Niečo podobné sa stalo raz pri práci na projekte, za ktorý som bol zodpovedný. Prečo sa to stalo? Pretože som málo pochopil, čo je funkcia X a ako súvisí s rámcom F. Čo som mal urobiť? Požiadajte osobu, ktorá zadáva vývojovú úlohu, aby jasne vysvetlila, ako zamýšľaný postup vedie k požadovanému výsledku, namiesto toho, aby jednoducho opakoval to, čo sa urobilo pre iné moduly, alebo aby bral svoje slovo, že to je to, čo funkcia X potrebuje urobiť.
Skúsenosti s týmto projektom ma naučili odmietnuť začať proces vývoja, kým nebudeme jasne rozumieť tomu, prečo sa od nás žiadajú určité veci. Jednoznačne odmietnuť. Keď dostanete úlohu, prvým impulzom je okamžite sa jej ujať, aby ste nestrácali čas. Ale zásada „zmraziť projekt, kým sa nedostaneme do všetkých detailov“ môže skrátiť premárnený čas rádovo.
Aj keď sa na vás snažia vyvíjať nátlak, prinútiť vás začať pracovať, hoci nerozumiete zdôvodneniu, odolajte. Najprv zistite, prečo ste dostali takúto úlohu, a rozhodnite sa, či je to správna cesta k cieľu. Toto všetko som sa musel naučiť tvrdou cestou – dúfam, že môj príklad uľahčí život tým, ktorí toto čítajú.
Štvrtá úroveň porozumenia: ???
V programovaní je vždy čo sa naučiť a verím, že som len načrtol tému porozumenia. Aké ďalšie úrovne porozumenia ste objavili počas rokov práce s kódom? Aké rozhodnutia ste urobili, ktoré mali pozitívny vplyv na kvalitu kódu a aplikácie? Ktoré rozhodnutia sa ukázali ako nesprávne a dali vám cennú lekciu? Podeľte sa o svoje skúsenosti v komentároch.
Zdroj: hab.com