Estas últimas semanas he estado trabajando convirtiendo viejos programas en Clipper MS-DOS a (x)Harbour, por el tema de los 64 bits y el Windows 7.
Como comenté hace algún tiempo, en México, la empresa
ABITS vendió hace mas de 10 años una suite de productos administrativos (Facturación, Contabilidad, Nómina y Bancos) y tuvo la sensatez (o insensatez, depende del punto de vista) de vender sus programas con el código fuente en CA-Clipper incluido, excepto algunos módulos como por ejemplo el de impresión de reportes y el de manejo de los archivos en red, esos iban metidos en un archivo .LIB con alguna función "C" para el tema de los menús.
El caso es que hoy, mas de 10 años después (ABITS dejó de producir los programas en Clipper hace mucho tiempo, ahora son los representantes de Crystal Reports en México), me encuentro que en el mismo mes (Septiembre), me han llamado 4 empresas distintas, de distintas partes de la república, que a la fecha siguen usando los programas de ABITS en Clipper y MS-DOS ¿ porqué ?, esa es una muy buena pregunta y quizá encontremos la respuesta al final de este artículo.
No me piden pasarlos a Windows, no no no, no me piden que se los desarrolle en web, tampoco, me piden simplemente que sigan funcionando como están, pero con Windows Vista, o con servidores Windows 2008 server de 64 bits y que no se les dañen las tablas de datos.
¿ Y siguen usando modo consola ? (voy a llamarlo "modo consola" porque el MS-DOS oficialmente no existe en los sistemas operativos de 32 bits), pues sí, y no les interesa que sea Windows o Web, lo que les interesa es que lo que hace (Contabilidad, Facturación y Nómina), lo hace muy bien, además de que al tener el código fuente disponible, muchos de ellos han modificado el programa para ajustarlo a sus propias necesidades o bien han creado sus módulos para su giro de negocio específico.
Si tú como programador te haz disciplinado a seguir ciertos estándares y reglas para desarrollar tus programas, como usar notación húngara, identar el código, ordenar los nombres de tus PRGs de forma identificable, etc. y luego ves el código fuente de los programas de ABITS seguro te da un infarto (por decir lo menos), no hay estándares de programación, no hay módulo de carga definido, hay un montón de PRGs sin función predeterminada, las variables se llaman "x, y, z", hay variables públicas sacadas de la manga a media función, vamos, por dentro el software es una falta de respeto a la programación, y sin embargo, ¡ funciona !, les resuelve el problema a las personas, e incluso les permite meterle mano para hacer lo que la empresa requiera.
Hoy mismo leía un post del blog de
Joel Spolsky, sobre El programador "
Duct Tape", (Duct Tape = Textualmente "Cinta para ductos", cinta de tela adhesiva multiuso, usalmente de color gris, de alta resistencia, que sirve desde para reparar una cañería rota hasta para atar personas).
Un programador Duct Tape, es aquel que resuelve los problemas de programación de la manera mas sencilla y práctica posible, evitando entrar en las complicaciones propias que pueden presentarse al utilizar una característica avanzada de un lenguaje de programación. El resultado de tener un programador de este tipo en tu equipo es que el producto final por dentro podrá parecer espantoso (después de todo está hecho con cinta de ductos, aflojatodo, pegamento escolar y botellas de PET) pero que funcionará espectacularmente bien y rápido porque se ha enfocado en la simplicidad y no en la complejidad que conlleva usar "florituras" del lenguaje de programación o de herramientas de terceros, mientras que si no tienes un programador Duct Tape en tu equipo seguramente estarás pensando en utilizar titanio, paladio, alguna aleación de metales raros, y combustible nuclear de plutonio en resumen: alguna técnica extraña de programación (bloques de código por ejemplo... ¿ bloque de que...????), sin pensar que construir un programa con tantas cosas y tan complejas de usar y de conseguir, demorará mas tiempo en la producción y resultará mas caro en costo.
Los amigos de ABITS supieron ver esto muy bien en su momento, su código no es bonito, para nada bonito, pero el programa funciona muy bien, hace lo que tiene que hacer y punto, un programador con conocimientos básicos y medios de Clipper le puede meter mano sin ningún problema y hacer cosas productivas con él, porque no usa cosas "complejas" del lenguaje.
Esto me lleva a otra reflexión: Si tu eres una empresa de software, el objetivo de tu empresa es primordialmente vender programas que funcionen correctamente, punto. Te pagan por programar bien, no por programar bonito, porque a final de cuentas no le muestras al usuario final que bonito programas, ni que bien estructurados están tus fuentes, ni si hasta usas mayúsculas y minúsculas en el código y le pones acentos a los comentarios, ¿ que mas dá que salten Warnings cuando compilas ?, ¿ que mas dá usar un FOR... NEXT en vez de un AEVAL() ?, ¿ o un SELECT en vez de un ALIAS-> ?, seamos prácticos, lo que pone dinero en tu cuenta bancaria es la venta de tu producto, no que tan bonito ni que tan estético sea el código fuente de tu programa por dentro.
Cuando compras un coche no te importa si los cables del sistema eléctrico están ordenados por colores o por calibre o por instrumento, es mas, te espantaría ver como están los cables del sistema eléctrico detrás del tablero de instrumentos, debajo de la alfombra del coche o detrás de los faros, porque lo que tu buscas en un coche es que el arranque cuando metas la llave y le des vuelta, y que te lleve de un lugar a otro de una manera rápida, segura y confortable, el sistema eléctrico es necesario para que funcione el coche, el cómo estén organizados los cables del sistema eléctrico no es importante, lo importante es que hagan lo que tienen que hacer.
En el artículo de Joel también se comenta algo como esto: Una solución que resuelve un problema al 50% y que está al alcance de todo el mundo, es mucho mejor y mas duradera que una solución que resuelva un problema al 99%, pero que nadie tenga acceso a ella, porque la tienes metida en un laboratorio haciéndola bonita, depurándola, ajustándola, etc. para además de que sea eficiente, sea estética pero nunca la liberas porque estás preocupado mas por la estética que por la eficiencia.
La solución de ABITS dista mucho hoy en día de tener las técnicas "modernas" de programación (UML, SQL, arquitectura de 3 capas, etc), pero en su momento les solucionó la vida a muchas empresas (algunos cuantos miles de productos vendieron) y hoy en día sigue solucionando problemas, ya no a miles, pero yo calculo que a unos cientos sí, y por eso la siguen usando, quizá no es la mejor, no es para Windows, ni para Internet, pero es algo a lo que se tiene acceso, es fácil de usar y de configurar y sabemos que funciona y hace la facturación, la contabilidad y la nómina, y las hace bien, y si no las hace bien, tienes el código fuente para corregir los errores.
A petición de estos usuarios del software de ABITS hemos desarrollado una serie de soluciones para permitirles continuar trabajando por mucho tiempo mas, estas soluciones se pueden implementar en muy poco tiempo y sin dejar de utilizar el software que actualmente se usa, ni detener la operación de la empresa, es decir... podemos reparar el avión estando en vuelo.
Para darle robustez a los datos, usamos
Advantage Database Server, hemos desarrollado un pequeño módulo .PRG que con solo agregarlo a la compilación del programa Clipper original, convierte a los programas de ABITS en programas 100% cliente servidor, incluso con acceso vía Internet a los datos (y desde CA-Clipper MS-DOS, no se lo pierdan. No es la solución optima, prefiero hacerlo a 32 bits, pero funciona) y gracias a las modificaciones a los clientes TCP/IP que Sybase iAnywhere hizo para el cliente CA-Clipper de Advantage, migrar los programas de Abits a cliente/servidor solo lleva unas horas. Este mismo módulo lo tenemos ya listo para (x)Harbour, simplemente se cambia del código fuente, y listo, funcionan las tablas con el programa de 32 bits.
Para el caso de los 32 y 64 bits, desarrollamos un proyecto en
XEdit, que permite recompilar los códigos fuentes de los programas Abits con (x)Harbour y tenerlos funcionando en 32 bits en muy poco tiempo (usualmente medio día, hay que lidiar con algunas funciones con nombres largos que se les escaparon a los chicos de ABITS cuando hicieron el software, pero ya las tenemos muy bien ubicadas en que parte del código se encuentran), la maravilla de compilar en unas cuantas horas los códigos fuentes se debe a que los programas no utilizan absolutamente nada de complejidades del lenguaje de programación.
Hay una parte del código fuente de ABITS que no se entregaba con el producto original, aunque lo compraras con el código fuente, para resolver esto desarrollamos las funciones faltantes (incluso las que están en "C") y que tienen la misma funcionalidad que sus equivalentes para CA-Clipper, bien dice el dicho que:
en esta vida lo importante no es saber, sino tener el teléfono del que sabe.Y finalmente para el tema de los reportes usamos
FastReports (que por cierto ha liberado una versión nueva para xHarbour, la 4.8, a la cual le han aumentado algunas cosillas interesantes para trabajar mejor con Xailer), la gran ventaja de FastReports es que se puede utilizar perfectamente desde un programa en modo consola de 32 bits con (x)Harbour, generando reportes para cualquier tipo de impresora (matriz de puntos incluida y para impresoras con puerto USB o bien conectadas en red), con 11 formatos de exportación distintos, y que además son muy simples de hacer.
Conclusión: El código viejo no tiene nada de malo (el código fuente no se oxida, ni se hecha a perder con el tiempo), todo lo contrario, como los buenos vinos, con el tiempo, el código fuente se ha usado, se ha probado y se ha depurado, así que, de los males el menor, en vez de tener que volver a programar todo en otro lenguaje, ¿ Porqué no darle otra oportunidad a ese viejo código que todavía nos funciona ?.
