Tu ideme znova: vidíte oznámenie a cítite, že známy odpor. Recenzia kódu sa často cíti kognitívne ťažká a nedeterministická: príliš veľa ciest, ktoré treba nasledovať, príliš veľa nejednoznačnosti, príliš veľa názorov. Ale ako maximalizovať hodnotu recenzie bez vyčerpania recenzentov alebo uväznenia tímu v nekonečných diskusiách? Zdravý, udržateľný proces preskúmania som destiloval do akronýmu: Prioritizuje to, čo je skutočne dôležité - od obchodnej logiky a prípadov na okraji až po spoľahlivosť a čitateľnosť - a zároveň udržiava subjektívne názory pod kontrolou. PERFECT Čo je to Code Review? Revízia kódu je proces overenia, či kód spĺňa definovanú sadu požiadaviek.To môže byť vykonané iným vývojárom, samotným autorom, alebo s pomocou automatizovaných nástrojov. Tieto požiadavky sú definované obchodnými alebo technickými potrebami.V vývoji produktov alebo vlastného softvéru sú vždy v konečnom dôsledku riadené obchodnými cieľmi.Takéto požiadavky môžu zahŕňať kvalitu kódu, prevenciu kritických problémov, rýchlejšie vývojové cykly, rast tímu a ďalšie faktory. Napríklad, osobná túžba vývojára napísať dokonale čistý kód nie je sám o sebe platným dôvodom na preskúmanie kódu. Avšak, keď sa preukáže, že čistý kód znižuje výrobné chyby, zlepšuje celkovú kvalitu softvéru alebo pozitívne ovplyvňuje motiváciu a udržateľnosť tímu, stáva sa legitímnym účelom preskúmania kódu. Naozaj potrebujete revíziu kódu? Revízia kódu môže trvať až 20-30% pracovného času vývojára, vrátane preskúmania kódu a čakania na recenzie.Táto cena môže byť znížená zavedením štruktúrovanejšieho procesu preskúmania kódu, ktorý budem popisovať neskôr v tomto článku. V ideálnom prípade by ste mali analyzovať kompromis medzi časom a úsilím vynaloženým na preskúmanie kódu a obchodnou hodnotou, ktorú poskytuje, najlepšie pomocou metrík, a rozhodnúť, či výsledné zlepšenia odôvodňujú tieto náklady. Každý projekt musí nájsť svoju vlastnú prijateľnú rovnováhu. Krátka odpoveď je takmer vždy Dokonca aj ľahká, ale štruktúrovaná revízia zvyčajne stojí málo a prináša významnú hodnotu, čo je rozumné použiť vo väčšine projektov. Avšak, ak sa revízia kódu zmení na "kult nákladov", keď recenzie existujú len formálne, schválenia sa vyskytujú bez skutočnej diskusie a žiadne skutočné problémy sa zabraňujú, potom jednoducho nepotrebujete peer-to-peer revíziu v tejto forme. yes Ak proces preskúmania kódu vystaví komunikačné problémy alebo výrazne spomalí doručenie, tímy môžu byť v pokušení úplne ho opustiť.Zatiaľ čo to môže priniesť krátkodobú úľavu, dlhodobý výsledok je zvyčajne negatívny. Princípy preskúmania perfektného kódu Nižšie uvádzam súbor princípov preskúmania kódu podľa ich významu.Tieto princípy opisujú ideálny proces preskúmania kódu, ktorý pokrýva všetky základné aspekty.Predstavujú všeobecný, štandardizovaný prístup a môžu byť prispôsobené kontextu konkrétneho projektu. Aby som si ich ľahšie zapamätal, používam akronym , kde každé písmeno zodpovedá prvému písmenu princípu. PERFECT   dôležité : Recenzenti by mali vždy mať na pamäti, že len preto, že sa im nepáči kus kódu, neznamená to, že kód je zlý. Ak máte niečo na komentár, jasne opíšte, čo je zlé a prečo, podporte svoju spätnú väzbu konkrétnymi argumentmi a navrhnite alternatívu - aspoň na vysokej úrovni. dôležité : 1. účel ✔️ Code solves the task. Toto je primárna a nevyjednávaná požiadavka. Ak kód nevyrieši žiadnu úlohu, nemá žiadnu hodnotu a pravdepodobne by sa nemal zlúčiť vôbec. Pre recenzenta je prvým krokom pochopiť, čo je úloha a aký výsledok sa očakáva, že kód bude produkovať. Táto informácia môže pochádzať z pracovného lístka, popisu recenzie alebo dokonca z priamej diskusie s kolegami. Užitočnou technikou je zhruba opísať, ako by ste sa k riešeniu priblížili a porovnať ho s implementovaným kódom. Bez ohľadu na to, ako čistý alebo čitateľný je kód, má malý zmysel, ak nevyrieši zamýšľanú úlohu. Prípady Edge ✔️ Edge cases are handled. Skúste identifikovať prípady obchodného aj technického rohu a overte, či ich kód správne spracováva. To zahŕňa neočakávané vstupy, nezvyčajné výsledky výpočtov, vynechané požiadavky alebo podmienky, hraničné hodnoty, limity typu, zrušiteľnosť a mnoho ďalších. Významná časť výrobných chýb je spôsobená prehliadanými prípadmi.Ak aspoň jedna iná osoba identifikuje aj niekoľko z nich, pravdepodobnosť výrobných problémov sa môže dramaticky znížiť. Jedným z zaujímavých typov okrajových prípadov, na ktoré sa oplatí venovať pozornosť, je „nemožné prípady“. Jedná sa o situácie, ktoré sú svojou povahou nebezpečné, ale v súčasnom stave kódu sa zdajú byť nedosiahnuteľné. Napríklad prístup k hodnote z opcie alebo možno typu bez výslovného overenia jeho prítomnosti. To môže byť v súčasnom stave kódu bezpečné, ale často je ťažké predpovedať, ako budúce zmeny, najmä tie, ktoré sa vykonajú bez plného povedomia o existujúcich predpokladoch, ovplyvnia túto logiku. V praxi sa takéto prípady majú tendenciu hromadiť. Zatiaľ čo jeden prípad nemusí spôsobiť problémy, väčší počet z nich výrazne zvyšuje celkové riziko. Dobrou praxou je používať 3. spoľahlivosť ✔️ Code does not have performance and security issues. Akýkoľvek obchodný alebo misijný projekt by mal mať prísne požiadavky na výkon a bezpečnosť. Aj keď projekt priamo nesúvisí s peniazmi alebo ľudskou bezpečnosťou, často je ťažké predpovedať, ako sa môže opätovne použiť, integrovať do iných systémov alebo vyvíjať v priebehu času. Z tohto dôvodu je dobrou praxou vždy overiť, či kód spĺňa aspoň základné očakávania týkajúce sa výkonu a bezpečnosti. Napríklad, že nezavádza zjavné prekážky výkonu a že verejné rozhrania sú riadne zabezpečené. Dokonca aj jednoduché kontroly pomáhajú zabrániť veľkej triede problémov, ktoré by inak stáli oveľa viac na opravenie neskôr, keď sa objavia skutočné problémy vo výrobe. Z hľadiska spoľahlivosti sa preskúmanie kódu zvyčajne zameriava na oblasti, kde sa pravdepodobne vyskytnú zlyhania, nebezpečné správanie alebo zhoršená výkonnosť.Toto zahŕňa časovú a pamäťovú zložitosť (vhodnú pre očakávaný objem údajov, čas vykonania a použitie pamäte), validáciu vstupov a výstupov, ukladanie poverení, zlomené integrácie, zrušenie vyrovnávacej pamäte a podobné obavy.Tento zoznam nie je vyčerpávajúci a kontrolné zoznamy špecifické pre konkrétne projekty tu tiež fungujú veľmi dobre. 4. formy ✔️ Code aligns with design principles. Toto zarovnanie pomáha štandardizovať reprezentáciu kódu, čo uľahčuje čítanie a porozumenie - tak pre iných vývojárov, ako aj pre pôvodného autora v budúcnosti. Na rozdiel od správnosti podnikania, výkonu alebo bezpečnosti, otázky dizajnu majú tendenciu byť subjektívnejšie.Z tohto dôvodu sú jasné argumenty a zdieľané dohody nevyhnutné na minimalizáciu nekonštruktívnych diskusií a konfliktov počas preskúmania. Existuje mnoho známych princípov, ktoré možno aplikovať, ako napríklad SOLID, KISS, DRY a ďalšie. Niektoré z nich zostávajú do značnej miery subjektívne, zatiaľ čo iné poskytujú konkrétnejšie kritériá a usmernenia. Avšak, bez ohľadu na konkrétny princíp, väčšina diskusií o dizajne nakoniec prichádza do riadenia súdržnosti a spájania. Z tohto dôvodu odporúčam rozvíjať pevné pochopenie týchto pojmov a aplikovať princípu v kontexte vášho projektu, zaobchádzanie s inými princípmi dizajnu ako s príkladmi alebo konkrétnymi interpretáciami tejto hlavnej myšlienky. High Cohesion / Low Coupling 5. dôkazy ✔️ Tests and CI pipelines pass. Testy uľahčujú debugovanie, refaktorovanie a zavádzanie nových zmien, pričom znižujú počet výrobných chýb a zlepšujú celkovú stabilitu. Automatizované potrubia CI pomáhajú čiastočne automatizovať preskúmanie kódu a zabezpečujú, že kód je v správnom a nasadzovateľnom stave. Ak existujú testy, stavebné potrubia alebo iné automatizované kontroly, musia prejsť. V opačnom prípade môže celá revízia kódu stratiť svoju hodnotu, pretože oprava zlomených potrubí môže zaviesť významné zmeny, ktoré si vyžadujú opätovnú revíziu kódu. Okrem toho, ak sú testy alebo potrubia trvalo zlomené alebo ignorované, zvyčajne to znamená, že už nie sú aktívne používané, obsahujú zastarané správanie a môžu spôsobiť viac zmätku ako úžitku. Ak existujú dohody okolo písomných testov, zmeny by mali byť zodpovedajúcim spôsobom pokryté testami. Tieto testy by mali byť tiež preskúmané pomocou rovnakých princípov ako výrobný kód. Minimálne by mali validovať zamýšľanú logiku, dodržiavať dohodnutú štruktúru a konvencie a mať prijateľný výkon. V ideálnom prípade by výrobný kód nemal obsahovať špeciálnu logiku napísanú len na testovanie. Namiesto toho by mala byť kódová základňa navrhnutá spôsobom, ktorý prirodzene umožňuje jednoduché a spoľahlivé testovanie. 6. jasnosť ✔️ Code clearly communicates its intent. Rôzni ľudia majú rôzne spôsoby čítania a porozumenia kódu, rôzne pozadie a rôzne úrovne skúseností. Výsledkom je, že jasnosť kódu je často subjektívna a je ťažké napísať kód, ktorý je rovnako ľahko pochopiteľný pre každého. Napriek tomu by sme sa mali snažiť, aby bol zámer kódu čo najjasnejší. V ideálnom prípade by mal byť kód zrozumiteľný bez čítania každého riadku - malo by byť možné ho čítať diagonálne. To výrazne zjednodušuje a znižuje náklady na preskúmanie, údržbu, vyrovnávanie a zavedenie nových zmien. Môžu zahŕňať konvencie pre pomenovanie, štruktúru súborov (dobrým kritériom je schopnosť nájsť veci bez vyhľadávania), dĺžku bloku, hniezdenie, poradie vyhlásení, dokumentáciu, používanie komentárov a ďalšie. Ak neexistujú dohodnuté objektívne kritériá a kód nie je explicitne nejasný, radšej nechám tieto rozhodnutia autorovi, aj keď osobne nesúhlasím s niektorými voľbami. 7 chutí ✔️ Personal preferences are noted but do not block changes. Každý recenzent prináša svoje vlastné vývojové návyky a osobné preferencie. Čím menej písomných dohôd o preskúmaní má tím, tým viac názorových komentárov sa objavuje.Takéto komentáre spomaľujú proces preskúmania, vytvárajú zbytočné trenie a môžu nakoniec viesť k nekonzistencii kódu. Zároveň majú mnohé z týchto pripomienok stále zmysel a môžu poukázať na skutočné problémy. Nemali by byť úplne ignorované. Je však dôležité stanoviť jasné očakávania: ak komentár recenzenta nie je podporovaný jasným uvažovaním a konštruktívnym návrhom, autor sa môže rozhodnúť, že sa s ním nebude zaoberať. Cenné názory sa môžu neskôr prehodnotiť a premeniť na zdieľané dohody. Akonáhle sa niečo stane dohodou, nemusí byť úplne objektívne - jednoducho sa stáva súčasťou toho, ako tím funguje. Ako urobiť, aby to skutočne fungovalo Poznať správne princípy preskúmania kódu a dôsledne konať na nich sú dve veľmi odlišné veci.Zatiaľ čo neexistuje žiadny univerzálny recept, ktorý by fungoval pre každý tím, môžem vám poskytnúť niekoľko základných, ale účinných odporúčaní. Hlavným cieľom je, aby preskúmanie kódu nebolo kognitívne náročnou činnosťou, ktorá vyčerpáva nadmerné zdroje od vývojárov, ale jasný a rutinný proces.V ideálnom prípade by recenzenti mali dodržiavať súbor vopred definovaných konvencií namiesto toho, aby premýšľali alebo odkladali, venovali väčšiu pozornosť skutočným problémom a dosahovali ešte vyššiu celkovú kvalitu preskúmania. 
 
 
 
 
 
 
 
 
 
 
 Establish written review conventions. These should include the principles described above, their concrete implementation in the context of your project, and any other aspects you want reviewers to pay attention to. 
 
 
 Keep conventions up to date and actionable. All criteria should be usable during review at any moment. Whenever you notice a recurring review pattern (comment → discussion → fix), turn it into a convention. 
 
 
 Require self-review before peer review. Everyone should perform self-review using the same conventions before sending code for review by others. This saves time for all participants and helps reviewers build experience and efficiency over time. 
 
 
 Integrate code review into the development process. Define clear rules for selecting reviewers, the number of reviewers, how comments are written and resolved, how updates are communicated, approval rules, review status visibility, and review SLAs. There should be a clear answer to common questions around code review, instead of uncertainty, anxiety, and unnecessary stress. 
 
 Automate everything that can be automated. 
 
 
 Stop approving with "LGTM". "LGTM" (Looks Good To Me) often signals that the reviewer did not fully understand the changes and simply wants to move on. While reviewers are not responsible for the final outcome of approved code, such approvals reduce the value of the review itself. 
 
 
 Practice code review whenever possible. Code review is a skill that improves through deliberate practice. The more experience reviewers gain, the less effort reviews require and the more effective they become. This can be supported through attention to structure, constructive feedback, short workshops, and other focused practices. Naozaj potrebujete všetky princípy? Aj keď nemáte v úmysle použiť všetky tieto princípy v praxi, ich pochopenie je stále užitočné.Pomáhajú formovať technickú víziu, podporujú informované diskusie a prinášajú štruktúru procesu preskúmania kódu objasnením, kedy majú rôzne prístupy zmysel. Ako už bolo spomenuté, revízia kódu nie je jedinou technikou, ale spektrom postupov. Zásady opísané vyššie pomáhajú maximalizovať výhody revízie kódu vo všeobecnosti. Avšak v konkrétnom projekte môžu niektoré prístupy vyžadovať viac úsilia ako ich hodnota.

Walkthroughs, tutorials, guides, and tips. This story will teach you how to do something new or how to do something better.

This story contains AI-generated text. The author has used AI either for research, to generate outlines, or write the text itself. 

More About Me

Read My Stories

Tento zvuk je vyrobený v pôvodnom jazyku príbehu!

Proces preskúmania trvalo udržateľného kódu pre zaneprázdnené tímy (PERFECT)

About Author

KOMENTÁRE

ZAVISTE ŠTÍTKY

TENTO ČLÁNOK BOL PREDSTAVENÝ V

Related Stories

When Blood Told

THE CRAB-SPIDER

Mutmut: a Python mutation testing system

Behavior of a shapely Spider

When Blood Told

THE CRAB-SPIDER

Mutmut: a Python mutation testing system

Behavior of a shapely Spider

Light-Mode

Classic

Newspaper

Minty

Dark-Mode

Neon Noir

Minty

HN StartUps