LINQ: el futuro se nos vino encima

miércoles, 21 de noviembre de 2007

... y cuando quisimos darnos cuenta, ya estaba acá

Anteayer (19/11/07) Microsoft hizo públicos

Hay tantas novedades en esta version del producto....

En nuestra opinion, el mayor impacto (y el mayor trabajo de difusión, discusión y esclarecimiento) gira en torno a LINQ y las extensiones a los lenguajes C# y VB que lo soportan.

Se abre un mundo de posibilidades que hay que explorar, entender, elegir...

Vuelva a este blog para más discusiones sobre el tema, en breve!

Jose.

Leer más...

Las buenas prácticas de desarrollo siempre pagan

lunes, 12 de noviembre de 2007

En estos días estuvimos evaluando un conjunto de aplicaciones desarrolladas durante los últimos siete años por una importante cadena de supermercados en Argentina, en el lenguaje Visual FoxPro.

Cuando en 2000 se inició el proyecto de reemplazo de su sistema completo de gestión comercial y de inventarios, nos convocaron para participar en la definición de la arquitectura y la construcción de un framework de clases que sirviera de base para el crecimiento futuro de la aplicación.

Siete años y más de cien mil horas de horas de programación despues, nos tocó evaluar la factibilidad y costo de la conversión a .NET (C#) de toda la lógica de negocios, desarrollada en VFP por un equipo de programadores que se sucedieron en el tiempo agregando funcionalidad y nuevos módulos

Para la evaluación desarrollamos un parser en C#, que realiza un análisis “drill down” del código Visual FoxPro analizando las clases y métodos y verifica cuánto del código es mapeable a expresiones simples con invocaciones a métodos básicos (y por lo tanto, es convertible en forma automática con una herramienta a desarrollar).

En este proceso de evaluación constatamos algunas suposiciones iniciales, y nos llevamos algunas sorpresas:

Arquitectura. Tal como se esperaba, lo que por diseño se concibió para ser interoperable participa a la perfección en el proceso de evolución de la arquitectura:
  • Los componentes de negocios, todos implementados como componentes COM que intercambian XML y acceden a datos en SQL Server, pueden ser “mapeados” exactamente a los nuevos componentes en .NET implementados como servicios.
  • En la capa de presentación, el hecho de haber implementado desde el principio un “dispatcher” que centraliza las invocaciones a la capa de negocios permite introducir fácilmente un conmutador de las llamadas para encaminarlas a los componentes COM originales o bien a los nuevos servicios .NET (Strategy Pattern, GOF).
  • Esto permitirá que la conversión de la lógica de negocios y el reemplazo de componentes se realice en forma gradual, y de hecho permitiría escenarios de coexistencia de las tecnologías en forma permanente, si esa fuera la estrategia deseada.
Prácticas de desarrollo. Con cierta sorpresa, dada la cantidad de programadores que se alternaron durante el proceso de evolucion de las aplicaciones, constatamos un muy alto nivel de calidad y de homogeneidad en las prácticas de desarrollo:

  • De los más de 12000 métodos presentes en la capa de negocios, más de 7000 tienen de 1 a 10 líneas de código, y otros 2000 entre 11 y 20 líneas; con un altísimo grado de reuso de los métodos y clases base para la funcionalidad de uso frecuente.
  • El análisis sintáctico del código permite estimar en más de 8500 los métodos directamente convertibles en forma automática, por consistir en invocaciones a métodos del framework propio con expresiones o comparaciones simples (If …. Then, etc), con otros 2000 métodos que también pueden convertirse en forma automática pero requieren algun grado de revision manual.
En conclusión, y sin minimizar la magnitud que requerirá una tarea de migración tecnológica tan importante (por la evolución cualitativa que representa .NET), constatamos con satisfacción que el costo inicial de desarrollar una arquitectura distribuida, interoperable, y de establecer un marco y prácticas de desarrollo precisas, tiene un triple efecto de devolución:

  • En la calidad del sistema, que permitió el crecimiento y evolución de la cadena durante estos años, y su mantenibilidad aún cuando los equipos vayan renovandose.
  • En la posibilidad concreta, y ya puesta en práctica, de integrar los componentes originales con otros desarrollados en tecnologías radicalmente nuevas, sin necesariamente encarar una reconversión completa.
  • En las enormes ventajas, en caso de encarar una reconversión, de partir con mucho terreno ganado y una proporcion muy mayoritaria de código que puede convertirse automáticamente.
Considere estos factores a la hora de encarar su próximo proyecto: “quick and dirty” (rápido y sucio) no siempre siempre resulta rápido; pero casi con seguridad va a resultar sucio y finalmente caro.
Leer más...