Aquí anem de nou: veus la notificació, i sents que la resistència familiar. Revisió del codi sovint se sent cognitivament pesat i no determinista: massa camins per seguir, massa ambigüitat, massa opinions. Però com es pot maximitzar el valor d’una revisió sense esgotar els revisors o atrapar l’equip en interminables debats? He destil·lat un procés de revisió saludable i sostenible en un acrònim: Prioritza el que realment importa - des de la lògica de negoci i els casos d'avantguarda fins a la fiabilitat i la llegibilitat - mantenint en control les opinions subjectives. PERFECT Què és la revisió de codi? La revisió de codi és un procés de verificació que el codi compleix un conjunt definit de requisits, que pot ser realitzat per un altre desenvolupador, per l'autor mateix, o amb l'ajuda d'eines automatitzades. Aquests requisits es defineixen per necessitats empresarials o tècniques. En el desenvolupament de productes o programari personalitzat, sempre es basen en els objectius empresarials. Aquests requisits poden incloure la qualitat del codi, la prevenció de problemes crítics, cicles de desenvolupament més ràpids, creixement de l'equip i altres factors. Per exemple, el desig personal d'un desenvolupador d'escriure codi perfectament net no és, per si mateix, una raó vàlida per a la revisió de codi. No obstant això, quan es demostra que el codi net redueix els errors de producció, millora la qualitat general del programari, o impacta positivament en la motivació i el manteniment de l'equip, es converteix en un propòsit legítim de la revisió de codi. Realment necessites una revisió de codi? La revisió de codi pot durar fins al 20-30% del temps de treball d'un desenvolupador, incloent tant la revisió del codi com l'espera de revisions. Aquest cost es pot reduir introduint un procés de revisió de codi més estructurat, que descriuré més endavant en aquest article. Idealment, hauríeu d'analitzar el compensació entre el temps i l'esforç gastat en la revisió de codi i el valor empresarial que proporciona, preferiblement utilitzant mètriques, i decidir si les millores resultants justifiquen aquest cost. Cada projecte ha de trobar el seu propi equilibri acceptable. La resposta més curta és gairebé sempre Fins i tot una revisió lleugera però estructurada sol costar poc i proporcionar un valor significatiu, la qual cosa fa que sigui raonable utilitzar-la en la majoria de projectes. No obstant això, si la revisió del codi es converteix en un "culte de càrrega", quan les revisions només existeixen formalment, les aprovacions es produeixen sense una discussió real, i no s'eviten problemes reals, llavors simplement no necessiteu una revisió entre pares en aquesta forma. yes Si un procés de revisió de codi exposa problemes de comunicació o retarda significativament el lliurament, els equips poden ser temptats a abandonar-lo del tot. Tot i que això pot portar alleujament a curt termini, el resultat a llarg termini sol ser negatiu. Un enfocament més eficaç és abordar els problemes subjacents, com ara les bretxes de comunicació o un procés de revisió no estructurat, en comptes d'eliminar completament la revisió de codi. Principi de revisió del codi perfecte A continuació, exposo un conjunt de principis de revisió de codi ordenats per la seva importància. Aquests principis descriuen un procés ideal de revisió de codi que cobreix tots els aspectes essencials. Per fer-los més fàcils de recordar, utilitzo l'acrònim , on cada lletra correspon a la primera lletra d'un principi. PERFECT   És important: Els revisors sempre han de tenir en compte que només perquè no els agrada una peça de codi, no vol dir que el codi sigui dolent. Si teniu alguna cosa a comentar, descriu clarament el que està malament i per què, recolzeu el vostre feedback amb arguments concrets i proposeu una alternativa - almenys a un nivell alt. Eviteu declaracions vagues com "això és dolent". És important: 1 Objectiu ✔️ Code solves the task. Aquest és el requisit principal i no negociable. Si el codi no resol cap tasca, no té cap valor i probablement no hauria de fusionar-se en absolut. Per a un revisor, el primer pas és entendre què és la tasca i quin resultat s'espera que produeixi el codi. Aquesta informació pot provenir d'un bitllet de seguiment de treball, la descripció de la revisió o fins i tot una discussió directa amb els col·legues. Una vegada que la tasca és clara, el revisor ha de verificar que el codi realment la resol. Una tècnica útil és esbossar aproximadament com s'aproparia a la solució i comparar-la amb el codi implementat. Sense això, el valor de la revisió s'acosta a zero.No importa com sigui net o llegible el codi, té poc sentit si no resol la tasca prevista. Casos d'Edge ✔️ Edge cases are handled. Intenta identificar els casos d'angle de negoci i tècnic i comprovar que el codi els gestiona correctament. Això inclou entrades inesperades, resultats de càlcul inusuals, requisits o condicions omesos, valors límit, límits de tipus, nul·labilitat i molts altres. Una part significativa dels errors de producció són causats per casos d'avantguarda ignorats. Si almenys una altra persona identifica fins i tot alguns d'ells, la probabilitat de problemes de producció es pot reduir dramàticament. Un dels tipus interessants de casos d'avantguarda que val la pena prestar atenció és "casos impossibles". Aquestes són situacions que són intrínsecament perilloses però semblen inaccessibles en l'estat actual del codi. Per exemple, accedir a un valor des d'una opció o potser tipus sense comprovar explícitament la seva presència. Això pot ser segur en l'estat actual del codi, però sovint és difícil predir com els canvis futurs, especialment aquells realitzats sense consciència plena de les suposicions existents, afectaran aquesta lògica. En la pràctica, aquests casos tendeixen a acumular-se. Mentre que una sola instància pot no causar problemes, un nombre més gran d'ells augmenta significativament el risc en general. Una bona pràctica és utilitzar les característiques del llenguatge 3 Fiabilitat ✔️ Code does not have performance and security issues. Qualsevol projecte relacionat amb el comerç o crític de la missió hauria de tenir requisits de rendiment i seguretat estrictes. Fins i tot si un projecte no està directament relacionat amb els diners o la seguretat humana, sovint és difícil predir com es pot reutilitzar, integrar-se en altres sistemes o evolucionar amb el temps. Per aquest motiu, és una bona pràctica verificar sempre que el codi compleixi almenys les expectatives bàsiques de rendiment i seguretat. Per exemple, que no introdueixi barreres òbvies de rendiment i que les interfícies públiques estiguin correctament protegides. Fins i tot simples comprovacions ajuden a prevenir una gran classe de problemes que d'una altra manera costarien molt més solucionar més tard, quan apareixin problemes reals en la producció. Des d'una perspectiva de fiabilitat, la revisió de codi se centra en les àrees on és més probable que es produeixin fallades, comportaments insegurs o rendiment degradat. Això inclou la complexitat del temps i la memòria (apropiada per al volum de dades esperat, el temps d'execució i l'ús de la memòria), la validació d'entrada i sortida, l'emmagatzematge de credencials, les integracions trencades, la invalidació del cache i preocupacions similars. 4 Formació ✔️ Code aligns with design principles. Aquest alineament ajuda a estandarditzar la representació del codi, fent-lo més fàcil de llegir i entendre - tant per a altres desenvolupadors com per a l'autor original en el futur. A diferència de la correcció empresarial, el rendiment o la seguretat, les preguntes de disseny tendeixen a ser més subjectives.Per aquest motiu, els arguments clars i els acords compartits són essencials per minimitzar les discussions i els conflictes no constructius durant la revisió. Hi ha molts principis ben coneguts que es poden aplicar, com ara SOLID, KISS, DRY, i altres. Alguns d'ells romanen en gran mesura subjectius, mentre que d'altres proporcionen criteris i orientacions més concrets. Tanmateix, independentment del principi específic, la majoria de les discussions de disseny finalment es redueixen a gestionar la cohesió i l'acoblament. Per aquest motiu, recomano desenvolupar una comprensió sòlida d'aquests conceptes i aplicar el concepte de cohesió. Principi en el context del seu projecte, tractant altres principis de disseny com a exemples o interpretacions específiques d'aquesta idea central. High Cohesion / Low Coupling 5 Evidències ✔️ Tests and CI pipelines pass. Les proves faciliten el debugging, la refactoring i la introducció de nous canvis, alhora que redueixen el nombre de bugs de producció i milloren l'estabilitat general. Si existeixen proves, conductes de construcció o altres controls automatitzats, han de passar. En cas contrari, tota la revisió de codi pot perdre el seu valor, ja que la reparació de conductes trencades pot introduir canvis significatius que requereixen una revisió del codi.A més, si les proves o conductes es trenquen o s'ignoren permanentment, normalment significa que ja no s'utilitzen activament, contenen comportaments obsolets i poden causar més confusió que beneficis. Si hi ha acords establerts al voltant de les proves d'escriptura, els canvis han de ser coberts per proves en conseqüència. Aquestes proves també han de ser revisades utilitzant els mateixos principis que el codi de producció. Com a mínim, han de validar la lògica prevista, seguir l'estructura i les convencions acordades i tenir un rendiment acceptable. Idealment, el codi de producció no ha d'incloure lògica especial escrita només per a proves. En canvi, la base de codi ha de ser dissenyada d'una manera que naturalment permeti proves fàcils i fiables. 6 Claredat ✔️ Code clearly communicates its intent. Diferents persones tenen diferents maneres de llegir i entendre el codi, diferents antecedents i diferents nivells d'experiència. Com a resultat, la claredat del codi és sovint subjectiva, i és difícil escriure codi que sigui igual de fàcil d'entendre per a tothom. No obstant això, hauríem d'esforçar-nos per fer la intenció del codi tan clara com sigui possible. Idealment, el codi hauria de ser comprensible sense llegir cada línia - hauria de ser possible llegir-lo de forma diagonal. Això simplifica i redueix significativament el cost de revisar, mantenir, depurar i introduir nous canvis. Els acords clars poden incloure convencions per nomenar, estructura de fitxers (un bon criteri és la capacitat de trobar coses sense cercar), longitud de bloc, niu, ordre de declaracions, documentació, ús de comentaris i altres. Si no hi ha criteris objectius acordats i el codi no és explícitament incert, prefereixo deixar aquestes decisions a l'autor, fins i tot si personalment no estic d'acord amb algunes opcions. 7 El gust ✔️ Personal preferences are noted but do not block changes. Cada revisor porta els seus propis hàbits de desenvolupament i preferències personals. Com menys acords de revisió escrita un equip té, els comentaris de revisió amb més opinió tendeixen a aparèixer. Aquests comentaris retarden el procés de revisió, creen fricció innecessària i, finalment, poden portar a la inconsistència del codi. Al mateix temps, molts d'aquests comentaris encara tenen sentit i poden apuntar a problemes reals. No s'han d'ignorar completament. No obstant això, és important establir expectatives clares: si el comentari d'un crític no està recolzat per un raonament clar i una proposta constructiva, l'autor pot optar per no abordar-lo. Opinions valuoses es poden revisar més tard i convertir en acords compartits. Una vegada que alguna cosa es converteix en un acord, no ha de ser completament objectiu - simplement es converteix en una part de com funciona l'equip. Com fer que funcioni realment Conèixer els principis de revisió de codi adequats i actuar de forma coherent sobre ells són dues coses molt diferents.Encara que no hi ha cap recepta universal que funcioni per a cada equip, puc proporcionar-vos diverses recomanacions bàsiques però efectives. L'objectiu principal és fer que la revisió del codi no sigui una activitat cognitivament exigent que esborri recursos excessius dels desenvolupadors, sinó un procés clar i rutinari.Idealment, els revisors haurien de seguir un conjunt de convencions predefinides en lloc de sobrepensar o procrastinar, prestant més atenció als problemes reals i aconseguint una qualitat de revisió encara més alta. 
 
 
 
 
 
 
 
 
 
 
 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. Realment necessites tots els principis? Fins i tot si vostè no té la intenció d'utilitzar tots aquests principis en la pràctica, la comprensió d'ells encara és útil.Els ajuden a formar una visió tècnica, donar suport a discussions informades, i portar l'estructura al procés de revisió de codi per aclarir quan els diferents enfocaments tenen sentit. Com es va esmentar anteriorment, la revisió de codi no és una única tècnica, sinó un espectre de pràctiques. Els principis descrits anteriorment ajuden a maximitzar els beneficis de la revisió de codi en general. Tanmateix, en un projecte específic, alguns enfocaments poden requerir més esforç que el valor que aporten. En aquests casos, és raonable aplicar selectivament només aquelles pràctiques que són realment beneficioses en el context del vostre projecte.

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. 

Un procés de revisió de codi sostenible per a equips ocupats (Perfecte)

About Author

COMENTARIS

Etiquetes penjant

AQUEST ARTICLE VA SER PRESENTAT A

Related Stories

The Jewel Robbery at the Grand Metropolitan

Generar líders de qualitat ASAP: HackerNoon's Content-Relevant Niche Ads FTW

Startups of The Year: Meet the Cybersecurity Industry

TON Game ‘BANANA’ Hits 1M Users In 72 Hours

The Jewel Robbery at the Grand Metropolitan

Generar líders de qualitat ASAP: HackerNoon's Content-Relevant Niche Ads FTW

Startups of The Year: Meet the Cybersecurity Industry

TON Game ‘BANANA’ Hits 1M Users In 72 Hours

Light-Mode

Classic

Newspaper

Minty

Dark-Mode

Neon Noir

Minty

HN StartUps