¿Qué haces con un desarrollador que no prueba su código? [cerrado]

https://stackoverflow.com/questions/139228

02-07-2019
|

Pregunta

Uno de nuestros desarrolladores escribe código continuamente y lo pone en el control de versiones sin probarlo. La calidad de nuestro código está sufriendo como resultado.

Además de deshacerme del desarrollador, ¿cómo puedo resolver este problema?

EDIT

He hablado con él al respecto varias veces y hasta le he dado una advertencia por escrito

Solución

Si realiza sistemáticamente revisiones de código antes de permitir que un desarrollador confirme el código, bueno, su problema está mayormente resuelto. Pero este no parece ser su caso, así que esto es lo que recomiendo:

Hable con el desarrollador. Discuta las consecuencias para otros miembros del equipo. La mayoría de los desarrolladores quieren ser reconocidos por sus pares, por lo que esto podría ser suficiente. También señale que es mucho más fácil corregir errores en el código que tiene en mente que el código de semanas. Esta parte tiene sentido si tiene alguna forma de propiedad del código en su lugar.
Si esto no funciona después de un tiempo, intente establecer una política que haga que cometer código con errores sea desagradable para el autor. Una forma popular es hacer que la persona que rompió la construcción sea responsable de las tareas de crear la siguiente. Si su proceso de compilación está completamente automatizado, busque otra tarea servicial para ocuparse en su lugar. Este enfoque tiene el beneficio adicional de no señalar a nadie en particular, haciéndolo más aceptable para todos.
Use medidas disciplinarias . Dependiendo del tamaño de su equipo y de su empresa, estos pueden tomar muchas formas.
Despide al desarrollador. Hay un costo asociado con mantener manzanas podridas. Cuando llegues tan lejos, al desarrollador no le importan sus compañeros desarrolladores, y ya tienes un problema de personas en tus manos. Si el ambiente de trabajo se envenena, es posible que pierda mucho más, en términos de productividad y de personas, que este único desarrollador malo.

Otros consejos

Si puedes hacer revisiones de código, ese es un lugar perfecto para atraparlo.

Requerimos revisiones antes de fusionar con el enlace de iteración, por lo que normalmente todo se captura entonces.

Palizas rituales! ¡Por cada error, un latigazo!

(Una broma para cualquiera que no lo entienda)

Como desarrollador que rara vez prueba su propio código, puedo decirte una cosa que me hizo cambiar lentamente mi comportamiento ...

Visibilidad

Si el entorno permite expulsar el código, esperar a que los usuarios encuentren problemas y luego esencialmente preguntar "¿Qué tal ahora?" después de realizar un cambio en el código, no hay un incentivo real para probar sus propias cosas.

Las revisiones de código y la colaboración lo alientan a trabajar para hacer un producto de calidad mucho más que si solo estuviera entregando 'Widget X' mientras sus compañeros de trabajo trabajan en 'Widget Y' y 'Widget Z'

Cuanto más visible sea su trabajo, más probabilidades tendrá de que le importe lo bien que funciona.

Revisión de código. Incluya a todos sus desarrolladores en una sala todos los lunes por la mañana y pídales que traigan sus logros más orgullosos basados ??en el código de la semana anterior junto con ellos a la reunión.

Permítales llamar la atención y entusiasmarse al explicar lo que hicieron. Pídales que traigan copias del código para que otros desarrolladores puedan ver de qué están hablando.

Comenzamos este proceso hace unos meses, y es sorprendente ver la cantidad de controles de calidad subconscientes que tienen lugar. Después de todo, si simplemente se les pide a los desarrolladores que hablen sobre qué es lo que más les entusiasma, estarán totalmente emocionados de mostrarle a las personas su código. Luego, otros desarrolladores verán los errores de calidad y discutirán públicamente por qué están equivocados y cómo debería escribirse realmente el código.

Si esto no hace que tu dev escriba un código de calidad, probablemente no sea una buena opción para tu equipo.

Hágalo parte de sus objetivos de revisión anual. Si no lo logra, no hay aumento de sueldo.

A veces, aunque solo tiene que aceptar que alguien simplemente no es adecuado para su equipo / entorno, debería ser un último recurso y puede ser difícil de manejar, pero si ha agotado todas las demás opciones, puede ser lo mejor en el largo plazo.

Dígale al desarrollador que le gustaría ver un cambio en sus prácticas dentro de 2 semanas o comenzará el procedimiento disciplinario de su compañía. Ofrezca toda la ayuda y asistencia que pueda, pero si no puede cambiar a esta persona, no es el adecuado para su empresa.

Usando el control de crucero o una herramienta similar, puede hacer que los registros activen automáticamente una prueba de compilación y unidad. Aún debe asegurarse de que haya pruebas unitarias para cualquier nueva funcionalidad que él agregue, lo que puede hacer mirando sus registros. Sin embargo, este es un problema humano, por lo que una solución técnica solo puede llegar tan lejos.

