Como líder del equipo, ¿qué consejos puedo dar a un desarrollador junior que escribe códigos de trabajo, pero complejos y difíciles de entender?

Answer 1

A2A

Creo que se trata menos de consejos y más de motivar al desarrollador Jr.

Como líder del equipo, hable con todo el equipo sobre qué tan mejor serán sus vidas con el código de mantenimiento. Esto no aislará al desarrollador Jr, y crea una cultura en torno al desarrollo comunitario. Es “codificación social”, lo que puede notar es el lema de Github. Este enfoque convierte a sus desarrolladores Sr en campeones culturales, que ofrecen consejos regulares al desarrollador Jr. Proporcione a todos ejemplos de éxito, como proyectos de código abierto que tienen muchos colaboradores.

Cuando era un desarrollador más nuevo, trabajaba para una compañía muy conocida (que estaba clasificada entre los 10 primeros lugares para trabajar en los EE. UU. En ese momento) que se incentivaba a través de pequeñas recompensas. Si un gerente nombrara a alguien por excelencia (de cualquier tipo), recibiría una tarjeta de regalo de $ 50–100. El programa de recompensas se centró principalmente en el crecimiento y la apreciación profesional. El dinero es un motivador universal que puede actuar como un catalizador.

Si eso falla, asigne el desarrollador Jr a la base de código de otra persona, incluso si es solo para un proyecto de desecho temporal. Haz que experimenten el dolor de pasar por un código complejo por su cuenta.

Usted podría simplemente tener un desarrollador de mierda que no está realmente preparado para eso, pero si quieren crecer, encuentre su motivador. Hay motivadores que van más allá de ser un mejor desarrollador … no tenga miedo de aprovecharlos.

Answer 2

Si quiere “arreglar” a este desarrollador, tendrá que entender qué está mal con la forma en que él codifica.

• Algunos desarrolladores valoran escribir código muy rápido. Resolver el código de trabajo rápidamente sin tener en cuenta la comprensibilidad o el mantenimiento se valora en las competencias de codificación académica y en algunos lugares de trabajo. Este tipo de programador piensa que es un “buen” desarrollador porque es rápido. Podría ser tan simple como decirle a este desarrollador que valora la simplicidad y la capacidad de mantenimiento por encima de la velocidad, y podría volver a trabajar el código para mejorar su legibilidad. Debido a que a algunos empleadores realmente les gusta este tipo de desarrollador, no necesariamente le estás haciendo un favor al tratar de “arreglarlo”. Si se muestra reacio a cambiar, puede ser necesario aconsejarle que hay otros empleadores que valoran la codificación rápida más que usted.
• A veces, un desarrollador junior solo necesita tiempo para madurar. Algunos programadores lo “entienden” de inmediato, y algunos toman más tiempo. Poner a este desarrollador en proyectos menos críticos, como administrar el conjunto de pruebas hasta que haya visto más código, podría ser una respuesta. Este desarrollador necesita ver más código. Debería participar en las revisiones de software o en la programación de pares tanto como sea posible. También puedes introducirlo a medidas de complejidad.
• Y … entonces hay desarrolladores que simplemente no son tan buenos. Voy a hablar a continuación sobre las formas de ayudar a las personas a escribir un código mejor, pero si no puede lograr que mejore, a veces lo ayudo a darse cuenta de que sus días están contados y que es hora de pasar a otro trabajo. .

Es difícil diagnosticar problemas específicos en los desarrolladores, y aún más difícil enfrentarlos y hacerles saber que su código apesta. Puedes comprometerte a mejorar las habilidades de codificación de todo un equipo.

• Revisión, revisión, revisión. Casi todos los carteles en este hilo han mencionado la revisión del software. Permítame ir más allá y decir que tal vez quiera probar una revisión de peso pesado que consiste en una reunión cara a cara real con copias impresas del código revisado de antemano, porque reduce la tendencia a echar un vistazo rápido al código. Aquí hay una entrada detallada del blog sobre cómo hago las revisiones de código y los resultados que puede esperar.
• Existen herramientas que producen un informe de la complejidad ciclomática de cada función. Pida a los desarrolladores que sigan trabajando o pida ayuda hasta que obtengan la puntuación de complejidad ciclomática con un valor particular, o haga que la complejidad ciclomática sea un tema de cada revisión de código. Hacer que el desarrollador justifique la escritura de código complejo. Ser calificado por un programa es de alguna manera menos intimidante que el hecho de que un ser humano le diga que el código es ilegible.
• Los compiladores tienen un nivel de advertencia que puede ajustar en los scripts que crean el código de su equipo. Haga que deshacerse de las advertencias sea un tema de revisión de código.
• Puede instalar un comprobador estático. Mismo comentario que el anterior.
• Los estándares de codificación imponen un estilo de codificación más uniforme. Si el problema es descuidado, eso ayudará. Tenga en cuenta que los estándares de codificación a veces son difíciles de hacer tragar para un equipo existente.