Od začátku roku 2018 zastávám v týmu pozici lead/boss/lead developer – říkejte si tomu jak chcete, ale jde o to, že jsem plně zodpovědný za jeden z modulů a za všechny vývojáře, kteří pracují na to. Tato pozice mi dává nový pohled na vývojový proces, protože jsem zapojen do více projektů a aktivněji se podílím na rozhodování. Nedávno jsem si díky těmto dvěma věcem najednou uvědomil, jak moc má míra porozumění vliv na kód a aplikaci.
Chci zdůraznit, že kvalita kódu (a konečného produktu) úzce souvisí s tím, jak jsou si lidé, kteří kód navrhují a píší, vědomi toho, co dělají.
Možná si právě teď říkáte: „Díky, Cape. Samozřejmě by bylo fajn porozumět tomu, co píšete obecně. V opačném případě byste si také mohli najmout skupinu opic, aby stiskly libovolné klávesy, a nechat to být." A máte naprostou pravdu. V souladu s tím považuji za samozřejmé, že si uvědomujete, že je nezbytné mít obecnou představu o tom, co děláte. To lze nazvat nulovou úrovní porozumění a nebudeme to podrobně rozebírat. Podrobně se podíváme na to, co přesně potřebujete pochopit a jak to ovlivňuje rozhodnutí, která každý den děláte. Kdybych tyto věci věděl předem, ušetřilo by mi to spoustu ztraceného času a pochybného kódu.
I když níže neuvidíte jediný řádek kódu, stále věřím, že vše, co je zde řečeno, má velký význam pro psaní vysoce kvalitního a expresivního kódu.
První úroveň porozumění: Proč to nefunguje?
Vývojáři obvykle dosáhnou této úrovně velmi brzy ve své kariéře, někdy dokonce bez jakékoli pomoci ostatních - alespoň podle mých zkušeností. Představte si, že jste obdrželi hlášení o chybě: některá funkce v aplikaci nefunguje, je třeba ji opravit. jak budete postupovat?
Standardní schéma vypadá takto:
- Najděte část kódu, která způsobuje problém (jak to udělat, je samostatné téma, věnuji se tomu ve své knize o starším kódu)
- Proveďte změny v tomto úryvku
- Ujistěte se, že je chyba opravena a nedošlo k žádné regresní chybě
Nyní se zaměřme na druhý bod – provádění změn v kódu. Existují dva přístupy k tomuto procesu. První je ponořit se do toho, co se přesně děje v aktuálním kódu, identifikovat chybu a opravit ji. Za druhé: pohyb podle pocitu – přidejte, řekněme, +1 k podmíněnému příkazu nebo smyčce, zjistěte, zda funkce funguje v požadovaném scénáři, pak zkuste něco jiného a tak dále do nekonečna.
První přístup je správný. Jak vysvětluje Steve McConnell ve své knize Code Complete (kterou mimochodem vřele doporučuji), pokaždé, když něco v kódu změníme, měli bychom být schopni s jistotou předpovědět, jak to ovlivní aplikaci. Cituji zpaměti, ale pokud oprava chyby nefunguje tak, jak jste očekávali, měli byste být velmi znepokojeni a měli byste zpochybnit celý svůj akční plán.
Abychom shrnuli, co bylo řečeno, k provedení dobré opravy chyb, která nesníží kvalitu kódu, musíte porozumět jak celé struktuře kódu, tak zdroji konkrétního problému.
Druhá úroveň porozumění: Proč to funguje?
Tato úroveň je chápána mnohem méně intuitivně než předchozí. Já, ještě jako začínající vývojář, jsem se to naučil díky svému šéfovi a následně opakovaně vysvětloval podstatu věci nováčkům.
Tentokrát si představme, že jste obdrželi dvě hlášení o chybě najednou: první se týká scénáře A, druhé scénáře B. V obou scénářích se stane něco špatného. Podle toho nejprve vyřešte první chybu. Pomocí principů, které jsme vyvinuli pro pochopení úrovně XNUMX, se ponoříte hluboko do kódu relevantního pro daný problém, zjistíte, proč způsobuje, že se aplikace chová tak, jak se chová ve scénáři A, a provedete přiměřené úpravy, které přinesou očekávaný výsledek. . Všechno jde skvěle.
Poté přejdete ke scénáři B. Zopakujete scénář ve snaze vyvolat chybu, ale – překvapení! - nyní vše funguje jak má. Chcete-li potvrdit svůj odhad, vrátíte zpět změny, které jste provedli při práci na chybě A, a chyba B se vrátí. Vaše oprava vyřešila oba problémy. Šťastný!
S tímhle jsi vůbec nepočítal. Přišli jste na způsob, jak opravit chybu ve scénáři A a nemáte ponětí, proč to fungovalo ve scénáři B. V této fázi je velmi lákavé myslet si, že oba úkoly byly úspěšně dokončeny. To je celkem logické: smyslem bylo odstranit chyby, ne? Ale práce ještě není dokončena: stále musíte přijít na to, proč vaše akce napravila chybu ve scénáři B. Proč? Protože to může fungovat na špatných principech a pak budete muset hledat jiné východisko. Zde je několik příkladů takových případů:
- Vzhledem k tomu, že řešení nebylo přizpůsobeno chybě B, při zohlednění všech faktorů jste mohli nevědomky porušit funkci C.
- Je možné, že někde také číhá třetí chyba související se stejnou funkcí a vaše oprava chyby na ní závisí pro správné fungování systému ve scénáři B. Všechno teď vypadá dobře, ale jednoho dne bude tato třetí chyba zaznamenána a opravena. Pak ve scénáři B dojde k chybě znovu a je dobré, když jen tam.
To vše dodává kódu chaos a jednoho dne vám to spadne na hlavu – nejspíš v tu nejméně vhodnou chvíli. Budete muset sebrat svou vůli, abyste se přinutili trávit čas pochopením toho, proč se zdá, že všechno funguje, ale stojí to za to.
Třetí úroveň porozumění: Proč to funguje?
Můj nedávný poznatek se vztahuje právě k této úrovni a pravděpodobně by mi nejvíce prospěl, 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. S funkcí X nejste příliš obeznámeni, ale bylo vám řečeno, že abyste s ní byli kompatibilní, musíte použít rámec F. Jiné moduly, které se integrují s X, pracují přesně s ním.
Váš kód nebyl od prvního dne jeho života s frameworkem F vůbec v kontaktu, takže jeho implementace nebude tak snadná. To bude mít vážné důsledky pro některé části modulu. Vy se však vrhnete do vývoje: strávíte týdny psaním kódu, testováním, zaváděním pilotních verzí, získáváním zpětné vazby, opravou regresních chyb, objevováním nepředvídatelných komplikací, nedodržením původně dohodnutých termínů, psaním dalšího kódu, testováním, získáváním zpětné vazby, oprava regresních chyb – to vše za účelem implementace rámce F.
A v určitém okamžiku si najednou uvědomíte – nebo možná od někoho uslyšíte – že vám možná framework F vůbec nezajistí kompatibilitu s funkcí X. Možná, že všechen ten čas a úsilí bylo vynaloženo úplně špatně.
Něco podobného se stalo jednou při práci na projektu, za který jsem byl zodpovědný. Proč se to stalo? Protože jsem málo rozuměl tomu, co je funkce X a jak souvisí s rámcem F. Co jsem měl udělat? Požádejte osobu, která zadává vývojový úkol, aby jasně vysvětlila, jak zamýšlený postup vede k požadovanému výsledku, spíše než aby jednoduše opakoval to, co bylo uděláno pro jiné moduly, nebo aby bral slovo, že to je to, co funkce X potřebuje udělat.
Zkušenost s tímto projektem mě naučila odmítnout zahájit vývojový proces, dokud jasně neporozumíme tomu, proč jsme požádáni, abychom dělali určité věci. Klidně odmítnout. Když dostanete úkol, prvním impulsem je okamžitě se ho ujmout, abyste neztráceli čas. Ale zásada „zmrazit projekt, dokud se nedostaneme do všech podrobností“ může zkrátit promarněný čas o řády.
I když se na vás snaží vyvíjet nátlak, donutit vás začít pracovat, ačkoli nerozumíte zdůvodnění, odolejte. Nejprve zjistěte, proč jste dostali takový úkol, a rozhodněte se, zda je to správná cesta k cíli. Musel jsem se to všechno naučit tvrdě - doufám, že můj příklad usnadní život těm, kteří toto čtou.
Čtvrtá úroveň porozumění: ???
V programování je vždy co se naučit a věřím, že jsem pouze načrtl povrch tématu porozumění. Jaké další úrovně porozumění jste během let práce s kódem objevili? Jaká rozhodnutí, která jste udělali, měla pozitivní dopad na kvalitu kódu a aplikace? Jaká rozhodnutí se ukázala jako špatná a dala vám cennou lekci? Podělte se o své zkušenosti v komentářích.
Zdroj: www.habr.com