¿Cómo tratar sin revisiones de código en mi nuevo lugar cuando vengo de esa práctica?

El equipo de mi nueva empresa no tiene un proceso de revisión de código.

Vengo de empresas con la revisión del código como una cultura obligatoria y, por lo tanto, no me siento cómodo cometiendo mi código sin que alguien lo revise.

Creo firmemente que la revisión de código es una forma de mejorar la calidad y ahorrar tiempo porque detecta problemas potenciales antes (tenga en cuenta que no estoy hablando de programación de pares).

• ¿Cómo puedo mostrar que la revisión de código no es una pérdida de tiempo sino un ahorro de tiempo?
• ¿Se puede omitir la revisión del código si tiene pruebas unitarias?

¿Se puede omitir la revisión del código si tiene pruebas unitarias?

¿Pero por qué?

La función principal de la revisión por pares es no detectar errores.

Sí, puede identificar algunos errores potenciales y un código dudoso propenso a errores, esto sucede a menudo, pero ocasionalmente detectar algunos errores no significa que la revisión por pares sea una forma confiable de descartar la presencia de errores. Lejos de eso. No es la herramienta adecuada para verificar la corrección funcional de la implementación.

Sin embargo, la revisión de código impone la mantenibilidad del código . Exigiré que el código sea limpio y comprensible (no solo para su autor) antes de que entre en producción.

La presencia de pruebas unitarias es completamente ortogonal a eso. Puede tener una cobertura del 100% del código y todas las pruebas que pasen por un código totalmente incomprensible.

La revisión de código también sirve para familiarizar a otros desarrolladores con su trabajo para que sepan qué es qué y puedan recoger desde allí, o manejar informes de errores mientras está de vacaciones, etc. Saber lo que ha hecho de inmediato puede ayudarlos. hacen bien su trabajo: mantenga la base de código coherente (respete patrones y convenciones similares en toda la aplicación) o evite la duplicación de código.

En un esquema más amplio de cosas, uno también aprende y crece como desarrollador al leer el código de otras personas.

Las pruebas unitarias difícilmente pueden ser una sustitución de ninguna de ellas. Sí, si están bien escritos, se leen como documentación, y debemos esforzarnos por esto. Pero, de nuevo, esto no es mutuamente exclusivo con la realización de una revisión por pares, sino todo lo contrario: todas las ventajas de la revisión por pares siguen siendo válidas, el hecho de que sus pares tengan algunas buenas pruebas unitarias para mirar solo hará que el proceso de revisión sea más fácil y aún más beneficioso en lugar de redundante.

¿Existen estudios y estadísticas que muestren que la revisión del código no es una pérdida de tiempo sino un ahorro de tiempo?

No se de ninguno. También es difícil realizar tales estudios, porque necesitaría dos equipos que tengan una tarea de complejidad igual y realista para realizar, donde uno usa revisiones de código y el otro no. Probablemente necesites que resuelvan el mismo problema, lo que significa tirar mucho dinero por la ventana. Y necesitaría repetir el experimento con la frecuencia suficiente para obtener relevancia estadística, lo que aumentaría ese lanzamiento de dinero en órdenes de magnitud.

Si solo mide la eficiencia de las compañías que utilizan revisiones de código contra las compañías que no lo hacen, no solo no está claro cómo medir la eficiencia, sino también cuál es la causa real. Las revisiones de código son parte de una cultura más amplia. Es difícil determinar qué parte de la realidad hace que el equipo sea más eficiente (y puede muy bien depender de la naturaleza del equipo o del proyecto). O la presencia de esta cultura puede significar simplemente que la empresa es más pequeña o más joven, y cada una tiene muchos efectos. O bien puede ser simplemente que la disposición a someterse a revisiones de códigos impide o fomenta una distancia saludable hacia su ego;)

Pero no lo olvide: tiene su propia experiencia para aprovechar. Es parte de por qué te contrataron. Entonces, si realmente cree que puede aumentar la eficiencia (y su equipo realmente sufre una falta de ella), comuníquelo claramente.

¿Se puede omitir la revisión del código si tiene pruebas unitarias?

No Si cree en la importancia de las pruebas, entonces sus pruebas deberían ser lo primero que se revisará. ¿Qué pasa si no tienen sentido? ¿O si la cobertura es pésima? ¿O si prueban la implementación en lugar del comportamiento?

