QĂ« nga fillimi i vitit 2018, unĂ« mbaj pozitat e liderit/kryetarit/zhvilluesit tĂ« avancuar nĂ« ekip â quajeni si tĂ« doni, por thelbi Ă«shtĂ« se unĂ« kam pĂ«rgjegjĂ«sinĂ« totale pĂ«r njĂ« nga modulet dhe pĂ«r tĂ« gjithĂ« zhvilluesit qĂ« punojnĂ« mbi tĂ«. Ky pozicion mĂ« ofron njĂ« perspektivĂ« tĂ« re mbi procesin e zhvillimit, pasi jam i angazhuar nĂ« njĂ« numĂ«r mĂ« tĂ« madh projektesh dhe marr pjesĂ« mĂ« aktivisht nĂ« marrjen e vendimeve. SĂ« fundmi, falĂ« kĂ«tyre dy rrethanave, papritur kuptova se sa shumĂ« niveli i kuptimit ndikon nĂ« kod dhe nĂ« aplikacion.
Mendimi që dua të shpreh është se cilësia e kodit (dhe e produktit përfundimtar) është ngushtë e lidhur me aq sa njerëzit që merren me projektimin dhe shkruajnë kodin e kuptojnë atë që po bëjnë.
Ndoshta tani po mendoni: "Faleminderit, kap. Sigurisht, do ishin të dobishme të kuptoje se çfarë po shkruan. Në të kundërt, mund të punësojmë një grup majmunësh që të godasin çelësat rastësisht dhe të qetësohemi me këtë." Dhe keni të drejtë. Prandaj, e pranoj si një fakt të gatshëm: ju e kuptoni se është e domosdoshme të keni një përmbledhje të përbashkët të asaj që bëni. Këtë mund ta quajmë nivelin zero të kuptimit, dhe nuk do ta shqyrtojmë atë në detaje. Në vend të kësaj, do të analizojmë se çfarë saktësisht duhet të kuptoni dhe si ndikon këto në vendimet që merrni çdo ditë. Nëse do isha njohur me këto gjëra më herët, do të më kishte kursyer një sasi të madhe kohë të humbur dhe kod të dyshimtë.
Megjithëse keni parasysh se nuk do të shihni asnjë rresht kodi këtu, akoma mendoj se gjithçka që është thënë këtu ka një rëndësi të madhe për shkruan kod të cilësisë së lartë dhe të shprehshëm.
Niveli i parë i kuptimit: Pse nuk funksionon?
Ky nivel zakonisht arrin zhvilluesit nĂ« fazat mĂ« tĂ« hershme tĂ« karrierĂ«s sĂ« tyre, ndonjĂ«herĂ« madje pa ndihmĂ«n e askujt â tĂ« paktĂ«n sipas vĂ«zhgimeve tĂ« mia. Imagjinoni se keni marrĂ« njĂ« raport pĂ«r gabime: njĂ« funksion nĂ« aplikacion nuk funksionon, duhet ta riparoni. Si do tĂ« veproni?
Skema standarde duket kështu:
- Të identifikoni fragmentin e kodit që shkakton problemin (si ta bëni këtë është një temë e veçantë, e cila e zbuloj në librin tim për kodin obsolett)
- Të bëni ndryshime në atë fragment
- Të siguroheni që gabimi është rregulluar dhe nuk ka ndodhur ndonjë gabim regresiv
Tani le tĂ« pĂ«rqendrohemi nĂ« pikĂ«n e dytĂ« â bĂ«rjen e ndryshimeve nĂ« kod. EkzistojnĂ« dy qasje ndaj kĂ«tij procesi. E para: tĂ« kuptoni se çfarĂ« saktĂ«sisht po ndodh nĂ« kodin aktual, tĂ« identifikoni gabimin dhe ta rregulloni atĂ«. E dyta: tĂ« avanconi nĂ« mĂ«nyrĂ« tĂ« rastĂ«sishme â tĂ« shtoni, pĂ«r shembull, +1 nĂ« njĂ« operator kushtor ose cikĂ«l, tĂ« shihni nĂ«se funksioni ka filluar tĂ« punojĂ« nĂ« skenarin e kĂ«rkuar, pastaj tĂ« provoni diçka tjetĂ«r dhe kĂ«shtu deri nĂ« pafundĂ«si.
Qasja e saktë është e para. Siç shpjegon Steve McConnell në librin e tij Code Complete (në fakt, e rekomandoj shumë), çdo herë që ne bëjmë ndonjë ndryshim në kod, duhet të jemi në gjendje të parashikojmë me siguri se si do të ndikojë kjo në aplikacion. Citoj nga kujtesa, por nëse riparimi i gabimit nuk funksionon ashtu siç e prisnit, kjo duhet t'ju shqetësojë; duhet ta vënë në pikëpyetje gjithë planin tuaj të veprimit.
Kështu, për të kryer një riparim të mirë të gabimeve që nuk do ta përkeqësojë cilësinë e kodit, duhet të kuptoni si strukturën e kodit ashtu edhe burimin e problemit të veçantë.
Niveli i dytë i kuptimit: Pse funksionon?
Ky nivel arrihet shumë më pak intuitivisht se sa ai i mëparshmi. Ndërsa isha ende një zhvillues i ri, e kuptova atë nga shefi im, dhe më vonë disa herë e shpjegova thelbin e tij fillestarëve.
Këtë herë le të imagjinojmë se ju keni pranuar menjëherë dy raportet për gabime: në të parin flitet për skenarin A, në të dytin për skenarin B. Në të dy skenarët ndodh diçka e gabuar. Prandaj, filloni së pari me gabimin e parë. Duke u udhëhequr nga parimet që kemi nxjerrë për nivelin e parë të kuptimit, ju thelloheni në kodin që lidhet me problemin, zbuloni pse ai e detyron aplikacionin të sillet kështu në skenarin A dhe bëni ndryshime të arsyeshme që japin saktësisht atë rezultat që prisnit. Gjithçka shkon shkëlqyeshëm.
Pastaj kaloni nĂ« skenarin B. Ju pĂ«rsĂ«risni skenarin nĂ« njĂ« pĂ«rpjekje pĂ«r tĂ« provokuar gabimin, por â surprizĂ«! â tani gjithçka funksionon si duhet. NĂ« mĂ«nyrĂ« pĂ«r tĂ« konfirmuar hipotezĂ«n tuaj, ju anulloni ndryshimet e bĂ«ra gjatĂ« punĂ«s mbi gabimin A dhe gabimi B kthehet pĂ«rsĂ«ri. Riparimi juaj i gabimit zgjidhi tĂ« dy problemet. Fat i mirĂ«!
Nuk e kishit pritur këtë. Keni gjetur një mënyrë për të riparuar gabimin në skenarin A dhe nuk keni asnjë ide se pse ka funksionuar për skenarin B. Në këtë fazë, temptimi për të vendosur se të dy detyrat janë plotësuar me sukses është shumë i madh. Kjo është krejtësisht logjike: qëllimi ishte të hiqnim gabimet, apo jo? Por puna nuk ka mbaruar akoma: ju ende duhet të kuptoni pse veprimet tuaja riparuan gabimin në skenarin B. Pse? Sepse, ndoshta, ai po funksionon në parime të gabuara, dhe atëherë do të duhet të kërkoni një zgjidhje tjetër. Ja disa shembuj të tillë:
- pasi zgjidhja nuk ishte mundësuar me qëllim për gabimin B duke marrë parasysh të gjithë faktorët, ndoshta pa e kuptuar keni prishur funksionin C.
- nuk përjashtohet se ndonjëherë aty ndodhet edhe një gabim i tretë, i lidhur me të njëjtin funksion, dhe riparimi juaj e lidh funksionimin e saktë të sistemit në skenarin B me të. Tani gjithçka duket mirë, por një ditë të bukur do të zbuloni atë gabimin e tretë dhe do të riparohet. Atëherë në skenarin B do të shfaqet përsëri një gabim, dhe mirë është nëse vetëm aty.
TĂ« gjitha kĂ«to sjellin kaos nĂ« kod dhe njĂ« ditĂ« do t'ju bien nĂ« kokĂ« â me siguri nĂ« momentin mĂ« tĂ« papĂ«rshtatshĂ«m. Do t'ju duhet tĂ« mblidhni vullnetin pĂ«r tĂ« detyruar veten tĂ« kaloni kohĂ« duke kuptuar pse gjithçka duket se funksionon, por ia vlen.
Niveli i tretë i kuptimit: Pse funksionon?
Një zbulim i fundit i imi lidhet pikërisht me këtë nivel, dhe ndoshta do të më kishte dhënë më shumë përfitime, nëse do të kishim arritur në këtë mendim më herët.
Për të qenë më të qartë, le të marrim një shembull: moduli juaj duhet të bëhet i përshtatshëm për funksionin X. Nuk jeni shumë të njohur me funksionin X, por ju është thënë se për t'u bërë i përshtatshëm me të duhet të përdorni kornizën F. Module të tjera që integrohen me X funksionojnë pikërisht me të.
Kodi juaj qĂ« nga dita e parĂ« nuk ka pasur tĂ« bĂ«jĂ« fare me kornizĂ«n F, prandaj implementimi i saj do tĂ« jetĂ« mjaft i vĂ«shtirĂ«. Kjo do tĂ« ketĂ« pasoja tĂ« rĂ«ndĂ«sishme pĂ«r disa komponentĂ« tĂ« modulit. MegjithatĂ«, ju angazhoheni plotĂ«sisht nĂ« zhvillim: pĂ«r javĂ« tĂ« tĂ«ra shkruani kod, testoni, publikoni versione pilot, merrni reagime, rregulloni gabimet regresive, zbuloni komplikime tĂ« papritura, nuk pĂ«rshtateni nĂ« afatet fillestare, shkruani akoma disa kode, testoni, merrni feedback, rregulloni gabimet regresive â e gjithĂ« kjo pĂ«r tĂ« implementuar kornizĂ«n F.
Dhe nĂ« njĂ« moment, ju papritur e kuptoni â ose ndoshta dĂ«gjoni nga dikush â se ndoshta korniza F nuk do t'ju japĂ« fare pĂ«rshtatshmĂ«ri me funksionin X. Ndoshta, gjithĂ« ky kohĂ« dhe energji u shpenzua pĂ«r njĂ« gjĂ« tĂ« gabuar.
NjĂ« gjĂ« e tillĂ« ndodhi njĂ« herĂ« gjatĂ« punĂ«s nĂ« njĂ« projekt pĂ«r tĂ« cilin isha pĂ«rgjegjĂ«s. Pse ndodhi kĂ«shtu? Sepse nuk e kuptoja mirĂ« se çfarĂ« ishte thelbi i funksionit X dhe si lidhej ai me kornizĂ«n F. ĂfarĂ« duhej tĂ« kisha bĂ«rĂ«? TĂ« kĂ«rkoja nga ai qĂ« jepia detyrĂ«n e zhvillimit tĂ« mĂ« shpjegonte qartĂ« se si plani i veprimit do tĂ« sillte rezultatin e dĂ«shiruar, nĂ« vend qĂ« thjesht tĂ« pĂ«rsĂ«risja atĂ« qĂ« ishte bĂ«rĂ« pĂ«r module tĂ« tjera, ose tĂ« besoja se ishte e nevojshme pĂ«r funksionin X.
Përvoja e këtij projekti më mësoi të refuzoj të filloj procesin e zhvillimit derisa të kem një kuptim të qartë se përse na kërkohet të kryejmë këto veprime. Të refuzoj në mënyrë të drejtpërdrejtë. Kur merrni një detyrë, impulsi i parë është të filloni menjëherë, për të mos humbur kohë. Por politika "ngrirje e projektit, derisa të hyjmë në të gjitha detajet" mund të reduktojë kohet e humbura me shumë herë.
Edhe nĂ«se ju bĂ«jnĂ« presion, pĂ«rpjekje pĂ«r tĂ« filluar punĂ«n, edhe pse nuk e kuptoni se pĂ«rse, rezistoni. SĂ« pari, kuptoni se çfarĂ« qĂ«llimi ka detyra qĂ« ju Ă«shtĂ« dhĂ«nĂ«, dhe vendosni nĂ«se Ă«shtĂ« rruga e duhur pĂ«r arritjen e qĂ«llimit. MĂ« Ă«shtĂ« dashur tĂ« mĂ«soj gjithĂ« kĂ«tĂ« pĂ«rmes pĂ«rvojĂ«s sĂ« hidhur â shpresoj se pĂ«r ata qĂ« po e lexojnĂ«, shembulli im do t'iu lehtĂ«sojĂ« jetĂ«n.
Niveli i katërt i kuptimit: ???
Në programim gjithmonë ka për të mësuar, dhe besoj se sapo kam prekur sipërfaqet më të larta të temës së kuptimit. Cilat janë nivelet e tjera të kuptimit që keni zbuluar gjatë viteve të punës me kodin? Cilat vendimeve keni marrë, të cilat kishin një efekt pozitiv në cilësinë e kodit dhe aplikacionit? Cilat vendimeve rezultuan të gabuara dhe ju dhanë një mësim të vlefshëm? Ndani përvojën tuaj në komentet.
Burimi: habr.com
