Fuqia e madhe e kërkesave për tërheqje të vogla: Si përmirësojnë rishikimet dhe përshpejtojnë zhvillimin

Unë kam shkruar kodin profesionalisht për më shumë se pesë vjet tani. Për katër vitet e para, kurrë nuk u kujdesa për madhësinë e kërkesave të mia për tërheqje (PR). Megjithatë, vitin e fundit, kalova nga paraqitja e PR masive me mijëra linja ndryshimesh në zbërthimin e tyre në më të vogla, më të menaxhueshme. Përfitimet e këtij ndryshimi kanë qenë të mëdha, dhe në këtë blog, unë do t'i ndaj ato avantazhe.

Sipas GitHub , një kërkesë tërheqëse është:

Një kërkesë tërheqëse është një propozim për të bashkuar një grup ndryshimesh nga një degë në tjetrën. Në një kërkesë tërheqëse, bashkëpunëtorët mund të shqyrtojnë dhe diskutojnë grupin e propozuar të ndryshimeve përpara se t'i integrojnë ndryshimet në bazën kryesore të kodeve.

Në thelb, një kërkesë tërheqjeje është një mënyrë për të bashkëpunuar; ne duhet të bëjmë gjithçka që është e mundur për të përmirësuar këtë bashkëpunim. Një metodë efektive për të përmirësuar këtë bashkëpunim është mbajtja e PR-ve të vogla.

Nuk ka asnjë përkufizim universal për të bërë dallimin midis një PR të vogël dhe të madhe. Mbështetja vetëm në numrin e linjave të ndryshuara është e pamjaftueshme, pasi kodi dhe testet e gjeneruara automatikisht mund të rrisin numrin e linjave. Kur i referohem PR-ve të vogla në këtë artikull, dua të them ndarjen e një PR më të madhe në PR të shumta më të vogla, logjikisht koherente. Çdo PR më e vogël duhet të jetë e pavarur, e shkrirë dhe e vendosshme.

Unë nuk mbroj ndarjen artificiale si ndarja e një PR në dy, njëra që përmban të gjithë kodin dhe tjetra vetëm me testet, pasi kjo qasje nuk arrin të sjellë ndonjë përfitim që ndaj më poshtë.

Shqyrtime efikase:

Kërkojini një programuesi të rishikojë 10 rreshta kodi, ai do të gjejë 10 probleme. Kërkojini atij të bëjë 500 rreshta dhe ai do të thotë se duket mirë.

Ndërsa humoristik, ky citim mbart të vërtetën. Të gjithë janë të zënë me punën e tyre dhe kur i kërkoni dikujt të rishikojë një PR, në thelb po kërkoni kohën e tij. Rishikimi i një PR kërkon që rishikuesi të ndryshojë kontekstin nga puna e tij dhe nëse rishikimi kërkon një kohë të konsiderueshme, mund të jetë sfiduese për ta që të kthehen në punën e tyre, duke ndikuar potencialisht në motivimin dhe angazhimin e tyre ndaj rishikimit.

PR-të më të vogla, të cilat marrin vetëm rreth 20-30 minuta për t'u rishikuar, janë shumë më të lehta për t'u trajtuar në krahasim me ato që mund të zgjasin 2-3 orë. Plus, PR-të më të mëdha shpesh çojnë në anashkalime, sepse shtrirja jonë e vëmendjes mund të trajtojë vetëm kaq shumë, dhe kalimi midis shumë ndryshimeve në një PR të vetme mund të jetë konfuze. Nga përvoja ime, PR-të më të vogla priren të marrin reagime më të mira dhe të çojnë në biseda më kuptimplote të projektimit.

Shqyrtime më të shpejta:

Në këtë pikë, po mendoj të shtoj PR-në time në testamentin tim në rast se është ende në shqyrtim pasi të jem larguar.

PR-të më të gjata kërkojnë një angazhim të konsiderueshëm kohor nga rishikuesit, duke i bërë ata më pak të prirur për të tërhequr vëmendjen - veçanërisht nëse ato nuk janë të lidhura me veçori me ndikim të lartë. Nga ana tjetër, PR-të e vogla rishikohen shpejt, pasi kërkojnë më pak nga koha e recensuesit dhe janë më pak ndërhyrëse.

Kjo shpejtësi e rishikimeve mund të jetë vendimtare për përmbushjen e afateve të projektit; Unë kam parë që projektet të vonohen sepse rishikuesit e vjetër nuk mund të ndajnë kohë për PR masive (edhe pse kjo mund të ndodhë me PR të vogla, rreziku është në thelb më i lartë me ato të mëdha).

Ripunim më i vogël:

