¿Alguna vez has estado involucrado en una GRAN reescritura? [cerrado]

55

Joel Spolsky dijo en una de sus famosas publicaciones:

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

Chad Fowler escribió:

Usted ha visto los videos, las publicaciones del blog y la publicidad, y ha decidido que va a 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).

systemmpuntoout
fuente
¿Cuál es su umbral para GRANDE ?
rwong
Un proyecto que se consolida durante muchos años; es decir, no es un proyecto que pueda reescribirse en un mes.
systemmpuntoout
:) Eso puede ser cualquier cosa. Lo que puede hacer alguien recién salido de la universidad sin experiencia en varios meses a un año es bastante diferente de lo que puede hacer alguien con una década o más de experiencia ganada con esfuerzo.
Berin Loritsch
Mozilla realizó una transición exitosa de addons.mozilla.org de CakePHP a Django. Hay una charla que describe esta gran reescritura ( DjangoCon 2010 Switching addons.mozilla.org de CakePHP a Django ), pero la versión TL: DR es que cambiaron una URL a la vez.
user16764
El contrapunto a Joel es el libro seminal de Fred Brook "Mythical Man Month". En su ensayo sobre sistemas piloto, él afirma que tirarás un sistema , por lo que también podrías planificar el evento. En efecto, habrá al menos una reescritura, probablemente dos, ya que el "mayor peligro" a los ojos de Brook se encuentra en el segundo sistema donde florece todo lo anterior y las características.
EBarr

Respuestas:

62

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 sistema anterior simplemente podría apagarse en una fecha, período en particular. Ninguna otra opción era aceptable. Creo que se les ocurre esto, 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 omitieron y lo que se necesita para apagar el sistema anterior.
Arrendajo
fuente
22

Las reescrituras pueden ser muy exitosas si las aplica correctamente. No sé si estos cumplen con su umbral de proyectos "GRANDES" (TM), pero permítanme describirles un par de reescrituras más exitosas.

Proyecto 1

La compañía para la que trabajé tenía un sistema de impresión de tiras para estanterías que se usaba para generar las etiquetas que ves en las estanterías minoristas a partir de algo llamado planograma . El planograma se generó en 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: definimos la reescritura solo para el motor de plantillas. Utilizamos un diseño OO adecuado para atender los requisitos actuales, así como para abordar los nuevos requisitos del tablero de clavijas. El tiempo para la reescritura fue de 1 mes. Si hiciéramos una reescritura a escala completa de toda la cadena de herramientas, nos hubiera 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: nuestro equipo tardó 3 meses en completarse, 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 en el lugar 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 3

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 Java Swing que los desarrolladores originales escribieron sin comprender realmente Swing. Con eso quiero decir que no siguieron las recomendaciones de Sun para tratar con Swing y administrar la interfaz de usuario correctamente, como resultado, entrarías 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 la aplicación Swing mal 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 tenían que rastrear demostró que Swing era la tecnología incorrecta para lo que realmente necesitaban. No pudimos seguir con 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 en base al 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 posiblemente debían ser rastreados también bajo.

Conclusión

Las reescrituras a veces son necesarias, y se pueden completar con éxito si lo planifica correctamente. Puede llegar más lejos con las reescrituras específicas para partes de un sistema que con las 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 muestre su progreso actual a su cliente a intervalos regulares para que puedan ayudarlo a atrapar las peores ofensas.
  • Las reescrituras dirigidas son útiles para lidiar con las peores ofensas en su código base. No haga una reescritura completa si puede limitar el alcance y abordar la mayoría de sus problemas.
Berin Loritsch
fuente
12

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.

Walter
fuente
No lo llamaría una reescritura ... más como una actualización ... a menos que haya convertido el código a C # o algo así. ¿Empezaste desde cero con el nuevo código?
Jay
44
@ Jay - Todos fueron reescritos, sin conversión. Aprovechamos la oportunidad para rediseñar las tres aplicaciones. No veo ningún valor en una conversión directa si no se abordan las deficiencias del sistema existente. En nuestro caso eso comenzaba desde cero.
Walter
¿Qué tan grandes eran? ¿Cuántas líneas de código en el sistema original, cuántos meses-persona tomó la reescritura?
MarkJ
11

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 antiguo, y pasará innumerables horas haciendo que su nuevo sistema funcione de acuerdo con la forma en que diferentes usuarios del sistema antiguo piensan que debería funcionar. Es probable que los requisitos originales del sistema anterior tampoco estén disponibles.

Jesper
fuente
1
Puedo dar fe de esto. Está bien usar una copia de trabajo del sistema anterior como entrada para un documento de requisitos. Pero entonces el cliente debe cerrar sesión en ese documento, no una vaga noción del antiguo sistema.
Adrian Ratnapala
9

La mía es una historia de "éxito". Mi proyecto involucró 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: Implementar 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, la administración de identidad añadida 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 proyectos. Aproximadamente 20 desarrolladores, 10 analistas, 10 probadores.

Tiempo de finalización (comienzo a fin): 1,5 años.

Lanzamiento exitoso: casi fracaso

Éxito de longevidad: fabuloso

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.

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 centrarse por completo en sus aplicaciones y pueden confiar en que cualquier problema de autenticación / autorización existe con la aplicación de gestió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.

Joel Etherton
fuente
5

