Alternativas de reescritura de software [duplicado]

Es cierto que la reescritura es el enfoque más radical y debe evitarse siempre que sea posible.

Intente crear un nivel intermedio entre su aplicación y la base de datos. No necesariamente debe ser un proyecto separado, pero todas las solicitudes de base de datos deben pasar por él. Si logra realizar este primer paso, será fácil cambiar la base de datos en cualquier momento, solo tendrá que volver a escribir un solo módulo de su proyecto.

Una vez hecho esto, intente dividir su proyecto en pequeñas piezas lógicas y vuelva a escribirlas ("traducir") una tras otra (si realmente cree que no se puede evitar). Si tiene pruebas de unidad, serían de gran ayuda.

Antes de tomar una decisión sobre el enfoque que le gustaría adoptar, siempre siento que es importante que el equipo de desarrollo siempre considere la opción de una reescritura completa, aunque muchos piensan que casi siempre es una mala decisión. elección.

Tómese un tiempo para escribir algunos hitos de alto nivel que deben alcanzarse, y tome algunas decisiones arquitectónicas de muy alto nivel sobre qué tecnologías centrales formarán parte del nuevo software. En este punto, haga una estimación aproximada del tiempo que necesitaría para completar un proyecto de este tipo. Es bueno, independientemente de la elección que tome para tener al menos una buena idea de lo que le costará un esfuerzo de reescritura en términos de tiempo y dinero.

El otro costo muy importante de una reescritura que muchos descuidan a considerar puede ser el costo exorbitante del despliegue en dinero, tiempo y horas de trabajo. Los usuarios se sienten cómodos con el uso de sistemas antiguos defectuosos, memorizan las peculiaridades y los errores, las soluciones se convierten en parte de su rutina, memorizan las teclas de acceso rápido para realizar sus tareas favoritas rápidamente, se vuelven sorprendentemente productivos con el tiempo.

He visto reescrituras que, por todas las cuentas, deberían haber sido un gran éxito, el desarrollo llegó con menos tiempo y con menos presupuesto, los problemas principales ya no existen, el sistema más nuevo era más fácil y más barato encontrar talento para mantener, el aprendizaje la curva era más pequeña ... el único problema importante que se había descuidado fue la adopción por parte del usuario y la participación de los usuarios basada en Agile. Cuando se les dijo que su sistema de mainframe basado en texto había sido reemplazado por un cliente de escritorio basado en GUI, no estaban familiarizados con él y la productividad había disminuido. La entrada del usuario solo provino de un solo individuo que ya no realizó estas funciones de trabajo, por lo que las combinaciones de teclas tan importantes, la falta de compatibilidad con el teclado, las teclas de acceso rápido, el ordenamiento deficiente de las pestañas y la necesidad de una gran cantidad de interacción con el ratón de apuntar y hacer clic, hicieron que la productividad cayera. Seguro que se habrían puesto cómodos y productivos eventualmente, y sin los errores principales y el rendimiento mejorado, habrían sido mucho más productivos con el nuevo sistema basado en GUI una vez que se resolvieron los problemas.

Lo que desafortunadamente sucedió es que hubo una revuelta abierta contra el nuevo sistema y, a pesar de la aceptación de la administración, no pudieron obligar a los usuarios en el terreno a adoptarlo. El proyecto falló en el despliegue. Los costos ocultos y los riesgos de implementación y capacitación para una reescritura son importantes a considerar cuando se comparan con el costo creciente de mantener el sistema heredado.

Otra opción a considerar es buscar en las tecnologías que causan más dolor, la licencia más costosa, el talento más difícil de encontrar, el buggy inherente, etc. Un buen comienzo podría ser reescribir pequeños fragmentos de la aplicación en tales Una forma de desacoplar los componentes centrales. Una vez hecho esto, es más fácil cambiar y reemplazar componentes a medida que el tiempo se vuelve disponible para volver a escribirlos, y esto reduce en gran medida el riesgo de refactorización en general.

Si fuera usted, empezaría por reemplazar solo la base de datos. Puede usar uno que sea más popular y que sea más fácil de mantener gracias al grupo de talentos. A medida que reemplaza el esquema, puede comenzar lentamente a separar la lógica específica del acceso a la base de datos en módulos separados, lo que facilita la separación de la lógica empresarial de la implementación de la base de datos y el código de acceso a la base de datos. Se puede justificar en mejorar el rendimiento, reducir el costo de mantenimiento y acelerar el proceso.

Algunos pensamientos aleatorios:

Las reescrituras de big bang son propensas a problemas de big bang, por lo que muchas personas sugieren un enfoque incremental para reescribir una aplicación. Idealmente, entonces, debes dividir y conquistar .

Si va por un enfoque incremental, los desafíos son:

• Cómo dividir la aplicación existente en componentes actualizables
• Cómo actualizar cada componente
• Cómo integrar componentes nuevos con los anteriores

