¿Cómo navegar trabajando con un proceso de desarrollo que no apoya el código limpio?

Esta es tu respuesta aquí.

Esta empresa no realiza revisiones de código, pruebas unitarias y la calidad del código no está en la mente de los supervisores.

Así que la única persona que hace algo de forma estructurada eres tú. Aunque el código es (en su opinión) un desastre, los otros desarrolladores lo saben y lo entienden. Arreglar las cosas rompe su visión de cómo funciona todo.

Por lo tanto, siga trabajando de la manera que desee, pero no se tome más tiempo para refactorizar el código de los demás (ya ha visto que no les gusta eso).

Si alguien estropea su parte del código base mientras está fuera, programe un tiempo para arreglarlo cuando regrese.

Si no puede vivir así, es posible que deba explorar otras opciones de empleo: no es probable que cambie la forma en que funciona este equipo sin ser un líder del equipo.

Un acercamiento emocional a los temas relacionados con el trabajo no es nada productivo, pero es muy habitual. Usted mencionó en un comentario que el colega resistente al cambio no es la misma persona que escribió el código en primer lugar. Esto significa que podría ponerse a la defensiva porque no intentó arreglar el código por sí mismo, por lo tanto, percibe el cambio recomendado como un desafío. O tal vez simplemente es perezoso y no quiere refactorizar el código.

Estoy seguro de que ha utilizado argumentos como: el código mal escrito puede funcionar pero es propenso a errores, no es comprensible para los nuevos empleados, no se puede mantener fácilmente y todo esto conduce a la pérdida de un tiempo valioso. Si esto no funcionó, debe intentar usar el emocionalismo usted mismo.

• Sé que el código funciona, eso se debe a que hizo un buen trabajo en la implementación/mantenimiento, pero es muy difícil para mí y potencialmente para cualquier nuevo miembro del equipo de desarrollo entenderlo y trabajar en él (esto también puede sonar como una campana). a por qué todos sus predecesores renunciaron).

• Sé que ha hecho un buen trabajo y respeto su opinión, pero siento que la mía no es tan respetada. Estoy tratando de ayudar a todos con un cambio que nos beneficiará a largo plazo.

También puede organizar una reunión con los desarrolladores, el líder del equipo Y el gerente/supervisor del proyecto para hacer una breve presentación de la naturaleza beneficiosa del código limpio y las pruebas.

• Trae tantos ejemplos como puedas de cómo esto te ayudará en el futuro.
• Haz una estimación del esfuerzo.
• Lo más importante es pedir sus recomendaciones sobre cómo se puede optimizar el código y cómo pueden trabajar juntos para implementar los cambios.
• Haga un plan sobre cuándo puede llevarse a cabo esto.

En otras palabras, hacer un esfuerzo organizado y bien documentado para introducir la optimización de código en el proyecto. educarlos

¡Buena suerte!

Cuando se ve desde el punto de vista de la gestión, una enorme refactorización de código

• Quema cientos de horas de tiempo del personal,
• No agrega nuevas características al código,
• Corre el riesgo de agregar nuevos errores que no estaban allí antes.

Es poco probable que las solicitudes para detener todo y simplemente refactorizar sean recibidas con entusiasmo por alguien que no sea la persona que quiere hacerlo.

Una opción más realista es la mejora incremental. Cada vez que agregue una nueva función o corrija un error, deje el código en un mejor estado que cuando lo encontró.

Esta empresa no realiza revisiones de código, pruebas unitarias y la calidad del código no está en la mente de los supervisores.

Si desea cambiar esto, depende de usted presentar buenos argumentos de por qué debería cambiar, respaldados con datos . Recuerde que las revisiones de código y las pruebas unitarias de escritura toman tiempo de los programadores, y eso es un costo. Cualquier hora que pases revisando el código de otra persona es una hora en la que no estás escribiendo código que genere dinero. Cualquier prueba unitaria escrita que nunca falla (es decir, nunca detecta un error potencial) es una pérdida de recursos que nunca se recuperará.

La gerencia sabrá cuánto cuesta hacer X horas de revisiones de código, Y horas de pruebas de escritura y Z horas adicionales para "mejorar la calidad del código". Una declaración de "pero tendremos menos errores más adelante" o "hace que escribir código en el futuro sea más fácil" es vaga y no está cuantificada; tendrá poco peso con la gestión. ¿Puede cuantificar cuánto tiempo se pierde debido a la mala calidad del código, la falta de revisiones del código y la falta de pruebas unitarias? Tenga en cuenta cuánto tiempo sobrevive el código. En la empresa para la que trabajo, una gran cantidad de código carece de pruebas unitarias, pero una gran cantidad de código también se descartará o se reescribirá en un plazo de 6 a 12 meses.

Las pruebas unitarias y la calidad del código son cosas buenas para tener (revisiones de código OTOH, no estoy de acuerdo), pero también lo son las computadoras portátiles rápidas y una cafetería interna con café gratis y de calidad. Mejorarán la productividad, pero también tienen un costo. Solo si la ganancia de la productividad mejorada supera el costo, tiene sentido que la gerencia los implemente.

¡Sigue adelante, no eres un árbol!

Como desarrollador, sabes que no puedes trabajar en un lugar como este, y sabes que no puedes cambiar nada (cambiar la forma de pensar de tu jefe), así que ¡sigue adelante! ¡Encuentra otro trabajo en el mejor lugar!