Siempre he sentido que uno de los sellos distintivos de un buen líder es alguien que proporciona la capacitación adicional según sea necesario durante cada ciclo de desarrollo. Para mí, eso significa que no solo estoy codificando o revisando el código, sino que sentado con más desarrolladores junior, emparejando la programación con ellos para ayudarlos a evitar el tipo de minas terrestres que he pisado.
Principalmente, no me hago ilusiones de que nuestro objetivo principal es educativo, no lo es. Ya sea que sea un senior, un lead o un desarrollador junior, el objetivo no es su edificación. El objetivo siempre es entregar un código de calidad al cliente. Preferiblemente a tiempo, dentro del presupuesto, haciendo lo que quieran. Sin embargo, reconozco que es imposible para mí hacer todo el trabajo por mí mismo, por lo que me incumbe liderar para ayudar a todos a ayudar al equipo a tener éxito. Y eso significa reconocer las oportunidades de capacitación cuando aparecen en la naturaleza.
Entonces, a su pregunta sobre si las solicitudes de extracción son el lugar para entrenar a los juniors, debo decir que no es raro que surjan momentos de enseñanza durante estos. Oye, tendrás que lidiar con tu primer conflicto de fusión, repasemos eso después de la revisión. Oh, mira, no incluiste ninguna prueba unitaria para tu DAO, pospondremos tu revisión hasta que hayamos tenido la oportunidad de cubrir esos nuevos métodos. ¿Por qué pensaste que sería mejor usar primitivas dobles en este cálculo financiero que BigDecimals? Sí, eso no es realmente raro.
Entonces, aunque diría que ciertamente puede suceder, pero claramente no es el objetivo principal de una solicitud de extracción. Tampoco creo que haya una expectativa de que el código en una solicitud de extracción esté listo para producción. A menudo no lo es.
Si está utilizando ramas de funciones y versiones en una estrategia de ramificación de estilo gitflow, entonces sus solicitudes de extracción se convertirán en algo más parecido a los candidatos de versión. No está listo para la producción, sino algo más aproximado. Usted sabe que su código se compila (a la derecha) y tiene suficiente seguridad de prueba para hacer una afirmación decente de que cumple con los objetivos de la historia del usuario. Y dado que ya ha realizado varias pruebas de integración en su entorno de desarrollo, tiene una gran demostración lista para usar en caso de que se le solicite que demuestre sus cambios, lo que hará, durante la revisión de su RP.
En última instancia, creo que deberíamos brindar asistencia durante las revisiones del RP, pero esa asistencia no se trata de la codificación general. En cambio, está asociado con la preparación de ese código propuesto para su inclusión con una base de trabajo de código de calidad de producción. El RP es una oportunidad para que los desarrolladores demuestren que tienen una justificación y un sólido conocimiento de cada cambio que han incluido en el RP. E incluso entonces, incluso después de haberlos pesado con pruebas unitarias, demostraciones y un montón de preguntas, todavía no se espera que los cambios propuestos estén listos para la producción.
El código está cerrado después de todo eso. Pero luego dejamos que QA lo torture.