Google: ¿Cómo revisar el código?

Explicación de términos en este artículo:

Si crees que el artículo es demasiado largo, puedes arrastrarlo directamente al final del artículo para leer el resumen

Estándares CR

El objetivo principal de cr (revisión de código) es garantizar que la calidad del código base de Google sea cada vez mejor. Todas las herramientas y procesos relacionados se crean para este propósito. Para lograr este objetivo, es necesario realizar una serie de concesiones y compensaciones.

En primer lugar, los desarrolladores deben poder avanzar en las tareas de las que son responsables. Si nunca envía código mejorado al código base, el código base nunca mejorará. Además, si un revisor dificulta la revisión, los desarrolladores no estarán dispuestos a realizar mejoras en el futuro.

Por otro lado, los revisores son responsables de garantizar la calidad de cada lista de cambios (en lo sucesivo, CL) y de garantizar que la calidad general del código de su base de código no empeore. Esto puede ser complicado porque a menudo es necesario degradar el código para que funcione, especialmente cuando el equipo se encuentra bajo severas limitaciones de tiempo y todos sienten que tienen que tomar atajos para lograr sus objetivos.

Además, los revisores tienen propiedad y responsabilidad sobre el código que están revisando. Quieren asegurarse de que el código siga siendo coherente, fácil de mantener y cumpla con los aspectos mencionados en "Qué esperar en CR" a continuación.

Por lo tanto, tenemos las siguientes reglas como estándar para lo que esperamos en CR:

En términos generales, cuando CL existe, el revisor debe aprobarlo, momento en el cual definitivamente es Mejorará la calidad general del código del sistema en el que está trabajando, incluso si este CL no es perfecto. Este es el primer principio en toda RC. Por supuesto, esto tiene limitaciones. Por ejemplo, si una CL agrega una funcionalidad que un revisor no desea en su sistema, el revisor ciertamente puede rechazarla, incluso si el código está bien diseñado.

Un punto clave aquí es que no existe un código "perfecto", sólo un código mejor. Los revisores no deberían exigir a los autores que pulen cada pequeño párrafo de un artículo antes de aprobarlo. En cambio, los revisores deberían sopesar la necesidad de desarrollo frente a la importancia de los cambios propuestos. Los revisores no deben buscar la perfección, sino la mejora continua. La CL que mejora la mantenibilidad, legibilidad y comprensibilidad del sistema en su conjunto no debería retrasarse días o semanas sólo porque no es "perfecta".

Los revisores siempre deben sentirse libres de dejar un comentario diciendo algo mejor, pero si no es muy importante, prefiera el comentario con "nit:" para que el autor sepa que es solo un comentario que puede seleccionar. ignorar.

CR tiene una función importante: enseñar a los desarrolladores algo nuevo sobre un lenguaje, marco o principios generales de diseño de software. Está bien dejar comentarios que ayuden a los desarrolladores a aprender cosas nuevas. Compartir conocimientos es parte de mejorar la salud del código de su sistema con el tiempo. Sólo necesita recordar que si su comentario es puramente educativo pero no esencial para cumplir con los estándares descritos en este documento, precedido por "nit:" o de otra manera indique que el autor no está obligado a comentar en este CL para resolverlo.

La realidad y los datos trastocan las preferencias personales. Cuando se trata de estilo de codificación, la guía de estilo es la autoridad absoluta. Cualquier punto que no esté en la guía de estilo (como espacios, etc.) es una cuestión de preferencia personal. El estilo de codificación debe ser coherente con los existentes. Si el proyecto no tiene un estilo consistente desde antes, acepta el estilo del autor.

Todos los aspectos del diseño de software nunca son solo una cuestión de puro estilo de codificación o preferencia personal.

Se basan en principios fundamentales y deberían basarse en esos principios, no sólo en opiniones personales, que a veces tienen pocas opciones. Si el autor puede demostrar (ya sea mediante datos o algún hecho basado en principios) que su método es igualmente eficaz, entonces el revisor debe aceptar la preferencia del autor. De lo contrario, las opciones de estilo de codificación dependen de principios estándar de diseño de software.

Si no se aplican otras reglas, los revisores pueden exigir a los autores que sean coherentes con lo que hay actualmente en la base del código, siempre y cuando el código no empeore la salud general del código del sistema.

En cualquier conflicto con CR, el primer paso siempre debe ser que el desarrollador y el revisor intenten llegar a un consenso basándose en este artículo y la Guía del autor de CL.

