Od začetka leta 2018 opravljam funkcijo vodilnega/šefa/vodilnega razvijalca v ekipi – recite temu kakor hočete, a bistvo je, da sem v celoti odgovoren za enega od modulov in za vse razvijalce, ki delajo na njem. To delovno mesto mi daje nov pogled na razvojni proces, saj sem vključen v več projektov in bolj aktivno sodelujem pri odločanju. Pred kratkim sem zaradi teh dveh stvari nenadoma spoznal, kako močno mera razumevanja vpliva na kodo in aplikacijo.
Poudariti želim, da je kakovost kode (in končnega izdelka) tesno povezana s tem, kako se ljudje, ki oblikujejo in pišejo kodo, zavedajo, kaj počnejo.
Morda si trenutno mislite: »Hvala, Cap. Seveda bi bilo lepo razumeti, kaj na splošno pišete. V nasprotnem primeru bi lahko najeli skupino opic, da pritisnejo poljubne tipke in pustite pri tem.« In imate popolnoma prav. Zato se mi zdi samoumevno, da se zavedate, da je potrebna splošna predstava o tem, kaj počnete. To lahko imenujemo ničelna raven razumevanja in je ne bomo podrobno analizirali. Podrobno si bomo ogledali, kaj natančno morate razumeti in kako to vpliva na odločitve, ki jih sprejemate vsak dan. Če bi te stvari vedel vnaprej, bi mi prihranilo veliko izgubljenega časa in vprašljive kode.
Čeprav spodaj ne boste videli niti ene vrstice kode, še vedno verjamem, da je vse, kar je tukaj povedano, zelo pomembno za pisanje visokokakovostne, ekspresivne kode.
Prva stopnja razumevanja: Zakaj ne deluje?
Razvijalci običajno dosežejo to raven zelo zgodaj v svoji karieri, včasih celo brez pomoči drugih - vsaj po mojih izkušnjah. Predstavljajte si, da ste prejeli poročilo o napaki: neka funkcija v aplikaciji ne deluje, treba jo je popraviti. Kako boste nadaljevali?
Standardna shema izgleda takole:
- Poiščite del kode, ki povzroča težavo (kako to storiti, je posebna tema, o tem govorim v svoji knjigi o podedovani kodi)
- Spremenite ta delček
- Prepričajte se, da je napaka odpravljena in da ni prišlo do napak regresije
Zdaj pa se osredotočimo na drugo točko - spreminjanje kode. Obstajata dva pristopa k temu procesu. Prvi je, da se poglobimo v to, kaj točno se dogaja v trenutni kodi, prepoznamo napako in jo odpravimo. Drugič: premaknite se po občutku - dodajte, recimo, +1 pogojnemu stavku ali zanki, preverite, ali funkcija deluje v želenem scenariju, nato poskusite nekaj drugega in tako naprej ad infinitum.
Prvi pristop je pravilen. Kot pojasnjuje Steve McConnell v svoji knjigi Code Complete (ki jo mimogrede zelo priporočam), bi morali biti vsakič, ko nekaj spremenimo v kodi, sposobni z gotovostjo napovedati, kako bo to vplivalo na aplikacijo. Citiram po spominu, a če popravek hrošča ne deluje tako, kot ste pričakovali, bi morali biti zelo vznemirjeni in podvomiti v svoj celoten akcijski načrt.
Če povzamem, kar je bilo povedano, če želite izvesti dober popravek napake, ki ne poslabša kakovosti kode, morate razumeti celotno strukturo kode in vir določene težave.
Druga raven razumevanja: Zakaj deluje?
To raven razumemo veliko manj intuitivno kot prejšnjo. Jaz, ko sem bil še razvijalec začetnik, sem se tega naučil po zaslugi svojega šefa in nato novincem večkrat razložil bistvo zadeve.
Tokrat si predstavljajmo, da ste prejeli dve poročili o hroščih hkrati: prvo je o scenariju A, drugo o scenariju B. V obeh scenarijih se zgodi nekaj narobe. V skladu s tem se najprej lotite prvega hrošča. Z uporabo načel, ki smo jih razvili za razumevanje ravni XNUMX, se poglobite v kodo, ki je pomembna za težavo, ugotovite, zakaj povzroči, da se aplikacija obnaša tako, kot se v scenariju A, in opravite razumne prilagoditve, ki ustvarijo želeni rezultat. . Vse gre super.
Nato preidete na scenarij B. Ponovite scenarij, da bi izzvali napako, toda - presenečenje! — zdaj vse deluje kot mora. Da potrdite svoje ugibanje, razveljavite spremembe, ki ste jih naredili med delom na napaki A, in napaka B se vrne. Vaš popravek napak je rešil obe težavi. srečno!
Na to sploh nisi računal. Iznašli ste način za odpravo napake v scenariju A in nimate pojma, zakaj je deloval pri scenariju B. Na tej stopnji je zelo mamljivo misliti, da sta bili obe nalogi uspešno zaključeni. To je povsem logično: bistvo je bilo odpraviti napake, kajne? Toda delo še ni končano: še vedno morate ugotoviti, zakaj ste s svojimi dejanji popravili napako v scenariju B. Zakaj? Ker morda deluje po napačnih načelih in potem boste morali iskati drug izhod. Tu je nekaj primerov takih primerov:
- Ker rešitev ni bila prilagojena napaki B, ob upoštevanju vseh dejavnikov, ste morda nevede pokvarili funkcijo C.
- Možno je, da se nekje skriva tudi tretja napaka, povezana z isto funkcijo, od katere je odvisen vaš popravek napake za pravilno delovanje sistema v scenariju B. Zdaj je vse videti dobro, toda nekega dne bo ta tretja napaka opažena in odpravljena. Potem se bo v scenariju B napaka znova pojavila in dobro je, če samo tam.
Vse to dodaja kaos kodi in vam bo nekoč padlo na glavo - najverjetneje v najbolj neprimernem trenutku. Zbrati boste morali svojo moč volje, da se boste prisilili, da boste porabili čas za razumevanje, zakaj se zdi, da vse deluje, vendar je vredno.
Tretja stopnja razumevanja: Zakaj deluje?
Moj nedavni vpogled se nanaša ravno na to raven in verjetno bi mi najbolj koristila, če bi na to idejo prišel prej.
Da bo bolj jasno, poglejmo primer: vaš modul mora biti združljiv s funkcijo X. Niste dobro seznanjeni s funkcijo X, vendar so vam rekli, da morate za združljivost z njo uporabiti ogrodje F. Drugo moduli, ki se integrirajo z X, delujejo točno z njim.
Vaša koda sploh ni bila v stiku z ogrodjem F od prvega dne svojega življenja, zato njena implementacija ne bo tako enostavna. To bo imelo resne posledice za nekatere dele modula. Vendar se vržete v razvoj: porabite tedne za pisanje kode, testiranje, uvajanje pilotnih različic, pridobivanje povratnih informacij, popravljanje napak regresije, odkrivanje nepredvidenih zapletov, neupoštevanje prvotno dogovorjenih rokov, pisanje dodatne kode, testiranje, pridobivanje povratnih informacij, popravljanje regresijskih napak – vse to z namenom implementacije F ogrodja.
In na neki točki se nenadoma zaveš - ali morda od nekoga slišiš - da ti morda ogrodje F sploh ne bo omogočilo združljivosti s funkcijo X. Morda sta bila ves ta čas in trud vložena povsem narobe.
Nekaj podobnega se je zgodilo enkrat med delom na projektu, za katerega sem bil odgovoren. Zakaj se je to zgodilo? Ker nisem dobro razumel, kaj je funkcija X in kako je povezana z ogrodjem F. Kaj bi moral storiti? Osebo, ki dodeljuje razvojno nalogo, prosite, naj jasno razloži, kako predvideni potek dejanj vodi do želenega rezultata, namesto da preprosto ponavlja, kaj je bilo narejeno za druge module, ali da ji verjamete na besedo, da je to tisto, kar mora funkcija X narediti.
Izkušnje s tem projektom so me naučile, da zavrnem začetek razvojnega procesa, dokler ne bomo jasno razumeli, zakaj se od nas zahteva, da naredimo določene stvari. Odkrito zavrni. Ko prejmete nalogo, je prvi impulz, da se je takoj lotite, da ne izgubljate časa. Toda politika "zamrznitve projekta, dokler ne preučimo vseh podrobnosti" lahko zmanjša izgubljeni čas za več vrst velikosti.
Tudi če poskušajo na vas pritiskati, vas prisiliti, da začnete delati, čeprav ne razumete razloga za to, se uprite. Najprej ugotovite, zakaj ste dobili takšno nalogo, in se odločite, ali je to prava pot do cilja. Vsega tega sem se moral naučiti na težji način - upam, da bo moj primer olajšal življenje tistim, ki to berejo.
Četrta stopnja razumevanja: ???
Pri programiranju se je vedno treba naučiti več in verjamem, da sem le opraskal površje teme razumevanja. Katere druge ravni razumevanja ste odkrili v letih dela s kodo? Katere odločitve ste sprejeli, da so pozitivno vplivale na kakovost kode in aplikacije? Katere odločitve so se izkazale za napačne in so vas naučile dragoceno lekcijo? Delite svoje izkušnje v komentarjih.
Vir: www.habr.com