it-swarm-es.com

¿Alguna vez has estado involucrado en una GRAN reescritura?

Joel Spolsky dijo en una de sus publicaciones famosas:

El peor error estratégico que puede cometer cualquier compañía de software: reescribir el código desde cero.

Chad Fowler escribió:

Ha visto los videos, las publicaciones del blog y la publicidad, y ha decidido que volverá a implementar su producto en Rails (o Java, o .NET, o Erlang , etc.).

Tener cuidado. Este es un camino más largo, más difícil y más propenso a fallas de lo que espera.

¿Alguna vez has estado involucrado en una GRAN reescritura?
Estoy interesado en su experiencia sobre este tema trágico, y en particular, en cualquier gran reescritura que se haya completado con éxito (si corresponde).

55
systempuntoout

He estado involucrado en algunas reescrituras durante mi carrera y fueron todos desastres. Creo que todos fallan por las mismas razones

  • Se requiere una gran subestimación del esfuerzo: cada vez que alguien quiere una reescritura, es porque el sistema anterior está utilizando tecnología antigua y es difícil de mantener. Lo que no tienen en cuenta es que, debido a su edad, puede tener entre 30 y 40 años de esfuerzo de desarrollo. Pensar que puedes reescribir todo en 6 meses con un equipo de 5 es una tontería.
  • Conocimiento perdido: el antiguo sistema ha existido durante tanto tiempo, hace muchas cosas y está enganchado a todo. No hay documentación actualizada ni un único punto de autoridad que realmente sepa todo lo que hace el sistema. Habrá conocimientos con usuarios particulares en departamentos particulares, y encontrarlos a todos es difícil o imposible.
  • Decisiones de gestión deficientes: las reescrituras en las que he estado involucrado tenían expectativas similares de parte de la dirección: el nuevo sistema debería 'terminarse', y el antiguo sistema simplemente podría desactivarse en una fecha, período en particular. Ninguna otra opción era aceptable. Creo que tienen esto en la cabeza, porque están gastando todo este dinero para contratar nuevas personas para este gran proyecto. En realidad, la mejor estrategia de mitigación de riesgos es reescribir las funciones principales del sistema anterior, por ejemplo, abordar el 50-75% del sistema anterior para una primera versión, ¡y luego ver cómo funciona! Debido a los puntos 1 y 2 anteriores, esto probablemente funcionaría mucho mejor, ya que descubrimos algunas de las características que se perdieron y lo que se necesita para apagar el sistema anterior.
62
Jay

Las reescrituras pueden ser muy exitosas si las alcanzas correctamente. No sé si estos alcanzan su umbral de proyectos "GRANDES" (TM), pero permítanme describirles algunas de las reescrituras más exitosas.

Proyecto 1

La empresa para la que trabajé tenía un sistema de impresión de tiras de estanterías que se usaba para generar las etiquetas que ves en las estanterías minoristas a partir de un planograma . El planograma se generó en el software estándar de la industria y nuestras herramientas leyeron ese documento para crear las tiras de estantería utilizando una plantilla para la tienda de destino. El software de plantillas era un desastre con máquinas de estados finitos anidados que abarcaban varias clases y 3 DLL. Cuando llegó el momento de implementar el (entonces) enfoque pendiente de patente para hacer tableros de clavijas, estaba claro que el código actual no podía soportar lo que queríamos hacer.

Solución: Alcanzamos la reescritura solo para el motor de plantillas. Utilizamos el diseño adecuado OO) para atender los requisitos actuales, así como para abordar los nuevos requisitos de la placa de clavijas. El tiempo para la reescritura fue de 1 mes. Si hicimos una reescritura a escala completa del toda la cadena de herramientas habría llevado más de un año, pero no necesitábamos hacerlo.

Proyecto 2

Una aplicación web que nuestro equipo creó desde cero comenzó a superar su diseño original. Nuestro cliente también tenía un conjunto de nuevos requisitos que harían que el sitio fuera mucho mejor para nuestros usuarios, más compatible con "Web 2.0" si lo desea. Si bien podríamos haber forjado nuestro diseño existente en el marco que teníamos actualmente, el mantenimiento fue una pesadilla. Conocíamos la aplicación íntimamente y sabíamos qué partes teníamos que presentar y qué partes iban a desaparecer como parte de la nueva versión.

Solución: Le tomó a nuestro equipo 3 meses completarlo, no fue trivial. El producto final fue más rápido, más escalable y más agradable para los usuarios finales. Superamos las expectativas de nuestros clientes. Dicho esto, tuvimos que dividir nuestro equipo para que las correcciones de errores más inmediatas y los parches de curita se hicieran en el sistema existente mientras la otra mitad trabajaba en el nuevo sistema. Tuvimos pruebas exhaustivas y las incorporamos al principio del proceso. La razón por la que esto funcionó tan bien es porque conocíamos íntimamente esta aplicación y nuestro cliente.