Tomado de algunas diapositivas aleatorias que encontré , pero los datos duros provienen del libro Code Complete de Steve McConnell:

¿Son útiles las revisiones de código?

"Creo que las revisiones de código de pares son lo más importante que puedes hacer para mejorar tu código"

Jeff Atwood de Coding Horror en http://www.codinghorror.com/blog/2006/01/code-reviews-just-do-it.html

---

"Las inspecciones individuales generalmente detectan alrededor del 60 por ciento de los defectos, que es más alto que otras técnicas, excepto la creación de prototipos y las pruebas beta de alto volumen".

Steve McConnell, Code Complete 2nd Edition, página 485

Esa cifra del 60% proviene del documento IEEE de Shull et al 2002 Lo que hemos aprendido sobre la lucha contra los defectos que contiene la sección titulada:

"Las revisiones por pares detectan el 60% de los defectos"

Descargo de responsabilidad: esta respuesta es mi experiencia personal :)

Hice muy malas experiencias con las revisiones de código en el código que mantenemos. Debido a que generalmente solo tenemos un revestimiento más o menos y no hay mucho que revisar.

Pero en proyectos reales hice buenas experiencias, en mi tiempo de examen mi entrenador revisó mi código regularmente y me ayudó mucho encontrar algunos errores que cometía con mucha frecuencia, que ya no hago.

Entonces diría que depende en gran medida de lo que estás haciendo, cuántas personas eres, etc.

Además, el riesgo de que sus revisiones de código terminen en una guerra no es subestimarse.

Puede pedirle a su líder de equipo y / o colega que revise su código por pares, incluso si las revisiones de código no se realizan normalmente, tal vez como parte de su capacitación.

Asegúrese de que su código esté bien escrito y probado antes de la revisión.

Cuando era líder de equipo, solía hacer revisiones de código de nuevos empleados, hasta que (después de un tiempo) dejaba de encontrar errores o cualquier otra cosa para criticar en su código, y en qué punto dejaba de hacer revisiones de código con ellos; eso sucedería cuando:

• Aprendieron los sistemas con los que interactúan y no necesitaron mis explicaciones.
• Aprendieron a diseñar y / o probar su código hasta que estuvo libre de errores antes de que lo viera
• Aprendieron lo suficiente sobre mis pautas de estilo de codificación que consideraría que su código se puede mantener

Las revisiones de código tienen varios propósitos:

• Encontrar defectos en el código
• Transferencia de conocimiento entre los miembros del equipo.

Creo que está bien hacer revisiones de código de nuevos empleados, incluso si el equipo elige omitir las revisiones de código entre los miembros experimentados del equipo.

No existe una regla general para que se realicen revisiones de código en ningún software desarrollado ... todo depende del alcance de la aplicación, el tamaño del cliente y el tamaño de la empresa. Por ejemplo, si está compilando una aplicación donde es una aplicación simple donde puede que no se implementen más versiones en el futuro, las pruebas unitarias son suficientes allí. Pero una vez más, la revisión del código entra en vigencia cuando habla sobre el rendimiento de la aplicación en la que necesita revisar el código para detectar cualquier caída breve del código que podría haberse hecho de una mejor manera para facilitar un rendimiento más rápido.

Las revisiones de código generalmente se realizan cuando hay un equipo de más de 2 desarrolladores y un líder tecnológico donde el líder tecnológico quiere garantizar la calidad de la aplicación y asegurarse de que se sigan los estándares del código para escalar la aplicación para futuras mejoras y actualizarla para diferentes Próximas versiones.

Por ejemplo, tenemos muchas plataformas de código abierto de CMS ahora y estas plataformas lanzan actualizaciones de vez en cuando para mejorar las características de la plataforma, imagina a un desarrollador usando una de estas plataformas y no ha seguido los estándares de código como la codificación rígida en archivos centrales, escribiendo aplicaciones código en archivos de plantilla, y si este código pasa a producción y más tarde cuando el cliente desea actualizar la plataforma a una nueva versión, nunca se actualizará a menos que la codificación se vuelva a realizar según los estándares de código para esa plataforma. Aquí se convierte en un problema grave el lanzamiento del código a producción sin que se realice una revisión del código.

Entonces, diría que realizar revisiones de código antes del lanzamiento es imprescindible para cualquier compañía de software profesional y las excepciones solo pueden ser para aplicaciones personales / de muy pequeña escala donde el desarrollador es un programador muy experimentado y tiene experiencia con él.

