Aquí imos de novo: ves a notificación, e sentes esa resistencia familiar. A revisión do código adoita sentirse cognitivamente pesada e non determinista: demasiados camiños a seguir, demasiada ambigüidade, demasiadas opinións. Pero como maximizar o valor dunha revisión sen esgotar os revisores ou atrapando ao equipo en debates interminables? Distilamos un proceso de revisión saudable e sustentable nun acrónimo: Prioriza o que realmente importa - desde a lóxica empresarial e os casos de vantaxe ata a fiabilidade e a lexibilidade - mantendo as opinións subxectivas en control. PERFECT ¿Que é a revisión de código? A revisión de código é un proceso de verificación de que o código cumpre un conxunto definido de requisitos.Pode ser realizada por outro desenvolvedor, polo propio autor, ou coa axuda de ferramentas automatizadas. Estes requisitos están definidos por necesidades empresariais ou técnicas.No desenvolvemento de produtos ou software personalizado, sempre están impulsados en última instancia polos obxectivos empresariais. Estes requisitos poden incluír calidade de código, prevención de problemas críticos, ciclos de desenvolvemento máis rápidos, crecemento do equipo e outros factores. Por exemplo, o desexo persoal dun desenvolvedor de escribir código perfectamente limpo non é, por si só, un motivo válido para a revisión do código. Con todo, cando se demostra que o código limpo reduce os erros de produción, mellora a calidade global do software, ou afecta positivamente á motivación do equipo e á sustentabilidade, convértese nun obxectivo lexítimo da revisión do código. Realmente necesitas unha revisión de código? A revisión do código pode levar ata o 20-30% do tempo de traballo dun desenvolvedor, incluíndo tanto a revisión do código como a espera de revisións. Idealmente, debes analizar o equilibrio entre o tempo e o esforzo gastado na revisión de código e o valor empresarial que proporciona, preferiblemente usando métricas, e decidir se as melloras resultantes xustifican ese custo. Cada proxecto debe atopar o seu propio equilibrio aceptable. A resposta máis curta é case sempre Mesmo unha revisión lixeira pero estruturada adoita custar pouco e proporcionar un valor significativo, o que fai razoable a súa utilización na maioría dos proxectos. Con todo, se a revisión do código se converte nun "culto de carga", cando as revisións só existen formalmente, as aprobacións ocorren sen unha discusión real e non se impiden problemas reais, entón simplemente non precisa de revisión peer-to-peer nesta forma. yes Se un proceso de revisión de código expón problemas de comunicación ou ralentiza significativamente a entrega, os equipos poden estar tentados a abandonalo por completo.Aínda que isto pode traer alivio a curto prazo, o resultado a longo prazo é xeralmente negativo.Un enfoque máis eficaz é abordar os problemas subxacentes, como lagoas de comunicación ou un proceso de revisión non estruturado, en lugar de eliminar completamente a revisión de código. Principios de revisión do código perfecto A continuación, describo un conxunto de principios de revisión de código ordenados pola súa importancia. Estes principios describen un proceso ideal de revisión de código que cobre todos os aspectos esenciais. Para facelos máis fáciles de lembrar, uso o acrónimo , onde cada letra corresponde á primeira letra dun principio. PERFECT   moi importante: Os revisores sempre deben ter en conta que só porque non lles gusta unha peza de código, non significa que o código sexa malo. Se ten algo que comentar, describa claramente o que está mal e por que, apoie o seu feedback con argumentos concretos e propoña unha alternativa - polo menos a un alto nivel. moi importante: 1 Obxectivo ✔️ Code solves the task. Este é o requisito primario e non negociable. Se o código non resolve ningunha tarefa, non ten valor e probablemente non debería fusionarse en absoluto. Para un revisor, o primeiro paso é comprender que é a tarefa e que resultado se espera que produza o código. Esta información pode vir dun boletín de seguimento do traballo, a descrición da revisión ou mesmo unha discusión directa con colegas. Unha vez que a tarefa está clara, o revisor debe comprobar que o código realmente a resolve.Unha técnica útil é esbozar aproximadamente como se achegaría á solución e comparala co código implementado. Sen iso, o valor da revisión achégase a cero.Non importa o limpo ou legible que sexa o código, ten pouco sentido se non resolve a tarefa pretendida. Casos de Edge ✔️ Edge cases are handled. Probe identificar os casos de esquina de negocios e técnicos e comprobar que o código os manexa correctamente. Isto inclúe entradas inesperadas, resultados de cálculo inusuais, requisitos ou condicións omitidos, valores límite, límites de tipo, nulidade e moitos outros. Para un proxecto específico, pode ser útil manter unha lista de verificación dedicada. Unha parte significativa dos erros de produción son causados por casos de borda esquecidos.Se polo menos unha outra persoa identifica mesmo algúns deles, a probabilidade de problemas de produción pode reducirse drasticamente. Estes son situacións que son inherentemente perigosas, pero parecen inaccesibles no estado actual do código. Por exemplo, acceder a un valor desde unha opción ou talvez tipo sen comprobar explicitamente a súa presenza. Isto pode ser seguro no estado actual do código, pero a miúdo é difícil predicir como os cambios futuros, especialmente aqueles feitos sen plena conciencia das suposicións existentes, afectarán a esta lóxica. Na práctica, tales casos tenden a acumularse. Mentres que unha única instancia pode non causar problemas, un maior número deles aumenta significativamente o risco global. Unha boa práctica é usar as características da linguaxe como se pretendía, impor controis explícitos, manexar estados inesperados explicitamente e resolver estes casos antes de fusionarse. 3 Fiabilidade ✔️ Code does not have performance and security issues. Aínda que un proxecto non estea directamente relacionado co diñeiro ou a seguridade humana, a miúdo é difícil predicir como pode ser reutilizado, integrado noutros sistemas ou evolucionar ao longo do tempo. Por esta razón, é unha boa práctica comprobar sempre que o código cumpre polo menos as expectativas básicas de rendemento e seguridade. Por exemplo, que non introduce obstáculos obvios ao rendemento e que as interfaces públicas estean correctamente aseguradas. Mesmo as comprobacións simples axudan a evitar unha gran clase de problemas que doutro xeito custarían moito máis para solucionar máis tarde, cando aparecen problemas reais na produción. Desde unha perspectiva de fiabilidade, a revisión de código normalmente céntrase en áreas onde é máis probable que ocorran fallos, comportamento inseguro ou rendemento degradado. Isto inclúe a complexidade do tempo e da memoria (apropriado para o volume de datos esperado, tempo de execución e uso de memoria), validación de entrada e saída, almacenamento de credenciais, integracións rotas, invalidación de caché e preocupacións similares. 4 Forma ✔️ Code aligns with design principles. Este aliñamento axuda a estandarizar a representación do código, o que o fai máis fácil de ler e entender - tanto para outros desenvolvedores como para o autor orixinal no futuro. A diferenza da corrección empresarial, o rendemento ou a seguridade, as preguntas de deseño tenden a ser máis subxectivas.Por esta razón, os argumentos claros e os acordos compartidos son esenciais para minimizar as discusións e os conflitos non construtivos durante a revisión. Hai moitos principios ben coñecidos que se poden aplicar, como SOLID, KISS, DRY, e outros. Algúns deles permanecen en gran parte subxectivos, mentres que outros proporcionan criterios e orientacións máis concretos. Con todo, independentemente do principio específico, a maioría das discusións de deseño rematan en xestionar a cohesión e o acoplamento. Por esta razón, recomendo desenvolver unha sólida comprensión destes conceptos e aplicar o Principio no contexto do seu proxecto, tratando outros principios de deseño como exemplos ou interpretacións específicas desta idea principal. High Cohesion / Low Coupling 5 Evidencias ✔️ Tests and CI pipelines pass. As probas facilitan a debugue, o refactoring e a introdución de novos cambios, ao mesmo tempo que reducen o número de erros de produción e melloran a estabilidade global. Se existen probas, construcións de gasodutos ou outros controis automatizados, deben pasar. Se non, toda a revisión de código pode perder o seu valor, xa que a reparación de gasodutos rotos pode introducir cambios significativos que requiren a revisión do código. Ademais, se as probas ou os gasodutos son permanentemente rotos ou ignorados, normalmente significa que xa non se utilizan activamente, conteñen comportamentos desactualizados e poden causar máis confusión que beneficio. Se hai acordos establecidos en torno a probas de escritura, os cambios deben ser cubertos por probas de acordo. Estes probas tamén deben ser revisados usando os mesmos principios que o código de produción. Polo menos, deben validar a lóxica pretendida, seguir a estrutura e as convencións acordadas e ter un rendemento aceptable. Idealmente, o código de produción non debe incluír unha lóxica especial escrita só para probas. 6 Claridade ✔️ Code clearly communicates its intent. Diferentes persoas teñen diferentes maneiras de ler e entender o código, diferentes antecedentes e diferentes niveis de experiencia. Como resultado, a claridade do código é a miúdo subxectiva e é difícil escribir código que sexa igualmente doado de entender para todos. Aínda así, debemos esforzarnos por facer a intención do código o máis clara posible. Idealmente, o código debe ser comprensible sen ler cada liña - debería ser posible lelo diagonalmente. Isto simplifica significativamente e reduce o custo de revisión, mantemento, depuración e introdución de novos cambios. Poden incluír convencións para nomear, estrutura de ficheiros (un bo criterio é a capacidade de atopar cousas sen buscar), lonxitude de bloque, nicho, orde de declaracións, documentación, uso de comentarios e outros. Se non hai criterios obxectivos acordados e o código non é explícitamente ambiguo, prefiro deixar estas decisións ao autor, aínda que persoalmente discrepo con algunhas opcións. 7 O sabor ✔️ Personal preferences are noted but do not block changes. Cada revisor trae os seus propios hábitos de desenvolvemento e preferencias persoais. Canto menos acordos de revisión escrita ten un equipo, os comentarios de revisión máis opinados tenden a aparecer. Ao mesmo tempo, moitos destes comentarios aínda teñen sentido e poden apuntar a problemas reais. Non deben ser ignorados por completo. Con todo, é importante establecer expectativas claras: se o comentario dun revisor non é apoiado por un razoamento claro e unha proposta construtiva, o autor pode optar por non abordalo. Opinións valiosas poden ser revisadas máis tarde e convertidas en acordos compartidos. Unha vez que algo se converte nun acordo, non ten que ser totalmente obxectivo - simplemente convértese nunha parte de como funciona o equipo. Como facelo realmente funcionar Coñecer os principios correctos de revisión de código e actuar de forma consistente sobre eles son dúas cousas moi diferentes.Aínda que non hai unha receita universal que funcione para cada equipo, podo proporcionarche varias recomendacións básicas pero eficaces. O obxectivo principal é facer que a revisión de código non sexa unha actividade cognitivamente esixente que drene recursos excesivos dos desenvolvedores, senón un proceso claro e rutineiro. Idealmente, os revisores deben seguir un conxunto de convencións predefinidas en lugar de sobrepensar ou procrastinar, prestando máis atención aos problemas reais e logrando unha calidade xeral aínda maior da revisión. 
 
 
 
 
 
 
 
 
 
 
 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. ¿Realmente necesitas todos os principios? Mesmo se non ten a intención de usar todos estes principios na práctica, a comprensión deles aínda é útil. axudan a formar unha visión técnica, apoiar as discusións informadas e traer estrutura ao proceso de revisión de código ao aclarar cando diferentes enfoques teñen sentido. Como se mencionou anteriormente, a revisión de código non é unha única técnica, senón un espectro de prácticas. Os principios descritos anteriormente axudan a maximizar os beneficios da revisión de código en xeral. Con todo, nun proxecto específico, algúns enfoques poden requirir máis esforzo que o valor que proporcionan.

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 proceso de revisión de código sustentable para equipos ocupados (PERFECT)

About Author

COMENTARIOS

Etiquetas colgantes

ESTE ARTIGO FOI PRESENTADO EN

Related Stories

HackerNoon Decoded 2024: Celebrating Our Life Hacking Community!

HackerNoon Decoded 2024: Celebrating Our Startups Community!

HackerNoon Decoded 2024: Celebrating Our Management Community!

R Systems BlogBook—Chapter 1: Round 2 is Now Open for Submissions🎉

HackerNoon Decoded 2024: Celebrating Our Life Hacking Community!

HackerNoon Decoded 2024: Celebrating Our Startups Community!

HackerNoon Decoded 2024: Celebrating Our Management Community!

R Systems BlogBook—Chapter 1: Round 2 is Now Open for Submissions🎉

Light-Mode

Classic

Newspaper

Minty

Dark-Mode

Neon Noir

Minty

HN StartUps