Proyecto

Tengo que incluir una falla aquí. Apoyamos a un cliente que necesitaba una herramienta de gestión de la información para su uso en situaciones de desastre/crisis. Heredamos una aplicación de Swing Java) que los desarrolladores originales escribieron sin comprender realmente Swing. Por eso quiero decir que no siguieron las recomendaciones de Sun para tratar con Swing y administrar la interfaz de usuario correctamente, como resultado usted entraría en bucles de eventos infinitos y otros problemas extraños y difíciles de rastrear. Como resultado, estaba cargado de errores, problemas de interfaz de usuario, etc. Esta era una aplicación muy complicada. Para preservar nuestra cordura, intentamos reescribir mal aplicación Swing escrita en una aplicación Swing bien escrita.

Solución: Completamos la reescritura en aproximadamente 4.5 meses cuando estimamos 3 meses. La aplicación funcionó mejor, tanto en la interfaz de usuario como en la cantidad de datos que podía manejar. Luego ocurrió el tsunami en 2004. La magnitud de la cantidad de personas que tuvieron que rastrear demostró que Swing era la tecnología incorrecta para lo que realmente necesitaban. No pudimos seguir nuestro ajuste de rendimiento, y finalmente abandonaron la herramienta en favor de una aplicación web adoquinada creada por el equipo de Oracle que tenían en casa. Claro que podríamos justificar lo que hicimos basándonos en el conocimiento que teníamos en ese momento, pero la reescritura no fue lo suficientemente agresiva, y no le dijimos a nuestro cliente que sus requisitos para la cantidad de personas que podían posiblemente necesita ser rastreado eran demasiado bajos.

Conclusión

Las reescrituras son a veces necesarias, y se pueden completar con éxito si lo planifica correctamente. Puede llegar más lejos con reescrituras específicas para partes de un sistema que con reescrituras de venta completa. Finalmente, lo que hace que un proyecto falle no es necesariamente la reescritura en sí. Si bien nunca podemos ser clarividentes, podemos encontrar algunos de los peores escenarios. Aprendí a diseñar mis sistemas para soportar dos veces el peor de los casos que se me ocurre. En el caso del sistema de gestión de crisis, eso no fue suficiente: los números reales fueron 20 veces el peor de los casos que nos dieron. Pero ese no era el peor de los casos en el que podíamos pensar.

  • Las reescrituras por el bien de las reescrituras no son tus amigos. Siempre hay mucha complejidad que no ves, y encontrarás que las cosas feas que ves son herramientas de capacitación para tu cliente. Siempre muestra tu progreso actual a tu cliente a intervalos regulares para que puedan ayudarte a atrapar las peores ofensas.
  • Las reescrituras dirigidas son útiles para lidiar con los peores delitos en su base de código. No haga una reescritura completa si puede limitar el alcance y abordar la mayoría de sus problemas.
22
Berin Loritsch

He estado involucrado con varias reescrituras que fueron de VB6 a .NET. En 2 casos, las reescrituras se realizaron sin problemas y en realidad terminamos antes de lo previsto. La otra reescritura tardó más de lo esperado, pero se completó sin problemas importantes.

En nuestro caso particular, la reescritura NO fue la peor decisión que nuestra compañía podría tomar. Los resultados finales fueron en realidad mucho más estables que los originales y nos pusieron en un lugar mucho mejor.

12
Walter

Una de las mayores trampas cuando se realiza una reescritura completa de un sistema existente es pensar "No necesitamos especificar qué debe hacer el nuevo sistema, es muy simple, ¡solo tiene que hacer exactamente lo que hace el sistema anterior!" .

El problema es que lo más probable es que nadie sepa exactamente qué hace el sistema anterior, y pasará innumerables horas haciendo que su nuevo sistema funcione de acuerdo con la forma en que los diferentes usuarios del sistema antiguo piensan que debería funcionar. Es probable que los requisitos originales del sistema anterior tampoco estén disponibles.

11
Jesper

La mía es una historia de "éxito". Mi proyecto involucraba un sitio primario con 4 sitios satelitales escritos/administrados independientemente (subdominios con diferentes aplicaciones en ellos). Teníamos 4 bases de usuarios principales (todas dentro de directorios activos separados) y ninguna tenía un sistema de autenticación común. 3 eran aplicaciones bien establecidas y en silos y el cuarto satélite era completamente nuevo y había copiado gran parte de su código base de nuestro sitio más establecido.

