Si se decide que nuestro sistema necesita una revisión, ¿cuál es la mejor manera de hacerlo?

Question

Estamos manteniendo una aplicación web construida en ASP clásico utilizando VBScript como lenguaje principal.Estamos de acuerdo en que nuestro backend (marco, por así decirlo) está desactualizado y no nos proporciona las herramientas adecuadas para avanzar rápidamente.Prácticamente hemos adoptado el patrón webMVC actual que está por todas partes y no podemos hacerlo, de manera razonable, con la tecnología actual.Las grandes características que faltan son el envío adecuado y las plantillas con herencia, entre otras.

Actualmente se están discutiendo dos caminos:

1. Porte la aplicación existente a ASP clásico usando JScript, lo que nos permitirá, con suerte, pasar de allí a .NET MSJscript sin demasiados problemas y, finalmente, terminar en la plataforma .NET (preferiblemente, las cosas de MVC ya estarán terminadas para entonces, ASP. NET no es mucho mejor de lo que estamos ahora, en nuestra opinión).Se ha argumentado que este es el camino más seguro y con menos riesgos que la siguiente opción, aunque podría llevar un poco más de tiempo.
2. Reescriba completamente la aplicación utilizando alguna otra tecnología; en este momento el líder del paquete es Python WSGI con un marco personalizado, ORM y una buena solución de plantillas.Aquí hay margen de maniobra incluso para Django y otras soluciones prediseñadas.Es de esperar que este método sea la solución más rápida, ya que probablemente ejecutaríamos una versión beta junto al producto real, pero tiene el potencial de generar una gran pérdida de tiempo si no podemos hacerlo bien.

Esto no significa que nuestra lógica haya desaparecido, ya que lo que hemos construido a lo largo de los años es bastante estable, como se ha señalado, simplemente es difícil de manejar.Está construido sobre SQL Server 2005 con un uso intensivo de procedimientos almacenados y publicado en IIS 6, sólo para un poco más de información.

Ahora, la pregunta.¿Alguien ha tomado alguno de los dos caminos anteriores?Si es así, ¿fue exitoso?, ¿cómo podría haber sido mejor?, etc.No pretendemos desviarnos mucho de hacer una de esas dos cosas, pero algunas sugerencias u otras soluciones podrían ser útiles.

Answer 1

¡No tires tu código!

Es el peor error que puedes cometer (en una base de código grande).Ver Cosas que nunca debes hacer, parte 1.

Ha invertido mucho esfuerzo en ese código antiguo y ha solucionado muchos errores.Tirarlo a la basura es un error clásico de los desarrolladores (y lo he cometido muchas veces).Te hace sentir "mejor", como una limpieza de primavera.Pero no necesita comprar un apartamento nuevo ni todos los muebles nuevos para equipar su casa.Puedes trabajar en una habitación a la vez...y tal vez algunas cosas simplemente necesiten una nueva mano de pintura.Por tanto, aquí es donde entra en juego la refactorización.

Para obtener nuevas funciones en su aplicación, escríbalo en C# y llámelo desde su ASP clásico.Te verás obligado a ser modular cuando reescribas este nuevo código.Cuando tenga tiempo, refactorice también partes de su código antiguo en C# y solucione los errores a medida que avanza.Con el tiempo, habrá reemplazado su aplicación con código completamente nuevo.

También puedes escribir tu propio compilador.Escribimos uno para nuestra aplicación ASP clásica hace mucho tiempo para permitirnos generar PHP.Se llama wasabi y creo que es la razón por la que Jeff Atwood pensó que Joel Spolsky se volvió loco.En realidad, tal vez deberíamos enviarlo y luego podrías usarlo.

Nos permitió cambiar todo nuestro código base a .NET para la próxima versión y reescribir solo una porción muy pequeña de nuestro código fuente.También hizo que mucha gente nos llamara locos, pero escribir un compilador no es tan complicado y nos dio mucha flexibilidad.

Además, si se trata de una aplicación únicamente interna, déjela.No lo reescriba: usted es el único cliente y si el requisito es ejecutarlo como ASP clásico, puede cumplir con ese requisito.

Answer 2

¡Aproveche esto como una oportunidad para eliminar funciones no utilizadas!Definitivamente opte por el nuevo idioma.Llámalo 2.0.Será mucho menos trabajo reconstruir el 80% que realmente necesita.

Comience limpiando su cerebro de toda la aplicación.Siéntese con una lista de sus objetivos generales y luego decida qué funciones son necesarias en función de cuáles se utilizan.Luego rediseñelo con esas características en mente y constrúyalo.

(Me encanta eliminar código).

Answer 3

Funciona mejor de lo que crees.