Busque divisiones lógicas que ya existen en la aplicación. ¿Hay piezas de hardware separadas? ¿Diferentes tecnologías? ¿Capas? ¿Sirve diferentes clases de usuario de negocios? ¿O realizar diferentes grupos de funciones de negocios?

Cuanto mejor organizado esté su código original, más fácil será su tarea. Como resultado, dividir una aplicación de esta manera casi seguramente implicará una cierta cantidad de refactorización de la aplicación original. Por ejemplo, sacar llamadas de base de datos en un único conjunto de módulos / clases. Tenga en cuenta que no está intentando mejorar su aplicación anterior, su propósito es simplemente modularizarla. Solucionar otros problemas debería ser más fácil con la nueva tecnología (después de todo, esa es una de las razones por las que migra en primer lugar).

Cuanto más pequeños sean los trozos con los que está tratando, más fácil será su tarea. Así que toma las cosas paso a paso. Incluso si solo administra unos pocos cientos de líneas de código, al menos eso es un comienzo.

Si puede automatizar el proceso de actualización de cualquier manera, entonces hágalo. Por ejemplo, puede comprar / hacer una herramienta para convertir el código del programa o los esquemas de base de datos.

Escriba pruebas de unidad para el código antiguo y el nuevo.

Su enfoque sugerido - encapsulate the legacy stuff behind a webservice es una buena práctica a seguir. asegurará que la lógica de negocios se mantendrá igual que antes y minimizará el tiempo de desarrollo para una aplicación con mejor aspecto.

Considere algunas bases de datos No-Sql actualmente disponibles en el mercado.

Actualmente, estamos utilizando Raven DB para las necesidades del proyecto. Aunque, es bastante extraño comenzar a meterse en ello. Sin embargo, parece ser una buena combinación para un enfoque de DDD puro.

Aquí hay una publicación que explica los aspectos positivos de Raven DB entre las bases de datos de No-Sql - ¿Por qué Raven DB?

Dos problemas.

Uno, el tema del equipo tigre. Por lo general, estos desarrollos fallan, ya que el antiguo sistema sería el requisito para el nuevo, mientras que el anterior también cambia, es una paradoja de Zeno. El tío Bob escribió un artículo sobre esto, pero es también es parte de varias de sus charlas y quizás también de sus libros.

En segundo lugar, el problema de la interfaz de usuario.

No es solo que las personas estén acostumbradas a la interfaz de usuario. Esa es la punta del iceberg.

Para los usuarios, el sistema ES la interfaz de usuario . Es por eso que se llamó "interfaz de usuario" en primer lugar. Ni siquiera entiendo realmente cómo podrían odiar el sistema de base de datos subyacente , ya que no tienen nada que ver con eso. ¿No es suficiente "debajo"?

Si la interfaz de usuario, el comportamiento, los datos, y el rendimiento siguen siendo los mismos, podría cambiar cada bit del sistema, los usuarios no lo notificarían. Podría convertirlo de Borland Pascal a Turbo C y viceversa, podría cambiar el sistema operativo del servidor de FreeBSD a Solaris, de Windows a Linux, de Intel a PPC, lo que sea.

Y esto es bueno y malo para ti. Mientras mantengas la interfaz de usuario, puedes cambiar el sistema. Si cambia la interfaz, asegúrese de que la lógica se quede atrás por un tiempo.

(Su único problema será que los usuarios no tienen un problema con el sistema subyacente: tienen un problema con su interfaz de usuario. Cada solicitud de cambio iniciada por el usuario se basa en la interfaz de usuario, esto es lo que SVN / Los registros de CVS / git se muestran en todos los sistemas, porque ese es el idioma que habla el usuario.)

Es como refactorizar: o cambias la estructura del código, pero no modificas el comportamiento, o cambias el comportamiento, pero no cambias la estructura del código. Y tener pruebas automatizadas para eso.

No sé cómo puede probarlo, por lo general usamos pantallas de captura para aplicaciones realmente antiguas. Incluso he visto un frontend bancario que literalmente escribió los resultados de un envío de formulario en un terminal al código antiguo. No bromeando.

Cambia un paso a la vez. Tener un sistema híbrido por un tiempo. Cambiar la interfaz de usuario, retener el sistema, cambiar el sistema, retener la interfaz de usuario, cambiar la interfaz de usuario, retener el sistema, cambiar el sistema, retener la interfaz de usuario ...

Es bueno que tengas la fuente. Incluso si es Pascal, hace que tu vida sea unos miles de millones de magnitudes más fácil.

Para un refactor, reuní todas las entradas que el sistema obtuvo en un período de prueba intensivo de media hora, y recopilé todos los cambios de base de datos que debía hacer. Puede leer sobre esto aquí

Tal vez debería recopilar el uso real del sistema, mediante el uso de registradores de teclas y captura de terminal como kibitz o script .

Oh, y reza para que tus pruebas cubran todo.