QĂ« nga fillimi i vitit 2018, unĂ« kam marrĂ« postin e liderit/drejtorit/tĂ« zhvilluesit tĂ« avancuar nĂ« ekip â quajeni si tĂ« doni, por e rĂ«ndĂ«sishme Ă«shtĂ« se unĂ« plotĂ«sisht jam pĂ«rgjegjĂ«s pĂ«r njĂ« nga moduli dhe pĂ«r tĂ« gjithĂ« zhvilluesit qĂ« punojnĂ« mbi tĂ«. Ky pozicion mĂ« hap njĂ« perspektivĂ« tĂ« re mbi procesin e zhvillimit, pasi jam i angazhuar nĂ« mĂ« shumĂ« projekte dhe marr pjesĂ« mĂ« aktivisht nĂ« vendimmarrje. SĂ« fundmi, falĂ« kĂ«tyre dy rrethanave, papritur e kuptova sa shumĂ« niveli i kuptimit ndikon nĂ« kod dhe nĂ« aplikacion.
Mendimi që dua të shpreh lidhet me faktin se cilësia e kodit (dhe e produktit përfundimtar) është ngushtë e lidhur me atë se sa njerëzit që merren me dizajnimin dhe shkruajnë kodin janë të vetëdijshëm për atë që po bëjnë.
Ndoshta tani po mendoni: "Faleminderit, kapiten. Sigurisht, do të ishte mirë të kuptoje çfarë po shkruan. Ndryshe, me të njëjtin sukses mund të angazhojmë një grup majmunësh që të godasë rastësisht në tastierë dhe të qetësohemi me këtë." Dhe keni plotësisht të drejtë. Ndaj, e pranoj si një të dhënë: ju e kuptoni se të kesh një kuptim të përgjithshëm për atë që bën është e nevojshme. Kjo mund të quhet niveli zero i kuptimit, dhe ne nuk do ta shqyrtojmë atë në detaje. Do të shqyrtojmë në detaje se çfarë saktësisht duhet të kuptosh dhe si ndikon kjo në vendimet që merr çdo ditë. Nëse do ta dija këto gjëra paraprakisht, do të më kishte kursyer një sasi të madhe kohë të humbur dhe kod të dyshimtë.
Pavarësisht se nuk do të shihni asnjë rresht kodin më poshtë, unë akoma mendoj se gjithçka që thuhen këtu ka rëndësi të madhe për shkruarjen e një kodi cilësor dhe ekspresiv.
Niveli i parë i kuptimit: Pse nuk funksionon?
Zhvilluesit zakonisht arrijnĂ« nĂ« kĂ«tĂ« nivel nĂ« fazat mĂ« tĂ« hershme tĂ« karrierĂ«s sĂ« tyre, ndonjĂ«herĂ« madje edhe pa ndihmĂ«n e tĂ« tjerĂ«ve â tĂ« paktĂ«n sipas vĂ«zhgimeve tĂ« mia. Imagjinoni se keni marrĂ« njĂ« raport tĂ« defektit: njĂ« funksion nĂ« aplikacion nuk funksionon, dhe duhet ta rregulloni. Si do tĂ« veproni?
Skema standarde duket kështu:
- TĂ« gjeni fragmentin e kodit qĂ« shkakton problemin (si tĂ« bĂ«het kjo â Ă«shtĂ« njĂ« temĂ« e veçantĂ«, e cila e trajtoj nĂ« librin tim pĂ«r kodin e vjetĂ«r)
- Të bëni ndryshime në këtë fragment
- Të siguroheni se defekti është korrigjuar dhe se nuk ka ndodhur ndonjë gabim regresiv
Tani do tĂ« pĂ«rqendrohemi nĂ« pikĂ«n e dytĂ« â ndryshimin e kodit. Ka dy qasje pĂ«r kĂ«tĂ« proces. E para: tĂ« kuptosh saktĂ«sisht se çfarĂ« po ndodh nĂ« kodin aktual, tĂ« identifikosh gabimin dhe ta korrigjosh atĂ«. E dyta: tĂ« ecĂ«sh nĂ« errĂ«sirĂ« â tĂ« shtosh, pĂ«r shembull, +1 nĂ« operatorin kusht ose nĂ« cikĂ«l, tĂ« shohĂ«sh nĂ«se kjo funksionon nĂ« skenarĂ«t qĂ« nevojiten, pastaj tĂ« provosh ndonjĂ« gjĂ« tjetĂ«r dhe kĂ«shtu deri nĂ« pafundĂ«si.
Qasja e saktë është ajo e parë. Siç shpjegon Steve McConnell në librin e tij Code Complete (për lehtësim, e rekomandoj shumë), sa herë që ne ndryshojmë diçka në kod, duhet të jemi në gjendje të parashikojmë me besim se si do të ndikojë kjo në aplikacion. Po citoj nga memoria, por nëse rregullimi i gabimit nuk rezulton ashtu siç e kishe pritur, kjo duhet të të shqetësojë shumë, duhet të vësh në dyshim të gjithë planin tënd të veprimit.
Duke përmbledhur, për të kryer një rregullim të mirë të gabimeve, i cili nuk do të dëmtojë cilësinë e kodit, duhet të kuptosh si strukturën e kodit, ashtu edhe burimin e problemit të veçantë.
Niveli i dytë i kuptimit: Pse funksionon kjo?
Ky nivel arrin të kuptohet shumë më pak intuitivisht se niveli i mëparshëm. Unë, duke qenë ende një zhvillues i ri, e kuptova këtë falë shefit tim, dhe më pas shpesh e kam shpjeguar thelbin e kësaj çështjeje fillestarëve.
Tani le tĂ« imagjinojmĂ« se keni marrĂ« njĂ«kohĂ«sisht dy raportime pĂ«r gabime: nĂ« tĂ« parin flitet pĂ«r skenarin A, dhe nĂ« tĂ« dytin â pĂ«r skenarin B. NĂ« tĂ« dy rastet ndodh diçka e gabuar. Prandaj, sĂ« pari merresh me gabimin e parĂ«. Duke u udhĂ«hequr nga parimet qĂ« nxorrĂ«m pĂ«r nivelin e parĂ« tĂ« kuptimit, ju futeni thellĂ« nĂ« kodin qĂ« ka lidhje me problemin, e kuptoni pse ai e bĂ«n aplikacionin tĂ« sillet ashtu siç sillet nĂ« skenarin A, dhe bĂ«ni ndryshime tĂ« arsyeshme qĂ« japin pikĂ«risht rezultatin qĂ« prisnit. Gjithçka shkon mrekullueshĂ«m.
Pastaj kaloni te skenari B. E pĂ«rsĂ«risni skenarin nĂ« pĂ«rpjekje pĂ«r tĂ« provokuar gabimin, por â surprizĂ«! â tani gjithçka funksionon siç duhet. PĂ«r tĂ« konfirmuar dyshimin tuaj, anuloni ndryshimet e bĂ«ra gjatĂ« punĂ«s mbi gabimin A, dhe gabimi B riaktualizohet. Rregullimi juaj zgjidhi tĂ« dy problemet. Fat i mirĂ«!
Nuk e kishit pritur kurrë këtë. Keni gjetur një mënyrë për të riparuar gabimin në skenarin A dhe nuk keni asnjë ide pse ka funksionuar edhe për skenarin B. Në këtë pikë, tundimi është i madh për të vendosur se të dyja detyrat janë finalizuar me sukses. Kjo është logjike: qëllimi ishte të eliminohen gabimet, apo jo? Por puna ende nuk ka përfunduar: ju duhet të kuptoni pse veprimet tuaja e korrigjuan gabimin në skenarin B. Pse? Sepse, ndoshta, ai punon mbi parime të gabuara, dhe atëherë do t'ju duhet të kërkoni një zgjidhje tjetër. Ja disa shembuj të tillë.
- pasi zgjidhja nuk u përzgjodh saktësisht për gabimin B duke marrë parasysh të gjithë faktorët, ndoshta pa e ditur, keni prishur funksionin C.
- nuk përjashtohet që ndoshta ndodhet edhe një gabim i tretë, i lidhur me të njëjtin funksion, dhe riparimi juaj i gabimit lidh funksionimin e duhur të sistemit në skenarin B me të. Tani gjithçka duket mirë, por në një moment të bukur këtë gabim të tretë do ta vënë re dhe do ta riparojnë. Pastaj, në skenarin B do të shfaqet përsëri një gabim, dhe shpresojmë se vetëm atje.
TĂ« gjitha kĂ«to sjellin haos nĂ« kod dhe njĂ« ditĂ« do t'ju bien nĂ« krye â shumĂ« ndoshta, nĂ« momentin mĂ« tĂ« papĂ«rshtatshĂ«m. Do t'ju duhet tĂ« mbledhni vullnetin pĂ«r t'u detyruar tĂ« ndani kohĂ« pĂ«r tĂ« kuptuar pse gjithçka duket se funksionon, por ia vlen.
Niveli i tretë i kuptimit: Pse funksionon?
Ahaime të fundit lidhet pikërisht me këtë nivel, dhe ndoshta ky do të më jepte më shumë përfitime, nëse do të më vinte kjo mendim më herët.
Për ta bërë më të qartë, le të shqyrtojmë një shembull: moduli juaj duhet të bëhet kompatibil me funksionin X. Nuk jeni shumë të njohur me funksionin X, por ju është thënë se për të qenë kompatibil me të, duhet të përdorni framework-un F. Modul të tjerë që integrohen me X, punojnë pikërisht me të.
Kodi juaj nga dita e parĂ« e jetĂ«s sĂ« tij nuk ka qenĂ« nĂ« asnjĂ« moment nĂ« kontakt me kuadrin F, prandaj implementimi i tij nuk do tĂ« jetĂ« aq i lehtĂ«. Kjo do tĂ« ketĂ« pasoja serioze pĂ«r disa pĂ«rbĂ«rĂ«s tĂ« modulit. MegjithatĂ«, ju jeni plotĂ«sisht tĂ« angazhuar nĂ« zhvillim: kaloni javĂ« duke shkruar kod, testoni, publikoni versione pilot, merrni reagime, korrigjoni gabimet regresive, zbuloni komplikacione tĂ« papritura, nuk pĂ«rfshiheni nĂ« afatet fillestare, shkruani akoma ca kod, testoni, merrni feedback, korrigjoni gabimet regresive â gjithĂ« kjo pĂ«r tĂ« implementuar kuadrin F.
Dhe nĂ« njĂ« moment ju papritmas e kuptoni â ose ndoshta e dĂ«gjoni nga dikush â se ndoshta kuadrin F nuk do t'ju japĂ« atij pĂ«rputhshmĂ«ri me funksionin X. Ndoshta tĂ« gjitha kĂ«to kohĂ« dhe forca ishin tĂ« investuara krejtĂ«sisht gabim.
NjĂ« gjĂ« e tillĂ« ndodhi njĂ«herĂ« gjatĂ« punĂ«s nĂ« njĂ« projekt pĂ«r tĂ« cilin unĂ« isha pĂ«rgjegjĂ«s. Pse ndodhi kĂ«shtu? Sepse nuk e kuptoja mirĂ« se çfarĂ« pĂ«rfshin funksioni X dhe si lidhet ai me kuadrin F. ĂfarĂ« duhej tĂ« kisha bĂ«rĂ«? TĂ« kĂ«rkoja nga personi qĂ« jep detyrĂ«n pĂ«r zhvillim tĂ« shpjegonte qartĂ« se si plani i propozuar çon nĂ« rezultatin e dĂ«shiruar, nĂ« vend qĂ« thjesht tĂ« pĂ«rsĂ«risja atĂ« qĂ« ishte bĂ«rĂ« pĂ«r module tĂ« tjera, apo tĂ« besoja verbĂ«risht se kĂ«shtu duhet pĂ«r funksionin X.
Përvoja e këtij projekti më mësoi të refuzoj të filloj procesin e zhvillimit derisa të kemi një kuptim të qartë për arsyen pse na kërkohet të kryejmë veprime të caktuara. Të refuzoj me fjalë të drejtpërdrejta. Kur merr detyrën, impulsi i parë është të fillosh menjëherë me të, që të mos humbasësh kohë kot. Por politika "ndalojmë projektin derisa të mësojmë të gjitha detajet" mund të reduktojë ndjeshëm kohën e humbur.
Edhe nĂ«se ju ushtrohet presion pĂ«r tĂ« filluar punĂ«n, edhe pse nuk e kuptoni arsyen â qĂ«ndroni fort. Fillimisht kuptoni, pĂ«r çfarĂ« qĂ«llimi kĂ«rkohet njĂ« detyrĂ« e tillĂ« nga ju, dhe vendosni nĂ«se Ă«shtĂ« rruga e duhur pĂ«r tĂ« arritur qĂ«llimin. MĂ« Ă«shtĂ« dashur ta kuptoj kĂ«tĂ« pĂ«rmes pĂ«rvojĂ«s sĂ« hidhur â shpresoj se pĂ«r ata qĂ« e lexojnĂ«, shembulli im do ta lehtĂ«sojĂ« jetĂ«n.
Niveli i katërt i kuptimit: ???
Programimi ka gjithmonĂ« diçka pĂ«r tĂ« mĂ«suar, dhe mendoj se vetĂ«m kam prekur sipĂ«rfaqen e temĂ«s sĂ« kuptimit. ĂfarĂ« nivele tĂ« tjera kuptimi keni zbuluar gjatĂ« viteve tuaj me kodin? Cilat vendime keni marrĂ« qĂ« kanĂ« ndikuar pozitivisht nĂ« cilĂ«sinĂ« e kodit dhe aplikacionit? Cilat vendime janĂ« bĂ«rĂ« gabim dhe ju kanĂ« mĂ«suar njĂ« mĂ«sim tĂ« vyer? Ndani pĂ«rvojĂ«n tuaj nĂ« komentet.
Burimi: habr.com