Ripërpunimi i një PR të madh pas ndryshimeve të dizajnit është si rirregullimi i shezlloneve në një anije që sapo keni përfunduar... dhe më pas e fundosni atë.

Të gjithë kemi përjetuar situata kur dikush kupton gjatë rishikimit të PR se një dizajn tjetër do të kishte qenë më i mirëmbajtur dhe më i sigurt për të ardhmen, dhe ne duhet të shpenzojmë kohë shtesë për të ripunuar PR bazuar në dizajnin e ri (për të mos thënë se ata ishin plotësisht në bord me dizajnin që u zbatua fillimisht :p). Kjo është shumë e natyrshme sepse ndonjëherë gjërat bëhen më të qarta sapo t'i shihni të shkruara në kod dhe filloni të vini re aspekte që mund t'i keni humbur gjatë fazës së projektimit.

Me PR të mëdha, kjo mund të jetë një çështje e rëndësishme sepse ju duhet të ripunoni shumë elementë, por me PR më të vogla, është më e lehtë të bësh ndryshime. Më e rëndësishmja, ka një shans më të ulët për t'u ripunuar, sepse rishikuesit kanë më shumë gjasa të identifikojnë çështjet herët dhe t'i trajtojnë ato në PR-të fillestare, duke lejuar që PR-të e mëvonshme të bazohen në dizajnet e reja.

Testim më i mirë:

PR-të më të vogla përfitojnë edhe ju si autor i PR-së. Ato ndihmojnë në testimin e ndryshimeve më të vogla në mënyrë graduale në vend që të testojnë të gjithë projektin me një hap. Testimi i ndryshimeve më të vogla rezulton në testime më shteruese të secilit komponent të sistemit, duke çuar kështu në më pak gabime të prodhimit. Kjo vlen si për testet e automatizuara ashtu edhe për testimin manual të kryer nga ju ose inxhinierë të dedikuar të QA.

Për më tepër, PR më të vogla zvogëlojnë gjasat e rasteve të testimit të humbura, pasi mund të përqendroheni në një fushë të kufizuar dhe jo në të gjithë sistemin.

Shkrimi i testeve? Kjo tingëllon si problemi i Future Me.

Kam parë zhvillues (përfshirë veten time në të kaluarën) që hezitojnë të shkruajnë teste automatizimi për shkak të investimit të perceptuar në kohë pa vlerë të menjëhershme, "të dukshme" për veçorinë/produktin. PR-të më të vogla e zvogëlojnë këtë fërkim duke kufizuar numrin e testeve të kërkuara dhe kohën e shpenzuar për shkrimin e tyre.

Korrigjimi më i lehtë:

Pavarësisht se sa i plotë është testimi juaj, gabimet e prodhimit do të ndodhin! Të jesh në gjendje të korrigjosh gabimet në prodhim është thelbësore pasi defektet e prodhimit ndikojnë drejtpërdrejt te përdoruesit, biznesin ose të dyja. Me PR të mëdha, sipërfaqja e ndryshimit është gjithashtu e madhe, duke e bërë atë kohë dhe të vështirë gjetjen e shkakut rrënjësor të çështjeve. Nga ana tjetër, PR-të më të vogla përmbajnë më pak kod dhe kështu e bëjnë korrigjimin shumë më të shpejtë.

Korrigjimi i ndryshimeve të vogla është si të gjesh një gabim shtypi; korrigjimi i ndryshimeve të mëdha është si korrigjimi i një enciklopedie.

Vendosja në faza e veçorive:

E fundit, por jo më pak e rëndësishme, PR-të më të vogla janë gjithashtu të dobishme për menaxherin dhe përdoruesit e produktit tuaj. Duke përdorur PR të vogla, ju mund të shtyni vazhdimisht pjesë të sistemit drejt prodhimit, gjë që ndihmon në marrjen e reagimeve të hershme nga përdoruesit dhe lejon korrigjimet e hershme të kursit nëse është e nevojshme.

Të anashkalosh reagimet e hershme është si të gatuash një vakt me pesë pjata pa shijuar asgjë - thjesht po shpreson se nuk është një fatkeqësi.

Përfitimet e PR-ve të vogla janë të shumta dhe pikat e përshkruara më sipër janë ndër më me ndikimet që kam përjetuar personalisht. Nëse keni hasur në avantazhe të tjera të PR-ve të vogla ose sfida me ato më të mëdha që nuk i kam mbuluar, komentoni me njohuritë tuaja.

Shpresoj që ky artikull t'ju motivojë të përqafoni PR më të vogla. Nëse jeni tashmë në bord, shpresoj se kjo do të përforcojë vlerën e kësaj praktike.

Faleminderit për lexim, deri herën tjetër, vazhdoni të kodoni dhe qëndroni kurioz!