No somos una compañía de software. ¿Una reescritura completa sigue siendo una mala idea? [duplicar]

14

Entiendo el razonamiento detrás del artículo de Joel Spolsky " Cosas que nunca debes hacer, Parte I ", pero Siempre véalo referenciado en situaciones en las que el objetivo final es la producción de software. ¿Qué pasa si soy un desarrollador que mantiene un sitio de comercio electrónico? Mi trabajo no es escribir una plataforma minorista, sino ponerla en uso. De hecho, esto no sería una reescritura, como tal, sino una gran base de datos y una transición de diseño web.

El software en el que se basa nuestro sitio está escrito en ASP clásico y, en esencia, le faltan muchas características que los clientes esperan de un sitio de compras actual. En lugar de seguir agregando estas características de forma poco sistemática, mi intuición es que debería comenzar a hacer la transición a una plataforma más moderna. Perderíamos las personalizaciones que hemos hecho a lo largo de los años, pero, francamente, muchas de estas características ya existen (¡y es casi seguro que se han implementado mejor!) En el paquete al que me gustaría cambiar.

¿Soy víctima del espíritu de Netscape o tengo razón al pensar que mi tiempo se gasta mejor en lugares además de hacer que nuestras herramientas hagan lo que necesitamos?

Para aclarar, esto es el equivalente de cambiar las plataformas de blogs para nosotros. Cualquier "desarrollo" que yo haga es esencialmente reescribir el front-end de nuestro sitio web, mientras que el back-end está fuera de mi control.

Supongamos que el desarrollo de WordPress se había detenido hace años, y faltaban características "modernas" como comentarios, páginas estáticas, enlaces permanentes limpios, etc. Claro, podría escribir un complemento para agregar esas cosas, pero después de un tiempo, no lo haría. ¿Sería mejor cambiar las plataformas a algo que tuviera todas esas características (necesarias) integradas desde el principio?

    
pregunta Nicholas Sideras 31.05.2011 - 22:17
fuente

9 respuestas

33

Antes de actualizar ...

Podría ser una buena idea si, y solo si:

  • agrega características que sus clientes solicitan ,
  • no pierda ninguna de las características existentes sobre la solución actual,

    (algunos usuarios preguntarán por ellos, y si usted es una empresa pequeña, dejar a los clientes es muy costoso y podría comenzar una ola)

  • no agrega requisitos invisibles / ocultos y efectos secundarios,

  • no viene con restricciones ambientales (o considérelas en los cálculos),
  • su nuevo middleware objetivo está desarrollado y apoyado activamente , y lo será durante un tiempo (largo),
  • cuidadosamente considera los costos (y luego ve un beneficio relativamente a corto plazo) de:
    • desarrollo,
    • implementación,
    • entrenamiento,
    • mantenimiento & apoyo,
    • mantenimiento & apoyo,
    • mantenimiento & apoyo.

Asegúrese de que no será más difícil de mantener que ahora.

Además, mencionas tu tecnología actual, pero a qué te gustaría moverte. Es aún más peligroso si cambias de tecnología.

Si decides actualizar ...

Asegúrate de:

  • copia de seguridad sus datos,
  • ensayar un plan de recuperación empresarial ...
    • para volver al estado de trabajo actual lo más rápido posible si las cosas van mal,
    • para comunicarse con los clientes sobre la transición (fallida) y los problemas, y el estado de sus datos.

Si actualizas (y si es posible) ¡hazlo de forma iterativa!

  1. Actualice su base de datos o cree una nueva,
  2. copia sobre tus datos,
    • actualice sus copias de seguridad con regularidad para trabajar con copias recientes,
    • y copia de seguridad de las copias antiguas , así como (cifrado de forma segura, etc ...)
  3. Desarrollar en un entorno separado ,
  4. prueba mucho internamente ,
  5. prueba con un grupo focal de algunos clientes de confianza.

Si es necesario un cambio completo de middleware, verifique si hay alguna historia exitosa de migraciones entre estas 2 soluciones de software, y lea con atención lo que otras personas han hecho y las dificultades y obstáculos que encontraron.

Calidad de refactor y monitor

Si solo se trata (o casi por completo) de código desordenado, no lo hagas . En su lugar:

  • Lea mi respuesta en cómo organizar un código sucio y sin comentarios (se aplica a fragmentos de código específicos, pero también a bases de código más grandes, ¡y el material recomendado podría ayudar!)
  • Solo refactorista a lo largo del tiempo,
  • Utilice integración continua y inspección continua para monitorear la calidad y los impactos de la refactorización,
  • Y trate de comunicarse con los clientes para preguntar claramente qué funciones les faltan y crear un caso de negocios muy sólido en torno a cada uno de ellos para saber si valen la pena para pequeños proyectos de mejora.

El desarrollo es costoso, el mantenimiento es aún mayor, y construir cosas sin ninguna razón en particular puede ser bueno para complacer a los usuarios, pero recuerde que tendrá que mantenerlo y darle soporte.

