¿Debo intentar persuadir a mi gerente de que el ordenamiento de códigos debe tener prioridad sobre los plazos de las reuniones? [duplicar]

él es el jefe, es su decisión. Y estoy de acuerdo con él. NUNCA cambie el código por cambiarlo. Si hay una razón válida para el cambio (digamos que las cosas se desempeñan por debajo de los requisitos tal como están), las cosas deberían cambiar, pero "creo que no es lo suficientemente bonito" no es una razón válida.
Su celo religioso (y eso es lo que es en esta etapa, o parece ser) costaría dinero, introduciría riesgos (cada cambio de código corre el riesgo de romper el producto, requerir más cambios, más pruebas, más retrasos). Eso nunca es bueno.
En vez de eso, tome notas y recoja esos cambios cuando las partes afectadas de la aplicación deban cambiar de cualquier manera.

  

Mi gerente tiene plazos ajustados para cumplir.

La mayoría lo hace.

  

El proyecto actual en el que estoy trabajando actualmente está programado

Bien. ¡Mantenlo de esa manera!

  

He notado un par de áreas bastante significativas en el código que están muy mal escritas. (Los bits de código se llaman dos o tres veces, cuando solo se necesita llamar una vez.)

Si eso no es un problema importante de corrección o rendimiento, entonces no suena tan mal. A menudo, llamar al mismo código innecesariamente dos veces es mejor que llamarlo una vez y guardar el resultado en caché. He visto muchos errores debido a la lógica de almacenamiento en caché defectuosa. Pero confiemos en que es un código incorrecto.

  

El problema es que, en lo que respecta a mi gerente, el programa funciona. Como él lo ve, no tiene sentido realizar cambios largos en el código que nos harán perder la fecha de lanzamiento, sin ninguna mejora tangible que pueda ver. Él sigue diciendo "Eso no es una prioridad. Está funcionando bien como está".

Su gerente es correcto. Usted está en el negocio de entregar valor a las partes interesadas, no en el negocio de la prettificación de códigos. Si no puede argumentar que hacer que el código sea más bonito ofrece más valor a las partes interesadas que alcanzar la fecha de lanzamiento, entonces no haga el argumento.

  

¿Debo seguir tratando de persuadirlo?

No.

  

¿Debo hacer lo que él sugiere y dejarlo?

No.

Debería intentar convencer a su administración para que programe un "hito de la calidad del código" después de que se haya cumplido el plazo . Cuando sus plazos se hayan cumplido y esté planificando la próxima versión, lo primero que debe hacer es programar un análisis posterior al lanzamiento que explique en detalle qué fue lo que salió bien y lo que salió mal. Eso incluye analizar riesgos para el éxito futuro , riesgos como código de baja calidad que se registró con problemas conocidos para cumplir con una fecha límite . Use el tiempo reservado para el "hito de la calidad" para mitigar esos riesgos. Le ayudará si puede llegar a esa reunión con una lista precisa de los problemas que le gustaría abordar.

El argumento para hacer eso es que al hacerlo, ayudará a garantizar que su administrador continuará cumpliendo con los plazos en el futuro .

Aquí hay algunos puntos:

1. Cada cambio causa más errores. La modificación del código complejo causa más errores de los que puede solucionar. Lo ideal sería escribirlo una vez y nunca modificarlo. Agregar código nuevo está bien, pero cambiar la lógica existente causa más errores. Si el resultado final es un desastre la primera vez que lo escribiste, piensa en lo malo que será si lo modificas sin recordar todas las reglas que te dieron el desastre original.
2. El código complejo siempre se ve mal. El código es complicado por una razón. Codifica la lógica de negocios importante, y eso siempre es complejo. Todo el código complejo parece un desastre para las personas que no conocen las reglas que sigue el código. Una vez que se conocen las reglas, es un buen sistema lógico que simplemente funciona correctamente. Olvidará las reglas (o, lo que es peor, alguien más escribió el código y nunca tuvo las reglas) y comenzará a pensar que la lógica de negocios importante es un desastre. La limpieza de dicho código es un gran error.
3. Con el tiempo, las reglas de negocios quedan desactualizadas . Ahora tienes un gran lío, y la mitad de las reglas codificadas para tu software están desactualizadas. ¿Ya es hora de reescribir? Definitivamente no. La única forma de deshacerse de las reglas comerciales que ya están codificadas en el código fuente del software es deshacer todo el sistema. De lo contrario, terminará con fallos en cascada en los que una pieza faltante del software activa los fallos en un código no relacionado que ha funcionado bien durante los últimos 10 años.
4. Mantener es una actividad difícil. Mantener el desorden requiere habilidad. Debe conocer todas las reglas comerciales recopiladas en los últimos 10 años para realizar modificaciones. Olvídate de uno de ellos y tu cambio está causando más daño del que está arreglando. Un buen plan es insertar una nueva lógica, pero nunca modificar la vieja lógica. Refactorizar o reescribir es una manera incorrecta de abordar el problema. Debe comenzar a escribir código de trabajo y nunca confiar en la posibilidad de corregirlo más tarde; la oportunidad nunca aparecerá. Una vez codificado en código, es como concreto; siempre está ahí y romperlo es peligroso.

Muchos gerentes no entienden el concepto de "deuda técnica", que es exactamente lo que está intentando evitar que se acumule.

