Od početka 2018. u timu obnašam poziciju lead/boss/lead developera - nazovite to kako hoćete, ali poanta je da sam u potpunosti odgovoran za jedan od modula i za sve developere koji rade na tome. Ova pozicija daje mi novi pogled na proces razvoja, jer sam uključen u više projekata i aktivnije uključen u donošenje odluka. Nedavno sam, zahvaljujući te dvije stvari, odjednom shvatio koliko mjera razumijevanja utječe na kod i aplikaciju.
Ono što želim istaknuti jest da je kvaliteta koda (i konačnog proizvoda) usko povezana s time koliko su ljudi koji dizajniraju i pišu kod svjesni onoga što rade.
Možda upravo sada mislite: “Hvala, Cap. Naravno, bilo bi lijepo razumjeti što uopće pišete. U suprotnom, možete unajmiti skupinu majmuna da pritisnu proizvoljne tipke i ostaviti na tome." I potpuno ste u pravu. U skladu s tim, uzimam zdravo za gotovo da shvaćate da je neophodno imati opću predodžbu o tome što radite. To se može nazvati nultom razinom razumijevanja i nećemo je detaljno analizirati. Detaljno ćemo pogledati što točno trebate razumjeti i kako to utječe na odluke koje svakodnevno donosite. Da sam znao te stvari unaprijed, uštedjelo bi mi puno izgubljenog vremena i upitnog koda.
Iako ispod nećete vidjeti niti jednu liniju koda, i dalje vjerujem da je sve što je ovdje rečeno od velike važnosti za pisanje visokokvalitetnog, izražajnog koda.
Prva razina razumijevanja: Zašto ne radi?
Programeri obično dostignu ovu razinu vrlo rano u svojoj karijeri, ponekad čak i bez ikakve pomoći drugih - barem prema mom iskustvu. Zamislite da ste primili izvješće o bugu: neka funkcija u aplikaciji ne radi, potrebno ju je popraviti. Kako ćete postupiti?
Standardna shema izgleda ovako:
- Pronađite dio koda koji uzrokuje problem (kako to učiniti je zasebna tema, pokrivam to u svojoj knjizi o naslijeđenom kodu)
- Izmijenite ovaj isječak
- Uvjerite se da je greška ispravljena i da nije došlo do grešaka regresije
Sada se usredotočimo na drugu točku - izmjene koda. Postoje dva pristupa ovom procesu. Prvi je istražiti što se točno događa u trenutnom kodu, identificirati grešku i popraviti je. Drugo: pomaknite se prema osjećaju - dodajte, recimo, +1 uvjetnoj izjavi ili petlji, pogledajte radi li funkcija u željenom scenariju, zatim pokušajte nešto drugo, i tako u nedogled.
Prvi pristup je ispravan. Kao što Steve McConnell objašnjava u svojoj knjizi Code Complete (koju, usput, toplo preporučujem), svaki put kad nešto promijenimo u kodu, trebali bismo moći s pouzdanjem predvidjeti kako će to utjecati na aplikaciju. Citiram po sjećanju, ali ako ispravak bugova ne radi onako kako ste očekivali, trebali biste biti vrlo zabrinuti i trebali biste preispitati cijeli svoj akcijski plan.
Da sažmemo ono što je rečeno, kako biste izvršili dobar ispravak bugova koji ne degradira kvalitetu koda, trebate razumjeti i cjelokupnu strukturu koda i izvor specifičnog problema.
Druga razina razumijevanja: Zašto funkcionira?
Ova se razina shvaća mnogo manje intuitivno nego prethodna. Ja sam, dok sam još bio programer početnik, naučio to zahvaljujući svom šefu, a kasnije sam opetovano objašnjavao suštinu stvari novopridošlicama.
Ovaj put, zamislimo da ste primili dva izvješća o greškama odjednom: prvo se odnosi na scenarij A, drugo je na scenarij B. U oba scenarija događa se nešto pogrešno. U skladu s tim, prvi se pozabavite prvom greškom. Koristeći načela koja smo razvili za razumijevanje razine XNUMX, dubinski ulazite u kod koji je relevantan za problem, otkrivate zašto uzrokuje da se aplikacija ponaša onako kako se ponaša u scenariju A i radite razumne prilagodbe koje proizvode željeni rezultat. . Sve ide super.
Zatim prelazite na scenarij B. Ponavljate scenarij u pokušaju da izazovete pogrešku, ali — iznenađenje! — sada sve radi kako treba. Da biste potvrdili svoju pretpostavku, poništite promjene koje ste napravili dok ste radili na bugu A, a bug B se vraća. Vaš ispravak pogreške riješio je oba problema. Sretan!
Na ovo uopće nisi računao. Smislili ste način da popravite pogrešku u scenariju A i nemate pojma zašto je uspio u scenariju B. U ovoj fazi, vrlo je primamljivo misliti da su oba zadatka uspješno dovršena. To je sasvim logično: poanta je bila eliminirati pogreške, zar ne? Ali posao još nije gotov: još uvijek morate shvatiti zašto ste svojim postupcima ispravili pogrešku u scenariju B. Zašto? Jer možda radi na pogrešnim principima, a onda ćete morati potražiti drugi izlaz. Evo nekoliko primjera takvih slučajeva:
- Budući da rješenje nije prilagođeno pogrešci B, uzimajući u obzir sve čimbenike, možda ste nesvjesno pokvarili funkciju C.
- Moguće je da negdje vreba i treći bug, povezan s istom funkcijom, a vaš ispravak buga ovisi o njemu za pravilan rad sustava u scenariju B. Sada sve izgleda dobro, ali jednog dana će ovaj treći bug biti uočen i ispravljen. Tada će se u scenariju B pogreška ponovno pojaviti, i dobro je samo tamo.
Sve to dodaje kaos kodu i jednog dana će vam se obrušiti na glavu - najvjerojatnije u najnepovoljnijem trenutku. Morat ćete skupiti svoju snagu volje kako biste se natjerali da provedete vrijeme u razumijevanju zašto se čini da sve funkcionira, ali isplati se.
Treća razina razumijevanja: Zašto funkcionira?
Moj nedavni uvid odnosi se upravo na tu razinu i vjerojatno bi mi od nje najviše koristi da sam ranije došao na ovu ideju.
Da bi bilo jasnije, pogledajmo primjer: vaš modul mora biti kompatibilan s funkcijom X. Niste osobito upoznati s funkcijom X, ali rečeno vam je da morate koristiti okvir F da biste bili kompatibilni s njom. moduli koji se integriraju s Xom rade točno s njim.
Vaš kod uopće nije bio u kontaktu s F okvirom od prvog dana svog života, tako da njegova implementacija neće biti tako laka. To će imati ozbiljne posljedice za neke dijelove modula. Međutim, bacate se na razvoj: provodite tjedne pišući kod, testirajući, uvodeći pilot verzije, dobivajući povratne informacije, popravljajući pogreške regresije, otkrivajući nepredviđene komplikacije, ne poštujući prvotno dogovorene rokove, pišući još koda, testirajući, dobivajući povratnu komunikaciju, ispravljanje grešaka regresije - sve to u svrhu implementacije F okvira.
I u nekom trenutku iznenada shvatite - ili možda čujete od nekoga - da vam okvir F možda uopće neće dati kompatibilnost sa značajkom X. Možda su svo to vrijeme i trud uloženi potpuno krivo za to.
Nešto slično dogodilo se jednom prilikom rada na projektu za koji sam ja bio odgovoran. Zašto se to dogodilo? Zato što sam slabo razumio što je funkcija X i kako se odnosi na okvir F. Što sam trebao učiniti? Zamolite osobu koja dodjeljuje razvojni zadatak da jasno objasni kako namjeravani tijek radnje dovodi do željenog ishoda, umjesto da jednostavno ponavlja ono što je učinjeno za druge module ili da im vjeruje na riječ da je to ono što značajka X treba učiniti.
Iskustvo s ovim projektom naučilo me da odbijem započeti proces razvoja sve dok ne budemo jasno razumjeli zašto se od nas traži da radimo određene stvari. Izravno odbiti. Kada dobijete zadatak, prvi poticaj je da ga se odmah prihvatite kako ne biste gubili vrijeme. Ali politika "zamrzni projekt dok ne uđemo u sve detalje" može smanjiti izgubljeno vrijeme za nekoliko redova veličine.
Čak i ako pokušaju izvršiti pritisak na vas, prisiliti vas da počnete raditi, iako ne razumijete razlog za to, oduprite se. Najprije shvatite zašto ste dobili takav zadatak i odlučite je li to pravi put do cilja. Sve sam ovo morao naučiti na teži način - nadam se da će moj primjer olakšati život onima koji ovo čitaju.
Četvrti stupanj razumijevanja: ???
U programiranju se uvijek može još naučiti i vjerujem da sam samo zagrebao površinu teme razumijevanja. Koje ste još razine razumijevanja otkrili tijekom godina rada s kodom? Koje ste odluke donijeli da su pozitivno utjecale na kvalitetu koda i aplikacije? Koje su se odluke pokazale pogrešnim i naučile su vas vrijednu lekciju? Podijelite svoje iskustvo u komentarima.
Izvor: www.habr.com