¿Cómo elijo qué código revisar?

Soy parte de un equipo de siete desarrolladores en una pequeña empresa de software y estoy tratando de presentar revisiones grupales de código y diseño. Hemos realizado algunas revisiones en el pasado, pero ha sido esporádico. Me gustaría que sea algo más regular.

He leído Code Complete y otros recursos similares y hablan sobre la mecánica de cómo llevar a cabo revisiones de códigos, pero no he podido encontrar ninguna de las mejores prácticas sobre cómo elegir qué revisar. Tenemos una base de código que tiene más de ocho años y que cubre una variedad de idiomas, por lo que hay mucho que se puede ver.

Estos son algunos de los factores en los que puedo pensar que podrían afectar la elección:

• Lenguaje: C, Java, SQL, PL / SQL
• Antigüedad del código: código nuevo versus código antiguo
• Uso del código: código utilizado con frecuencia vs (efectivamente) código muerto / poco usado
• Importancia del código: código crítico vs código no crítico
• Desarrollador: código de desarrollador junior vs código de desarrollador senior

Entiendo que esta no es una pregunta con una respuesta definitiva absoluta, pero cualquier guía sería útil.

Algunas preguntas relacionadas periféricamente:

• Enfoques de revisión de código (Menciones de revisión de secciones críticas y nuevo código de desarrollador)
• ¿Deberíamos intentar revisar todo nuestro código?

En general, debe revisar todo . Si una nueva aplicación tiene 2 000 LOC, se deben revisar todos los 2 000 LOC.

Es por eso que no hay una mejor práctica sobre cómo elegir qué revisar.

Si se acerca a una base de código grande existente, nunca revisada antes, entonces es lo mismo cuando debe reescribir una base de código grande existente y elegir dónde comenzar. Depende fuertemente:

• en la base de código (un solo código monolítico sería más difícil de reescribir / revisar que un conjunto de componentes separados, etc.),

• su contexto (¿puede detener todo lo que trabaja y pasar tres meses (tres años?) trabajando solo en reescribir / revisar, o debe hacerlo por pequeños lapsos, solo cuando tenga tiempo libre)?

• el tipo de revisión que hace (¿tiene una lista de verificación de cosas para revisar? Dependiendo de los elementos de la lista de verificación, es posible que desee revisar algunas partes primero).

Si yo fuera tú lo haría:

• siga el principio del 80% -20%, mencionado en el primer comentario de la segunda pregunta a la que se vinculó.

• tener en cuenta que el 100%, siendo un ideal, quizás no valga la pena. Es como una cobertura de código del 100% para pruebas unitarias, excepto que dicha cobertura de código es casi imposible o extremadamente costosa.

• comience con las partes del código que usa más y cuáles son las más importantes. Si la base de código tiene una biblioteca que autentica y registra nuevos usuarios en su sitio web corporativo, revísela primero, porque ciertamente quiere encontrar agujeros de seguridad antes que los hackers.

• use las métricas existentes para determinar qué es más importante revisar. Si una parte de la base de código no tiene pruebas unitarias, mientras que otra, igualmente importante, tiene una cobertura de código del 85%, comience por revisar la primera parte. Si una parte de la base de código fue escrita por un desarrollador que se sabía que era inexperto e introducía más errores que cualquiera de sus colegas, comience por revisar su código primero.

Comience por revisar todos los cambios que realice en el código; eso evitará que el problema empeore. Luego comience a revisar el código según la frecuencia de los cambios; Estas serán las áreas 'problemáticas'.

Querrá encontrar alguna forma de rastrear que ha revisado una sección de código para poder analizar la cobertura de revisión de su código en relación con otras inquietudes.

Si puede determinar qué código no está cubierto por sus pruebas, se convierte en una prioridad más alta para la revisión.

Revise todos los cambios nuevos que se hayan realizado antes de que lleguen a producción. guiones de instalación, código fuente, cambios en la base de datos, ¡todo! El objetivo de la revisión del código es evitar que el código incorrecto entre en producción. Ya sea un esquema organizacional deficiente o simplemente un error introducido porque se perdió algo.

Refactorizar el código actual en el que está trabajando va de la mano con la revisión del código. Por ejemplo, cuando estoy revisando el código, si hubiera un código duplicado en una clase que contuviera una corrección de errores, incluso si el desarrollador no cambiara ese código en su corrección, no lo pasaría. Me gustaría que regresaran y eliminaran el código duplicado.

Si refactoriza implacablemente, la revisión de código se vuelve útil. De lo contrario, es una pérdida de tiempo.

Si incorpora el proceso de revisión de código como paso en su proceso de desarrollo, la base de código mejorará con el tiempo. Mejor aún, no debe permitir que sus desarrolladores asuman nuevas funciones o arreglen errores hasta que el registro de revisión de código esté vacío. Esto garantiza que se realice la revisión del código.

Si hay áreas conocidas que necesitan ser refactorizadas, pero tomará mucho tiempo hacerlo (es decir, 1 semana o más). Luego cree un elemento de trabajo para esa refactorización por sí mismo y agréguelo como un elemento para trabajar.

Comience por revisar todo el código nuevo y las modificaciones al código existente.

Al revisar las modificaciones al código existente, el desarrollador debe seguir la regla boyscout. Deje el código mejor de lo que lo encontró.

Eso no significa que tenga que arreglar todo el archivo para que sea perfecto. Pero no debería aumentar el desorden, debería hacerlo un poco mejor. Quizás moviendo las modificaciones a nuevas clases que estén estructuradas adecuadamente y dejando el resto del archivo de código original como está (después de todo, está 'funcionando).

Una vez que comience a mejorar el código revisando todos los nuevos códigos y modificaciones, como desarrolladores, debe saber qué áreas de la aplicación requieren más cambios. Luego, revise esos, discuta cómo se pueden mejorar, poco a poco.

Revisar el código escrito hace 10 años, por el simple hecho de revisarlo, no tiene sentido, el desarrollador debería haber mejorado durante esos 10 años. Por lo tanto, no tiene sentido revisarlo solo para aprender lo que todos saben.

El propósito de las revisiones de código es mejorar y corregir los errores que está cometiendo actualmente y compartir ese conocimiento entre el equipo.

En mi proyecto incluimos la revisión del código como un requisito imprescindible en la mayoría de los casos para cualquier tarea / historia de usuario / error que se desarrolle. Estamos utilizando procesos scrum / agile y el ticket / historia no se mueve a compilado (es decir, una acumulación de QA) hasta que se escriben las pruebas unitarias y se completa la revisión del código.

Para este propósito , utilizamos el análisis Atlassian FishEye con la revisión del código Crucible integrado con JIRA + SVN.

Cuando el desarrollador registra el código para una historia específica, crea una nueva revisión de código en FishEye, donde selecciona a los otros miembros del equipo para hacer la revisión.

Una vez que se completa la revisión del código, (la herramienta resalta los cambios enviados y permite dejar los comentarios para la línea de código específica) el desarrollador corrige los problemas mencionados / implementa las mejoras sugeridas y mueve el ticket a la columna Construido en JIRA, eso significa que la historia es listo para ser probado y que no se esperan más cambios de código para este elemento de trabajo específico.

Esto también garantiza que el control de calidad no pruebe nada que pueda modificarse y potencialmente romperse mientras se refactoriza el código después de la revisión del código .

En resumen, todo el código debe ser revisado: esto es compatible con la alta calidad del código, que generalmente resulta en un mejor diseño, legibilidad, mantenibilidad y capacidad de prueba del código y mejora el rendimiento del desarrollo a largo plazo.