Cuando llegar a un consenso se vuelve particularmente difícil, el revisor y el autor deben reunirse cara a cara en lugar de simplemente intentar resolver el conflicto a través de los comentarios de CR (aunque si hace esto, asegúrese de discutir los resultados). Documentado en los comentarios de CL para futuros lectores).

Si esto no resuelve el problema, la solución más común es actualizar. Normalmente, el camino hacia la escalada es tener una discusión más amplia en el equipo, involucrar al líder del equipo, pedirle al encargado del código que tome una decisión o pedir ayuda al gerente técnico. No permita que otra persona se quede al margen porque el autor y los revisores no pueden ponerse de acuerdo.

Qué buscar en CR

Nota: Al considerar cada punto, asegúrese de considerar los criterios de CR.

Lo importante en cr es observar el diseño general de CL. ¿Tiene sentido la interacción de diferentes segmentos de código en CL? ¿Este cambio pertenece a la base de código de su negocio o a otra base de código que se introdujo? ¿Se integra bien con el resto del sistema? ¿Es ahora el momento adecuado para agregar esta función?

¿Este CL hace lo que quieren los desarrolladores? ¿Los desarrolladores diseñaron este código para beneficiar a los usuarios? Los "usuarios" suelen ser tanto usuarios finales (cuando se ven afectados por el cambio) como desarrolladores (que deben "usar" este código en el futuro).

En la mayoría de los casos, esperamos que los desarrolladores puedan probar completamente el CL al hacer cr, para que pueda funcionar correctamente. Sin embargo, como revisor, aún debes pensar en casos extremos, buscar problemas, intentar pensar como un usuario y asegurarte de no ver errores con solo leer el código.

Si lo deseas, puedes verificar la CL tú mismo. Si el cambio provocará directamente efectos visibles para el usuario, como cambios en la interfaz de usuario, es muy importante verificar los cambios de CL.

Al leer el código, puede resultar difícil entender cómo ciertos cambios afectarán a los usuarios. Para tales cambios, si no le conviene probarlo usted mismo, puede pedirle al desarrollador que le demuestre la función (demostración).

Además, un punto particularmente importante a considerar la funcionalidad durante cr es si la programación concurrente en cl puede teóricamente conducir a condiciones de interbloqueo o carrera. Este tipo de problemas son difíciles de encontrar simplemente ejecutando el código y generalmente requieren que alguien (desarrolladores y revisores) piense detenidamente para asegurarse de que no se introduzcan problemas (tenga en cuenta que esta también es una buena razón para no usar programación paralela en este caso). En algunos casos, pueden producirse condiciones de carrera o interbloqueos, lo que puede hacer que sea muy complicado inspeccionar o comprender el código).

¿Es una CL más compleja de lo necesario? Aquí hay algunas cosas que se deben verificar para cualquier nivel de CL: ¿Es una sola línea de código demasiado compleja? ¿Es la función demasiado compleja? ¿Es la clase demasiado compleja? "Complejo" generalmente significa que el código es difícil de leer y lo más probable es que otros desarrolladores hayan introducido otros errores al modificar este código.

Un tipo de complejidad es causado por el exceso de ingeniería. Los desarrolladores harán que ese fragmento de código sea demasiado general, excediendo lo que se necesitaba originalmente o agregando nuevas características que el sistema no necesita actualmente.

Los revisores deben prestar especial atención al diseño excesivo. Se anima a los desarrolladores a resolver los problemas que saben que deben resolverse ahora en lugar de especular sobre problemas que tal vez deban resolverse en el futuro. Empiece a resolver problemas futuros a medida que surjan, porque así podrá verlos con mayor claridad.

Considere las pruebas unitarias, las pruebas de integración y las pruebas de un extremo a otro como cambios apropiados requeridos por CL. Generalmente, además del código comercial del entorno de producción, también se deben agregar pruebas al CL. A menos que la CL exista para manejar un asunto de emergencia.

Además, también debemos asegurarnos de que la prueba es correcta, razonable y útil. Las pruebas no están destinadas a probarse a sí mismas y, en general, rara vez se prueban por el simple hecho de realizar pruebas (como probar si hay algún problema con el código de prueba y luego pasar por el proceso de prueba), por lo que debemos asegurarnos de que las pruebas sean correctas. eficaz.