Además, si no es una compañía de software, ¿tiene suficiente personal capacitado para apoyar esta tarea durante el desarrollo y después de la implementación? ¿Qué pasa si parte de su personal se va en medio de la tarea?

    
respondido por el haylem 31.05.2011 - 22:27
fuente
11

Los proyectos fallidos sobre los que escribió Joel Spolsky fueron importantes empresas. Para los pocos ejemplos que proporcionó, hay algunos ejemplos de reescritura de éxitos:

  • Mac OS X
  • Windows NT

Ahora Windows se ha reescrito más de una vez, y cada vez que se ha golpeado o se ha perdido, los cambios serán bien recibidos o no. Por ejemplo, NT fue un éxito, ya que hizo que Windows fuera utilizable en la empresa (donde antes vivía Unix). Por otro lado, Vista no fue tan bien recibida. Sin embargo, en ambos casos, Microsoft cubrió sus apuestas.

El punto que Spoelski hace es que una reescritura de software es una propuesta increíblemente arriesgada . A medida que aumenta la complejidad del proyecto, el riesgo aumenta exponencialmente.

El contrapunto con Brooks y el comentario para deshacerse de es que su primera versión de cualquier cosa es un proceso de aprendizaje. Al tratar de tratarlo como algo más que un proceso de aprendizaje, va a encerrarse en un código incorrecto durante mucho tiempo. En Pragmatic Programmer y en muchas otras fuentes, la pequeña refactorización para limpiar las decisiones erróneas es mucho menos arriesgada que la reescritura a escala completa.

Ahora, en tu situación, tienes que mirar las opciones que tienes frente a ti. Tienes los siguientes desafíos:

  • Su software actual se basa en una plataforma obsoleta
  • Las plataformas más nuevas resuelven mejor y más completamente los problemas que tuvo con su plataforma actual
  • Cambiar las plataformas es arriesgado
  • Las reescrituras necesitan planificación, o fallarán

Antes de considerar realizar una reescritura, debe responder algunas preguntas por sí mismo:

  • ¿Este software ya está cerca del final de su vida útil? (es decir, si tiene una vida útil limitada, el costo y el riesgo asociados con el cambio de la plataforma pueden no valer la pena)
  • ¿Es el software simple / pequeño? Cuanto más grande sea el software o más complejo sea, más cosas pueden y irán mal.
  • ¿Es su plataforma de destino capaz de hacer todo lo que necesita? Para evaluar esto, podría valer la pena simplemente hacer las cosas cuestionables para ver si es factible. Puede ser posible, pero tan feo como lo que tienes ahora. Es mejor descubrirlo con una prueba controlada que después de haber tomado la decisión.
  • ¿Cuánto tiempo puede esperar su cliente entre los lanzamientos? Si se puede realizar una reescritura completa en el mismo ciclo de lanzamiento (o más rápido), entonces es probable que no sea fácil. Sin embargo, la mayoría de los clientes no se preocupan por sus problemas y no ven sus problemas como sus problemas. No querrán esperar mientras haces una reescritura completa.

He pasado por este ejercicio más de una vez, y algunas veces se pronunció a favor de una reescritura y otras veces se pronunció a favor de mantener el status quo. Varias veces, descubrimos que si reescribimos solo una parte de la aplicación, podríamos reducir significativamente nuestro dolor sin dejar de ofrecer valor al cliente.

    
respondido por el Berin Loritsch 31.05.2011 - 22:42
fuente
5

Migrar incrementalmente

El punto acerca de no volver a escribir desde cero es que corre el riesgo de estropear todo su producto a través de especificaciones inestables, listas de errores fuera de control, etc., y el tiempo / costos que gastaría sin nada disponible para mostrar para su trabajo. Es difícil de justificar.

Como ya está utilizando ASP, recomiendo implementar nuevas partes del sitio en ASP.NET y mover gradualmente las páginas más antiguas al marco más reciente a medida que las actualiza. Hicimos esto con un producto heredado y durante 18 meses lo migramos por completo, pero podríamos enviar una actualización cada dos semanas para satisfacer la demanda de los clientes.

    
respondido por el JBRWilkinson 31.05.2011 - 22:30
fuente
4

La idea completa de una reescritura completa es que no hay nada, ni una sola cosa, de valor en ninguna parte del código existente. De hecho, toda la idea era defectuosa y debería eliminarse de la tierra.

En mi experiencia, esto rara vez es el caso. En general, es solo obsoleto, y se le debe dar una nueva capa de pintura a través de una transición a una plataforma menos obsoleta. Las aplicaciones anteriores casi todas representan un estrato fosilizado de comportamiento de aprendizaje y optimización. Son capas sobre capas de mejoras incrementales en un intento de alcanzar un pico funcional. Ignora este proceso a tu propio riesgo.