Objetivo: Implemente un sistema de identidad para toda la empresa que pueda autenticar cuentas en 4 dominios y administrar cuentas completas (con autoservicio) en 1 de los dominios. Debido a que .Net ya se implementó en los satélites, el sitio asp clásico que sirvió como "entrada" necesitaría ser reescrito, agregar la administración de identidad y todos los sitios necesitarían pruebas de regresión para asegurarse de que ningún servicio se vea afectado.

Recursos: 3 arquitectos principales: programador, gestión de identidad, gerente de proyecto. Aproximadamente 20 desarrolladores, 10 analistas, 10 probadores.

Tiempo de finalización (principio a fin): 1.5 años

Lanzamiento correcto: Fallo cercano

Éxito de longevidad: Excelente

Yo era el arquitecto de gestión de identidad, así que diseñé las bases de datos, subsistemas e interfaces lógicas por las cuales interactuarían todos los satélites. El arquitecto "programador" fue un desarrollador líder con un amplio conocimiento comercial de todos los satélites y experiencia con las aplicaciones y su desarrollo hasta ese momento.

Después de varios meses de reunir requisitos con aproximadamente 50 personas diferentes de varios departamentos de nuestra corporación, logramos resolver la arquitectura lógica y comenzamos a eliminar el código. Debido a la naturaleza del cambio, tuvimos que reescribir nuestro propio sitio web y toda la funcionalidad que contenía en .Net. En algunos casos era solo una cuestión de refactorización. En muchos casos implicó una reescritura completa de los procesos que lo rodean. En 2 casos, simplemente abandonamos la característica original como no importante. Perdimos 2 fechas límite en el proceso (pero terminamos alcanzando la fecha límite original que había propuesto, apenas). El día del lanzamiento, nada funcionó. Lanzamos un sábado, por lo que el impacto fue bastante mínimo, pero pasé todo el día revisando registros, reescribiendo piezas y evaluando las cargas del servidor. Más pruebas podrían haber ayudado. Un SDLC más completo podría haber ayudado aún más (teníamos un SDLC, pero era mixto).

Al final del primer día, todos los sitios estaban en funcionamiento y todo funcionaba (diría que fue un éxito nominal). En el transcurso de los últimos 2.5 años, todo ha sido un gran éxito. Tener todos nuestros sitios en una arquitectura común con una base de marco común ha hecho que el desarrollo y el trabajo entre desarrolladores sean mucho más fáciles. Las características que escribí en nuestro sitio hace 2.5 años (durante nuestra reescritura) han sido vistas/adoptadas por un par de silos satelitales.

Hemos aumentado el registro, el seguimiento de usuarios, el aumento del tiempo de actividad, una aplicación singular responsable de la autenticación/autorización/identificación. Los silos satelitales pueden enfocarse completamente en sus aplicaciones y pueden confiar en que cualquier problema de autenticación/autorización existe con la aplicación de administración de identidad.

Nuestro proyecto fue una gran frustración, angustia y desastres. Al final ha valido la pena y algo más. Estoy 100% de acuerdo con la evaluación de reescrituras de Joel Spolsky como regla general, pero siempre hay excepciones. Si está considerando una reescritura, solo necesita asegurarse de que sea absolutamente lo que necesita. Si es así, prepárate para todos los dolores que vienen con él.

9
Joel Etherton

Estoy involucrado en una gran reescritura de código ahora ... ¡el único problema es que soy el único trabajando en ello! El costo de mantenimiento de nuestro software actual es indignante, tiene muchos errores y tenemos un empleado de FT que lo mantiene, así que decidimos construir el nuestro.

Es mucho más lento de lo que esperaba, pero en última instancia creo que será mucho mejor porque tendremos nuestra propia base de código para que cualquier cambio que quieran en el futuro pueda implementarse fácilmente (el software debe cambiar con frecuencia para mantenerse al día tiempos actuales). También estamos haciendo algunos cambios importantes en el diseño mientras lo reescribimos.

4
Rachel

Todo depende. En mi caso, seguí el consejo de Joel Spolsky y me equivoqué . Se trataba de un sitio web de seguros. El sitio era horrible y esto es lo que hice, luego lo que debería haber hecho:

Malo estrategia: supervisé a un grupo de 4 estudiantes para:

  • Estudiante # 1 - reescribió el acceso a la base de datos/consultas para hacerlos seguros
  • Estudiante # 2 - movió todos los css "arriba"
  • Estudiante # 3 - hizo todas las páginas compatibles con w3c
  • Estudiante # 4: resolvió todos los errores pendientes
  • Yo mismo: eliminé todas las advertencias de php y cosas malas (código duplicado, etc.)

Tomó 2 meses. Luego rediseñamos el sitio. Luego lo hicimos en varios idiomas. En general, teníamos que mantener una gran parte del código malo y la estructura de la base de datos se mantuvo igual. Así que todavía estoy trabajando en cosas malas durante un año y nunca se terminará hasta que decidamos una reescritura completa, lo que nunca sucederá en realidad.