Cuando hay un problema real con el código, ¿fallará la prueba? ¿La prueba producirá falsos positivos si cambia el programa que se está probando? ¿Cada prueba hace una afirmación simple y útil? ¿Están las pruebas separadas adecuadamente entre los diferentes métodos de prueba?

Nombres

¿El desarrollador eligió un nombre apropiado para todo? Un buen naming significa que el nombre es suficiente para expresar plenamente cuál es la función de la cosa o lo que debe hacer. Pero al mismo tiempo, el nombre no debería ser demasiado largo para leerlo.

Artículo de referencia recomendado: Código limpio 101: nombres y funciones significativos

Comentarios

¿Los desarrolladores dejan comentarios claros en un inglés comprensible? Estos comentarios ¿Es realmente necesario?

Por lo general, los comentarios son bastante útiles para explicar por qué existe este fragmento de código, en lugar de explicar qué está haciendo un fragmento de código. Si el código en sí no se puede explicar claramente, significa que es necesario simplificarlo aún más. Hay excepciones, por supuesto. Por ejemplo, al explicar qué hace una expresión regular o un algoritmo complejo, un comentario que explique lo que hace el código es bastante útil. Pero la mayoría de los comentarios se utilizan para explicar información que no está incluida en el propio programa, como por ejemplo los motivos por los que se hace de esta manera.

También es útil mirar los comentarios anteriores para esta CL, tal vez haya un elemento de tarea pendiente que se pueda eliminar ahora, un comentario que sugiera por qué no se debe realizar este cambio, etc.

Cabe señalar que los comentarios son diferentes de los archivos de clases, módulos y funciones. Los últimos tres deben poder expresar el propósito de un fragmento de código, cómo usarlo y el comportamiento cuando se usa.

Google proporciona guías de estilo para todos los idiomas principales, incluso los más desconocidos, así que asegúrese de que su CL siga las instrucciones de la guía adecuada.

Si desea mejorar algunos puntos en CL que no están incluidos en la guía de estilo, introduzca Nit en su comentario: para que los desarrolladores sepan que se trata de un problema menor que cree que puede mejorar el código. y no es obligatorio. Pero recuerde, no bloquee los envíos de CL basándose únicamente en preferencias de estilo personales.

Los desarrolladores no deben incluir cambios importantes de estilo y otros cambios de código en CL al mismo tiempo. Esto dificultará ver qué cambios se han realizado en CL. También hace que las fusiones y reversiones sean más complejas y crea otros problemas. Por ejemplo, si el autor quiere reformatear el código, pídale que refactorice el nuevo formato en una nueva CL.

Si la CL cambia la compilación, prueba, interacción y versión, verifique si los documentos relacionados también se actualizan al mismo tiempo, incluidos README, páginas g3doc y otros archivos de referencia generados. Si CL ​​elimina o desaprueba algún código, considere si se debe eliminar la documentación correspondiente y pregunte si falta documentación.

Revise cuidadosamente cada línea de código que se le haya asignado.

Algunas cosas, como archivos de datos, código generado, estructuras de datos grandes, se pueden escanear un poco. Nunca escanee una clase, función o bloque de código escrito por un desarrollador y asuma que no tiene nada de malo internamente. Obviamente, algunos códigos necesitan una revisión más cuidadosa que otros. Esta es una decisión que debe tomar usted mismo, pero al menos debe asegurarse de comprender qué hace todo el código.

Si leer el código es demasiado complicado y ralentiza la revisión, antes de continuar con la revisión, infórmaselo al desarrollador y espera a que te explique y aclare el código. En Google empleamos a muchos ingenieros de software talentosos y usted es uno de ellos. Si usted no puede entenderlo, es probable que nadie más lo haga tampoco. Por lo tanto, cuando pides a los desarrolladores que aclaren este código, también estás ayudando a los futuros desarrolladores a comprender el código.

Si comprende pero cree que no está calificado para revisar una determinada parte, asegúrese de que haya una persona adecuada (calificada) entre los revisores para revisar esa parte. Especialmente cuando se trata de cuestiones complejas como seguridad, concurrencia, accesibilidad e internacionalización.

A menudo resulta útil ver CL en suficiente contexto. En términos generales, la herramienta cr solo mostrará unas pocas líneas de código alrededor de la parte modificada. Pero a veces hay que mirar el documento completo para asegurarse de que los cambios tengan sentido. Por ejemplo, es posible que solo vea 4 líneas de código nuevo agregadas, pero cuando observe el archivo completo, encontrará que estas 4 líneas se agregaron a 50 líneas de código y deberá dividirlo en funciones más pequeñas.