Las revisiones de código tienen ventajas que no provienen del proceso de revisión en sí: siempre existe un dilema para obtener código de alta calidad, pero creado en poco tiempo. Sin revisiones de código, está solo, por lo que puede sacrificar la calidad por hacer el código en poco tiempo. Con las revisiones de código, hay un revisor que no le permite salirse con la suya, lo cual es exactamente lo que desea, verse obligado a pasar el tiempo para obtener el código de calidad que es lo que quería en primer lugar, y que sabes que terminarás ahorrando tiempo porque cada hora que pasas escribiendo un código mejor es dos horas ahorradas en la depuración (o más).

Sin revisiones de código, usted está solo, por lo que depende de usted mantener una alta calidad de código. Una solución simple es revisar cada cambio que realice usted mismo y arreglar cosas que no cumplen con sus estándares de calidad.

Esto también evita situaciones horribles donde las revisiones de código conducen a choques de egos: la situación en la que el programador A usaría el método X, mientras que B usaría el método Y, por lo que si A escribe el código que usa el método X, el revisor B insiste en el método Y, entonces, A reescribe el código usando el método Y, mientras que si B hubiera escrito el código y A lo hubiera revisado, habría sucedido exactamente lo contrario.

Si eres un defensor de las revisiones de código, me temo que no hay un sustituto real. El caso desafortunado y estereotípico es un lugar de trabajo que no hace revisiones de código porque (A) no están familiarizados con la práctica, y / o (B) no quieren dedicar el tiempo y el esfuerzo para obtener una revisión de código sistema en su lugar.

Básicamente, para obtener lo que quiere aquí, necesita un cambio de cultura en el lugar de trabajo, y eso nunca es simple o fácil. No olvide que incluso si su lugar de trabajo está 100% convencido de que las revisiones de códigos son excelentes y quieren adoptarlas, en realidad, cambiar a la nueva forma de trabajo requerirá una inversión significativa de tiempo, energía y productividad. Esta inversión debe pagarse por sí misma, pero debe tener la aceptación de la inversión, no solo de la recompensa. Vea el video de Roy Osherove "Pruebas unitarias y TDD: cómo hacer que suceda" : los desafíos de adoptar revisiones de código son muy similares a los de adoptar pruebas unitarias.

Mientras tanto, haga lo que pueda para obtener todo lo que pueda:

• Si hay otros desarrolladores que ven el valor de las revisiones de código, intente revisarse entre sí, incluso de manera informal.
• Si tiene un mentor o algún desarrollador responsable de su capacitación, explíquele el valor que ve en las revisiones de código y pregúnteles si estarían dispuestos a revisar su código, al menos en ocasiones.
• Dígale a su gerente que desea revisar el código de otras personas, porque lo ayudará a comprender mejor el sistema.
• Si en algún momento se convierte en un líder de equipo, puede instalar revisiones de código localmente, solo para su equipo.

Uno de los principales beneficios de cualquiera de estos es que, si puede mantenerlos a lo largo del tiempo, los desarrolladores a su alrededor comenzarán a notar las revisiones de código. Demostrará efectivamente cómo las revisiones de código pueden integrarse dentro de la cultura existente, y eso abre el camino para que la cultura comience a cambiar. Las revisiones de código ayudan , por lo que si puede demostrarlo a pequeña escala, eso abrirá el camino para que otros, y la cultura en general, sigan su ejemplo.

Deja de preocuparte por eso: a tu nuevo empleador simplemente no le importan las revisiones de códigos. Aprenda a tener cierta confianza en sus propias habilidades sin que otra persona le diga que está bien que verifique el código que ha escrito. Pronto aprenderá a vivir sin el proceso tedioso que está revisando el código de otras personas.

Siga las pautas de estilo (o simplemente el estilo) que todos los demás usan. Use su experiencia para decidir qué necesita comentar, qué convenciones de nomenclatura usar, etc.

Luego pruebe todo antes de registrarlo. Lo más importante es que funciona correctamente.

Si a su nuevo empleador no le gusta la idea de las revisiones de código, puede deberse a que tienen una asociación negativa con las metodologías anticuadas de tipo comando y control y apuntan a un conjunto de prácticas más moderno y ágil. En este caso, pueden estar más abiertos a la idea de la programación de pares, que proporciona muchos de los mismos beneficios, y es ampliamente considerada como una práctica más dinámica y moderna.