Software Reescribir-frente a correr Análisis de costo

Question

El departamento de TI en el que trabajo como programador gira en torno a una base de código de más de 30 años (Fortran y C). El código está en malas condiciones, en parte como resultado de más de 30 años de cambios ad-hoc mal pensados, pero también sospecho que mucho tiene que ver con las capacidades de los programadores que hicieron los cambios (y que, por cierto, todavía están alrededor).

El negocio que depende del software opera 363 días al año y 20 horas al día. Desafortunadamente hay numerosas interrupciones. Este es el primer lugar donde he trabajado donde hay desarrolladores de turno para aplicar soluciones de código operativo a los sistemas de producción. Cuando era primero, en realidad había una copia del código fuente y las herramientas de desarrollo en los servidores de producción para que pudieran aplicarse cambios sobre la marcha; afortunadamente esa práctica ahora se ha detenido.

He sugerido un par de veces a la gerencia que los costos del tiempo de inactividad, tener programadores de turno, personal operativo adicional, clientes insatisfechos, etc. están costando mucho más al negocio en el medio, y posiblemente incluso a corto plazo, de lo que sería lanzar un esfuerzo total para volver a escribir/refactorizar/reemplazar todo (la base del código es de aproximadamente 300k líneas).

Idealmente, serían una consultora externa que podría entrar y ejecutar la regla sobre la calidad del código y los costos involucrados para mantenerlo funcionando frente a reescribir/refactorizar/reemplazarlo. La pregunta que tengo es ¿cómo debería una empresa hacer ese tipo de análisis de costos en el software Y poder confiar en ese análisis? Los primeros consultores de TI en la calle pueden afirmar que pueden hacer el análisis, pero ¿cómo se puede hacer que la administración se sienta cómoda con lo que les dice el personal interno?

Answer 1

En primer lugar, el perfil del asesor que necesita es muy específico. A menos que pueda encontrar a alguien que trabaje en un dominio similar con los mismos idiomas, no lo contrate.

En segundo lugar, hay una probabilidad del 99% (me gustan los números dramáticos) el análisis se irá de la siguiente manera:

• Consultor explora la aplicación
• Consultor entiende el 10% de la aplicación
• Se acabó el tiempo , tiempo para el informe
• consultor asesora a una reescritura completa (sin refactorización, reescritura llanura)

Así que también puede hacer que la economía de lo que costará el consultor.

sólo tiene dos soluciones aquí:

• Conservar con el código fuente real, sino determinar los métodos adecuados para solucionar los problemas para que tenga una refactorización carrera muy larga que se progressly hecha por aquellos que conocen la aplicación
• Obtener un equipo secundario para hacer una nueva aplicación para reemplazar el antiguo

Si hablo de un equipo secundario, es porque no se puede llevar sólo un arquitecto para hacer la nueva aplicación y tienen el viejo equipo de trabajo con Hola m:

• Están demasiado ocupados en la antigua aplicación
• Habrá fricciones porque el recién llegado, sin duda, hay que subestimar la tarea en cuestión

hablo por experiencia, créame.

Si elige la "nueva aplicación", no ponga sus esperanzas demasiado altas. Usted terminará con una aplicación que tiene menos de la mitad de las funcionalidades de la actual, simplemente porque no puede incluir más de 30 años de casos especiales y arreglos de situaciones excepcionales en un software recién diseñado.

Ah, también, si los desarrolladores dicen que tienen un plan, por supuesto, escúchelos. Ellos probablemente saben de lo que están hablando.

Answer 2

Recientemente hemos decidido reescribir completamente grandes porciones de nuestro código comercial desde cero, y no ha ido tan bien como esperábamos. He visto muchas citas que dicen que nunca deberías volver a escribir nada desde cero, y ahora veo por qué. Recomendaría empezar desde pequeño, no intente reescribir todo al mismo tiempo. Identifique las áreas problemáticas grandes y concéntrese en refaccionar pequeñas porciones del sistema a la vez. Debido a que hay más de 30 años de trabajo en el sistema, llevará mucho tiempo recuperarlo a un estado razonable. Teníamos unos 5-8 años de trabajo por reescribir, y ha sido difícil. ¡No me puedo imaginar más de 30 años de trabajo!

Answer 3

Creo que su descripción proporciona toda la información necesaria sobre la calidad del código (la falta de ella). El hecho de que se necesiten tantos recursos de soporte también indica los altos costos involucrados en el mantenimiento del sistema existente.

