¿Desenredar un desastre de software? ¿Es hora de Big Rewrite?

Question

Recientemente comencé un trabajo sabiendo que las prácticas de la compañía necesitaban ayuda: sin control de fuente, sin seguimiento de errores, definitivamente sin pruebas automatizadas. Me dijeron que su código de aplicación no era bueno.

Qué subestimación.

Su código es un lío profano de asp clásico, vb.net no orientado a objetos (¡conjuntos de registros!), Hojas de estilo incrustadas, etc. La base de datos es una pesadilla: 500 tablas impares, la mitad de las cuales parecen basura vieja cientos y cientos de sprocs indocumentados. Los sprocs están llenos de lógica empresarial, lógica ui (muchos comandos PIVOT), etc.

Existen cuatro aplicaciones web de misión crítica superpuestas que utilizan este desastre, y ni que decir tiene que la mayor parte del trabajo fue realizado por consultores externos que ya no devuelve las llamadas de la compañía. (¿Quién puede culparlos?)

La gerencia está desconcertada por la incapacidad de su equipo web para cumplir con los requisitos del negocio. He tenido cierto éxito al explicar lo que salió mal: "imaginar una bola de cinta adhesiva y cables de siete pisos de altura ..."

Naturalmente, quieren respuestas, no quejas. Consideré una Gran Reescritura, pero parece estar llena de riesgos. Me animan a hacer una gran ganancia temprano, pero no estoy seguro de por dónde empezar. Agradecería cualquier sugerencia que todos puedan ofrecer.

Estoy pensando en acercarse a él de esta manera:

• EDITAR: obtener TFS 2010
• matar a todos "clásico" asp-si no puede ser compilado, que puede incluso no ser Seguro si tenemos todos las referencias correctas.
• Buscar quién utiliza qué sprocs/tablas a través de búsqueda de texto, eliminar material no utilizado
• Reescribir la funcionalidad en piezas, p. reemplace el carrito de compras asp con algo OO.

O alternativamente, seguimos golpeando la cinta adhesiva en el desorden existente mientras construimos el One True System en el lateral.

Agradecería cualquier sugerencia/historias de guerra/ofertas de empleo alternativo, etc.

Answer 1

Es difícil saber qué hacer en este tipo de casos, ya que ni mantener el sistema anterior ni reescribir el sistema es muy atractivo. Un problema con la reescritura es que es probable que haya muchos conocimientos incrustados en el sistema, casos especiales extraños, etc. Y si el código es realmente terrible, es probable que no pueda extraer fácilmente ese conocimiento si lo reescribe desde cero. .

Una alternativa a una nueva redacción es hacer lo que yo llamo "hacha de George Washington". Es como la vieja broma sobre el tipo que tiene el hacha que George Washington usó para talar el cerezo; por supuesto, tuvo que volver a colocar el mango tres veces y la cabeza cinco veces.

Cuando necesite agregar funciones o realizar cambios en el sistema, entre primero y agregue las pruebas que cubren la mayor parte de la funcionalidad de la parte que necesita modificar como puede administrar. Luego, refactorice las partes del código que necesita para poder comprender para agregar la función o realizar el cambio, ejecutando las pruebas en cada cambio. Tampoco es una mala idea ejecutar las pruebas funcionales que tenga con la frecuencia que sea práctica. Eventualmente, habrá reescrito todo el sistema o, al menos, habrá desmantelado todas las cosas más feas, pero no habrá tenido que detener todo el desarrollo durante un período indefinido para volver a escribir desde cero.

Por supuesto que hay algunas desventajas en este enfoque: las características y los cambios serán más lentos de lo que deberían ser durante bastante tiempo, hasta que tenga las cosas bajo control. Al final, tiene que ver todos los factores, ponderarlos y tomar una decisión, es posible que la reescritura desde cero sea la mejor opción.

Answer 2

no creo que pueda mantener este lío y trabajar con él. Pero sugiero que intentes crear Facade con este viejo código basura hasta que lo reescribas todo. Y luego reescribir partes de él, parte por parte.

La creación de una fachada no debería tomar mucho tiempo (al menos no mucho en comparación con Big Rewrite). Y después de eso, podrá comenzar a mejorar inmediatamente el software utilizando una API nueva y limpia. Y cuando tenga tiempo libre, reescribirá la parte antigua de la basura del código utilizando su forma de codificación.

Por supuesto, podría ser imposible crear una fachada para el tipo de código que tiene. ¿Lo es?

Answer 3