También es útil pensar en CL desde la perspectiva de todo el sistema. ¿Este CL mejora la calidad del código de todo el sistema o hará que todo el sistema sea más complejo? ¿Faltan pruebas? Nunca acepte CL que reduzca la calidad del código de todo el sistema. Debido a que la mayoría de los sistemas se vuelven complejos por la acumulación de muchos cambios pequeños, también es importante evitar que nuevos cambios introduzcan complejidad (aunque sea pequeña).

Personalmente creo que no se trata de no señalar errores, sino de incentivarlos en lugar de señalar errores, para que otros desarrolladores estén más motivados a hacer las cosas bien. De hecho, a través de una simple oración, hágale saber a la otra parte lo que ha hecho bien y que continuará manteniéndolo en el futuro y brindará una influencia positiva a otros desarrolladores.

Indique qué se modifica en cada confirmación para ayudar a los revisores a comprender rápidamente la situación

No sea tacaño con sus elogios en este momento

Cuando haga CR, asegúrese de:

Cómo navegar por CL

Ahora ya sabe qué buscar al revisar, pero ¿cómo debería hacerlo? ¿Se distribuirá la revisión? ¿Cuál es la forma más eficiente de realizar cambios en varios archivos?

¿Es este cambio significativo y razonable? Si cree que el cambio no debería ocurrir en primer lugar, explique inmediatamente por qué no debería ocurrir. También es una buena idea ofrecer a los desarrolladores sugerencias sobre qué hacer al rechazar un cambio como este.

Por ejemplo, podría decir: "Parece que ha logrado algunas cosas buenas, ¡gracias! Pero en realidad estamos avanzando en la dirección de eliminar el sistema FooWidget que está modificando, por lo que no No quiero comentar sobre eso en esta etapa. Realiza nuevas modificaciones. ¿Qué tal refactorizar nuestra nueva clase BarWidget?

Es importante tener en cuenta que el revisor debe rechazar cortésmente la CL y al mismo tiempo ofrecer alternativas. . Esta cortesía es importante porque queremos demostrar que nos respetamos unos a otros incluso cuando no estamos de acuerdo.

Si tiene varias CL que contienen cambios que no desea realizar, debe reconsiderar el proceso de desarrollo del equipo de desarrollo o publicar el proceso de desarrollo a colaboradores externos antes de escribir cualquier CL. más comunicación. Es mejor decir "no" antes de empezar a invertir, para evitar tener que tirar a la basura o reescribir por completo el trabajo en el que han puesto su corazón y su alma.

Ofrece alternativas para que la otra persona sepa qué hacer en lugar de dejar que lo resuelva por sí solo.

Señale problemas, informe alternativas o dé instrucciones.

Encuentre aquellos archivos que son las partes centrales de CL. Por lo general, hay archivos en la CL que contienen muchos cambios lógicos y es la parte principal de la CL. Así que primero veremos estas partes principales. Esto ayuda a proporcionar un contexto apropiado para otras partes más pequeñas de la CL y, a menudo, acelera la revisión. Si el CL es tan grande que no puede saber dónde están las partes principales, pregúntele al desarrollador qué mirar primero o pídale que divida el CL en varios CL.

Si encuentra algunos problemas de diseño importantes en la sección principal, debe dejar un comentario de inmediato para informar sobre el problema, incluso si no tiene tiempo para revisar el resto del CL de inmediato. Porque, de hecho, si el problema de diseño es lo suficientemente grave, continuar revisando otras partes del código puede ser simplemente una pérdida de tiempo, porque el resto del código que se está revisando puede volverse irrelevante o desaparecer.

Es importante enviar comentarios de diseño importantes de inmediato por dos razones principales:

Una vez que haya confirmado que no hay problemas de diseño importantes en todo el CL, intente encontrar un orden lógico. para revisar los archivos restantes y asegurarse de no perderse ninguno de ellos. Por lo general, después de explorar la sección principal, la forma más sencilla es explorar cada archivo en el orden proporcionado por la herramienta cr. A veces es útil leer las pruebas antes de leer el código principal, para saber qué hacer y buscar.

