¿El código revisa las buenas prácticas?

Cuando la empresa en la que trabajo contrató a nuevos gerentes, nos ofrecieron una visión general del código de alguien en cada reunión. Tenemos reuniones cada dos semanas, por lo que cada vez que uno de los desarrolladores debía mostrar su código en el proyector, y otros iban a discutirlo.

Pensé que esto sería genial: cada desarrollador sería más cuidadoso al escribir código y podríamos compartir mejor nuestra experiencia. Pero de alguna manera nos olvidamos de esto y la oferta siguió siendo una oferta.

¿Cuáles son los beneficios de esto y hay algún inconveniente?

Las revisiones de código son una gran práctica.

Probablemente sea la mejor manera de aprender de los errores y ver cómo otros resuelven ciertos problemas. También es una de las mejores formas de mantener la calidad en una base de código.

Las revisiones de código ocurren en muchas compañías, aunque es difícil decir que hay un proceso específico que todas siguen.

En una revisión de código más formal, un senior (o varios seniors) se sentará junto con un desarrollador para revisar su código, ofreciendo sugerencias y enseñanza al mismo tiempo.

Los beneficios adicionales de las revisiones de código (como se comentó para esta pregunta) incluyen:

• Una excelente manera de enseñar y aprender.
• Son una de las mejores formas de mejorar y mantener la coherencia de una base de código (estilo y modismos)
• Ayudan a garantizar que todos los miembros del equipo entiendan el estilo y las expresiones idiomáticas utilizadas en el proyecto y cómo usarlas.
• Las revisiones de código acelerarán el desarrollo a medida que detectan errores y fallas de diseño temprano (por lo tanto, aunque pueden ralentizar el desarrollo inicial, pagan dividendos en los ciclos de desarrollo posteriores)
• Hay soporte de herramientas que ayuda a simplificar el proceso de revisión de código

Las revisiones de código son una herramienta muy útil para el aprendizaje , especialmente cuando tienes un nuevo miembro del equipo a bordo. Bueno, también se conoce como proceso de revisión por pares :)

Existen diferentes tipos de revisiones de código:

• Sobre el hombro : donde un desarrollador mira por encima del hombro del autor del código mientras este último recorre el código.
• Transferencia de correo electrónico: el sistema de administración del código fuente envía el código por correo electrónico a los revisores automáticamente después de realizar el registro. Extracto del comentario: después de haber fallado en convencer a la gerencia para que asigne tiempo para cualquier tipo de revisión formal del código, me he ocupado de revisar los cambios de mis compañeros de trabajo cada vez que elimino nuevas revisiones del control de origen usando las herramientas de historial / diferencia incorporadas en Tortise
• Programación en pareja : dos autores desarrollan código juntos en la misma estación de trabajo, tal es común en la Programación extrema.
• Revisión de código asistida por herramientas : los autores y revisores utilizan herramientas especializadas diseñadas para la revisión de código por pares.

Solo hay uno associated disadvantagedonde las revisiones formales de códigos han requerido una inversión considerable en preparación para el evento de revisión y el tiempo de ejecución.

Más referencias se enumeran a continuación (para más lecturas de inmersión profunda)

• MSDN - Revisión de código
• Encuentre y repare vulnerabilidades antes de que se envíe su aplicación
• Enlace Wiki

Esa práctica en particular parece ineficiente y es probable que sea vergonzosa: quién quiere que sus errores apunten a todo un grupo de personas. Entonces, si no pueden elegir lo que se va a revisar y el código aún no está en producción, es probable que esto incomode a las personas.

Dependiendo de cuándo se revise el código puede hacer una gran diferencia en si los comentarios de revisión del código entran o no en el código. Si el desarrollador puede elegir y elegir solo el código de producción, es poco probable que los comentarios de revisión se implementen. Es agradable tener reuniones donde los desarrolladores pueden mostrar alguna técnica ingeniosa que aprendieron que otras personas estarían interesadas, pero eso no es una revisión de código. Eso es entrenamiento.

Hacemos una revisión de código de cada fragmento de código antes de que se mueva a QA. Cada pieza. Generalmente involucra solo al revisor de código y al desarrollador. No pasa al control de calidad hasta que el revisor del código lo apruebe formalmente. Entonces el desarrollador tiene que hacer los cambios. Hemos encontrado y solucionado rápidamente muchos problemas que QA podría no haber encontrado (también encuentran cosas que no vemos en la revisión de código). Además, reduce la codificación del vaquero e identifica rápidamente a las personas que no están funcionando bien para que podamos solucionar sus problemas y entrenarlos o deshacernos de ellos antes de que dañen nuestra aplicación. El tiempo de revisión del código es parte de nuestro tiempo estimado cuando planificamos el trabajo, por lo que no afecta en absoluto la fecha límite. Y en realidad, ahorra tiempo a largo plazo porque cuanto antes se encuentre un problema, más fácil será solucionarlo.

