Od početka 2018. godine sam na poziciji glavnog/šefa/glavnog programera u timu - zovite to kako hoćete, ali poenta je da sam ja u potpunosti odgovoran za jedan od modula i za sve programere koji rade na njemu. Ova pozicija mi daje novi pogled na razvojni proces, jer sam uključen u više projekata i aktivnije sam uključen u donošenje odluka. Nedavno sam, zahvaljujući ove dvije stvari, iznenada shvatio koliko mjera razumijevanja utiče na kod i aplikaciju.
Ono što želim da naglasim je da je kvalitet koda (i konačnog proizvoda) usko povezan sa to koliko su ljudi koji dizajniraju i pišu kod svjesni onoga što rade.
Možda trenutno razmišljate: „Hvala, Kap. Naravno, bilo bi lijepo razumjeti šta uopšte pišete. U suprotnom, možete unajmiti grupu majmuna da pritisnu proizvoljne tipke i ostavite to na tome.” I potpuno ste u pravu. Shodno tome, uzimam zdravo za gotovo da shvatite da je neophodno imati opštu ideju o tome šta radite. Ovo se može nazvati nultim nivoom razumijevanja i nećemo ga detaljno analizirati. Detaljno ćemo pogledati šta tačno treba da razumete i kako to utiče na odluke koje donosite svaki dan. Da sam znao te stvari unaprijed, uštedio bi mi mnogo izgubljenog vremena i upitnog koda.
Iako u nastavku nećete vidjeti niti jedan red koda, i dalje vjerujem da je sve što je ovdje rečeno od velike važnosti za pisanje visokokvalitetnog, izražajnog koda.
Prvi nivo razumevanja: Zašto ne radi?
Programeri obično dostignu ovaj nivo vrlo rano u svojoj karijeri, ponekad čak i bez pomoći drugih - barem prema mom iskustvu. Zamislite da ste dobili izvještaj o grešci: neka funkcija u aplikaciji ne radi, potrebno je popraviti. Kako ćete dalje?
Standardna shema izgleda ovako:
- Pronađite dio koda koji uzrokuje problem (kako to učiniti je posebna tema, pokrivam ga 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ške regresije
Sada se fokusirajmo na drugu tačku - unošenje izmjena u kod. Postoje dva pristupa ovom procesu. Prvi je da se udubimo u ono što se tačno dešava u trenutnom kodu, identifikuje grešku i popravi je. Drugo: kretanje po osjećaju - dodajte, recimo, +1 u uvjetnu izjavu ili petlju, pogledajte da li funkcija radi 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, inače, toplo preporučujem), svaki put kada nešto promijenimo u kodu, trebali bismo biti u mogućnosti s povjerenjem predvidjeti kako će to utjecati na aplikaciju. Citiram po sjećanju, ali ako ispravka greške ne funkcionira onako kako ste očekivali, trebali biste biti jako uznemireni i trebali biste preispitati cijeli svoj akcioni plan.
Da rezimiramo ono što je rečeno, da biste izvršili dobru ispravku greške koja ne degradira kvalitet koda, morate razumjeti i cjelokupnu strukturu koda i izvor konkretnog problema.
Drugi nivo razumevanja: Zašto funkcioniše?
Ovaj nivo se shvaća mnogo manje intuitivno od prethodnog. Ja, dok sam još bio početnik u programiranju, naučio sam to zahvaljujući svom šefu, a potom sam novopridošlicama više puta objašnjavao suštinu stvari.
Ovaj put, zamislimo da ste primili dva izvještaja o greškama odjednom: prvi se odnosi na scenarij A, drugi na scenario B. U oba scenarija, nešto se dešava pogrešno. Shodno tome, prvo se pozabavite prvom greškom. Koristeći principe koje smo razvili za razumijevanje nivoa XNUMX, kopate duboko u kod relevantan za problem, otkrivate zašto uzrokuje da se aplikacija ponaša na način na koji se ponaša u scenariju A i pravite razumna prilagođavanja koja daju rezultat koji želite. . Sve ide odlično.
Zatim prelazite na scenario B. Ponavljate scenario u pokušaju da izazovete grešku, ali—iznenađenje! — sada sve radi kako treba. Da biste potvrdili svoju pretpostavku, poništite promjene koje ste napravili dok ste radili na grešci A, a greška B se vraća. Vaša ispravka greške je riješila oba problema. Lucky!
Nisi uopste racunao na ovo. Smislili ste način da popravite grešku u scenariju A i nemate pojma zašto je to funkcioniralo za scenarij B. U ovoj fazi, vrlo je primamljivo misliti da su oba zadatka uspješno obavljena. Ovo je sasvim logično: poenta je bila otklanjanje grešaka, zar ne? Ali posao još nije gotov: još uvijek morate shvatiti zašto su svojim postupcima ispravili grešku u scenariju B. Zašto? Jer možda radi na pogrešnim principima, i tada ćete morati tražiti drugi izlaz. Evo nekoliko primjera takvih slučajeva:
- Budući da rješenje nije skrojeno za grešku B, uzimajući u obzir sve faktore, možda ste nesvjesno pokvarili funkciju C.
- Moguće je da negdje vreba i treća greška, vezana za istu funkciju, a vaša ispravka greške ovisi o tome za ispravan rad sistema u scenariju B. Sada sve izgleda dobro, ali jednog dana će ova treća greška biti uočena i ispravljena. Tada će se u scenariju B greška ponovo pojaviti, i dobro je samo da postoji.
Sve ovo dodaje haos kodu i jednog dana će vam pasti na glavu - najvjerovatnije u najnepovoljnijem trenutku. Morat ćete skupiti svoju snagu volje da natjerate sebe da potrošite vrijeme na razumijevanje zašto se čini da sve funkcionira, ali vrijedi.
Treći nivo razumevanja: Zašto funkcioniše?
Moj nedavni uvid se odnosi upravo na ovaj nivo, i to je vjerovatno onaj koji bi mi najviše koristio da sam ranije došao na ovu ideju.
Da bude jasnije, pogledajmo primjer: vaš modul mora biti kompatibilan sa funkcijom X. Niste posebno upoznati sa funkcijom X, ali vam je rečeno da morate koristiti F framework da biste bili kompatibilni s njom. moduli koji se integriraju sa X rade upravo s njim.
Vaš kod nije uopće bio u kontaktu sa F frameworkom od prvog dana njegovog života, tako da njegova implementacija neće biti tako laka. To će imati ozbiljne posljedice za neke dijelove modula. Međutim, bacite se na razvoj: provodite sedmice pisanja koda, testiranja, uvođenja pilot verzija, dobivanja povratnih informacija, popravljanja grešaka regresije, otkrivanja nepredviđenih komplikacija, nepoštovanja prvobitno dogovorenih rokova, pisanja još malog koda, testiranja, dobivanja povratne komunikacije, ispravljanje grešaka regresije - sve to u cilju implementacije F okvira.
I u nekom trenutku odjednom shvatite - ili možda čujete od nekoga - da vam okvir F možda uopće neće dati kompatibilnost sa funkcijom X. Možda je svo to vrijeme i trud uloženo potpuno pogrešno u to.
Nešto slično se dogodilo jednom dok sam radio na projektu za koji sam bio odgovoran. Zašto se to dogodilo? Zato što sam slabo razumio šta je funkcija X i kako se odnosi na okvir F. Šta sam trebao učiniti? Zamolite osobu koja dodjeljuje razvojni zadatak da jasno objasni kako planirani tok akcije vodi do željenog ishoda, umjesto da jednostavno ponavlja ono što je urađeno za druge module ili da im vjerujete na riječ da je to ono što funkcija X treba da uradi.
Iskustvo ovog projekta naučilo me je da odbijem započeti proces razvoja sve dok ne shvatimo zašto se od nas traži da radimo određene stvari. Odbij direktno. Kada dobijete zadatak, prvi impuls je da ga odmah preuzmete kako ne biste gubili vrijeme. Ali politika „zamrzavanja projekta dok ne uđemo u sve detalje” može smanjiti izgubljeno vrijeme za redove veličine.
Čak i ako pokušaju da izvrše pritisak na vas, da vas natjeraju da počnete raditi, iako ne razumijete razlog za to, oduprite se. Prvo, shvatite zašto vam se daje takav zadatak i odlučite da li je 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 nivo razumevanja: ???
U programiranju se uvijek može naučiti više, a vjerujem da sam samo zagrebao površinu teme razumijevanja. Koje druge nivoe razumevanja ste otkrili tokom godina rada sa kodom? Koje ste odluke doneli a koje su imale pozitivan uticaj na kvalitet koda i aplikacije? Koje su se odluke pokazale pogrešnim i dale su vam vrijednu lekciju? Podijelite svoje iskustvo u komentarima.
izvor: www.habr.com