Recientemente hice un gran trabajo de ingeniería inversa en una vieja y espantosa colección de código C.Función por función reasigné las características que aún eran relevantes en clases, escribí pruebas unitarias para las clases y construí lo que parecía una aplicación de reemplazo.Tenía algo del "flujo lógico" original a través de las clases, y algunas clases estaban mal diseñadas [principalmente esto se debía a un subconjunto de variables globales que era demasiado difícil de separar].

Pasó pruebas unitarias a nivel de clase y a nivel de aplicación general.La fuente heredada se utilizó principalmente como una especie de "especificación en C" para descubrir las reglas comerciales realmente oscuras.

El año pasado, escribí un plan de proyecto para reemplazar COBOL de 30 años.El cliente se inclinaba por Java.Creé un prototipo del modelo de datos revisado en Python usando Django como parte del esfuerzo de planificación.Pude hacer una demostración de las transacciones principales antes de terminar de planificar.

Nota:Fue más rápido construir el modelo y la interfaz de administración en Django que planificar el proyecto como un todo.

Debido a la mentalidad de "necesitamos usar Java", el proyecto resultante será más grande y más costoso que terminar la demostración de Django.Sin valor real para equilibrar ese costo.

Además, hice el mismo "prototipo básico en Django" para una aplicación de escritorio VB que necesitaba convertirse en una aplicación web.Construí el modelo en Django, cargué datos heredados y lo puse en funcionamiento en unas pocas semanas.Utilicé ese prototipo funcional para especificar el resto del esfuerzo de conversión.

Nota:Tenía una implementación de Django funcional (solo páginas de modelo y administración) que usé para planificar el resto del esfuerzo.

La mejor parte de hacer este tipo de prototipos en Django es que puedes trastear con el modelo, las pruebas unitarias y las páginas de administración hasta que lo consigas. bien.Una vez que el modelo sea correcto, puedes pasar el resto de tu tiempo jugueteando con la interfaz de usuario hasta que todos estén contentos.

Answer 4

Hagas lo que hagas, comprueba si puedes seguir un plan en el que no tengas que portar la aplicación de una sola vez.Es tentador tirarlo todo por la borda y empezar de cero, pero si logras hacerlo gradualmente, los errores que cometas no te costarán tanto ni causarán tanto pánico.

Answer 5

Hace medio año me hice cargo de una gran aplicación web (afortunadamente ya en Python) que tenía algunas deficiencias arquitectónicas importantes (plantillas y código mezclados, duplicación de código, lo que sea...).

Mi plan es que eventualmente el sistema responda a WSGI, pero todavía no he llegado a ese punto.Encontré que la mejor manera de hacerlo es en pequeños pasos.Durante los últimos 6 meses, la reutilización de código ha aumentado y el progreso se ha acelerado.

Principios generales que me han funcionado:

1. Deseche el código que no se utiliza ni se comenta
2. Desecha todos los comentarios que no sean útiles.
3. Definir un jerarquía de capas (modelos, lógica de negocios, lógica de vista/controlador, lógica de visualización, etc.) de su aplicación.Esta no tiene que ser una arquitectura muy clara sino que debería ayudarle a pensar en las distintas partes de su aplicación y ayudarle a categorizar mejor su código.
4. Si algo viola gravemente esta jerarquía, cambie el código infractor.Mueve el código, recodificalo en otro lugar, etc.Al mismo tiempo, ajuste el resto de su aplicación para usar este código en lugar del anterior.Deseche el viejo si ya no lo usa.
5. ¡Mantenga sus API simples!

El progreso puede ser tremendamente lento, pero debería valer la pena.

Answer 6

No recomendaría JScript ya que definitivamente es el camino menos transitado.ASP.NET MVC está madurando rápidamente y creo que se podría comenzar una migración hacia él, y al mismo tiempo mejorar el marco ASP.NET MVC a medida que se finaliza.Otra opción sería utilizar algo como ASP.NET con Subsonic o NHibernate.

Answer 7

No intente pasar a 2.0 (hay más funciones que las que existen actualmente o están programadas); en su lugar, cree su nueva plataforma con la intención de resolver los problemas actuales con el código base (mantenibilidad/velocidad/wtf) y continúe desde allí.

Answer 8

Un buen lugar para comenzar si está considerando migrar a Python es reescribir su interfaz de administrador en Django.Esto le ayudará a resolver algunos de los problemas en términos de poner en funcionamiento Python con IIS (o migrarlo a Apache).Hablando de eso, recomiendo isapi-wsgi.Es, con diferencia, la forma más sencilla de empezar a utilizar IIS.

Answer 9

Estoy de acuerdo con Michael Pryor y Joel en que casi siempre es una mejor idea continuar evolucionando el código base existente en lugar de reescribirlo desde cero.Por lo general, existen oportunidades para simplemente reescribir o refactorizar ciertos componentes para mejorar el rendimiento o la flexibilidad.