Qué hacer cuando sus colegas no valoran la capacidad de mantenimiento del código [duplicado]

No es a tus colegas a quienes debes convencer.

Si la administración realmente estuviera de acuerdo con usted, estarían aplicando las revisiones de código y TDD. Tal como están, solo asienten con la cabeza para hacer que dejes de molestarlos.

Veo dos opciones aquí:

1. Haga un discurso a la administración superior sobre cómo la alta rotación de empleados y la gran cantidad de informes de errores que enfrentan los clientes les están costando dinero. Incluya en su lanzamiento una solución viable que incluya revisiones de códigos forzados, TDD, etc. Envuelva un marco de tiempo alrededor de él y prometa entregarlo. Podrían hacerte un administrador encargado de arreglarlo.

2. Deja. Si sabes que va a colapsar, ¿por qué quedarte?

Veo que esto sucede mucho cuando un desarrollador trabaja en un proyecto exclusivamente durante un largo período de tiempo. Saben dónde están las trampas y cómo trabajar alrededor de ellas, por lo que generalmente no les importa que existan. La forma número uno de convencer a los desarrolladores para que empleen estándares de codificación comunes y las mejores prácticas es hacer que trabajen en el código de otros desarrolladores de vez en cuando. Verán rápidamente el valor del código de autodocumentación, el manejo adecuado de las excepciones, la limpieza del código muerto, etc. Haga esto una o dos veces y sus desarrolladores se complacerán en adoptar estas prácticas.

Con los gerentes, usualmente es una historia diferente. Los buenos gerentes responderán a las quejas de los desarrolladores y buscarán de manera proactiva formas de mejorar las prácticas de codificación de su empresa. A los malos administradores no les importará, siempre que el producto salga a tiempo. Para este tipo de gerentes, tendrá mostrar a ellos lo que está mal con la forma en que está haciendo las cosas. Explique que demora entre dos y tres veces el tiempo necesario para capacitar a un nuevo desarrollador, o que lleva días encontrar errores que podrían solucionarse en cuestión de minutos, todo porque la base del código es un desastre. Si es posible, muestre casos reales y concretos de los costos asociados con el código mal mantenido.

Atornille explicando las cosas a las personas .

Es posible que sea más fácil incorporar a la administración / a otros desarrolladores con algún tipo de integración continua. Entonces, si las pruebas no pasan, el código no se envía. Fin de la historia.