El administrador es correcto cuando se toma en el contexto de solo esta sección que te gustaría arreglar, pero esto realmente se convierte en un problema cuando muchas secciones se degradan con el tiempo, y otros desarrolladores entran y construyen sobre él.

Luego se descubre un error en parte del código, pero solo se corrige en una sección, no en las secciones copiadas y pegadas.

Si bien aún no está activo, hay otras cosas que debe tener en cuenta en las que probablemente esté pensando el administrador.

Tal vez este cambio de código signifique que una fase de prueba grande debe repetirse. También existe la posibilidad de que introduzcas errores en una función que funcionaba previamente.

Es su trabajo señalar estas cosas, pero aún así la decisión del gerente.

Sin embargo, debe intentar realizar cambios en su proceso de desarrollo para evitar estos problemas en el futuro.

1. Identifique los problemas repetidos y capacite a todos los desarrolladores en un método preferido. Todo el mundo no lo entenderá bien la primera vez, así que prepárate para descubrirlo en una revisión de código. De esta manera, puede tomarse el tiempo para hacer el cambio antes de que un administrador sepa que el código está funcionando lo suficientemente bien / se continúa con más pruebas.
2. Comience a tomar el factor # 1 en sus estimaciones. Su equipo mejorará con el tiempo, pero podrá gestionar mejor las expectativas por adelantado.

Esperemos que sus plazos se hayan establecido en función del tiempo que los desarrolladores pensaron que tomaría construir y no de otro método arbitrario. Algunos desarrolladores sienten que son portadores de malas noticias si hacen estimaciones de proyectos prolongados, por lo que lo evitan al ser demasiado optimistas.

Esta es una pregunta subjetiva, y aquí está mi punto de vista.

DEBES intentar persuadirlo. El hecho de que hayas escrito esta pregunta aquí responde eso. Lo difícil que deberías intentarlo es una pregunta diferente ...

Piensa en diferentes partes del sistema:

• ¿Hasta qué punto estás en el desarrollo de ese módulo?
• ¿Qué probabilidades hay de que ese mismo módulo se modifique significativamente en el futuro (espec. cambios)?
• ¿Está cambiando la interfaz pública del módulo?

Simplemente hágase esas preguntas y haga sus propios pros / contras.

Por ejemplo, si el módulo está casi terminado y es probable que se cambie después del lanzamiento, simplemente dejo la refactorización para más adelante. Pero si se encuentra en una etapa temprana, y es probable que las especificaciones no cambien, refactorice lo antes posible. Debido a que las especificaciones cambiarán, y después de no ver el código desordenado en dos años, tendrá dificultades para implementar nuevas especificaciones. cambios Puede ser tan malo que decida escribir el módulo desde cero y solo use algunas partes del código de la versión anterior del módulo.

Hay algún truco que puede convencer al administrador de que te permita refactorizar.

• Encuentra un error en el código existente. Puede dedicar tiempo a refactorizar mientras corrige errores.

No, no deberías. Las fechas límite son más importantes que el código de limpieza , porque probablemente no tenga idea de por qué se estableció la fecha límite en primer lugar. Tal vez tenga que terminar antes que su competidor, quien robaría a sus clientes. O algunas leyes están entrando en vigor. O simplemente se está volviendo demasiado caro para su hambriento CIO. O ...

Si cree que liberarlo sería un gran riesgo, entonces explíquelo a su gerente. Las razones válidas son: los datos de los clientes podrían perderse, la reputación de la empresa se verá afectada o algo más, lo que podría tener un impacto negativo en la empresa. Pero su gerente tiene que considerar los riesgos y las oportunidades, y tiene que decidir si vale la pena mover la fecha límite.

Pero solicite a su administrador que programe algunos recursos adicionales la próxima vez , para que el software no se convierta en un monolito grande e inalcanzable. Entonces su gerente puede cumplir con su fecha límite y tendrá tiempo suficiente para crear un buen software.

Hagas lo que hagas, no les des a los gerentes una razón para pensar en los programadores como personas en torres de marfil que no saben nada sobre negocios.

Actualizar porque leí que es una aplicación recientemente escrita :

Su primera prioridad debe ser hacer un análisis de la causa raíz para averiguar por qué se escribió ese código erróneo en primer lugar. ¿Cambian los requisitos? ¿Uno de los programadores no tiene la habilidad suficiente? ¿La fecha límite provoca una actitud de enviar y olvidar?

Los problemas en el código pueden crear líneas de tiempo poco prácticas para el mantenimiento en el futuro, especialmente si los problemas no están debidamente documentados con comentarios en el código.

La mayoría de los gerentes tienen una comprensión técnica suficiente para permitirles realizar su trabajo, pero no sabrán cómo codificar, ni tampoco entienden cómo los problemas pueden afectar las líneas de tiempo en el futuro.

Me dirigiría a su gerente por escrito y les explicaría lo que puede (y probablemente ocurrirá) en el futuro permitiendo que los problemas permanezcan intactos y sin resolver. Esto puede incluir líneas de tiempo que se verán afectadas cuando se modifiquen en el futuro para obtener actualizaciones, un rendimiento deficiente de la aplicación (lo que dará como resultado una satisfacción deficiente del usuario), etc. Cuando entiendan el impacto de los problemas y tomen una decisión, la aceptan y continúan. . En este punto, habrá hecho su trabajo como programador creíble y confiable (con una prueba escrita que tiene), y ahora el balón está en su campo para asumir la responsabilidad de cualquier problema relacionado con el problema que ha descrito.