Hoy, muchas personas usan revisiones de código en el desarrollo. La práctica es útil, necesaria. Incluso si no está haciendo una revisión, probablemente sepa de qué se trata.

Hay un montón de herramientas para la revisión de código en el mercado con escenarios de uso, recomendaciones y reglas listas para usar. GitHub, Phabricator, FishEye / Crucible, GitLab, Bitbucket, Upsource: la lista sigue y sigue. En Badoo, también trabajamos con ellos en un momento: en mi artículo anterior conté nuestra historia sobre las revisiones de código y cómo se nos ocurrió la invención de nuestra propia "bicicleta": soluciones Codeisok .

Hay mucha información, puede buscar en Google un montón de artículos sobre revisiones de código con ejemplos reales, prácticas, enfoques que hablan sobre qué tan bueno, qué tan malo, cómo hacer y cómo: no necesita, qué debe considerar y qué no, etc. e) En general, el tema es "absorbido hasta el hueso".

Es por eso que la otra parte del iceberg puede no ser notada.

Espero que tome en serio las cosas que describiré en este artículo, en algunos casos exagerando deliberadamente. Una revisión, como cualquier otro proceso, requiere una implementación cuidadosa y deliberada, mientras que el enfoque "Haremos como todos los demás, si solo" no solo puede fallar, sino incluso dañar.

Después de leer esta introducción, puede tener una pregunta: ¿qué tiene de complicado la revisión de código? El punto es insignificante. Además, la mayoría de las herramientas enumeradas anteriormente de inmediato y ofrecen una revisión del flujo (listo para usar: configurar, confirmar / iniciar, ¡y listo!).

Pero la práctica muestra que no todo es tan obvio como parece a primera vista. Incluyendo debido a la simplicidad imaginaria del proceso. Cuando todo está en funcionamiento, existe el riesgo de que el gerente se calme y deje de hundirse en el proceso, pasándolo a los desarrolladores. Y seguirán el proceso o harán algo más en detrimento de la solución de los problemas que el proceso de revisión está diseñado para resolver. El gerente puede no ser consciente de que algo va mal, porque no establece las reglas ni impone reglas. Si bien es muy importante para una empresa resolver los problemas lo más rápido posible, sin perder tiempo en actividades no planificadas .

Érase una vez, cuando trabajaba en otra empresa, la conversación sobre las revisiones de código con uno de los principales desarrolladores me hundió profundamente. Fue p1lot . Quizás uno de los lectores esté familiarizado con él (p1lot, hola :)). Actualmente está trabajando con nosotros en Badoo, lo cual es genial.

Entonces, PILOTO dijo: "Lo más difícil para mí en el proceso de revisión es comprometer y omitir aún más la tarea finalizada y que funciona correctamente, incluso si conozco otra forma de resolverlo e incluso si me gusta más mi método". En mi opinión, este es un pensamiento clave. Y el mensaje principal de mi artículo completo de alguna manera gira en torno a este postulado.

¿Por qué necesito un proceso de revisión de código?

¿Tiene una revisión en su empresa? ¿Lo estás haciendo bien? Tengo una prueba que puede hacer que lo dudes.

Solo necesita responder tres preguntas:

1. ¿Cuánto tiempo lleva una revisión de código para una tarea promedio (esférica en el vacío)?
   
2. ¿Cómo minimizas el tiempo de revisión?
   
3. ¿Cómo se determina si una revisión de una tarea específica se realiza correctamente?
   

Si no tiene respuestas claras a algunas (o todas) preguntas, si duda de sus respuestas, me atrevo a suponer que algo va mal.

Si no sabe cuánto tiempo llevará revisar, y no lo minimiza constantemente, ¿cómo lo planea? ¿Es posible que el artista, que realizó la revisión durante cuatro horas, no haya bebido té la mitad esta vez? ¿Es posible estar seguro de que el tiempo para beber té no aumenta de una tarea a otra? ¿O tal vez el revisor no mira el código en absoluto, sino que simplemente hace clic en "El código está bien"?

E, incluso si la revisión se realiza de buena fe, ¿cómo podemos asegurarnos de que con el crecimiento de la base del código y la compañía, el tiempo para completar las tareas no aumente? Después de todo, la administración, por regla general, espera que los procesos se aceleren, no disminuyan.