Personalmente, he enseñado a los desarrolladores menos experimentados muchas técnicas mejores a través de la revisión de código y he aprendido algunas técnicas mejores al revisar el código de otras personas, así como sus comentarios sobre mi código. La revisión adicional del código asegura que alguien más comprenda el código, lo que contribuye en gran medida a que sea más fácil de mantener. A veces, el código funciona, pero las preguntas de la revisión dejan en claro que habrá problemas de mantenimiento porque el código es difícil de entender. Es mejor refactorizar en esos casos mientras todo está fresco en su mente que un año después, cuando incluso el autor del código se rasca la cabeza y se pregunta por qué el código hace tal o cual cosa.

El problema con este tipo de revisión de código, un desarrollador cada dos semanas, el progreso será lento. Pueden pasar meses antes de que todos hayan tenido un giro bajo los reflectores.

Si bien las revisiones de código pueden ser buenas, debe haber una razón detrás de ellas y del procedimiento para hacerlo.

Varias cuestiones tendrían que decidirse:

• Quién elegiría al desarrollador y cuánto aviso se les daría. Sin previo aviso las revisiones son trampas.
• Quién elegiría la parte del código que se está revisando: la administración, el desarrollador principal del proyecto o el desarrollador que se está revisando.
• Es el propósito de enseñarle a la persona cuyo código está en el proyector cómo hacer algo mejor, o es el propósito de la persona cuyo código está en el proyector enseñar a todos los demás en la sala cómo mejorar su código.
• ¿Qué porcentaje de código se revisará de esta manera? ¿Será parte del proceso de control de calidad?

Si las personas que propusieron este plan aún no tienen respuestas a estas preguntas, es posible que lean un artículo sobre cómo todas las grandes compañías hacen revisiones de códigos, por lo que deberíamos hacerlas también, sin comprender el propósito detrás de ellas.

La revisión de código es una buena práctica, solo cuando la idea para la revisión de código proviene del equipo de desarrollo. Los desarrolladores no necesitan proyectores y presentaciones para revisarse mutuamente el código. Si quieren, preferirán ir a la conferencia.

Cuando la idea de la revisión del código proviene de la administración, puede sonar como una investigación de baja calidad de software y puede desmoralizar al equipo de desarrollo. No creo que el equipo de gestión deba participar en el proceso de revisión de código. Revisión del código junto con el equipo de administración: muy mala, asesina y práctica destructiva.

La revisión de código es una práctica excelente, especialmente si los desarrolladores la hacen para compartir conocimientos, y las reglas básicas se establecen de antemano para que las sugerencias y críticas sean CONSTRUCTIVAS, y no para usar un desarrollador individual para la práctica objetivo.

Los administradores que no son desarrolladores serán recibidos con sospecha por los desarrolladores si deciden hacer revisiones de código. La mayoría de los tipos de administradores no querrán entrar en los detalles en los que los desarrolladores se involucran inherentemente al mirar el código. La mayoría de los gerentes tampoco entenderán por qué los desarrolladores critican un enfoque sobre otro.

Si desea mostrar el buen trabajo que los desarrolladores están haciendo a la administración, entonces "revisión de código" tiene un significado diferente, y no debe ser tan detallado como las revisiones de código que se realizan para instruir / mejorar la calidad del código entre los desarrolladores. Este tipo de presentación podría ser útil para demostrar lo que hacen los desarrolladores si la presentación puede ser de mayor nivel y menos específica del código, centrándose en lo que los gerentes entienden (valor, ROI, etc.). Podría hacer que los gerentes entiendan que Joe ha agregado un valor significativo a la compañía al construir X, que podemos mostrar ahorra una cantidad Y de tiempo, o Z dólares por pedido, etc. Creo que podría valer la pena mostrar el valor de cada individuo. miembros de tu equipo. Sin embargo, recuerde que debe tener cuidado de no abrumar a su audiencia con jerga o demasiados niveles de detalle.

Si bien estoy totalmente de acuerdo en que las revisiones de códigos son muy constructivas para la enseñanza, me gustaría destacar que, de todos modos, para mí es garantizar que los patrones de diseño del equipo se sigan correctamente.