Estoy involucrado en una gran reescritura de código ahora ... ¡el único problema es que soy el único trabajando en ello! Los costos de mantenimiento de nuestro software actual son escandalosos, tienen muchos errores y tenemos 1 empleado de FT que lo mantiene, por lo que decidimos construir el nuestro.

Es mucho más lento de lo que esperaba, pero finalmente 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.

Rachel
fuente
Estoy en el mismo barco con mi cliente actual, excepto que llevo el sombrero de "temporizador completo". Mantener la aplicación de Access existente mientras termina la reescritura del "nuevo" reemplazo de .NET que he adquirido de desarrolladores anteriores. No es sencillo / fácil y los problemas imprevistos constantes hacen que tome mucho más tiempo del que todos esperan.
BenAlabaster
3
cuando haya terminado, actualice su respuesta con "Esperaba que fuera así, pero fue así" para ayudar a otros a hacer estimaciones más realistas.
1
@Thor Claro, pero puede estar esperando un tiempo. La aplicación tiene mucho más de lo que esperaba (seguridad, cumplimiento, etc.) e intentar construir algo BIEN en lugar de simplemente construir algo lleva más tiempo de lo que pensaba.
Rachel
Parece que ya tienes
11
@ Mark J. Lamentablemente, el proyecto se canceló después de aproximadamente un año porque la compañía no quería gastar el dinero y los recursos para seguir construyéndolo. Supongo que pensaron que estábamos bromeando cuando les dijimos que tomaría alrededor de 5 años con un programador de medio tiempo trabajando en ello ... Estaba muy decepcionado, pero aprendí mucho y siento que me hizo un mejor programador en general. .
Rachel
3

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 anterior 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.

Frank Shearar
fuente
¿Te importaría compartir por qué la versión anterior era demasiado mala para remediarla? ¿Cambiaste de plataforma?
1
Cambiamos las bases de datos (SQL Anywhere 6 a MS SQL Server 7), pero el controlador principal fue que la aplicación se había escrito casi por completo utilizando la peor forma de escribir Delphi: toda la lógica del modelo y del controlador en las vistas, triple línea de 500 líneas bucles anidados, etc. Fue un desastre, no pudimos ver cómo empezar a desarmarlo, y de todos modos estábamos cambiando las bases de datos.
Frank Shearar
3

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:

Mala 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, tuvimos 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.

Buena 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 tales 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 esté en inglés correctamente, muchas gracias

Olivier Pons

Olivier Pons
fuente
Si el proyecto llevara 2 meses, no lo consideraría una reescritura "GRANDE". Especialmente con un equipo de solo 5 personas.
Joel Etherton el
Tienes razón en un sentido. Simplemente pensé que "GRANDE" estaba más cerca de la reescritura "COMPLETA" que "> 2-4 personas trabajando en ello". ¿Crees que mi publicación es inútil? Si es así, lo eliminaré. Gracias.
Olivier Pons el
No, no creo que sea inútil en absoluto. Subes varios puntos decentes. Solo quería hacer mi comentario porque los problemas experimentados a pequeña escala son muy diferentes de los problemas vistos a gran escala. En mi respuesta considero la reescritura de mediana escala.
Joel Etherton el
@ Joel: ok, he leído tu respuesta, este no es el mismo "problema" en absoluto. Una vez más, todo depende del caso. Por cierto, traduje hace unos años todo el artículo de Joel en francés (en mi blog personal);)
Olivier Pons
2
@OlivierPons No estoy seguro de que comparar lo que realmente hiciste con lo que crees que podrías haber hecho es una comparación justa ...
vaughandroid
2

Una compañía para la que trabajé comenzó un importante refactor de la base de código.

La mitad del equipo se puso a trabajar en el refactor, y la otra mitad continuó manteniendo y mejorando el producto existente.

Como puede imaginar, el refactor nunca llegó a un punto en el que algo funcionó: fue solo un proceso constante y continuo 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 "incorporarnos" en las nuevas características que el equipo había agregado al producto existente después de haberlo hecho, y "ponernos al día".

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

Jasarien
fuente
2

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.

refro
fuente
1

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 de la informática o la ingeniería de software. Probablemente el equipo de mantenimiento de 32 programadores malos será reemplazado por 2 buenos después de refactorizar.

Maniero
fuente
Tengo curiosidad por escuchar un seguimiento de lo que sucedió en esto. ¿Tuvo éxito? ¿Qué aprendiste en el camino? ¿O dónde están las cosas ahora, si está sin terminar?
Kimball Robinson
1

Escribí un motor de blogs en 3 semanas. Lo reescribí 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.

Josh K
fuente
44
¿Considerarías un proyecto de 3 semanas como un proyecto grande?
John MacIntyre
@John: No, no diría que es grande , sin embargo, estoy señalando la diferencia horaria entre escribir algo y agregar piezas sobre la marcha, en lugar de volver a escribir con un plan sólido. Reescribí un sistema de gestión completo en 3 semanas que originalmente tardó alrededor de 8 meses en armar. Una vez más, un plan sólido y dirección es lo que necesita.
Josh K
Tener una versión existente (con o sin código fuente, pero con la que pueda jugar libremente) definitivamente ayuda al esfuerzo de reescritura. Más es mejor.
rwong
Para ser precisos, implementó un prototipo de motor de blogs en 3 semanas.
@Thorb: Claro, supongo que se podría decir.
Josh K
1

Hace un poco más de una década, trabajé para una compañía 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.

usuario281377
fuente