Esta es una pregunta sobre la evaluación del costo/beneficio o el ROI de un proyecto prospectivo.
Estoy trabajando en un proyecto de software de 6-8 años. Tiene muchos problemas y también fallas, además de algunas personas fallidas en su camino. Justo ahora, después de resucitar el proyecto (aplicación de software), cuando llega el nuevo requisito, los desarrolladores están buscando en el código (no en las características de trabajo en términos de uso) el código correspondiente. Hay ideas de crear, reescribir el proyecto desde el principio. Me pregunto si, desde su punto de vista, tiene sentido buscar en el código anterior algo que corresponda al nuevo requisito para la aplicación actual. Porque si es diferente, entonces los desarrolladores se comunicarán con el solicitante, describiendo lo que encontraron en el código y una vez más discutirán los requisitos.
Por un lado, fomenta la ingeniería de requisitos y el proceso de recopilación de requisitos, por otro lado, puede ser una pérdida o una extensión innecesaria del tiempo. Porque puede ser mejor y más rápido comenzar desde cero con el nuevo código para la nueva función. Y especialmente si el nuevo sistema o la reescritura del sistema pueden ser el caso.
Si bien puede haber opiniones sobre este tema, sería útil encontrar una metodología para poder recomendar si es mejor para las partes interesadas continuar invirtiendo en el código anterior o construir desde cero.
Su pregunta es bastante compleja y no se presta a una respuesta clara. Dada la abigüedad de los problemas que plantea su pregunta, encontrará que la mayoría de los participantes de StackoverFlow se inclinan a descartarlo como basado en opiniones. Sin embargo, la pregunta es real y en mi humilde opinión merece una respuesta.
El código heredado es familiar para los programadores que lo escribieron, por lo que naturalmente buscarán allí primero para abordar los nuevos requisitos. Es probable que al solicitante no le importe cómo se realiza la tarea, pero se inclinará por corregir el código existente. A menos que sepan cómo se escribe y funciona el código, pensarán que la reparación siempre será más rápida y económica que el reemplazo. A menudo ese es el caso, dependiendo de los nuevos requisitos.
Sin embargo, la acumulación de parches con el tiempo puede generar una deuda técnica que puede poner en peligro no solo la mejora de la aplicación, sino también socavar su rendimiento. Consulte el trabajo de Martin Fowler, Ward Cunniham y Steve Mconnell, en particular el seminario web sobre gestión técnica de la deuda de este último .
Además, la llegada de nuevos lenguajes y marcos puede dar lugar a soluciones más eficaces, seguras y/o eficientes. Pasar a estos nuevos enfoques puede verse como un desafío bienvenido o una idea terrible según la personalidad del desarrollador. Identificaría un par de arquitecturas de aplicaciones de destino y dibujaría las ventajas, desventajas y puntos interesantes (que no pertenecen a ninguna de las dos categorías).
The Mythical Man-Month: Essays on Software Engineering de Fred Brooks es un libro clásico sobre ingeniería de software que brinda una perspectiva de alto nivel de estos temas. Busque " el efecto del segundo sistema ".
Busque amablemente https://stackoverflow.com/ y https://softwareengineering.stackexchange.com/ para entradas relevantes.
Todd A. Jacobs
buscador de la verdad
Todd A. Jacobs