¿Cómo ser mejor al revisar el código?

Primero, creo firmemente en el proceso de revisión del código y siempre quiero que alguien más revise mi código. Mi pregunta realmente se centra en cómo puedo hacer un mejor trabajo al realizar una revisión de código para otra persona.

Sé que para realizar una revisión de código debe tener conocimiento de cómo funciona el código existente y conocer cuál es el estándar local, y creo que lo sé muy bien. Aún así, siento que nunca hago una revisión de código lo suficientemente buena para otras personas. También sé que ciertas personas parecen hacer un mejor código de revisión de trabajo que otras, por lo que me pregunto por aquellos que son excelentes revisores de códigos ¿cuáles son las técnicas que utiliza?

No hay forma de hacer una mejor revisión del código. Lo único que puede hacer es que siga mejorando con aprendizaje y experiencia.

Normalmente cosas que sigo

- Use variables judiciously
- Keep things in scope loose boundaries will generate more errors
- Orient your language of coding in domain specific terms, they make more sense
- Keep loops to minimum 2 for each method if needed
- use ternary operators
- Arrange methods alphabetically
- Keep errors at handling ease
- write less but efficient code

Creo que hay muchas cosas que puedes agregarle.

pregúntate qué hace que otros sean un buen crítico para ti.

también, a medida que avanzas en el código;

• detente ante cualquier cosa que no entiendas ahora escribe que se necesita un comentario
• identificar si cumple con los estándares de codificación: espacios, corchetes, camelCase..etc
• compruebe que incluye toda la funcionalidad
• haga pruebas simples de la lógica para ver si pasa condiciones límite, etc.

Solo apunto a

• explicando por qué se necesita un cambio sugerido. Asegurándome de entender la razón, no solo la solución
• acordar el formato del código, para que el código de todos se vea igual / familiar
• compartir una lista de rasgos de código que desea mantener. Póngalo en una wiki para que no todos tengan que cometer todos los errores una vez. Actualízalo con frecuencia.

Aparte de eso, "saber qué buscar" solo viene con experiencia, práctica y lectura.

En mi experiencia, la mejor manera es dejar que el equipo del hoyo haga la revisión del código. Utilizamos una lista de correo de confirmación en cada proyecto donde puede seguir todos los cambios de código en el sistema de control de versiones. La mayoría de nuestros desarrolladores se han suscrito a su lista de correo específica del proyecto porque están interesados ​​en los cambios de código.

Cuando alguien nota un mal camino en el nuevo código fuente, o le explica al confirmador cómo puede hacerlo de una mejor manera, si el confirmador es un aprendiz, o comienza una discusión al respecto, si se trata de un confirmador más experimentado.

Por supuesto, este método no garantiza que se revise todo el código nuevo, especialmente en momentos estresantes cuando ninguno de los miembros del equipo tiene tiempo libre para seguir cada cambio de código. Además, no todos los desarrolladores son responsables de garantizar que cada desarrollador haga su trabajo bien, solo de esto no puede garantizar que se revise. Pero, al menos en nuestros equipos, siempre hay un gerente técnico responsable de la calidad técnica.

Soy un verdadero fanático de las revisiones de código si se ajustan a los siguientes puntajes:

• cada desarrollador tiene la posibilidad de revisar todos los códigos y argumentos de su opinión
• nadie tiene derecho a abusar del código de otros
• no solo el código incorrecto activa una discusión, sino también el código correcto
• las discusiones terminan con felicidad para todas las personas involucradas
• la revisión se realiza casi en tiempo real, al menos antes de que se complete la función

Lo que he aprendido es que si eres alguien que revisa cada línea de código y piensas que tienes que controlar cosas como la calidad del código en términos de formato de código o eficiencia del código, entonces eres muy ineficiente porque haces cosas que las máquinas pueden hacer por tú. Su objetivo debe ser utilizar un sistema de integración continua que controle la calidad de construcción y código de cada contribución de código. Si este sistema genera informes y los envía a los contribuyentes, todo es perfecto.

Debo admitir que si tiene que revisar el código porque tiene que controlar o clasificar la calidad de un programador, entonces mis sugerencias no tienen sentido. En este caso tampoco revisaría el código fuente línea por línea. Yo revisaría cosas como:

• ¿hay problemas de seguridad relevantes
• son las API previstas utilizadas
• ¿el código aplicó la arquitectura especificada
• ¿escribió pruebas útiles (pero solo si fue instruido implícitamente, tuve que aprender)
• Documentación
• proceso de construcción
• ... y algo más, probablemente

Si eres un desarrollador experimentado, siempre encontrarás cosas como bucles que podrías hacer con un mejor rendimiento. Por supuesto, es útil explicar a otros ese conocimiento, pero esto no debería ser parte de la sesión de revisión. Si hay problemas de rendimiento significativos, no porque él (o ella) haya usado una variante menos eficiente de un tipo de lista.

Debido a que la pregunta inicial era por qué algunas personas parecen hacer una mejor revisión que otras, respondería que estas personas tal vez hagan una vista previa antes de que comience la revisión real, lo que significa que probablemente estén preparadas para que sepan exactamente lo que quieren revisar. .

[H] ¿Cómo puedo hacer un mejor trabajo al realizar una revisión de código para otra persona?

Hazles muchas preguntas

Sé que para realizar una revisión de código debe tener conocimiento de cómo funciona el código existente ...

En realidad, no, no es necesario conocer el código de antemano para ser un buen revisor.

Hace un par de trabajos, mi empleador comenzó a exigir que un revisor firmara todos los registros de códigos. Estaba trabajando principalmente en GUI en C, y uno de los mejores críticos para mí fue mi amigo Bill. Era competente en C, pero nunca había hecho mucho trabajo de GUI, y al entrar en las revisiones no tenía idea de cómo se suponía que debía funcionar mi código.

Pero hizo muchas preguntas al respecto y tuvo que explicarlo para poder entender lo que hizo mi código y por qué me estimuló mucho a pensar. Me llevó a encontrar muchos pequeños bichos raros con casos extremos, y también a considerar otros enfoques que podría haber tomado. Además, aunque había estado escribiendo C durante 22 años en ese momento y pensaba que era bastante competente, rápidamente mejoró la calidad de mi código.

Aunque ya no trabajo allí, todavía reviso los diferenciales antes del check-in y me pregunto: "¿Qué preguntas tendría Bill sobre esto?" Y a menudo, termino cambiando algo como resultado.