La cinta para conductos funciona, y no es fácil reconstruir un edificio de 7 pisos. OMI, seguiría dando palmadas en la cinta mientras planifico un nuevo sistema en el lado si el jefe está dispuesto a pagarle por la gran cantidad de horas que requeriría.A menudo encuentro que la gerencia quiere ver el "progreso" más que nada, en el sentido de que una nueva característica llamativamente deslumbrante pero llamativa obtendrá muchos más accesorios que una reconstrucción completa del sistema que al final parece ser la misma. A Boss probablemente no le importa mucho un carro OO vs. un carro que no sea OO. No es justo, lo sé, y en un lugar de trabajo ideal no sería el caso. Solo mis 2 centavos. Sin embargo, no es difícil establecer un git o svn repo, y ese es un paso en la dirección correcta. Los sistemas de emisión de tickets de RT o Trac pueden ser útiles para el seguimiento de errores y solicitudes de características.

Answer 4

brian - solo sigue abofeteando en la cinta de conductos y escaneando vinculados para nuevos trabajos :).

en serio, realmente necesita presentar un informe que detalle todos los riesgos y gastos relacionados con la oportunidad. en otras palabras, usted sabe cómo se debe hacer, por lo que tendrá que demostrarlo a través de un informe bastante completo que detalle prácticamente todo lo que ha dicho anteriormente. no es un pensamiento feliz, sino uno que en realidad será un producto entregado como tal, ya que el tipo de análisis que debe hacer es un producto para el que muchas compañías crearían un presupuesto.

espero que esta ayuda

Jim

Answer 5

El mejor artículo que he visto en este tema proviene de Joel, y es here.

Si recuerda el navegador Netscape, este fue uno de los navegadores más populares a finales de los años 1990, pero, como señala Joel a cabo en relación con la caída de Netscape:

Lo hicieron al hacer el peor estratégica error que cualquier compañía de software puede hacer:

Decidieron reescribir el código de rayar.

Lo que hay que recordar es que no importa qué tan malo sea ese código, no importa cuán devastador sea, hay partes que probablemente sean muy importantes para la aplicación. Si lo descarta y comienza desde cero, corre el riesgo de perder funcionalidad crítica, y su aplicación podría ser otra historia de Netscape.

Nunca es agradable pasar y averiguar qué está haciendo el código de otra persona, pero esa suele ser la forma más segura y segura de asegurarse de que se reescribe correctamente.

Así que vuelva a factorizar, mejore, consolide, actualice a nuevas tecnologías como ASP.NET, elimine el código muerto, etc., pero asegúrese de recordar aprender de las lecciones de los desarrolladores de netscape, es decir, no arrojar de distancia el código existente.

Como alguien dijo una vez, siempre es menos doloroso aprender de los errores de los demás que de sus propios errores.

¡Buena suerte!

Answer 6

Me he encontrado en situaciones similares, pero probablemente nunca haya estado tan mal. Mi mejor consejo es hacer algo que sea visible de inmediato. Luego tómese el tiempo necesario para hacer algo del trabajo detrás de escena. También sugiero que cualquier página que actualice con código nuevo también la actualice con una nueva apariencia, incluso si es leve, establecerá lo antiguo y lo nuevo. Esperemos que esto logre que la gerencia participe con sus planes para actualizar todo. ¡Buena suerte!

Answer 7

le recomiendo que lea "Working effectively with legacy code"

reescrituras incrementales y paso a paso de-crufting es la mejor solución, si es posible. De la misma manera que a nosotros (como expertos en tecnología) nos encantaría bajar las herramientas y arreglar el "ball-o-mud", la mayoría de las veces no puede dejar de ofrecer funcionalidades comerciales durante meses. Si lo hace, perderá la buena voluntad de los usuarios finales para el nuevo sistema incluso antes de que se complete.

http://ecx.images-amazon.com/images/I/51TG9F1B8AL._SL500_AA300_.jpg http://ecx.images-amazon.com/images/I/51TG9F1B8AL._SL500_AA300_.jpg

Answer 8

Brian - mis simpatías, parece que usted ha tomado más de una de mis antiguos clientes. Perdón por el desastre que te dejé, pero traté de limpiar las cosas antes de que el cliente se quedara sin dinero.

En serio, tenía un cliente con más de 25 aplicaciones en un lío similar: después de dos años, aproximadamente la mitad de ellas han sido revisadas, y las 5 mejores se han limpiado un poco.

No menciona el tamaño del equipo, pero superar la reticencia a cambiar las cosas puede hacer que sea imposible hacer algo. Si ese es el caso, aléjese; no hay nada más frustrante que volver a escribir algo solo para descubrir que sus otros desarrolladores están saboteando sus esfuerzos al no estar a bordo.

Suponiendo que tiene soporte, puede ver cómo resolver esto desde una perspectiva descendente o ascendente.

Lo primero que hay que hacer es poner en marcha alguna estructura: poner todo el lío en un sistema de versiones, para que al menos pueda rastrear lo que está haciendo y retroceder si es necesario. Configure un entorno de prueba separado para que pueda probar cosas sin afectar el desarrollo en curso y la capacidad de admitir el sistema.