Si la respuesta a la tercera pregunta no viene inmediatamente a la mente, entonces tiene sentido preguntar una más. ¿Sabes por qué realmente necesitas este proceso? ¿Porque "es tan habitual para todos los grandes"? ¿Quizás no lo necesitas para nada?

Si le pregunta a sus clientes potenciales y desarrolladores cuál es la revisión de código "correcta", se sorprenderá mucho de las diferentes cosas que escucha. Las respuestas pueden variar según la experiencia personal, las creencias, la confianza personal en la corrección o incorrección de las cosas, e incluso en la pila de tecnología utilizada y el lenguaje de desarrollo.

¿Recuerda las herramientas listas para la revisión de código, que ofrecen sus propios enfoques y flujo? Por ejemplo, me pregunto cómo responderían los desarrolladores de estas herramientas a la pregunta. ¿Sus respuestas sobre la "corrección" de la revisión se correlacionarán con las respuestas de sus empleados? No estoy seguro A veces veo tristemente cómo alguien implementa herramientas de revisión en casa, sin dudar ni un minuto de que sean necesarias. O la gente lo hace "para mostrar" o para informar que "implementaron la revisión del código, todo está bien". Y al final se olvidan de eso.


No quiero ser Cap, pero de todos modos. Cuando se comunique con los empleados, preste atención a respuestas como "Porque está tan establecido" o "Esta es la mejor práctica, todos lo hacen". Usted mismo es consciente de que no necesita implementar un proceso sin pensar sin comprender por qué es necesario. Cualquier proceso debe estar justificado e implementado (si es necesario) ajustado a las necesidades de la empresa y el proyecto, así como a los problemas que realmente existen y que realmente desea resolver. El culto a la carga en una empresa con una buena cultura de ingeniería no pertenece.

En consecuencia, es importante que el gerente transmita a las personas la revisión de código "correcta" que es necesaria precisamente en su proyecto. Y antes de esto, por supuesto, los criterios de "corrección" deben formularse para usted, elija las herramientas adecuadas y establezca las reglas apropiadas. Y ya hay cerca de control.

Revisión de código incorrecto

Entonces, ¿cuál es el proceso correcto? Vamos a hacerlo bien. A continuación habrá una gran parte de mi razonamiento personal, y para aquellos que no pueden esperar para saber lo que estoy escribiendo, propongo ir inmediatamente a la parte de "Buena revisión de código".

A los que se quedaron, les agradezco y, sin embargo, les propongo determinar la corrección de la revisión por mi cuenta, en función de las necesidades de su proyecto, considerando cuidadosamente todo. Y solo trato de ayudarte con esto.

Para resaltar cosas importantes y necesarias para usted en cualquier proceso, puede ser útil comenzar cortando las obviamente innecesarias que dañan la cultura de la ingeniería. Entonces hagámoslo.

Intercambio de conocimientos

A la pregunta "¿Por qué necesito un proceso de revisión de código?" He escuchado la respuesta " Compartir conocimiento " muchas veces. De hecho, una cosa útil y necesaria. Y muchos coinciden en que es importante contar con un proceso en el equipo para el intercambio de conocimientos y experiencia. Pero, ¿estás seguro de que la revisión del código es adecuada para esto?


En repetidas ocasiones he preguntado a las personas qué quieren decir con "intercambio de conocimientos". Y en respuesta escuché cosas diferentes.

En primer lugar, esta es una demostración para los recién llegados (en el equipo o el componente afectado) de las reglas y prácticas aceptadas: así es habitual que hagamos esto, y no lo hacemos, por eso y por eso.

En segundo lugar, esta es una nueva mirada de un principiante (nuevamente en un equipo o un componente afectado) sobre cómo se hacen las cosas ordinarias. De repente, se están haciendo de manera ineficiente, y ¿una nueva persona ayudará a descubrir esto?

En tercer lugar, esto es solo una introducción a alguna parte del código. De hecho, si en el futuro el revisor se enfrenta a la necesidad de cambiar esta parte del código, será mucho más fácil para él.

Repasemos todos los puntos e intentemos evaluar cuán relevantes son en el proceso de revisión.

Revisión de código como herramienta de capacitación para principiantes

En este caso, estamos hablando principalmente de tal escenario: a un principiante se le asigna una tarea, la realiza y luego un miembro experimentado del equipo (propietario del componente) indica los errores que cometió. El proceso es importante y necesario, no lo discuto: los principiantes deben mostrar de alguna manera las reglas aceptadas en el equipo.

