¿Qué conversión/reescritura exitosa ha hecho del software con el que estuvo involucrado? ¿Cuál es el lenguaje y el marco involucrados en el proceso? ¿Qué tan grande era el software en cuestión? Finalmente, ¿cuál es la primera o las dos cosas más importantes que aprendió al participar en el proceso?¿Qué conversión/reescritura exitosa de software ha hecho usted?
esto está relacionado con este question
voy por "más abstrusa" aquí:
conversión de código C teóricamente portátil en código C teóricamente portable a través de arquitecturas para apoyar un cambio de hardware que ahorra los dólares de empresa X por unidad.
El tamaño varía: esta es una necesidad común, y he hecho proyectos pequeños y grandes.
Aprendí a escribir más código C portátil. La elegancia es genial, pero cuando se trata de eso, el compilador se encarga de la interpretación y el código debe ser lo más simple y portátil posible.
Reescribí 20,000 líneas de Perl para usar "use strict" en cada archivo. Tuve que agregar "mi" a todas partes y tuve que corregir los errores que se descubrieron durante el proceso.
Lo más importante que aprendí al hacer esto es: "Siempre lleva más tiempo de lo que piensas".
Tuve que hacerlo de una sola vez durante la noche para que los otros codificadores no estuvieran escribiendo un código nuevo y no fijo al mismo tiempo. Pensé que iría rápido, pero no fue así, y todavía estaba pirateando a las 6 AM de la mañana siguiente.
¡Lo completé y registré antes de que todos los demás empezaran a trabajar!
Estoy haciendo una reescritura de un sistema de gestión Inhouse Project a un modelo MVC más estándar. Está en la pila LAMP (PHP) y estoy cerca del primer hito.
Las cosas que he aprendido de eso actualmente son cuán simple se siente el programa al principio y traté de no agregar complejidad hasta que sea necesario.
ejemplo es que i programado toda la funcionalidad primero (como si estuviera un usuario administrador) y luego, cuando que se ordena a cabo, añadir la complejidad de tener restricciones (niveles de usuario, etc)
No fue exitoso aún ... ¡todo lo mejor! – MarkJ
I portado/rediseñado/reescribió un programa de 30,000 líneas MS-DOS C++ en un programa Java Swing de longitud similar pero mucho más completo y utilizable.
Aprendí nunca a tomar otro trabajo relacionado con C++ o Java.
Abrí una aplicación Powerbuilder del servidor cliente, un par de cientos de pantallas válidas, en una aplicación ASP.NET (C#).
Debido a problemas de rendimiento y mantenimiento, durante el año anterior había trasladado una tonelada de SQL incrustado de los scripts de Powerbuilder a los procedimientos almacenados.
Aunque esto haría que muchos de ustedes se estremezcan, teniendo mucha lógica de negocios en la base de datos, significa que la aplicación Powerbuilder fue relativamente "ligera" y cuando construimos la interfaz de .Net, podría aprovechar el Base de código SQL y tiene mucha funcionalidad ya construida y probada.
No digo que recomendaría crear aplicaciones de esa manera, pero ciertamente funcionó a nuestro favor en esta instancia.
Teníamos una herramienta de generación de código en nuestro marco de aplicación que se usaba para leer en archivos de datos basados en texto, y otras 20 aplicaciones hicieron uso de ella.
Queríamos hacer uso de archivos de datos XML en lugar de archivos estructurados basados en texto. El código original estaba bastante desactualizado y era difícil de mantener. Reemplazamos esta herramienta por una combinación de scripts XSLT y una biblioteca de utilidades. Para la biblioteca de utilidades, podríamos usar algún código en la herramienta anterior.
El resultado fue que las 20 aplicaciones ahora podían hacer uso del formato de archivo basado en texto obsoleto o del nuevo formato basado en XML. También entregamos una herramienta de generación de conversiones que convertía archivos de datos antiguos a nuevos archivos de datos XML.
Después de sacar a relucir una o dos versiones, hemos decidido que ya no admitiremos el formato antiguo basado en texto y todos pueden convertir sus datos a XML.
hemos casi no tenemos que hacer conversiones manuales,
Reescribí una aplicación Java Web grande para una aplicación ASP.Net para una compañía de bienes raíces por varias razones.
Lo más importante que aprendí es que, sin importar cuán trivial sea la característica del sistema original, si no está en el segundo sistema, el cliente piensa que la reescritura es un error. La gestión de expectativas lo es todo al escribir el nuevo sistema.
Esta es la razón principal por la que las reescrituras son tan difíciles: parece tan fácil para el cliente ("Simplemente vuelva a hacer lo que ya tengo y agregue algunas cosas").
Convirtió la aplicación principal de la compañía de C++ preestablecido a C++ estándar. Teníamos una venta multimillonaria que dependía de que funcionase en AIX, y después de analizarla decidimos que la conversión a C++ estándar sería tan fácil como convertirla a C++ tradicional de IBM.
No sé el recuento de líneas, pero el código fuente se ejecutó a cientos de megabytes.
Utilizamos las herramientas estándar de Unix para hacer esto, incluidos vi y los compiladores surtidos.
Tardó algunos meses. La mayoría de las correcciones eran simples, detectadas por el compilador y casi reparadas mecánicamente. Algunos de ellos fueron mucho más complicados.
Creo que mi punto principal fue: no ser demasiado inteligente con el código en un lenguaje que no ha sido estandarizado aún, o es probable que las cosas cambien de forma inesperada. Tuvimos que investigar mucho sobre algunas de las ingeniosas adaptaciones/abusos de las transmisiones en C++.
Hace diez años, administré un equipo que convirtió un sistema CAD de DOS a Windows. La versión de DOS usó home-brew libraries para el dibujo de gráficos, la versión de Windows usó MFC. El software tenía unas 70,000 líneas de código C en el momento de la conversión. Lo más importante que aprendimos en el proceso es el poder de la abstracción. Todas las rutinas no portátiles específicas del dispositivo se aislaron en unos pocos archivos.Por lo tanto, era relativamente fácil sustituir las llamadas a la biblioteca basada en DOS que se dibujaría accediendo directamente al búfer de trama con llamadas a la API de Windows. De forma similar, para la entrada simplemente hemos sustituido el bucle de evento que verificó los eventos de teclado y mouse, con el correspondiente bucle de eventos de Windows. Continuamos nuestra política de aislar el código no portátil (esta vez Windows) del resto del sistema, pero aún no lo hemos encontrado particularmente útil. Tal vez algún día portaremos el sistema a Mac OS X y seremos agradecidos de nuevo.
El más genial para mí, creo, fue el port of MAME to the iPod. Fue una gran experiencia de aprendizaje con hardware incrustado, y pude trabajar con mucha gente excelente. Official site.
Varios. Pero menciono uno.
Era una herramienta de modelado de rendimiento. Parte delphi 1, parte turbo pascal. Necesitaba una reescritura, de lo contrario no iba a sobrevivir. Entonces comenzamos como un equipo de 2, pero solo yo sobreviví hasta el final. Y estaba listo antes de la fecha límite ;-).
Varias cosas que hicimos:
Realmente hicimos esto limpio y al final pagó fuertemente. Una gran experiencia de aprendizaje.
Reescribió un sistema para una empresa que procesa facturas legales, el sistema original era una monstruosidad de VB que no tenía idea de los buenos principios OO: todo estaba mezclado. El HTML hizo SQL, y el SQL escribió HTML. Una gran parte de esto fue un motor de reglas personalizado que usaba algo así como XML para las reglas.
Dos equipos hicieron la reescritura, lo que demoró unos 9 meses. Un equipo realizó la interfaz web y el flujo de trabajo de fondo, mientras que el otro equipo (en el que estaba) reescribió el motor de reglas. El nuevo sistema fue escrito en C#, y fue hecho primero. Agregar nuevas reglas al sistema cuando terminamos era muy sencillo, y todo era comprobable. A lo largo del camino, hicimos cosas como convertir la empresa de VSS a SVN, implementar la integración continua, automatizar la implementación y enseñar a otros desarrolladores cómo hacer TDD y otras prácticas de Scrum/XP.
La gestión de las expectativas fue crucial a través del proyecto. Tener un cliente que era conocedor del software fue muy útil.
Tener una combinación de pruebas a gran escala (de extremo a extremo) junto con una unidad integral y pruebas de integración ayudó muchísimo.
vBulletin convertido que está escrito en PHP en C#/Asp.NET. Estoy bastante familiarizado con ambos idiomas, pero PHP es el ganador para construir ese software. El mayor dolor en la parte trasera era la necesidad de hacer un equivalente C# de eval() de PHP para llamar a las plantillas.
Fue mi primer desafío al tratar de hacer una conversión. Aprendí que necesito más experiencia con C# y que escribirla desde cero es a veces la ruta más fácil.
Convertí un proceso de compilación dinámico escrito completamente en Perl en un C# /.Solución neta utilizando un motor de flujo de trabajo que un compañero de trabajo había desarrollado (que todavía estaba en beta, así que tuve que hacer algunos ajustes). Eso me dio la oportunidad de agregar funcionalidades fail-safe y fail-over al proceso de compilación.
Antes de preguntar, no, microsoft workflow-foundation no se pudo usar, ya que no puede cambiar dinámicamente un proceso durante su ejecución.
Lo que aprendí:
Al final cubrió aproximadamente 5k - 6k (incluido el motor wf) origen LoC de 3 200 archivos LoC Perl. Pero fue divertido, y mucho mejor al final;)
Transmitió una simulación escrita en Fortran 77 (a pesar de estar escrita en los años 90) a C/Java porque el original solo funcionaba en pequeños conjuntos de datos. Aprendí a amar la gran notación O después de varias veces de explicar por qué el simple hecho de mover toda la tabla de datos a la memoria al inicio del programa no iba a escalar.
Migrating the B-2 Stealth Bomber mission software from JOVIAL to C. Conversión 100% totalmente automatizada. ¡Seriamente!
lección principal: utilizando herramientas de conversión automatizadas configurables es una gran victoria.
+1 para tener éxito en su objetivo. –