Escribimos un pequeño trabajo de prototipo y refactorizamos fragmentos de código y, aunque al final nos sentimos cómodos con el producto, la legibilidad se ha dañado: la gente no puede mirarlo y ver con claridad lo que está sucediendo.

Los ojos independientes siempre son beneficiosos, me parece que te atascas en ciertos modos de pensamiento y esto es en todos los niveles de experiencia. Usted invirtió horas en el diseño y el código, por lo que es difícil lidiar con las revisiones de código cuando existe el temor de que su esfuerzo sea rechazado. Sin embargo, al final, con suerte, terminará con una aplicación más limpia, más ágil y más manejable, y la experiencia está arraigada en usted.

Para nuestro equipo, hacemos lo que @ElYusubov mencionó y utilizamos una herramienta específica para Code Review - Crucible. Las personas revisan, comentan y firman el código. Cada semana nos sentamos y revisamos cara a cara piezas de código interesantes y / o complejas.

Como pasante de ingeniería de software, he encontrado que las revisiones de código son inmensamente útiles.

En mi equipo, se requiere una revisión del código para cada confirmación (los grandes cambios terminan siendo formales, los cambios más pequeños terminan siendo 'miradas rápidas'). Definitivamente siento que mis habilidades de ingeniería / diseño han sido impulsadas por esto, especialmente porque es más probable que retire la pizarra blanca que el terminal de inmediato, ya que sé que estoy siendo 'observado'. :)

En efecto, creo que produce un código mucho mejor con el único inconveniente leve que es un tiempo de desarrollo un poco más lento (que en mi opinión, vale la pena a largo plazo cuando no tienes que arreglar / extender un código terriblemente diseñado). Además, creo que si tienes juniors / pasantes en el equipo, apreciarán la oportunidad de recibir comentarios valiosos. ¡Sé lo que hago!

Desde mi experiencia, la revisión de código es realmente genial si la realiza bien. Cuando tienes miembros y gerentes de equipo profesionales / maduros. Nosotros como programadores somos "solucionadores de soluciones". Nuestro trabajo no es crear líneas de "texto". Es por eso que tenemos que compartir ideas, errores, problemas, experiencias. La revisión del código es realmente una buena práctica para lograr esto.

Desafortunadamente, suena muy bien, pero es muy difícil de implementar en la mayoría de las empresas. Su equipo necesita mucha "autonomía". Convencer a sus gerentes o departamento financiero de que no crear nuevas funciones es rentable parece difícil.

En mi empresa estamos tratando de hacer una revisión de código. Pero se pasa demasiado tiempo persiguiendo al conejo (haciendo funciones).

Gran parte del estilo y las comprobaciones de tipo de sintaxis básica se capturan utilizando herramientas en estos días (FXCop, etc.).

Sin embargo, las revisiones de código son buenas, especialmente con los nuevos miembros de un equipo, cosas complejas o de alto impacto (por ejemplo, algo que será notorio para personas importantes si falla o causa un impacto comercial) y especialmente cuando se externaliza o utiliza contratistas a corto plazo (especialmente de nuevo cuando son hablantes no nativos, ya que los errores de traducción / problemas de idioma pueden permitir que el software pase todas las pruebas pero en realidad no haga lo que se supone que debe hacer).

No soy un fanático de poner código en un proyector para que un equipo lo revise, mucho mejor tener una reunión de revisión de código donde otro miembro del equipo (líder del equipo, etc.) revise una lista con el desarrollador. Esto afecta a menos personas, detiene mucho tiempo perdido en argumentos de estilo y es menos vergonzoso para el desarrollador. Es más constructivo y más fácil para el desarrollador absorber problemas reales y no cegarse por el tipo de comentarios "Hubiera hecho esto ...".

También creo que las revisiones de código no forzadas, como poner código en un recurso compartido o enviarlo por correo electrónico con la esperanza de que alguien renuncie a la hora del almuerzo para revisarlo, es una pérdida de tiempo.

Un asiento con un montón de listas, un marcador y una taza de café en el área de café es genial para esto.

Este tipo de show and tell grupal sería bueno para las nuevas tecnologías o para obtener varios jr. desarrolladores a la velocidad, pero no creo que sea tan bueno como una revisión constante del nuevo código. Es más eficiente tener que hacerlo uno a uno.

La revisión de código ayuda a ver "el todo". Los desarrolladores independientes tienden a ver solo sus requisitos / problemas. CR descubre ideas y soluciones desde toda la perspectiva. CR principalmente ayuda a eliminar el desperdicio de trabajo innecesario. Todo el producto es más barato y de mejor calidad.