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

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

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

Si te aproximas a una base de código grande existente, nunca revisado antes, entonces es lo mismo cuando debes 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 realiza (¿tiene una lista de verificación 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 que vinculó.

• tenga en cuenta que el 100%, ser un ideal, quizás no valga la pena. Es como una cobertura de código al 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 más utiliza 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 seguramente encontrará agujeros de seguridad antes que los piratas informáticos.

• use las métricas existentes para determinar qué es más importante revisar. Si una parte del código base no tiene ninguna prueba de unidad, mientras que otra parte, igualmente importante, tiene un 85% de cobertura de código, 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 no tenía experiencia y presentaba 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á averiguar de alguna manera que haya 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 cubre sus exámenes, se convierte en una prioridad más alta para su revisión.

Revise todos los cambios nuevos que se hayan realizado antes de que lleguen a producción. scripts de instalación, código fuente, cambios en la base de datos, ¡todo! El punto principal de la revisión del código es evitar que el código incorrecto llegue a producción. Ya sea un esquema de organización 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 había un código duplicado en una clase que contenía una solución de error, incluso si el desarrollador no cambiaba ese código en su solución, no lo aprobaría. Me gustaría que regresen y eliminen el código duplicado.

Si refactoriza implacablemente, la revisión del 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 correcciones de errores hasta que la acumulación de revisión de código esté vacía. Esto asegura 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 en el que se 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 de boyscout. Deja el código mejor de lo que lo encontró.

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

Una vez que comience a mejorar el código revisando todo el código nuevo y las modificaciones, como desarrolladores, debe saber qué áreas de la aplicación requieren más cambios. Luego, revíselas, analice 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 en 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 de código como una herramienta imprescindible en la mayoría de los casos para cualquier tarea / historia de usuario / error que se esté desarrollando. Estamos utilizando procesos scrum / ágiles y el ticket / historia no se mueve a la compilación (es decir, un atraso para el control de calidad) hasta que se escriben las pruebas unitarias y se completa la revisión del código.

Usamos el análisis Atlassian FishEye con la revisión del código Crucible integrada con JIRA + SVN para este propósito.

Cuando el desarrollador comprueba el código de una historia específica, crea una nueva revisión de código en FishEye, donde selecciona a los otros miembros del equipo para que realicen 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 está lista para ser probada 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 compruebe nada que pueda cambiarse y potencialmente romperse al refactorizar el código después de la revisión del código .

Para resumir, todo el código debe revisarse: 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.