Como respondí here, un buen enfoque a considerar es refactorizar una pieza del sistema a la vez hasta que todo funcione a un nivel aceptable. Estoy de acuerdo con que Joel no está descartando el código existente (consulte Things You Should Never Do. Las partes de su código funcionan, por lo que debe dejarlas en su lugar siempre que sea posible, y concéntrese en las secciones que provocan el tiempo de inactividad

Andy también hace un gran comentario sobre el inicio pequeño también.

Otra cosa que debes probar, es revisar los procesos en todo el sistema. ¿Cuando haces esto, debes intentar determinar qué situaciones de falla son causadas directa o indirectamente por la acción del usuario ?, ¿hay configuración o Si tiene problemas para corregir el código directamente, entonces aún puede apuntalarlo al tratar problemas externos de manera más efectiva.

Answer 4

Lo primero que se le viene a la mente es que está tratando prematuramente el argumento de reescritura/refactorización/reemplazo.El primer paso de dos pasos que recomendaría serían:

1. equipo realiza un test
2. QA

Es también dentro del ámbito de ingeniería para implementar estos. Las pruebas unitarias son un paso preliminar esencial antes de que pueda tener lugar cualquier refactorización razonable o reescritura. Con "prueba de unidad" me refiero a ajustar cada llamada de función con el código correspondiente que comprueba que el código funciona para todas las condiciones conocidas. En las actualizaciones complejas esto puede no ocurrir en el nivel más granular, pero cualquier prueba automatizada ayudará inmensamente.

Y control de calidad: tenga un equipo de control de calidad independiente (y agresivo) que pruebe rigurosamente las versiones beta antes de la producción. Sus planes de prueba y procedimientos de prueba se vuelven esenciales para cualquier tipo de esfuerzo de reemplazo.

Una vez que tenga el código bajo control, entonces se encontrará en una posición en la que la empresa puede considerar razonablemente cambios masivos.

Solo una nota sobre su comentario acerca de los consultores externos: a ninguna consultora le importará lo suficiente el código para proporcionar una garantía de calidad realista. QA termina estando casado con la cadera de los negocios que defienden los resultados de la empresa. En última instancia, es una función interna y un asesor externo no puede proporcionarle mucho más que comenzar realmente.

Answer 5

¿El código existe desde hace 30 años?

Los paradigmas de desarrollo han cambiado sustancialmente en las últimas tres décadas en muchos aspectos, y lo más relevante para su situación, creo, es en términos del tiempo (en días hábiles) requerido para crear algo para ingresar-> procesar -> salida algo.

300.000 líneas de código hace 30 años, probablemente podría encajar en 100.000 líneas o menos hoy en día, y que gastan menos horas hombre (?) Esto podría parecer optimista/ridícula para algunos, pero por otro lado es alcanzables, dependiendo sobre el tipo de aplicación en cuestión. No ha dado ninguna indicación sobre la clasificación del sistema: ¿se trata de un sistema de control de procesos de fabricación en tiempo real con sensores y actuadores vinculados a él? Un sistema de reserva de aerolínea? ¿Posprocesa alguna acumulación de datos? En otras palabras, ¿podría reconstruirse en algo como Java y rápidamente con un equipo agresivo y pequeño? ¿Se han documentado los requisitos y, en caso afirmativo, es necesario actualizarlos o volver a desarrollarlos desde cero? ¿La seguridad humana es un factor?

Un simple control rápido, creo que si debe o no depende de la reconstrucción (cualquier orden significa la misma cosa):

1. Número de tipos de código requerido.
2. Nivel de conocimiento de dichos tipos.
3. Qué idiomas no caben.
4. Qué idiomas caben.
5. Cuánto cuesta usar el/los idioma (s) elegido (s) en términos de hardware y software.
6. ¿Cuánto depende la empresa de esto para mantenerse con vida?
7. ¿Realmente es demasiado el tiempo de inactividad, o solo estás fastidiándote? (Tal vez realmente no les importa, pero pretenden).

¡Buena suerte con eso!

Answer 6

1. leído el libro Working Effectively with Legacy Code (véase también la short PDF version) y rodean el código con las pruebas automatizadas, como se indica en ese libro.

2. Refactorizar el sistema poco a poco. Si reescribe algunas partes del código, hágalo en un pequeño subsistema a la vez. No intente hacer un Grand Redesign.