Si se está acercando a esto desde una perspectiva descendente, querrá comenzar por limpiar los elementos de la interfaz de usuario: quitar todo el CSS incrustado, limpiar & racionalizarlo. Inventario de páginas, dependencias, etc. (esto solo puede llevar algo de tiempo, especialmente con ASP clásico).Identifique bloques de código repetidos y considere moverlos a controles de usuario compartidos. Vea si puede mapear los componentes de la interfaz de usuario en elementos de la base de datos.

Analice los registros de acceso para encontrar lo que se está utilizando y, con un poco de suerte, identifique el código que ya no se necesita. Probablemente también encuentre una serie de errores; estos pueden ser realmente útiles para comprender el sistema. Probablemente descubrirá que un pequeño subconjunto de la aplicación se usa con más frecuencia; ese es un buen lugar para buscar una victoria temprana más fácil.

Crea un conjunto de archivos CSS pequeños y limpios, y crea algunas páginas maestras que puedes usar para estandarizar la apariencia &. Tendrá que volver a escribir las páginas asp, pero es posible que pueda actualizar las páginas webforms para usar las nuevas páginas maestras más fácilmente.

El objetivo de este enfoque no es corregir demasiado, sino comprender la estructura e imponer cierta organización en ella. La baja tecnología puede ayudar: imprimir cada página en las aplicaciones más comunes y pegarlas en una pared. Ver todo lo expuesto así puede ser de gran ayuda.

El enfoque ascendente comienza en el archivo db: inventar todas sus tablas & procs almacenados. Vea si puede averiguar dónde se usa cada uno de los &. Puede pensar que no se usa algo, pero realmente la única forma de saberlo con certeza es eliminar el objeto de la base de datos (o cambiarle el nombre) y hacer pruebas. (Sí, he visto código que construye dinámicamente nombres de tabla en base a la entrada del usuario -. Ninguna herramienta de análisis va a ayudar con eso)

Una vez que obtenga una mejor idea de las dependencias entre las diferentes partes, puede empezar planeando cómo hacer gradualmente las correcciones. Si puede aislar diferentes subsistemas, considere realizar una migración a un nuevo esquema/conjunto de tablas y crear una capa de acceso a datos adecuada. Puede considerar la incorporación de pruebas unitarias en este momento, pero, sinceramente, tendrá suficientes problemas en sus manos, y esto podría terminar siendo un obstáculo para las personas que no están familiarizadas con él: aprenda a caminar antes de intentar volar.

Si no puede separar por completo las piezas, considere seguir realizando la migración, pero vea si puede colocar vistas o nuevos sprocs como su capa de fachada hasta que se pueda volver a escribir el código.

Hay una serie de libros que tratan sobre reingeniería de sistemas legados, no estoy seguro de que ninguno de ellos vaya a manejar esta situación, pero no estaría de más revisar la literatura para obtener consejos adicionales.

¡Buena suerte, y no olvides mantener el currículum actualizado!

Answer 9

Abordar sólo la parte de la base de datos de esto, aquí es un libro que Wil lhelp hacia fuera: http://www.amazon.com/Refactoring-Databases-Evolutionary-Database-Design/dp/0321293533/ref=sr_1_1?ie=UTF8&s=books&qid=1268158669&sr=8-1

Usted tiene que fijar cosa correctamente para refactorizar una base de datos y este libro tiene un valor incalculable.

También hay herramientas que pueden ayudarlo a encontrar las consultas de peor rendimiento, comience con ellas. Si puede obtener una gran ganancia en rendimiento en algo que molesta a todos, entonces le dará más influencia para seguir solucionando los otros problemas.

También puede consultar un libro sobre el ajuste del rendimiento específico del back-end de la base de datos que tiene. Hay una gran cantidad de problemas de rendimiento que se relacionan tanto con el diseño de la base de datos como con el diseño de la consulta, saber cómo solucionarlos puede ayudarlo de manera insoportable mientras refactoriza este desastre.

Sé que es tentador simplemente tirarlo y empezar de nuevo, pero se le introduciendo nuevas e importantes errores de esa manera, teniendo una enorme cantidad de tiempo, mientras que los usuarios ven ninguna mejora y posiblemente faltan algunos negocios muy importante reglas que deben ser aplicadas. Mientras que cambiar y refactorizar incrementalmente parece ser más difícil en un caso tan malo, realmente es la mejor opción.

Puede hablar con los usuarios y descubrir lo que perciben como los peores problemas que tiene el sistema, ese es un lugar para comenzar, después de todo, hacer que los usuarios estén más contentos es parte de lo que está allí.

Asegúrese de documentar las mejoras de rendimiento y otros cambios para su currículum. Piense cuánto mejor le parecerá a su próximo empleador potencial cuando pueda dar cifras reales de mejora del rendimiento. Los accpmplichments de Actaull adjuntos a las figuras que muestran cuánto logras son raros en los currículos, este trabajo realmente puede hacerte destacar en el futuro como alguien que hace cosas.