Se niega a escuchar al equipo, y recientemente detuvo las revisiones de códigos, las pruebas unitarias, compartió los detalles de implementación ...
Las revisiones de código no necesariamente requieren que el codificador envíe el trabajo para su revisión.
Una manera fácil de realizar un seguimiento de lo que hace es vigilar el historial de VCS, buscando sus registros. Si le preocupa su código, esta es una manera fácil de encontrarlo. Obtenga un historial de diferencias, mire lo que él puso y vea si alguna bandera roja salta hacia usted. Capture sus registros lo suficientemente rápido y si encuentra un problema, puede revertir la confirmación y enviarle un correo electrónico a tal efecto. Se le permite llamar a sus compañeros de equipo, incluso como un codificador junior, cuando ve algo obviamente mal.
Sí, él "codifica" rápidamente, pero su código es solo un generador de errores. Otros miembros del equipo y yo estamos en una "fase de corrección de errores" y el 80% de los errores proviene de su código. No quiero arreglar sus errores. Y la gerencia es ciega, o no quiere ver esto, o tal vez les gusta su "velocidad".
El código proviene de los requisitos. Los requisitos dan como resultado pruebas ejecutables que verifican que se hayan cumplido los requisitos. Esas pruebas pueden desglosarse aún más, y pueden escribirse antes de que se realicen cambios para verificar que los cambios cumplan con los requisitos (refactor rojo-verde; la esencia de TDD).
Agregue una métrica de "cobertura de código" al servidor de compilación de su equipo (esperemos que tenga uno; si no, ese es su primer problema). Simplemente verificando que las pruebas unitarias pasadas no detectarán los problemas con su nuevo código no TDD, hecho en áreas que no tienen pruebas unitarias. Después de ejecutar todas las pruebas unitarias, el servidor de compilación idealmente debería haber ejecutado cada línea de código, pero realmente hay algunas cosas que simplemente no puede probar unitariamente. Siendo realistas, aún debería poder esperar una cobertura del 95% o mejor (o excluir ciertas bibliotecas o tipos de archivos de la cobertura). Tarde o temprano, su vaquero registrará algo que rompe la construcción porque ha bajado el nivel de cobertura por debajo del umbral, y usted lo llama.
Y en lo que respecta a la "velocidad", la velocidad es la rapidez con la que se "hacen" las cosas, y no se "hacen" hasta que se hacen correctamente. Puede ponérselo a sus gerentes de esta manera; considere a un mecánico de automóviles que, cuando el gerente toma su BMW para obtener un cambio de aceite, se olvida de volver a enchufar el cárter de aceite y, como resultado, todo el aceite nuevo se derrama antes de que incluso salga del garaje. Claro, el cambio de aceite solo tomó cinco minutos, pero el gerente no se preocupará por eso cuando el motor de su automóvil se detenga en el camino a casa. Le importará que el mecánico haya fallado un paso, eso le va a costar mucho tiempo y dinero adicionales para arreglarlo. En este momento, le está pagando a un vaquero para que haga el trabajo muy rápido, y luego ' s pagarle al resto del equipo una suma mucho mayor para entrar y volver a hacer el trabajo correctamente. ¿Cuál es realmente la ventaja de seguir dejando que el vaquero haga lo suyo?
¿Hay alguna manera de que yo (como su colega más joven por edad, no su jefe) pueda hacer algo al respecto?
Llámalo. Cuando encuentre algo que él arruinó, muéstrele cómo está fallando su código, cómo pudo haber evitado el problema en primer lugar (incluido el diseño adecuado, TDD, revisiones de código) y lo que fue o deberá hacer como resultado para arreglar su código roto.
Siento que soy el último a quien realmente le importa el proyecto.
klaxons a todo volumen, luces intermitentes, sirenas sonando : si realmente sientes que eres la única persona a la que le importa la calidad del código producido por el equipo, entonces hay un problema GRAVE. Si sientes que estás tratando de arrastrar a todo el equipo pateando y gritando a la era de la buena codificación, y es demasiado peso para transportar, entonces déjalo caer. Si hay otro equipo en la compañía que lo está haciendo bien, solicite una transferencia, de lo contrario salga de allí.