Pero seamos honestos: ¿no es demasiado tarde? ¿No sería más correcto decirle al principiante acerca de estas reglas antes de admitirlo en el código? Después de todo, el precio de un error es muy alto: rara vez los principiantes trabajan de inmediato de la manera que necesita. Entonces, la tarea volverá y volverá para su revisión. Por lo tanto, el producto estará disponible para el usuario más tarde de lo que podría.

Resulta que en un proceso cuya duración es difícil de evaluar, agregamos otro, cuyos costos de tiempo son aún menos predecibles. Por lo tanto, aumentamos el tiempo requerido para entregar la tarea al usuario en una cantidad aún más desconocida.

Por supuesto, a veces la formación de principiantes a través de procesos de trabajo tiene derecho a existir. Pero a veces no pensamos en las deficiencias de los enfoques que se han convertido en un hábito. Y cometer un error aquí no solo es fácil, sino muy fácil.

Por ejemplo, si la empresa no cuenta con un proceso simplificado de capacitación y entrenamiento , el gerente se ve obligado a "arrojar al agua" a un recién llegado. Al mismo tiempo, este último no tiene otra opción: debe "nadar" o abandonar la empresa. Alguien realmente aprende de tales situaciones, y alguien no se pone de pie. Creo que muchos han encontrado problemas similares a lo largo de sus caminos profesionales. Mi mensaje es que el tiempo más valioso se puede pasar de manera no óptima debido a este fenómeno. Además del proceso de adaptación de un nuevo empleado en un equipo, puede no ser óptimo. Solo porque nadie tuvo las manos para organizar un proceso efectivo de introducción de nuevos empleados en el equipo, y el gerente pensó que el recién llegado aprendería todo en la etapa de revisión del código. Pero, de hecho, estos son dos procesos diferentes, muy necesarios e importantes.

Por supuesto, incluso en las condiciones en que las reglas se explicaron inicialmente al principiante y que la empresa tiene otros procesos de capacitación, el proceso de adaptación del principiante debe controlarse de alguna manera. Una revisión es un proceso que puede ayudar. Pero el control y el entrenamiento son dos cosas diferentes, ¿verdad? Además, todos los miembros del equipo necesitan control, y no solo los principiantes. Después de todo, todos podemos cometer errores, olvidarnos de los acuerdos y afectar de alguna manera la parte del sistema que posee todo el equipo (en este caso, el código).

¿Qué conclusión se puede hacer? El proceso descrito anteriormente tiene como objetivo lograr un objetivo diferente: no para la capacitación, sino para el control. Y este mismo control es necesario no solo para los principiantes, sino para todo el equipo.

Todo esto se formula fácilmente en la siguiente tesis: " Es necesaria una revisión del código para controlar el cumplimiento de los acuerdos y las reglas generales por parte de todos los miembros del equipo ". Y la capacitación de principiantes en este caso no será más que una sustitución artificial de un objetivo que solo confundirá a las personas y dirigirá el proceso en una dirección diferente.

Pero incluso con esta conclusión, que, al parecer, se formuló correctamente, la leña puede romperse. Una revisión de código es una fase que comienza cuando el código ya está escrito. Y puede suceder que el código escrito sin seguir las reglas generales sea muy costoso de adaptar al patrón general. Nuestra tarea es informar al contratista que algo salió mal lo antes posible. Y, por lo tanto, sostengo que a veces las revisiones de código no son el proceso más apropiado para monitorear el cumplimiento de las reglas generales. En muchos casos, las verificaciones de cumplimiento pueden y deben transferirse a etapas anteriores.

Por ejemplo, puede verificar el formato del código en los ganchos del sistema de control de versiones (así como el uso de clases seguras, arreglos para la ubicación de los archivos en las carpetas correspondientes, el uso de dependencias externas y bibliotecas de terceros, etc.). Esto minimiza el tiempo requerido para la revisión del código.

Continuando con la conversación sobre la formación de principiantes en el proceso de revisión de código, hagamos una analogía. Supongamos que produce algún tipo de producto, por ejemplo, pasteles. Supongamos que recibió un pedido de pastel para una boda VIP. ¿Confías la "revisión" del pastel terminado al novato? ¿Estás listo para que el nuevo pastelero se haga responsable de la vergüenza o el éxito de toda la panadería en esta boda? ¿O tal vez quieres que en esta etapa se familiarice con las reglas adoptadas por el equipo (cómo hornear pasteles, preparar crema e insistir en los arándanos con coñac)? Obviamente, tanto el proceso de introducir al principiante a las reglas como el control de su parte son cosas bastante extrañas en esta etapa: el pastel ya ha sido horneado. Entonces, ¿por qué podemos actuar de manera diferente con las características y el código? ¿O las características que lanzamos no traen vergüenza o el éxito de nuestro equipo a los ojos de los usuarios y clientes?

