Që nga fillimi i vitit 2018, unë mbaj pozicionin e drejtuesit/shefit/zhvilluesit kryesor në ekip - quani si të doni, por çështja është se unë jam plotësisht përgjegjës për një nga modulet dhe për të gjithë zhvilluesit që punojnë në të. Ky pozicion më jep një këndvështrim të ri në procesin e zhvillimit, pasi jam i përfshirë në më shumë projekte dhe më aktivisht në vendimmarrje. Kohët e fundit, falë këtyre dy gjërave, papritmas kuptova se sa ndikon masa e të kuptuarit në kod dhe në aplikacion.
Pika që dua të theksoj është se cilësia e kodit (dhe produkti përfundimtar) lidhet ngushtë me atë se sa të vetëdijshëm janë njerëzit që po hartojnë dhe shkruajnë kodin për atë që po bëjnë.
Ju mund të jeni duke menduar tani, “Faleminderit, Kap. Sigurisht, do të ishte mirë të kuptoni atë që po shkruani në përgjithësi. Përndryshe, ju gjithashtu mund të punësoni një grup majmunësh për të goditur çelësat arbitrar dhe ta lini atë me kaq." Dhe keni absolutisht të drejtë. Prandaj, e marr si të mirëqenë që ti e kupton se është e nevojshme të kesh një ide të përgjithshme për atë që po bën. Ky mund të quhet niveli zero i të kuptuarit, dhe ne nuk do ta analizojmë atë në detaje. Ne do të shikojmë në detaje se çfarë saktësisht duhet të kuptoni dhe si ndikon në vendimet që merrni çdo ditë. Nëse do t'i kisha ditur këto gjëra paraprakisht, do të më kishte kursyer shumë kohë të humbur dhe kod të dyshimtë.
Megjithëse nuk do të shihni asnjë rresht të vetëm kodi më poshtë, unë ende besoj se gjithçka që thuhet këtu është e një rëndësie të madhe për të shkruar një kod me cilësi të lartë dhe shprehës.
Niveli i parë i të kuptuarit: Pse nuk funksionon?
Zhvilluesit zakonisht e arrijnë këtë nivel shumë herët në karrierën e tyre, ndonjëherë edhe pa ndonjë ndihmë nga të tjerët - të paktën në përvojën time. Imagjinoni që keni marrë një raport gabimi: disa funksione në aplikacion nuk funksionojnë, duhet të rregullohen. Si do të vazhdoni?
Skema standarde duket si kjo:
- Gjeni pjesën e kodit që po shkakton problemin (si ta bëni këtë është një temë më vete, unë e mbuloj atë në librin tim rreth kodit të trashëguar)
- Bëj ndryshime në këtë fragment
- Sigurohuni që defekti është rregulluar dhe nuk ka pasur gabime regresioni
Tani le të përqendrohemi në pikën e dytë - duke bërë ndryshime në kod. Ekzistojnë dy qasje ndaj këtij procesi. E para është të hulumtoni se çfarë saktësisht po ndodh në kodin aktual, të identifikoni gabimin dhe ta rregulloni atë. Së dyti: lëvizni sipas ndjesisë - shtoni, le të themi, +1 në një deklaratë të kushtëzuar ose lak, shikoni nëse funksioni funksionon në skenarin e dëshiruar, pastaj provoni diçka tjetër, e kështu me radhë ad infinitum.
Qasja e parë është e saktë. Siç shpjegon Steve McConnell në librin e tij Code Complete (që unë e rekomandoj shumë, meqë ra fjala), sa herë që ndryshojmë diçka në kod, duhet të jemi në gjendje të parashikojmë me besim se si do të ndikojë në aplikacion. Po citoj nga kujtesa, por nëse një korrigjim i gabimeve nuk funksionon ashtu siç e prisnit, duhet të jeni shumë të alarmuar dhe duhet të vini në dyshim të gjithë planin tuaj të veprimit.
Për të përmbledhur atë që u tha, për të kryer një rregullim të mirë të gabimeve që nuk degradon cilësinë e kodit, duhet të kuptoni të gjithë strukturën e kodit dhe burimin e problemit specifik.
Niveli i dytë i të kuptuarit: Pse funksionon?
Ky nivel është kuptuar shumë më pak intuitivisht se ai i mëparshmi. Unë, ndërsa ishte ende një zhvillues fillestar, e mësova atë falë shefit tim, dhe më pas u shpjegova vazhdimisht thelbin e çështjes të ardhurve.
Këtë herë, le të imagjinojmë se keni marrë dy raporte të gabimeve në të njëjtën kohë: i pari ka të bëjë me skenarin A, i dyti ka të bëjë me skenarin B. Në të dy skenarët, diçka e gabuar ndodh. Prandaj, ju së pari trajtoni defektin e parë. Duke përdorur parimet që kemi zhvilluar për kuptimin e Nivelit 1, ju gërmoni thellë në kodin që lidhet me problemin, kuptoni pse ai bën që aplikacioni të sillet ashtu siç vepron në Skenarin A dhe bëni rregullime të arsyeshme që prodhojnë rezultatin që dëshironi. . Gjithçka po shkon shkëlqyeshëm.
Më pas kaloni në skenarin B. Ju e përsëritni skenarin në përpjekje për të provokuar një gabim, por - befasi! - Tani gjithçka funksionon siç duhet. Për të konfirmuar supozimin tuaj, ju zhbëni ndryshimet që keni bërë gjatë punës me defektin A dhe defekti B kthehet. Rregullimi juaj i gabimeve i zgjidhi të dyja problemet. Me fat!
Nuk llogarite fare në këtë. Ju keni gjetur një mënyrë për të rregulluar gabimin në skenarin A dhe nuk e keni idenë pse funksionoi për skenarin B. Në këtë fazë, është shumë joshëse të mendosh se të dyja detyrat janë përfunduar me sukses. Kjo është mjaft logjike: çështja ishte eliminimi i gabimeve, apo jo? Por puna nuk ka përfunduar ende: duhet të kuptoni se pse veprimet tuaja korrigjuan gabimin në skenarin B. Pse? Sepse mund të jetë duke punuar në parime të gabuara, dhe atëherë do t'ju duhet të kërkoni një rrugëdalje tjetër. Këtu janë disa shembuj të rasteve të tilla:
- Meqenëse zgjidhja nuk ishte përshtatur për gabimin B, duke marrë parasysh të gjithë faktorët, mund të keni prishur pa e ditur funksionin C.
- Është e mundur që diku fshihet edhe një defekt i tretë, i lidhur me të njëjtin funksion, dhe rregullimi juaj i gabimeve varet prej tij për funksionimin e saktë të sistemit në skenarin B. Gjithçka duket mirë tani, por një ditë ky gabim i tretë do të vihet re dhe do të rregullohet. Pastaj në skenarin B gabimi do të ndodhë përsëri, dhe është mirë nëse vetëm atje.
E gjithë kjo shton kaos në kod dhe një ditë do të bjerë mbi kokën tuaj - ka shumë të ngjarë në momentin më të papërshtatshëm. Do t'ju duhet të grumbulloni vullnetin tuaj për të detyruar veten të shpenzoni kohë duke kuptuar pse gjithçka duket se funksionon, por ia vlen.
Niveli i tretë i të kuptuarit: Pse funksionon?
Vështrimi im i fundit lidhet pikërisht me këtë nivel, dhe ndoshta është ai që do të më kishte dhënë më shumë përfitime nëse do të kisha ardhur në këtë ide më herët.
Për ta bërë më të qartë, le të shohim një shembull: moduli juaj duhet të bëhet i pajtueshëm me funksionin X. Ju nuk jeni veçanërisht të njohur me funksionin X, por ju është thënë se për të qenë i pajtueshëm me të duhet të përdorni kornizën F. Të tjera modulet që integrohen me X punojnë pikërisht me të.
Kodi juaj nuk ka qenë fare në kontakt me kornizën F që nga dita e parë e jetës së tij, kështu që zbatimi i tij nuk do të jetë aq i lehtë. Kjo do të ketë pasoja serioze për disa pjesë të modulit. Megjithatë, ju hidheni në zhvillim: kaloni javë të tëra duke shkruar kode, testuar, nxjerrni versionet pilot, merrni komente, rregulloni gabimet e regresionit, zbuloni komplikime të paparashikuara, nuk përmbushni afatet e rëna dakord fillimisht, shkruani disa kode të tjera, testoni, merrni komunikim reagimesh, korrigjimi i gabimeve të regresionit - e gjithë kjo për të zbatuar kornizën F.
Dhe në një moment ju e kuptoni papritur - ose ndoshta dëgjoni nga dikush - se ndoshta korniza F nuk do t'ju japë fare përputhshmëri me veçorinë X. Ndoshta e gjithë ajo kohë dhe përpjekje është bërë krejtësisht e gabuar për këtë.
Diçka e ngjashme ndodhi një herë gjatë punës në një projekt për të cilin unë isha përgjegjës. Pse ndodhi kjo? Sepse e kuptoja pak se cili ishte funksioni X dhe si lidhej ai me kornizën F. Çfarë duhet të kisha bërë? Kërkojini personit që cakton detyrën e zhvillimit të shpjegojë qartë se si drejtimi i synuar i veprimit çon në rezultatin e dëshiruar, në vend që thjesht të përsërisë atë që është bërë për modulet e tjera ose të marrë fjalën e tij se kjo është ajo që veçoria X duhet të bëjë.
Përvoja e këtij projekti më mësoi të refuzoja fillimin e procesit të zhvillimit derisa të kemi një kuptim të qartë se përse na kërkohet të bëjmë disa gjëra. Refuzoni drejtpërdrejt. Kur merrni një detyrë, impulsi i parë është ta merrni menjëherë për të mos humbur kohë. Por politika e "ngrirjes së projektit derisa të futemi në të gjitha detajet" mund të zvogëlojë kohën e humbur me urdhra të përmasave.
Edhe nëse përpiqen t'ju bëjnë presion, t'ju detyrojnë të filloni punën, megjithëse nuk e kuptoni arsyen për këtë, rezistoni. Së pari, kuptoni pse po ju jepet një detyrë e tillë dhe vendosni nëse kjo është rruga e duhur drejt qëllimit. Më është dashur t'i mësoj të gjitha këto në mënyrën e vështirë - shpresoj se shembulli im do ta bëjë jetën më të lehtë për ata që e lexojnë këtë.
Niveli i katërt i të kuptuarit: ???
Gjithmonë ka më shumë për të mësuar në programim dhe besoj se e kam gërvishtur vetëm sipërfaqen e temës së të kuptuarit. Çfarë nivelesh të tjera të të kuptuarit keni zbuluar gjatë viteve të punës me kodin? Çfarë vendimesh morët që patën një ndikim pozitiv në cilësinë e kodit dhe aplikimit? Cilat vendime rezultuan të gabuara dhe ju dhanë një mësim të vlefshëm? Ndani përvojën tuaj në komente.
Burimi: www.habr.com