¿Por qué no solo hablar con él? Probablemente no te morderá.

Haz que él "cuide niños" la compilación, y convertirse en el gestor de compilación. Esto le dará menos tiempo para desarrollar el código (lo que aumentará el rendimiento de todos) y le enseñará por qué es tan necesaria una buena construcción.
Aplicar casos de prueba: el código no se puede enviar sin casos de prueba de unidad. Modifique el sistema de compilación para que, si los casos de prueba no se compilan y ejecutan correctamente, o no existan, se deniega todo el registro de tareas.

-Adam

Publique estadísticas sobre la cobertura del código de prueba por desarrollador, esto sería después de hablar con él.

Aquí hay algunas ideas de una choza de mar.

Intro
   What shall we do with a drunken sailor, (3×)
   Early in the morning?
Chorus
   Wey–hey and up she rises, (3×)
   Early in the morning!
Verses
   Stick him in a bag and beat him senseless, (3×)
   Early in the morning!
   Put him in the longboat till he’s sober, (3×)
   Early in the morning!

etc. Reemplazar " marinero borracho " con un " desarrollador descuidado " ;.

Dependiendo del tipo de sistema de control de versiones que esté utilizando, podría configurar políticas de check-in que obliguen al código a pasar ciertos requisitos antes de permitir el check-in. Si está utilizando un sistema como Team Foundation Server, le ofrece la posibilidad de especificar la cobertura de código y los requisitos de pruebas unitarias para los registros.

Sabes, esta es una oportunidad perfecta para evitar distinguirlo (aunque estoy de acuerdo en que debes hablar con él) e implementar un proceso de prueba primero en casa. Si las reglas no son claras y las expectativas son conocidas por todos, he descubierto que lo que usted describe no es tan infrecuente. Me parece que hacer el esquema de desarrollo de prueba primero funciona bien para mí y mejora la calidad del código.

Es posible que estén demasiado centrados en la velocidad en lugar de la calidad.

Esto puede tentar a algunas personas a apresurarse a resolver problemas para borrar su lista y ver lo que aparece en los informes de errores más tarde.

Para rectificar este balance:

asigne solo un par de elementos a la vez en su sistema de seguimiento de problemas,
revisar el código y probar todo lo que hayan " completado " tan pronto como sea posible, por lo que volverá con ellos inmediatamente si hay algún problema
hable con ellos acerca de sus expectativas sobre cuánto tardará un artículo en hacerlo correctamente

La programación entre pares es otra posibilidad. Si está con otro desarrollador experto en el equipo que muere y cumple con los estándares de calidad y conoce el procedimiento, entonces esto tiene algunas ventajas:

Con un desarrollador experimentado sobre su hombro, aprenderá lo que se espera de él y verá la diferencia entre su código y el código que cumple con las expectativas
El otro desarrollador puede aplicar una política de prueba primero: no permitir que se escriba código hasta que se hayan escrito pruebas para él
Del mismo modo, el otro desarrollador puede verificar que el código cumple con los estándares antes de que se marque, lo que redunda en el número de inspecciones incorrectas

Todo esto, por supuesto, requiere que la compañía y los desarrolladores sean receptivos a este proceso, lo cual puede no ser.

Parece que a la gente se le han ocurrido muchas respuestas imaginativas y tortuosas a este problema. Pero el hecho es que esto no es un juego. Diseñar sistemas de presión de pares elaborados para " nombre y vergüenza " Él no va a llegar a la raíz del problema, es decir. ¿Por qué no está escribiendo pruebas?

Creo que deberías ser directo. Sé que dices que has hablado con él, pero ¿has tratado de averiguar por qué no está escribiendo exámenes? Claramente, en este punto él sabe que debería estar, así que seguramente debe haber alguna razón por la que no está haciendo lo que se le ha dicho que haga. ¿Es la pereza? ¿Dilación? Los programadores son famosos por sus egos y opiniones fuertes, tal vez esté convencido por alguna razón de que las pruebas son una pérdida de tiempo o que su código siempre es perfecto y no necesita pruebas. Si es un programador inmaduro, puede que no entienda completamente las implicaciones de sus acciones. Si es " demasiado maduro " él podría estar demasiado en su camino. Sea cual sea el motivo, abordalo.

Si se trata de una cuestión de opinión, debe hacerle entender que necesita dejar de lado su opinión personal y seguir las reglas. Deje en claro que si no se puede confiar en para que siga las reglas, será reemplazado. Si aún no lo hace, haz eso.

Una última cosa: documente todas sus discusiones junto con cualquier problema que ocurra como resultado de sus cambios. Si se trata de lo peor, puede verse obligado a justificar sus decisiones, en cuyo caso, tener pruebas documentales seguramente será invaluable.