Puede objetar, diciendo que no preparamos tareas "para personas importantes" todos los días y que es completamente posible que un principiante se le confíe una tarea no muy urgente o no muy importante. Y tendrás razón.

Pero, en primer lugar, ¿qué aprende un principiante de tareas triviales en las que hay pocos cambios de código (y estos cambios no están en lugares críticos y para los negocios probablemente no son tan importantes, ya que la tarea es urgente)? ¿Cómo puede aprender a hornear pasteles si bate la crema todo el tiempo? La transición de simple a compleja, por supuesto, es necesaria. Pero es necesario hacer esto, controlando cuidadosamente el proceso. Los principiantes necesitan que se les enseñe, no que dejen de aprender solos.

Y en segundo lugar, incluso un enfoque aparentemente útil y correcto puede dañar a una empresa. Comprender esto es muy simple, usar el método de llegar al punto del absurdo para hacer que la conclusión sea lo más simple y comprensible posible.

Imagine que declaramos abiertamente que las tareas que nos da el gerente de producto son necesarias para capacitar a los recién llegados. Por qué Y lo mismo que con la revisión del código: después de todo, confiamos algunas tareas simples y no urgentes a los principiantes para que aprendan a trabajar de la manera habitual en nosotros.

¿Qué puede resultar esto al final? Un artista entusiasta que fielmente hace su trabajo y cree que todo lo que hace debe hacerse lo mejor posible, se hará cargo del proceso de aprendizaje. Puede configurar la tarea para realizar varias implementaciones en lugar de una, de modo que luego pueda mostrar al alumno las desventajas y ventajas de los diferentes enfoques. Puede dar conferencias, comparando los enfoques y las mejores prácticas utilizadas en la empresa y más allá. Puede hacer mucho más para educar al principiante. Como resultado, el tiempo requerido para completar la tarea aumentará, porque en lugar de desarrollarnos, nos enfocamos en la capacitación .

En el caso de una revisión de código, un empleado tan entusiasta inicia una larga discusión en los comentarios a la revisión sobre los beneficios y los peligros de ciertas implementaciones, publica fragmentos de código con Stack Overflow, mostrando que hay otras ideas en otras cabezas, da enlaces a artículos y libros que el estudiante debe lea para comprender que su implementación es imperfecta.

Este es un proceso de aprendizaje normal que puede existir, pero que debe hacerse correctamente. Y no siempre vale la pena integrarlo en el proceso de resolución de un problema comercial. Porque estos son dos procesos diferentes. Deje que el principiante haga los diferentes componentes del pastel, deje que haga varias opciones, deje que algo arruine y bótelo. Deje que alguien más experimentado le muestre cómo actuar y vuelva a contar recetas antiguas. Pero aprender "en la línea de producción" que produce su producto para los clientes no es una buena idea. Y si ya lo ha decidido, “guíe al recién llegado” por el asa, sin permitir que interfiera con el proceso de producción durante su entrenamiento.

Si su empresa no es una institución, ni una escuela, ni una escuela técnica ni ninguna otra institución educativa, la capacitación no es su responsabilidad directa. El negocio lo ha contratado para resolver otros problemas y lograr otros resultados.

Por cierto, es por eso que no agregamos funcionalidad a Codeisok para cargar imágenes, escribir, resaltar el código en los comentarios, aunque ha habido y aún hay muchas solicitudes para tales funciones. Promovemos la idea de que la revisión de código no es un blog personal, ni un mensajero, ni un servicio de capacitación. Se necesita una herramienta para otra. De hecho, para indicar las fallas en el código, un comentario de texto sin formato es más que suficiente.

Revisión del código como una nueva mirada al código

Sigamos adelante. El siguiente escenario de "intercambio de experiencias" es el siguiente: hacemos algo en el equipo, observamos acuerdos internos y nuestros ojos se vuelven borrosos, y luego vino una nueva persona (de otra compañía o de otro componente), y tal vez verá fallas en nuestro organización del trabajo.

