¿Cómo manejar un código fuente realmente malo? [duplicar]

Actualmente estoy trabajando en un proyecto en el que heredé un producto que alguien más hizo a mitad de camino. Mi trabajo es terminar ese proyecto específico. Me dijeron que tenía las manos libres sobre qué hacer, así que miré el código fuente y decidí que era basura y comencé de nuevo.

En dos semanas, tenía un prototipo funcional cuando mi jefe vio lo que hice y se sintió muy decepcionado porque cambié el diseño general de la página sin preguntar (como dije, tenía las manos libres allí). Pero bueno, de esta vergüenza, volví al código fuente original.

Lo que pasa es que es muy malo e inestable. Está copiado de muchos sitios web diferentes sin fuentes, etc. y cada vez que trato de corregir un error, surgen otros veinte que dependían de ese error que solucioné.

Prácticamente no hay documentación (un archivo txt con una lista de paquetes para instalar) y ahora ya tomó alrededor de medio año (debería haber terminado después de un máximo de tres meses).

Creo que en este caso no es mi culpa no poder trabajar con ese código fuente ya que cada vez que le pregunté a la persona que trabajaba en él anteriormente, ella no tenía ninguna respuesta exacta y solo me dijo que siguiera buscando en Google y jugando hasta que Consigo lo que quiero. Pero me siento muy avergonzado frente a mi jefe (que es una persona muy agradable, pero también quiere que se termine ese proyecto).

¿Qué puedo hacer ahora? ¿Reiniciar todo? (Si no es así, ¿es la falacia de la concordia?) Explique por qué un producto tan mal escrito no se puede usar o se puede desarrollar más.

No quiero parecer incompetente y no quiero que el empleado anterior quede mal visto, ya que era una persona muy agradable y divertida. Pero su código era terrible.

¿Cómo manejar esto, preferiblemente de manera que no me despidan?

Simplemente diga que el código fuente tal como está es inestable y que cree que el mejor enfoque es comenzar de nuevo y usar el ejemplo de romper otros 20 elementos cambiando uno.
"Estaba muy decepcionado porque cambié el diseño general de la página": ¿entonces su jefe solo estaba mirando la salida del código fuente? ¿Por qué necesitaría volver al código incorrecto original para obtener el mismo resultado?
Esto es algo que le sucederá a cualquier desarrollador en algún momento de su carrera. En su caso, ¿no podría mantener el mismo front-end (HTML, etc.) y rediseñar el back-end para que sea más compatible?
Creo que tu jefe dejó bastante claras sus expectativas: no te metas con el código sin preguntar. El código pertenece a la empresa y no a usted. Además, esto puede ser una sorpresa para usted, pero los desarrolladores de software de todo el mundo heredan rutinariamente el código "malo", pero no se deshacen de todo y lo construyen desde cero. Si desea "mejorar" el código, elabore un plan con el jefe y hágalo por pasos.
Si está usando su nombre real aquí, puede considerar usar un alias en su lugar. Esta pila se puede buscar fácilmente.
La respuesta duplicada incorrecta está vinculada como razón cercana. Realmente no tiene nada que ver con la pregunta. Esto: softwareengineering.stackexchange.com/questions/155488/… debe vincularse como motivo cercano.

Respuestas (3)

Miré el código fuente y decidí que era basura y comencé de nuevo.

Aquí fue donde te equivocaste, como lo demuestra lo que sucedió a continuación:

En dos semanas, tenía un prototipo funcional cuando mi jefe vio lo que hice y se sintió muy decepcionado porque cambié el diseño general de la página sin preguntar.

No puede simplemente tirar el código incorrecto y comenzar de nuevo cada vez que lo encuentre: trabajar con código incorrecto es una habilidad necesaria para desarrollar.

Estoy bastante seguro de que la mayoría de las personas que trabajan en esta industria durante un período de tiempo heredado habrán heredado un código "malo", ¡es solo un hecho de la vida! Es natural simplemente querer comenzar en sus propios términos, pero tirarlo y comenzar de nuevo, especialmente sin autorización, no es el camino a seguir.

Diferentes personas tendrán diferentes formas de lidiar con el código incorrecto, pero la mía es tomarme el tiempo para examinar a fondo el código base existente, asegurándome de que al menos entiendo cómo funciona en un nivel fundamental (¡o cómo no!) A partir de eso punto, documentaré todo lo que haya encontrado que creo que debe cambiarse o corregirse, y calcularé estimaciones aproximadas de cuánto tiempo tomará. (Y esto es todo antes de cambiar nada).

Si documenta las cosas como se indicó anteriormente, puede llevar un documento mucho más concreto a la gerencia y tener una conversación mucho más constructiva sobre qué necesita cambiar y por qué.

No reinicies, refactoriza. Elija un bit que se vea mal y arréglelo, sin alterar realmente lo que se supone que debe hacer .

Luego elige otro bit y arregla eso. Corrija la documentación un poco a la vez también.

Eventualmente terminarás con algo que no es perfecto, pero es lo suficientemente bueno. Hará lo que se suponía que debía hacer el original. Y después de toda la refactorización, debería tener una buena comprensión de cómo funciona todo.

Dentro de dos semanas

Trabajó durante dos semanas sin avisarle a su jefe que estaba reescribiendo todo el proyecto. Estoy seguro de que si le hubieras hecho saber a tu jefe cuáles eran tus planes y por qué lo estabas haciendo desde el principio, habría ido mejor.

Usaste la palabra diseño, pero ¿fue la salida del programa la que cambió y el jefe se molestó? Si es así, ¿se resolvería haciendo coincidir la salida con el nuevo programa? ¿Fue el diseño del código en sí? Si es así, debe hablar con su jefe y convencerlo de por qué el nuevo diseño es mejor, o debe volver al código anterior y arreglarlo donde sea utilizable.