Como desarrollador, ¿debo seguir una mala práctica que utilizó el último desarrollador?

Trataré de responder desde ambas perspectivas:

Perspectiva de ingeniero de software

Para muchos ingenieros de software, la calidad del código y la limpieza del diseño son factores importantes. Limpiar el desorden después de que el desarrollador anterior condujera a mejorar nuestras propias vidas y muy probablemente las vidas de otros desarrolladores después de nosotros. Tenemos la suficiente habilidad técnica para superar los problemas que tal refactorización puede traer a los proyectos. Podemos aprender mucho durante el proceso.

Sin embargo, sigue siendo arriesgado, consume mucho tiempo y puede ser muy desalentador, incluso aburrido en algunos puntos. Este es un trabajo de mantenimiento difícil, no la creación de cosas nuevas.

Perspectiva del gerente

Esta es una base de código grande, se ha demostrado en el campo. Necesitamos nuevas funciones rápidamente, no queremos tocar el código de trabajo. Entendemos que podría ser mejor, pero no queremos invertir nuestro dinero en el tiempo dedicado a reemplazarlo con un nuevo código. Solo concéntrese en agregar un nuevo código y avance para agregar una nueva función. Entendemos que agregar nuevas funciones en el futuro será más difícil, pero lo aceptamos. Y aceptaremos eso en el futuro ya que no hay fondos para reescribir el código existente.

Sin embargo, es arriesgado mantenerlo en mal estado, ya que algunos errores que me escondo allí o nuevos errores pueden introducirse más fácilmente. Nos preocupa que preocupe a nuestros desarrolladores y que los haga menos productivos. Sería bueno tener un código de mayor calidad.

Resumen

En mi experiencia, la única forma de convencer a su gerencia para que realice cambios tan grandes en el código existente solo es posible cuando la introducción de una nueva característica de manera antigua conlleva un riesgo demasiado alto de falla e introduce muchos errores graves. En ese punto, el código está seriamente desordenado y es muy, muy difícil de arreglar y limpiar. Tenía algo de experiencia con ese tipo de trabajo (todo finalmente exitoso) y esto requiere mucho apoyo y comprensión tanto de los programas de sus colegas como de su gerente.

Si su gerente u otro jefe que le indica que haga el trabajo no respalda la idea de modificar el código, ni siquiera tenga una fecha para comenzar. La cantidad de estrés relacionada con pequeñas fallas en el proceso puede dañar seriamente su capacidad para lograr su objetivo principal. Probablemente sea mejor terminar tu tarea y marcharte.

Haga lo que le indiquen y obtenga el producto extendido / fijo, para que pueda recibir el pago. Luego, con permiso, comience a arreglarlo a un lado (si tiene tiempo). No me preocuparía de inmediato porque una vez más, usted y su empresa deben recibir un pago. A menos que algo sea deshonesto, extiéndelo. Habrá muchos otros proyectos para diseñar. Este no será su primer código de aspecto desordenado. El suyo será el próximo y lo encontrará usted.

En mi experiencia, es mejor arreglarlo poco a poco. Si lo reescribe (o simplemente soluciona todos los problemas), incluso un trabajo cuidadoso probablemente creará errores.

Refactorización: mejorar el diseño del código existente es un libro bastante bueno sobre cómo hacer esto sin una reescritura. Te lo advierto: está seco.