La idea es buena, suena razonable. De hecho, ¿qué pasa si estamos haciendo algo mal?

Pero nuevamente, volvamos a la vida de la tarea y al inicio de la fase de revisión del código. ¿Es muy tarde? El pastel ya está horneado, los pasteles están untados con crema, las rosas están pegadas. El precio del error es muy alto. Y luego descubrimos que en otra panadería en los pasteles agregamos refrescos, apagados con jugo de limón, para esplendor. ¿Y qué? Que hacer Remodelación?

Obviamente no, porque: 1) siempre lo hicimos sin refrescos, y el resultado no fue malo; 2) es posible que los clientes nos quiten pasteles, y no de otra panadería, porque no les gusta el sabor de los refrescos; 3) el pastel está listo, la boda es esta noche y no tendremos tiempo para hornear un nuevo pastel.

Entonces, ¿por qué es todo esto? Es necesario compartir experiencia. Se necesita una apariencia fresca. Pero, me parece, en una etapa diferente. Por ejemplo, antes de hornear pasteles, puedes consultar con un principiante: “¿Y cómo hiciste esto antes? ¿Por qué es mejor este método? Y, probablemente, vale la pena hornear un par de pasteles de la manera antigua y nueva para probar a nuestros clientes habituales y obtener su opinión.

La implementación irreflexiva de las mejores prácticas vistas en artículos o informes puede dañar a la empresa y al producto. "Todos los principales jugadores agregan refrescos a los pasteles:" Bugle "," Tracebook "," Rile.ru "," Yumdeks ". Todos lo hacen ". ¿Y qué? Debido a esto, ¿debería Petya abordar de inmediato una nueva versión de una tarea que ya está lista?

Estoy seguro que no Si inicialmente, antes de resolver el problema, no estaba de acuerdo con que "habrá refrescos en los pasteles", entonces es muy miope exigir su adición en la etapa de revisión del código. Su negocio no tiene el objetivo de "tener refrescos en pasteles". Si sus pasteles ya se venden bien, entonces no importa si tienen refrescos o no.

Debe comprender que el intercambio de experiencias es otro proceso que no está vinculado a una revisión de código de ninguna manera. Puede ocurrir antes, más tarde o en paralelo con él, pero es diferente. Puede organizar clases magistrales mutuas con competidores. Algunos intentan robar una receta súper secreta y una técnica ultramoderna de batir crema con un perforador. Alguien está tratando de espiar las ideas de otras personas y mejorar sus procesos con su ayuda. Pero es extraño hacer esto en un transportador en funcionamiento, en la etapa en que su producto está casi listo y el precio de la conversión es muy alto.

Después de todo, estamos hablando de la etapa de revisión. Una revisión de código que ya se ha escrito y está lista para el siguiente paso. Este código está esperando que el revisor haga clic en el botón "El código está bien". Y sus clientes no están preparados para el hecho de que preparará un pastel horneado con un nuevo chef para mostrarle cómo hornea pasteles y escucha sus críticas.

Revisión de código como introducción a un fragmento de código

Quizás esto parezca la parte más razonable y comprensible, con la que muchos están de acuerdo. El escenario aquí se entiende como sigue: un programador escribió el código de la tarea, el resto lo miró, lo estudió y ahora saben cómo trabajar con él. Por lo tanto, reducimos el riesgo de un factor de bus : si el desarrollador se va, otros podrán trabajar con éxito con su código. Y también estamos listos para el hecho de que la próxima vez este código puede ser "tocado" por otra persona, en cuyo caso él ya sabrá cómo trabajar con él.

Pensemos si esto realmente funciona según lo previsto y si realmente ayuda a las personas a compartir competencias y conocimientos sobre secciones específicas del código.


Veamos la situación a través de los ojos de la persona que escribió el código. , ?

, - (, , , ). , ? , . , , , .

, , , , . . , ?

, - . , - . , : , . , , , , .

, . , - ? — . , , .

, , , - . , . , , . , , , . . , - : , , .

? , , — . .

best practices « -» « , ». ¿Y qué? Best practices , , . , ? . , - , .

best practices, , . . — - , / — . « », « », « — , DI». ? ?

, , . , , — , .

, -, «», , - . ? - , , , . , . , .

-, « » «» , . -, . , , - , : ? . , , ( : , ).

, , . , , ( , ?).

