¿Cómo garantiza la calidad del código cuando tiene un programador más débil en su proyecto?

Es genial escuchar que las revisiones de código se realizaron sin problemas y que está viendo resultados pronto, ha visto que es efectivo y eso significa que el programador junior está ansioso por aprender (Todo lo bueno)

Algunas cosas que me gustaría sugerir que se pueden hacer en su extremo

1. Buenas muestras de código de la base de código existente: probablemente tenga algún código de calidad estelar en su base de código existente (con el formato/estilo esperado, convenciones de nomenclatura, bien diseñado y revisado ). Señale esto a su desarrollador junior para que pueda evaluar el punto de referencia que debe cumplir.
2. Análisis de código estático: invierta algo de tiempo para identificar una herramienta de análisis estático correcta para su proyecto (si aún no tiene una). Existen herramientas que ayudan a corregir el estilo de codificación, encontrar defectos tecnológicos como la complejidad ciclomática y problemas de seguridad. Sin embargo, esto podría tomar tiempo. Pero una herramienta de análisis estático reducirá los gastos generales en las sesiones de revisión de código. Será útil para todo el equipo. (Algunos ejemplos de java world - checkstyle , Findbugs )
3. Revisiones por pares: ¿puedes encontrar al menos un desarrollador más a su nivel? (no en el nivel de habilidad sino en la estructura del equipo) Si es así, puede introducir revisiones por pares entre todos los miembros junior antes de que un senior revise el código. De esta manera habrá menos gastos generales para el revisor senior. Si es posible, evite hacer revisiones por pares solo para el desarrollador en cuestión. Eso podría crear una dinámica de equipo negativa. También será una buena experiencia de aprendizaje para todo el equipo.
4. Revisión del código por parte del desarrollador senior/líder: con los pasos anteriores implementados antes de llegar a este punto, la sobrecarga será menor.

Para resumir lo anterior,

• Primero aclaramos expectativas
• Automatice con análisis de código estático
• Reduzca los gastos generales y aumente las oportunidades de aprendizaje
• Asegúrese de que la calidad se cumpla con una revisión final

Hacer programación en pareja. A menudo encuentro que Code Reviews tiende a desmoralizar a las personas, porque criticas (potencialmente mucho) su trabajo completo. Incluso si usted es bueno dando retroalimentación y el otro es bueno tomándola, esto será un problema.

En la programación en pareja, por otro lado, comienzan una tarea juntos desde cero. Deje que tome la iniciativa, escuche cómo quiere resolver el problema y haga sugerencias sobre cómo hacerlo mejor. Haga esto durante 1 hora o 2, como máximo. Luego debería continuar solo por un tiempo. Posteriormente, puede hacer una revisión del código. Descubrirá que hay mucho menos que criticar de esta manera. Y se sentirá animado, por eso y por la cooperación. Repite este ritual y cambia de pareja. Después de un tiempo, obtendrá sus valores y mejorará. Y al final, tal vez tú también puedas aprender algo de él ;)

Sugeriría que el nuevo miembro participe en la prueba del módulo existente en lugar de la codificación, ya que esto introduciría a los nuevos miembros en las prácticas y estándares de codificación existentes. Una vez que los nuevos miembros tengan una idea básica de las prácticas de codificación, sería mejor presentar al nuevo programador en informes de programación o formularios básicos.

Si no tienes mucho tiempo (y sigues los consejos mencionados anteriormente), entonces reservaría una reunión con él y personalmente iría con él a través de su código y le diría lo que no te gusta o incluso mejor acordaría un plan. sobre cómo estructurar/escribir código en sus proyectos.

De esta manera puede obtener beneficios mutuos que pueden ser efectivos de inmediato.

Me gustan otras respuestas, ya que están tratando de mitigar su situación inmediata y solucionar su problema.

Para ampliar esas respuestas, si usted es Gerente / PM y tiene cierta autoridad sobre lo que se está haciendo en el proyecto, en mi opinión, debe evaluar seriamente si vale la pena mantener a un programador que está lejos de sus estándares de contratación.

Teniendo en cuenta el problema de verse obligado a incorporar a esta persona en el equipo sin la contratación adecuada, las posibles implicaciones negativas en su equipo de la situación actual son :

• La ley de Brook ya la mencionaste
• Menor productividad general del equipo debido a la necesidad de "cuidar de niños" bajo rendimiento del desarrollador
• Degradación de la moral entre otros miembros del equipo y mayor riesgo de abandono debido al hecho de que los grandes ingenieros quieren trabajar con grandes ingenieros. Aceptar a una persona con un rendimiento bajo le quita el sentido de élite a su equipo y hace que sea menos convincente para los ingenieros permanecer en el equipo.

Como PM / Gerente, debe iniciar la discusión y tratar de crear conciencia sobre el hecho de cuán mala para la dinámica del equipo es la tolerancia de los trabajadores de bajo rendimiento. Además, sorprendentemente, muchos gerentes en las organizaciones todavía tratan a los trabajadores del conocimiento gerencial como si estuvieran trabajando en una fábrica y no en un trabajo creativo.

Desafortunadamente, Peopleware sigue siendo válido y más relevante que nunca.