En Google optimizamos la velocidad de los equipos de desarrollo que trabajan juntos para producir productos, en lugar de optimizar la velocidad del desarrollo individual. La velocidad de desarrollo individual es importante, pero no es tan importante como la velocidad de desarrollo de todo el equipo. Cuando el CR es lento, sucederán las siguientes cosas:

Si no se encuentra en un momento en el que necesita concentrarse en el trabajo, debe revisar el CL lo antes posible después de enviarlo. El tiempo máximo de respuesta a la revisión es de un día hábil. Seguir las pautas anteriores significa que el CL promedio debería recibir múltiples rondas de revisiones en un día (si es necesario).

Pero a veces la velocidad individual tiene prioridad sobre la velocidad del equipo. Si estás en un momento en el que necesitas concentrarte en el trabajo (por ejemplo, escribir código), no te interrumpas para hacer CR.

La investigación ha confirmado que los desarrolladores tardarán mucho tiempo en volver al proceso de desarrollo fluido original después de una interrupción. Por lo tanto, interrumpir el desarrollo puede resultar más costoso que hacer que otro desarrollador espere una revisión.

En cambio, podemos encontrar un momento adecuado para realizar RC antes de invertir en lidiar con los comentarios de revisión de otros. Esto podría ser cuando finaliza su tarea de desarrollo actual, durante el almuerzo, al salir de una reunión o al regresar de la micrococina, etc.

En términos generales, la velocidad de respuesta personal a los comentarios es más importante que la velocidad de todo el proceso de RC. Incluso si a veces lleva mucho tiempo completar todo el proceso, obtener respuestas rápidas de los revisores durante todo el proceso aliviará en gran medida la frustración de los desarrolladores por el lento proceso de CR.

Si realmente está demasiado ocupado para escaparse y no puede realizar una revisión completa de CL, aún puede responder rápidamente para informar al desarrollador cuándo comenzará la revisión, sugerir otros revisores que puedan responder más rápido, o Proporcione algunos comentarios generales preliminares. (Nota: esto no significa que deba interrumpir el desarrollo para recuperarse; busque un momento adecuado para interrumpir y hacerlo).

Es importante que los revisores dediquen suficiente tiempo a realizar revisiones para garantizar que el LGTM que brindan significa que "este código cumple con nuestros estándares".

Aun así, la velocidad de respuesta individual ideal es la más rápida posible.

Cuando tenga problemas con la zona horaria, intente responder al autor mientras todavía está en la oficina. Si ya se han ido a casa, asegúrese de completarlo antes de que regresen a la oficina al día siguiente.

Para acelerar las cosas, los revisores pueden dar LGTM o Aprobación en algunos casos incluso si todavía hay comentarios sin resolver en la CL. Una situación similar ocurre cuando:

Vale la pena considerar especialmente los comentarios LGTM cuando las dos partes se encuentran en diferentes zonas horarias; de lo contrario, el desarrollador esperará un día entero para obtener "LGTM, aprobación".

Si alguien solicita una revisión, pero el cambio es tan grande que no está seguro de cuándo tendrá tiempo para revisarlo, lo que normalmente hace es pedirle al desarrollador que divida la CL en varias CL más pequeñas. , en lugar de revisar el enorme CL de una vez. Esto es posible y puede ser muy útil para los revisores, incluso si requiere un esfuerzo adicional por parte del desarrollador.

Si la CL no se puede dividir en CL más pequeñas y no tiene tiempo suficiente para revisar rápidamente todo el contenido de la CL, al menos escriba algunos comentarios sobre su diseño general y envíelos de vuelta a los desarrolladores. para mejorar. Como revisor, uno de sus objetivos es evitar bloquear el progreso de los desarrolladores o permitirles tomar medidas adicionales rápidamente sin sacrificar la calidad del código.

Si sigues estas pautas y eres muy estricto con la RC, descubrirás que todo el proceso de RC será cada vez más rápido más adelante. Debido a que los desarrolladores aprenden cómo es el código de buena calidad y envían un excelente CL desde el principio, les lleva cada vez menos tiempo. Los revisores, por otro lado, aprenden a responder rápidamente en lugar de añadir retrasos innecesarios al proceso.

Pero no comprometa los estándares de cr y la calidad del código para aumentar la velocidad imaginada; después de todo, en realidad no hará que nada suceda más rápido a largo plazo.

