Nuo 2018 metų pradžios komandoje einu vadovaujančiojo/boso/vadovaujančio kūrėjo pareigas – vadinkite kaip norite, bet esmė ta, kad esu visiškai atsakinga už vieną iš modulių ir už visus dirbančius kūrėjus ant jo. Šios pareigos suteikia man naują požiūrį į plėtros procesą, nes dalyvauju daugiau projektų ir aktyviau dalyvauju sprendimų priėmime. Neseniai dėl šių dviejų dalykų aš staiga supratau, kiek supratimo matas turi įtakos kodui ir programai.
Noriu pabrėžti, kad kodo (ir galutinio produkto) kokybė yra glaudžiai susijusi su tuo, kaip kodą kuriantys ir rašantys žmonės žino, ką daro.
Galbūt dabar galvojate: „Ačiū, Cap. Žinoma, būtų malonu suprasti, ką apskritai rašai. Priešingu atveju taip pat galite pasamdyti beždžionių grupę, kuri paspaustų savavališkus klavišus ir palikite tai. Ir tu visiškai teisus. Todėl aš laikau savaime suprantamu dalyku, kad suvokiate, jog būtina turėti bendrą supratimą apie tai, ką darote. Tai galima pavadinti nuliniu supratimo lygiu, ir mes to išsamiai neanalizuosime. Išsamiai panagrinėsime, ką tiksliai turite suprasti ir kaip tai veikia jūsų kasdien priimamus sprendimus. Jei būčiau žinojęs šiuos dalykus iš anksto, būčiau sutaupęs daug sugaišto laiko ir abejotino kodo.
Nors žemiau nematysite nė vienos kodo eilutės, vis tiek tikiu, kad viskas, kas čia pasakyta, yra labai svarbi norint parašyti kokybišką, išraiškingą kodą.
Pirmasis supratimo lygis: kodėl tai neveikia?
Šį lygį kūrėjai dažniausiai pasiekia labai anksti savo karjeroje, kartais net be jokios kitų pagalbos – bent jau mano patirtis rodo. Įsivaizduokite, kad gavote pranešimą apie klaidą: kai kuri programos funkcija neveikia, ją reikia pataisyti. Kaip elgsitės toliau?
Standartinė schema atrodo taip:
- Raskite kodo dalį, dėl kurios kilo problema (kaip tai padaryti, yra atskira tema, aš ją aprašysiu savo knygoje apie seną kodą)
- Atlikite šio fragmento pakeitimus
- Įsitikinkite, kad klaida ištaisyta ir neįvyko regresijos klaidų
Dabar sutelkime dėmesį į antrąjį dalyką – kodo keitimą. Yra du šio proceso požiūriai. Pirmiausia reikia įsigilinti į tai, kas tiksliai vyksta dabartiniame kode, nustatyti klaidą ir ją ištaisyti. Antra: judėkite pagal jausmą – pridėkite, tarkime, +1 prie sąlyginio teiginio ar ciklo, pažiūrėkite, ar funkcija veikia norimu scenarijuje, tada pabandykite ką nors kita ir taip toliau be galo.
Pirmasis požiūris yra teisingas. Kaip Steve McConnell paaiškina savo knygoje Code Complete (kurį, beje, labai rekomenduoju), kiekvieną kartą, kai ką nors pakeisime kode, turėtume užtikrintai numatyti, kaip tai paveiks programą. Cituoju iš atminties, bet jei klaidų taisymas neveikia taip, kaip tikėjotės, turėtumėte labai sunerimti ir suabejoti visu savo veiksmų planu.
Apibendrinant tai, kas pasakyta, norint atlikti gerą klaidų taisymą, nepabloginantį kodo kokybės, reikia suprasti ir visą kodo struktūrą, ir konkrečios problemos šaltinį.
Antrasis supratimo lygis: kodėl tai veikia?
Šis lygis suvokiamas daug mažiau intuityviai nei ankstesnis. Aš, dar būdamas naujokas kūrėjas, išmokau tai savo viršininko dėka, o vėliau naujokams ne kartą paaiškinau reikalo esmę.
Šį kartą įsivaizduokime, kad iš karto gavote du pranešimus apie klaidas: pirmasis – apie A scenarijų, antrasis – apie B scenarijų. Abiejuose scenarijuose nutinka kažkas ne taip. Atitinkamai, pirmiausia pašalinkite pirmąją klaidą. Naudodami principus, kuriuos sukūrėme XNUMX lygio supratimui, įsigilinate į su problema susijusį kodą, išsiaiškite, kodėl dėl to programa elgiasi taip, kaip A scenarijuje, ir atlikite pagrįstus koregavimus, kad būtų pasiektas norimas rezultatas. . Viskas vyksta puikiai.
Tada pereinate prie scenarijaus B. Pakartojate scenarijų, bandydami išprovokuoti klaidą, bet – nustebinkite! - dabar viskas veikia kaip priklauso. Norėdami patvirtinti savo spėjimą, anuliuojate pakeitimus, kuriuos atlikote dirbdami su A klaida, ir klaida B vėl pasirodys. Jūsų klaidų taisymas išsprendė abi problemas. Pasisekė!
Jūs tuo visiškai nesiskaičiavote. Jūs sugalvojote būdą, kaip ištaisyti klaidą A scenarijuje ir neįsivaizduojate, kodėl tai veikė pagal scenarijų B. Šiame etape labai viliojama manyti, kad abi užduotys buvo sėkmingai atliktos. Tai gana logiška: esmė buvo pašalinti klaidas, ar ne? Tačiau darbas dar nebaigtas: vis dar turite išsiaiškinti, kodėl jūsų veiksmai ištaisė klaidą B scenarijuje. Kodėl? Nes gali būti, kad dirbama neteisingais principais, o tada reikės ieškoti kitos išeities. Štai keletas tokių atvejų pavyzdžių:
- Kadangi sprendimas nebuvo pritaikytas klaidai B, todėl, atsižvelgiant į visus veiksnius, galėjote nesąmoningai sugadinti funkciją C.
- Gali būti, kad kažkur slypi ir trečioji klaida, susijusi su ta pačia funkcija, ir nuo jos priklauso jūsų klaidų taisymas, kad B scenarijus tinkamai veiktų. Dabar viskas atrodo gerai, bet vieną dieną ši trečioji klaida bus pastebėta ir ištaisyta. Tada B scenarijuje klaida pasikartos, ir gerai, jei tik ten.
Visa tai į kodą įneša chaoso ir kada nors kris tau ant galvos – greičiausiai pačiu netinkamiausiu momentu. Turėsite sukaupti valios jėgą, kad priverstumėte save praleisti laiką suprasti, kodėl atrodo, kad viskas veikia, bet tai verta.
Trečias supratimo lygis: kodėl tai veikia?
Mano naujausia įžvalga susijusi būtent su šiuo lygmeniu, ir tai tikriausiai būtų davusi daugiausiai naudos, jei būčiau priėjęs prie šios minties anksčiau.
Kad būtų aiškiau, pažvelkime į pavyzdį: jūsų modulis turi būti suderinamas su X funkcija. Jūs nesate ypač susipažinęs su funkcija X, bet jums buvo pasakyta, kad norint, kad jis būtų suderinamas, reikia naudoti F sistemą. moduliai, kurie integruojami su X, veikia tiksliai su juo.
Jūsų kodas nuo pat pirmos gyvavimo dienos visiškai nesusisiekė su F karkasu, todėl jį įdiegti nebus taip paprasta. Tai turės rimtų pasekmių kai kurioms modulio dalims. Tačiau jūs pasiduodate kūrimui: praleidžiate savaites rašydami kodą, testuodami, diegdami bandomąsias versijas, gaudami grįžtamąjį ryšį, taisydami regresijos klaidas, atrasdami nenumatytas komplikacijas, nesilaikydami iš pradžių sutartų terminų, rašydami dar šiek tiek kodo, testuodami, gaudami grįžtamąjį ryšį, regresijos klaidų taisymas – visa tai siekiant įgyvendinti F sistemą.
Ir kažkuriuo momentu staiga supranti – o gal išgirsi iš ko nors – kad gal Framework iš viso nesuteiks suderinamumo su funkcija X. Galbūt visas tas laikas ir pastangos buvo tam skirtos visiškai neteisingai.
Kažkas panašaus nutiko kartą dirbant prie projekto, už kurį buvau atsakinga. Kodėl taip atsitiko? Nes mažai supratau, kas yra X funkcija ir kaip ji susijusi su F karkasu. Ką turėjau daryti? Paprašykite kūrimo užduotį skiriančio asmens aiškiai paaiškinti, kaip numatyta veiksmų eiga veda prie norimo rezultato, o ne paprasčiausiai kartoti, kas buvo padaryta kitiems moduliams, arba sakyti, kad būtent tai turi padaryti X funkcija.
Šio projekto patirtis išmokė mane atsisakyti pradėti kūrimo procesą, kol aiškiai nesuvoksime, kodėl mūsų prašoma atlikti tam tikrus dalykus. Atsisakykite kategoriškai. Gavus užduotį pirmas impulsas – nedelsiant jos imtis, kad nešvaistytų laiko. Tačiau politika „užšaldyti projektą, kol įsigilinsime į visas detales“ gali sumažinti sugaištą laiką daugybe dydžių.
Net jei jie bando daryti spaudimą, priversti pradėti darbą, nors nesuprantate to pagrindo, priešinkitės. Pirmiausia išsiaiškinkite, kodėl jums duota tokia užduotis, ir nuspręskite, ar tai teisingas kelias į tikslą. Viso to turėjau išmokti sunkiai – tikiuosi, kad mano pavyzdys palengvins gyvenimą tiems, kurie tai skaito.
Ketvirtas supratimo lygis: ???
Programavimo srityje visada galima išmokti daugiau, ir manau, kad supratimo temos paviršių tik subraičiau. Kokius kitus supratimo lygius atradote per daugelį metų dirbdami su kodu? Kokius sprendimus padarėte, kurie turėjo teigiamos įtakos kodo ir programos kokybei? Kokie sprendimai pasirodė neteisingi ir išmokė jums vertingos pamokos? Pasidalinkite savo patirtimi komentaruose.
Šaltinis: www.habr.com