tools code checklist code-review

code-review - checklist - code review tools



¿Qué implican las revisiones de tu código y qué patrones tienen éxito? (7)

Comience por echar un vistazo al concepto de inspecciones Fagan .

Este método realmente ayuda a la calidad del código revisado, ¡y a la revisión en sí misma!

Y siempre recuerda criticar el código y no el codificador.

Quiero entender mejor los patrones que funcionan y los patrones que no funcionan para revisiones de código exitosas.

  1. ¿Debería haber una diferencia entre una revisión formal del código y una revisión informal del código?

  2. ¿Qué nivel de documentación de la revisión del código hace la gente?

  3. ¿Puede una revisión de código ser igual de útil sin la participación del autor del código?

No creo que deba ser tanto formal como informal, ya que hay diferentes tipos de tiempo permitidos para las revisiones de código. Si hay un error que debe solucionarse lo antes posible y el cambio de código es solo unas pocas líneas de código, es posible que este se revise, pero probablemente no de la misma manera que si estuviera ejecutando un nuevo sistema ERP o CRM. Además, en algunos casos puede haber horas reservadas para revisar algún código, mientras que en otros debería tomar menos de 5 minutos.

La documentación puede estar en algunas formas. Puede ser simplemente un correo electrónico que dice que Joe revisó el trabajo de Bob y que esto está aprobado para pasar a la siguiente etapa para un lanzamiento. Alternativamente, pueden ser algunas páginas de notas sobre qué cambiar antes de promocionar el código para que se usen algunos patrones de diseño y se borre el código de su forma inicial rápida y sucia.

En cuanto a la última pregunta, creo que la respuesta es a veces. Si tiene algún código que quiera obtener otras opiniones sobre cómo optimizar el código, entonces no tener al autor participando puede ser útil para obtener ideas y luego hacer que el autor haga el cambio o justifique por qué el cambio no mejora el código, por ejemplo, si alguien quiere poner en un algoritmo de ordenación de burbujas esto puede ser rechazado debido a otros algoritmos de clasificación más eficientes como quicksort, mergesort y heapsort.

Editado para agregar un par de patrones que encontré útiles: Para revisiones de corrección de errores, el patrón que más me gusta es el siguiente: 1) Mostrar el error en un entorno de prueba / preparación para que pueda ver lo que salió mal. 2) Muéstreme dónde se cambió el código y una breve explicación de por qué se cambió de esta manera. 3) Muéstrame que el código está arreglado en tu máquina local.

Por el contrario, si uno implementa una API con una docena de métodos, entonces puede ser mejor tener alguna documentación que resuma lo que se usó en la implementación y por qué se hicieron algunas elecciones, por ejemplo, qué tipo de implementación de listas se utilizó como matriz, hashtable, lista vinculada, lista genérica, pila, cola, etc.

Las mejores revisiones de código que he hecho involucran una herramienta llamada Code Collaborator de Smartbear. El autor carga el código en un servidor. Los revisores y observadores pueden ver las diferencias entre el nuevo código y el código anterior y comentar sobre el nuevo código. Estas son las mejores prácticas:

  1. El autor comenta el código escrito para dar una pista al revisor sobre dónde comenzar.
  2. El revisor comenta y agrega los defectos que deberán corregirse antes de que se acepte la revisión. Solo las cosas importantes deben marcarse como defectos. No errores tipográficos o cosas que usted sabe que el desarrollador corregirá antes de comprometerse.
  3. Involucrar a nuevos desarrolladores como observadores. Esta es una buena capacitación para familiarizarlos con el proyecto.
  4. Involucre a "expertos" en la pieza de código, como observador o revisor.

Anti-patrones:

  1. Use la herramienta de revisión de código como una herramienta de revisión de diseño. No es adecuado para eso. Solo código de revisión para el cual se ha acordado un diseño.
  2. Involucrar a demasiados revisores y observadores
  3. Deje que la revisión permanezca en el sistema por más de un par de días.

Mi compañía, Smart Bear hace Code Collaborator (como lo menciona David Segonds ). También obsequiamos un libro gratuito llamado Los secretos mejor guardados de la Revisión del código de pares . Tiene algunas buenas prácticas recomendadas que aprendimos trabajando con nuestros clientes y mirando otras publicaciones.

Aquí hay algunos puntos:

  • Mantenga la revisión del código pequeña. Demasiado código a la vez es abrumador, por lo que si sus reseñas tienen demasiado código, revíselas con más frecuencia en fragmentos más pequeños.
  • Involucre a todos, pero no todos a la vez. La revisión del código es una oportunidad para que todos aprendan, revisores y autores por igual.
  • Recuerde, se trata del código, no del autor.

El patrón que considero crítico para las buenas revisiones de código es tener programadores con el tiempo y la motivación para realmente leer y comprender el código como revisores . Los revisores que solo le dan un vistazo superficial al código y señalan algunos cambios en el estilo del código realmente no contribuyen al proceso.

Usar el plugin Eclipse Jupiter y seguir el proceso que automatiza ha funcionado muy bien para nosotros. No es demasiado invasivo o burocrático, pero todavía ayuda a encontrar errores y problemas de diseño.

  • Programe revisiones o inspecciones regularmente y con frecuencia. Revisar / Inspeccionar módulos enteros cuando sean nuevos, y delta + código circundante para mantenimiento. Construir un atraso de cosas por revisar hace que todo el proceso sea intimidante.

  • Se revisa el código de todos, desde el más joven hasta el más antiguo, y cualquiera puede comentar sin temor a recriminación.

  • No solo revise / inspeccione el código; mire las pruebas (especialmente para TDD) y los resultados de las pruebas también. Detectamos algunos errores interesantes y omisiones en las pruebas al descubrir que lo que pensábamos que estábamos probando no era realmente lo que se estaba probando, o que inadvertidamente utilizamos datos de prueba de la misma clase de equivalencia cuando pensamos que estábamos usando distintas clases de datos.