En algunas situaciones de emergencia, es posible que CL desee relajar los criterios para pasar todo el proceso de RC rápidamente. Pero mire ¿Qué es una emergencia? para saber qué situaciones realmente califican como emergencias y cuáles no.

A veces los desarrolladores retrasan el procesamiento de los comentarios generados por CR. O no estarán de acuerdo con tus sugerencias o se quejarán de que eres demasiado estricto.

Cuando un desarrollador no esté de acuerdo con tu sugerencia, tómate un momento para considerar si tiene razón. Debido a que normalmente conocen el código mejor que usted, es posible que en realidad tengan una mejor comprensión de ciertos aspectos del código que usted. ¿Tienen sentido sus argumentos? ¿Tiene sentido desde la perspectiva de la calidad del código? Si es así, hágales saber que tienen razón y deje que el problema se haga evidente.

Pero los desarrolladores no siempre tienen razón. En este caso, el revisor debe explicar con más detalle por qué cree que su sugerencia es correcta. Una buena explicación generalmente demuestra comprensión de la respuesta del desarrollador e información sobre por qué se solicitó el cambio. Especialmente cuando el revisor cree que las sugerencias dadas mejorarán la calidad del código, debe continuar promoviendo sus argumentos. Siempre que crean que el esfuerzo adicional requerido finalmente mejorará la calidad general del código. La mejora de la calidad general del código a menudo se logra mediante cada pequeño cambio. A veces, a menudo se necesitan varias explicaciones de una sugerencia para que la otra parte comprenda realmente su intención. Recuerde, sea siempre cortés y dígale al desarrollador que escuchó lo que decía y que simplemente no estaba de acuerdo con el argumento.

Los revisores a veces piensan que si insisten en mejorar, harán que los desarrolladores se sientan frustrados y molestos.

Es cierto que a veces los desarrolladores se frustran, pero normalmente dura poco y luego te agradecen por ayudarlos a mejorar la calidad de su código. En términos generales, siempre que seas educado en tus comentarios, los desarrolladores no se molestarán en absoluto; estas preocupaciones sólo existen en la mente del crítico. La frustración a menudo está relacionada con la forma en que se escriben las revisiones de CR, más que con la insistencia del revisor en la calidad del código.

Una razón común de retraso es que los desarrolladores quieren hacer las cosas (comprensiblemente). No quieren pasar por otra ronda de CR para aprobar esta CL. En este punto normalmente dirán que lo solucionarán en una futura CL, por lo que deberías entregárselo a LGTM ahora. Por supuesto, algunos desarrolladores son muy buenos en esto e inmediatamente envían un CL de seguimiento (CL de seguimiento) para solucionar el problema, pero según la experiencia pasada, este tipo de "comportamiento de limpieza" de seguimiento es muy raro. A menos que el desarrollador limpie inmediatamente después de que se apruebe la CL, es poco probable que esto suceda. Esto no se debe a que los desarrolladores sean irresponsables, sino a que probablemente tengan mucho trabajo que hacer y la limpieza se olvida en la pila de trabajo. Por lo tanto, normalmente es mejor insistir en que los desarrolladores limpien su código después de fusionarlo. Porque pedirle a la gente que "limpie más tarde" es la forma más común de degradar la calidad de su código base.

Si CL ​​introduce una nueva complejidad, se debe abordar antes de comprometerse, a menos que sea una emergencia. Si la CL deja al descubierto problemas circundantes y no se pueden solucionar ahora, el desarrollador debe registrar el defecto y asignárselo a sí mismo para evitar que se olvide más adelante. O pueden optar por dejar un comentario TODO en el código y vincularlo al defecto que acaban de registrar.

Si comienzas CR con estándares bastante flexibles y luego te vuelves estricto, algunos desarrolladores comenzarán a quejarse en voz alta. En términos generales, aumentar la velocidad de las revisiones hará que estas quejas desaparezcan. Estas quejas pueden tardar meses en desaparecer, pero eventualmente los desarrolladores verán el valor de las revisiones rigurosas porque las revisiones rigurosas les ayudan a producir un código excelente. Y cuando algo sucede, sus manifestantes más ruidosos pueden incluso convertirse en sus más firmes partidarios, porque verán el valor de revisiones más estrictas.

Si ha seguido todos los pasos anteriores y aún encuentra un conflicto entre dos partes que no se puede resolver, consulte los estándares cr anteriores para obtener pautas y principios que pueden ayudar a resolver el conflicto.