Colócalo en su propia rama de desarrollo, y solo trae sus cosas al maletero cuando sepas que está completamente probado. Este podría ser un lugar donde sobresaliría una herramienta de gestión de control de fuente distribuida como GIT o Mercurial. Aunque con el aumento del soporte de ramificación / fusión en SVN, es posible que no tenga demasiados problemas para administrarlo.

EDITAR

Esto es solo si no puedes deshacerte de él o hacer que cambie su forma de ser. Si simplemente no puede detener este comportamiento (cambiando o disparando), entonces lo mejor que puede hacer es proteger al resto del equipo de los malos efectos de su codificación.

Si se encuentra en un lugar donde puede afectar las políticas, realice algunos cambios. Revise el código antes de registrarse y haga que las pruebas formen parte del ciclo de desarrollo.

Parece bastante simple. Haz que sea un requisito y, si no puede hacerlo, reemplázalo. ¿Por qué lo guardarías?

Normalmente no defiendo esto a menos que todo lo demás falle ...

A veces, un cuadro público de errores contados por desarrollador puede aplicar suficiente presión de grupo para obtener resultados favorables.

Prueba la zanahoria, haz que sea un juego divertido.
Por ejemplo, el complemento de Continuous Integration Game para Hudson
http://wiki.hudson-ci.org/ display / HUDSON / The + Continuous + Integration + Game + plugin

Coloque a sus desarrolladores en las ramas de su código, basándose en alguna lógica como, por característica, por corrección de errores, por equipo de desarrollo, lo que sea. Entonces los check-ins malos se aíslan a esas ramas. Cuando llegue el momento de hacer una compilación, fusionarse con una rama de prueba, encontrar problemas, resolver y luego fusionar su lanzamiento con una rama principal.

O elimine los derechos de confirmación para ese desarrollador y haga que envíen su código a un desarrollador más joven para su revisión y prueba antes de que pueda confirmarse. Eso podría motivar un cambio en el procedimiento.

Puede armar un informe con errores encontrados en el código con el nombre del programador responsable de ese software.

Si es una persona razonable, discuta el informe con él.

Si él se preocupa por su " reputación " publica el informe regularmente y ponlo a disposición de todos sus compañeros.

Si solo escucha a la "autoridad", haga el informe y envíe el problema a su gerente.

De todos modos, he visto a menudo que cuando las personas se dan cuenta de lo mal que parecen desde el exterior, cambian su comportamiento.

Hey, esto me recuerda a algo que leí en xkcd :)

¿Se refiere a escribir una prueba unitaria automatizada o una prueba unitaria manual antes del registro?

Si su tienda no escribe pruebas automatizadas, su verificación del código que no funciona es imprudente. ¿Está impactando al equipo? ¿Tiene un departamento de control de calidad formalizado?

Si todos están creando pruebas unitarias automatizadas, sugeriría que parte del proceso de revisión del código incluya también las pruebas unitarias. Se volverá obvio que el código no es aceptable según sus estándares durante su revisión.

Su pregunta es bastante amplia, pero espero que haya proporcionado alguna orientación.

Estoy de acuerdo con Phil en que el primer paso es hablar individualmente con él y explicarle la importancia de la calidad. La calidad deficiente a menudo se puede vincular a la cultura del equipo, departamento y empresa.

Convierta los casos de prueba ejecutados en uno de los entregables antes de que se considere que algo está "hecho".

Si no ha ejecutado casos de prueba, entonces el trabajo no está completo, y si la fecha límite pasa antes de tener la ejecución del caso de prueba documentada, entonces no se ha entregado a tiempo, y las consecuencias serían las mismas que si no hubiera completado el desarrollo.

Si la cultura de su empresa no lo permite, y valora la velocidad sobre la precisión, probablemente esa sea la raíz del problema, y ??el desarrollador simplemente está respondiendo a los incentivos existentes: se lo está recompensando por hacerlo un montón de cosas a medias en lugar de menos cosas correctamente.

Haga que la persona limpie las letrinas. Trabajó en el ejército. Y si trabaja en un grupo con personas que comen mucha comida india, no les llevará mucho tiempo alinearse.

Pero solo soy yo ...

Cada vez que un desarrollador comprueba algo que no se compila, ponga algo de dinero en un frasco. Lo pensarás dos veces antes de registrarte entonces.

Desafortunadamente, si ya le hablaste muchas veces y le diste advertencias por escrito, diría que es hora de eliminarlo del equipo.

Puede encontrar algunas respuestas útiles aquí: Cómo hacer que los programadores junior escriban pruebas ?

Licenciado bajo: CC-BY-SA con atribución

No afiliado a StackOverflow