Bueno estrategia:

  • Estudie todo el sitio, haga un buen "Documento de requisitos del producto".
  • Vuelva a diseñar correctamente la base de datos
  • Comenzar desde cero con mi propio marco (que ya funciona)
  • Rediseñado el sitio.
  • Hacer multilenguaje.

Tiempo que hubiera tomado: dos meses ( tal vez menos ).

  • Buen código.
  • Buen mantenimiento.
  • Productividad.
  • No hay respuestas como "no podemos hacer esto, el sitio web no puede manejar dichos productos".

Entonces, mis palabras finales: todo depende de la complejidad de las cosas que tienes que reescribir.

No dudes en corregir mi publicación para que sea un inglés adecuado, muchas gracias

Olivier Pons

3
Olivier Pons

Participé en una reescritura completa en mi trabajo anterior. Y estábamos muy felices de haberlo hecho. Digamos que a veces la base de código está tan podrida que es mejor comenzar de nuevo.

Era una aplicación interna, la principal aplicación comercial, de hecho.

Mantuvimos el sistema antiguo mientras escribíamos la versión 2. Si no recuerdo mal, nos llevó alrededor de un año (dos programadores y luego un tercero). Sin embargo, no necesitábamos tocar la base de datos, por lo que al menos la migración de datos no fue un problema.

3
Frank Shearar

He estado en una gran reescritura durante los últimos 3 años. Original estimamos que el proyecto tomaría 2 años. La idea básica era reemplazar el hardware, usar un sistema operativo existente, reescribir la lógica de negocios (de c a CPP), crear una nueva tarjeta IO) y escribir una nueva interfaz de usuario.

En el camino tomamos algunas decisiones terribles. No teníamos experiencia real en CPP y ningún mentor para enseñarlo bien. Intentamos construir un marco de UI basado en win32. El hardware era barato y el BSP estaba lleno de errores. El software era súper flexible pero difícil de mantener. El año pasado desechamos la interfaz de usuario local y desarrollamos una interfaz de usuario en .net. También reescribimos completamente nuestro mecanismo de persistencia y protocolo de comunicación de datos.

Tomó mucho esfuerzo adicional, pero ahora el proyecto está casi terminado y las primeras unidades se prueban en el campo. El proyecto tenía mucho riesgo de tener algún cambio para tener éxito. Hubo algunas cosas positivas sobre el proyecto, comenzamos a usar SVN (en lugar de VSS), nos tomamos el tiempo para escribir pruebas unitarias e implementamos una compilación nocturna. También comenzamos a usar scrum para tener un mejor proceso.

En retrospectiva, creo que la reescritura de la lógica de negocios no fue necesaria, solo deberíamos haber refactorizado las partes más feas. Y para escribir una IU desde cero, no lo haga a menos que sea su negocio principal.

2
refro

Una empresa para la que trabajé comenzó un importante refactor de la base de código.

La mitad del equipo estaba listo para trabajar en el refactor, y la otra mitad continuaba manteniendo y mejorando el producto existente.

Como puede imaginar, el refactor realmente nunca llegó a un punto en el que algo funcionó: fue solo un proceso continuo constante que realmente nunca tuvo nada que mostrar por sí mismo.

La idea era que sería mejor trabajar con la base de código refactorizada y podríamos simplemente "entrar" en las nuevas características que el equipo había agregado al producto existente después de que se hizo, y "ponerse al día".

Pero terminó siendo la caída de la compañía.

2
Jasarien

Hace un poco más de una década, trabajé para una empresa que decidió hacer un "rediseño" de su producto central envejecido. Desde entonces, mencionar la palabra "rediseño" es un delito punible. Tomó mucho más tiempo de lo esperado, obviamente costó más, y el nuevo producto era mucho más similar al producto anterior de lo inicialmente planeado.

1
user281377

En realidad estoy comenzando una gran refactorización. 4MLocs probablemente debería reducirse a 800KLocs o menos. Este proyecto tiene muchas funciones de copiar y pegar, malentendidos en el lenguaje, muchos comentarios repetitivos inútiles, malas decisiones, piratería temporal y más piratería convertida en permanente (incluidas soluciones alternativas), falta total de conocimiento sobre los principios básicos sobre Ciencias de la Computación o ingeniería de software. Probablemente el equipo de mantenimiento de 32 programadores malos será reemplazado por 2 buenos después de refactorizar.

1
Maniero

Escribí un motor de blogs en 3 semanas. Lo reescribo en 8 horas.

Planear con anticipación es clave para una reescritura exitosa. Conocer el sistema por dentro y por fuera también es un beneficio.

1
Josh K