— . , , . . ? bus factor , , - , .

, , , : , ?

— , , ?
— .
— ?
— .

. , ? , , , ? , , , — ?

, , , , , ?

, , , . , , .

, . , , , ( ), , ( , , , — , . .). , .

— , , , . ( , , . .) . — — .

Code review

« ?» . , , .

: - , , - , , . git blame , , , , , .

, , — , , , ( ) — . , , . . , ?


. ?

, , , . , , , . , - ( , ). , , — , , , .

, , . ? , .

, , , . , . , ? .

, , — , . ( )?

« - - » . , . .

: . .

, , . , . , .

, , — . , .

— . , . , . , .

, , :

? , , ? ? , , ? - , ? ? ? Y así sucesivamente.

, . , . , .

, , . , , , . , , , .

, best practices, . , , , , . . , , . , .

,

. , , . - , , - .

, , . , API- . , bus factor, .

, . .

- ? , . , . null , « ». .

, . , ? ?

-

Esta etapa de verificaciones también es muy importante, ya que tiene como objetivo mejorar el notorio soporte de código.

Mucha gente entiende lo que significa el término mantenibilidad del código, pero no todos pueden explicar qué es. Y si es así, ¿cómo establecer la tarea para que el equipo mantenga esta capacidad de mantenimiento? Por lo tanto, creo que un desarrollador que piense en cómo se probará su código, y mucho menos probará su propio código y escribirá un autotest para automatizar las pruebas, naturalmente se esforzará por garantizar que su código satisfaga la mayoría de los criterios de mantenimiento del código. De hecho, sin esto, escribir un autotest es casi imposible.

La recomendación general para cualquier cambio de código también puede ser la descomposición correcta de las tareas . Cuanto menor sea la cantidad de código que pasa por la tubería de todos los procesos, desde la idea hasta la producción, más fácil es este código para verificar el cumplimiento, probar, combinar con el código de otras tareas y cargar. Una revisión de código no es una excepción. Una tarea con una gran cantidad de líneas cambiadas en muchos archivos es muy difícil de leer y comprender (y tener en cuenta las dependencias). El riesgo y el costo de corregir errores pueden ser muy altos.

Conclusión

Eso, de hecho, es todo. Estos cuatro puntos son precisamente las cosas que deben verificarse en la etapa de revisión. Son fáciles de formalizar, fáciles de transmitir a los artistas intérpretes o ejecutantes, lo que significa que no es difícil formular criterios de verificación y predecir la duración. La automatización y otras formas de minimizar el tiempo de revisión son más que posibles.

Y finalmente, daré algunos consejos más.

Es importante recordar que cualquier devolución del código para revisión no afecta la calidad de la implementación de la mejor manera. Incluso si todos tienen buenas intenciones. En el caso de las revisiones de código, funciona así: el desarrollador corrige el código, pero no lo prueba tan a fondo como en la primera iteración (¿por qué? Después de todo, ya lo comprobó todo y lo cambió un poco). La experiencia ha demostrado que la mayoría de estas situaciones se convierten en errores precisamente en aquellos lugares donde hubo correcciones basadas en los resultados de la revisión del código. Así es como funciona la psicología humana.

Al comienzo del artículo, le sugerí que respondiera tres preguntas sobre la necesidad y la corrección de una revisión. Ahora tiene un algoritmo para ayudarlo a encontrar las respuestas. Conociendo los pasos de control y teniendo en cuenta el tamaño de la tarea, es muy posible planificar el tiempo requerido para la revisión del código, cada vez que se intenta reducirlo cada vez más.

Al implementar cualquier proceso, es importante recordar los objetivos que nos fijamos y los problemas que queremos resolver. Entonces será mucho más fácil separar los granos de la paja y formular criterios medibles para evaluar la efectividad. Y debe formularlos para usted y para su equipo, que también necesita resolver urgentemente los problemas que han surgido, pero puede comprenderlos a su manera.

Hay un punto más importante: aquellos procesos, reglas y valores que son justos para una compañía pueden no ser tan útiles y funcionar en otra. Lo que describí como ejemplos de la revisión correcta funciona en nuestra empresa. Promovemos el desarrollo rápido, lanzamientos frecuentes y revisión para cada tarea. Piense en cuán aplicable es esto a su proyecto, y que una revisión es uno de esos procesos que no se puede dejar al azar.

Pero la decisión, por supuesto, queda contigo.