Hay dos problemas notables en la pregunta, la parte con tacto y la parte que se aproxima . Estos son temas distintos: el primero es una cuestión de comunicación y dinámica de equipo, el segundo es una cuestión de planificación y priorización.
Con tacto . Supongo que desea evitar los egos cepillados y el rechazo negativo contra las revisiones. Algunas sugerencias:
- Tener un entendimiento compartido sobre los estándares de codificación y los principios de diseño.
- Nunca critique o revise el desarrollador , solo el código . Evite la palabra "usted" o "su código", solo hable sobre el código que se está revisando, separado de cualquier desarrollador.
- Ponga su orgullo en la calidad del código completado , de modo que se aprecien los comentarios que ayuden a mejorar el resultado final.
-
Sugerir mejoras en lugar de demanda. Siempre ten un diálogo si no estás de acuerdo. Intente comprender el otro punto de vista cuando no esté de acuerdo.
- Haz que las revisiones vayan en ambos sentidos. Es decir. Haga que la persona que revisó revise su código a continuación. No tengo comentarios "de una sola vía".
La segunda parte es la priorización . Tiene muchas sugerencias para mejorar, pero como la fecha límite se acerca, solo hay tiempo para aplicar algunas.
Bueno, ¡primero quieres evitar que esto suceda en primer lugar! Esto se hace realizando revisiones continuas e incrementales. No permita que un desarrollador trabaje durante semanas en una función y luego revísela en el último momento. En segundo lugar, las revisiones de código y el tiempo para implementar las sugerencias de revisión deben formar parte de la planificación y estimaciones regulares para cualquier tarea. Si no hay suficiente tiempo para revisar adecuadamente, algo salió mal en la planificación.
Pero asumamos que algo salió mal en el proceso, y ahora se enfrenta a una serie de comentarios de revisión, y no tiene tiempo para implementarlos todos. Tienes que priorizar. Luego vaya a los cambios que serán más difíciles y más riesgosos de cambiar más adelante si los pospone.
El nombre de los identificadores en el código fuente es increíblemente importante para la legibilidad y la capacidad de mantenimiento, pero también es bastante fácil y de bajo riesgo cambiar en el futuro. Lo mismo con el formato de código. Así que no te concentres en eso. Por otro lado, la cordura de las interfaces expuestas públicamente debería ser la máxima prioridad, ya que son realmente difíciles de cambiar en el futuro. Los datos persistentes son difíciles de cambiar: si comienza a almacenar datos inconsistentes o incompletos en una base de datos, es muy difícil solucionarlos en el futuro.
Las áreas que están cubiertas por pruebas unitarias son de bajo riesgo. Siempre puedes arreglar eso luego. Las áreas que no lo son, pero que podrían ser probadas por unidad tienen un riesgo menor que las áreas que no pueden ser probadas por unidad.
Supongamos que tiene una gran cantidad de código sin pruebas unitarias y todo tipo de problemas de calidad de código, incluida una dependencia codificada de un servicio externo. En cambio, al inyectar esta dependencia, puede hacer que el fragmento de código sea verificable. Esto significa que en el futuro puede agregar pruebas y luego trabajar para solucionar el resto de los problemas. Con la dependencia codificada, ni siquiera se pueden agregar pruebas. Así que ve por esta solución primero.
¡En primer lugar, intenta evitar terminar en este escenario!