Demasiado a menudo veo que las personas se comprometen a una "reescritura completa" y luego reescriben la aplicación al día 1 de su ciclo de mejora, sin incorporar ninguna de las lecciones o mejoras recogidas en años de operación. Sí, eso es horrible cruft glomming en una base de código de otra manera limpia, pero está ahí porque la base de código original era insuficiente. Sí, reescriba, pero incorpore las cosas que resultaron faltar en la idea original. El mejor software surge de esta manera: incorporando las lecciones aprendidas en lanzamientos inferiores en un lanzamiento más perfecto.

    
respondido por el Satanicpuppy 31.05.2011 - 22:38
fuente
3

es una opinión convencional de que reescribir es una mala idea. Y por una buena razón. Las reescritas en su totalidad son generalmente una mala idea y a menudo fallan espectacularmente.

Pero una mejor manera de expresar el consejo es ... "Una reescritura completa siempre es una mala idea, excepto cuando es una buena idea".

No sustituya la sabiduría convencional por su criterio personal (o el de su equipo) sobre lo que es mejor para su aplicación su . Un poco de sabiduría convencional no puede y no se aplica a todas situaciones. Depende de usted evaluar por sí mismo, teniendo en cuenta las advertencias que brindan los demás, si es necesario o no una reescritura. Nadie más aquí sabe tanto sobre su aplicación y objetivos de proyecto como usted sabe.

    
respondido por el GrandmasterB 31.05.2011 - 22:54
fuente
2

No suena como si estuvieras haciendo una reescritura completa, más que trasladar tu negocio a una nueva plataforma que ya implementa la funcionalidad existente, lo cual es mucho más sensato que reescribir un nuevo sistema por completo desde el principio. ¡Ve a por ello! ... y asegúrese de tener planes de copia de seguridad, planes de recuperación, ensayar y probar la transición varias veces (en un entorno de prueba aislado adecuado), realizar algunas pruebas de usabilidad en la nueva plataforma, etc. ...

Muchos negocios de transición de una plataforma a otra. Sé que hay empresas financieras que están migrando de sus sistemas de mainframe COBOL y es mucho más grande que solo una base de datos y una transición de diseño de UI. Pero también es esencial.

    
respondido por el FrustratedWithFormsDesigner 31.05.2011 - 22:33
fuente
1

La pregunta es sobre qué estrategia es "la mejor", ¿verdad? Como puede ver en las respuestas aquí, hay ventajas y desventajas para ambos. Entonces, ¿cómo decides? Mi respuesta es que tienes que hacer un análisis de riesgo adecuado. También tiene que sopesar las consecuencias en dos niveles: una perspectiva a corto plazo y otra larga, y eso tiene que ver con la vida útil prevista del sistema o producto. Todo se reduce a tomar la ruta más económica, y para hacerlo debe saber cuánto (tiempo) cuesta todo y los riesgos (en términos de costos) que implica. Esta no es una tarea fácil, pero debe hacerse si desea tomar una decisión comercial válida en lugar de una conjetura educada.

Cuidado con las respuestas categóricas.

    
respondido por el Jonny Augustsson 01.06.2011 - 13:20
fuente
0

Me enfrento a un problema similar con una aplicación web Java Struts desordenada. Planeo volver a escribir todo el sitio a tiempo, pero no puedo dejar de mejorar el código existente. En cambio, planeo desarrollar nuevas páginas con una mejor arquitectura y migrar las páginas antiguas cuando tengo que tocarlas o cuando no hay tareas urgentes.

    
respondido por el kevin cline 31.05.2011 - 22:25
fuente
0

Soy un proponente de reescrituras, contrario al consejo de Joel. Esto se debe principalmente a que he encontrado demasiados sistemas que simplemente fueron completamente equivocados y que se habían "equivocado" durante tanto tiempo que sería imposible refactorizar todo lo que necesitaba ser arreglado Y me refiero a "todo": la base de datos era incorrecta, el código era deficiente y no reutilizable, hasta el uso de HTML / CSS obsoletos. Cuando algo es tan malo, la refactorización es como colocar un ducto en una tubería con fugas: usted tendrá que reemplazarlo en algún momento, y hacerlo más temprano que tarde le ahorrará tiempo y dinero. He visto de primera mano los efectos de seguir el mantra "las reescrituras son malas", y el resultado final fue cuando el sistema finalmente se bloqueó, se estrelló espectacularmente y arrastró a la empresa a la bancarrota, todo porque nadie pudo ver que las cosas eran horrible y una reescritura hubiera sido la única gracia salvadora.

Para responder a la pregunta del OP, si el sitio no puede ser sostenible para el futuro, si utiliza tecnologías muy obsoletas que ya no son compatibles (lo que dificulta que las personas lo mantengan), es hora de considerar una volver a escribir. Si es o no una compañía de software, no es tan relevante como la pregunta sobre lo que guarda ( LONGTERM ), no caiga en la trampa de pensar a corto plazo; es esa trampa la que hace que los sistemas ¡se estancan y se infectan en primer lugar!) haciendo una reescritura será mayor que el equipaje adicional de mantener un sistema de enfermedades terminales.

    
respondido por el Wayne Molina 02.06.2011 - 14:04
fuente

Lea otras preguntas en las etiquetas