domingo, mayo 11, 2008

Bye, Bye COM: Estándares y Empresa

...otro Requiem, por COM (escrito por Ángel López). Un buen resúmen de la transición de COM a .NET, que da una idea de cómo mapear las relaciones entre las dos tecnologías. Sin embargo, quisiera agregar dos palabras al tema, que hacen a un asunto más general: el soporte de las tecnologías que son reemplazadas por nuevas versiones.
En distintas ocasiones, muchas más de las que se pudiera suponer, me he visto obligado a mantener código o arquitecturas que fueron quedando si no obsoletas, al menos demoradas; es decir, desarrollos con los que su propietario se siente conforme y no ve la necesidad de evolucionarlo radicalmente, adoptando un nuevo paradigma que le obligue a reescribir o reestructurar código por la simple razón de que la "nueva novedad" lo representa de otra manera. Éste es un fenómeno que en algunas plataformas puede degenerar en real atraso (1), pero que es absolutamente legítimo: una inversión satisfactoria no debería quedar descartada simplemente porque no encaja ya con la evolución de su propia plataforma nativa.
En el caso de la evolución de COM a .NET, así como en el paso de Visual Studio 6.0 a 2005 0 2008, el problema se plantea en el campo del soporte de documentación; quizá en cuanto a compatibilidad del código el problema no sea muy grande, pero es complicado si se requiere mantener una aplicación de VS 6 consultando MSDN; lo más que frecuente es que se hayan perdido las referencias de detalle, y que no se encuentren sino con grandes dificultades las descripciones de las versiones "antiguas" que se desea mantener. La única garantía es conservar bajo llave una copia de la documentación original, mas la historia de modificaciones, porque obtenerlo en la guía en línea puede ser casi imposible.
Este patrón se extiende al seguimiento de problemas, que una y otra vez conduce a callejones sin salida: páginas que ya no existen, aún para temas que debieran estar cercanos, pero que quizá hayan sido enviados a vía muerta en el curso del desarrollo del nuevo producto.
En más de una ocasión algún colega me explicó esto como una política disuasiva de Microsoft, para inducir a la masa de desarrolladores a adoptar las nuevas versiones de sus productos. Sin embargo, tengo la impresión de que, a nivel decisorio, esto produce otro efecto: la observación de una política de soporte del usuario descuidada y tiránica. Bastante alejada de la que he observado por muchos años sobre el AS400 y otros ambientes de IBM, y también, aunque no lo he requerido probar muy a fondo, con el caso del soporte de Sun sobre la plataforma Java.

Justamente, la conveniencia de no estar sujeto a las políticas de un proveedor, es lo que da al diseño guiado por modelos (MDA/MDD) un atractivo especial: la posibilidad de mantener el patrimonio de diseño a un mayor nivel de abstracción, nos otorga libertad de movimientos frente a proveedores y plataformas.

(1) Las facilidades de mantenimiento de código obsoleto -legacy- sobre el AS400 ;-) han llevado a muchas empresas a no innovar por años, dado que el código de su plataforma antigua sigue ejecutando sobre las nuevas versiones). Recuerdo algún caso de una distancia entre código ejecutado y sistema operativo de más de diez años.

2 comentarios:

Anónimo dijo...

Totalmente de acuerdo, muchas veces cualquier previsión que se realice en cuanto a documentación al momento del desarrollo/mantenimiento de una aplicación corre el riesgo de quedar "obsoleta" a la misma velocidad que la tecnología empleada para su desarrollo.

Por eso es importante incluir este análisis a la hora de empezar un proyecto, sobre todo al decidir las tecnologías (y las empresas propietarias de las mismas) de las que se va a terminar dependiendo.

Algo que puede ayudar a garantizar el encontrar la información que necesitemos en un futuro es basarse la cantidad de documentación generada por la comunidad de usuarios de la misma. Un ejemplo de esto puede ser la comunidad de Java por ejemplo, donde uno puede no solo puede encontrar la documentación oficial de Sun (artículos, javadoc, etc), desde las primeras versiones hasta las últimas, sino que además una gran cantidad generada por los propios implementadores.

Cordiales saludos

Jorge Ubeda dijo...

La comunidad de Java, y el sistema de documentación de IBM son mis referencias de comparación contra el estilo de Microsoft. Realmente, creo que este caso necesita un libro aparte.