[color=#FFFFCC]Mas de Principios RAD

En ocasiones anteriores hemos mencionado algunas cosas sobre RAD (diseño rápido de aplicaciones). Sin embargo, hace un mes mas o menos me pasó algo curioso, me contrató una empresa para hacer un trabajo free-lance referente precisamente a conciliaciones bancarias en una serie de programas realizados en Visual Basic 4.0 a 16 bits, utilizando el SDE, que viene siendo una especie de sistema para cambiar Clipper a Windows, pero menos logrado que Visual Objects o que el mismo Five Win.

Creo que es importante mencionar algunas cosas que me di cuenta que para mi eran obvias, pero nunca las había puesto por escrito, y permitirán entender mejor las lecciones que siguen; estoy trabajando en el motor de ayuda para que lo puedan consultar fuera de linea.

1. Debe tratar de tenerse un máximo de diez formularios en todo momento; en raras excepciones 20. Los que trabajaban conmigo en Nieto recordarán que el sistema de Visual que hice para todos los sistemas era de un solo formulario por programa, y el nuevo suministros era de mas de 30. Ustedes saben lo que provocaba en facilidad de uso y control de versiones.
2. No usar controles ajenos a Microsoft en la medida de lo posible, por muy bonitos que sean. Evitan reusar el código, y posiblemente hay algo mas moderno y mejor de Microsoft. Citando otra vez a Nieto, recuerden el problema de los dirvers de Merant para accesar DBFs en lugar de Utilizar ADO.
3. En la medida de lo posible, traten de liberar muchos cambios chicos seguidos que un cambio grande con todos; la curva de aprendizaje del usuario es mejor, y además permite corregir errores que no nos hubieramos dado cuenta.
4. En el desarrollo rápido de aplicaciones, debe tratar de burocratizarse lo menos posible el diseño. En muchos lugares el analista es el jefe del programador, o es un analista diferente al que hace el código, pero … es tremendamente frustrante, y tonto encontrar al 80% del trabajo un error garrafal de diseño que uno tiene que arreglar rehaciendo todo de cero.
5. Si tienen un empleado o usuario Beta, o documentan código para otro uso, traten de comentar el código; me refiero a No decir : Esto simplifica el código, sino a decir que cambia de una versión a otra.
6. En la medida de lo posible, deben tener una representación del modelo físico en lugar del modelo lógico; el modelo físico es mucho menos suceptible a confundir procesos con personas. En el modelo lógico pueden encontrar el proceso Usuarios, cuando este es una persona.

[color=#000000]………6a) Usando el modelo físico, si ven facturas lo mas probable es que se refieran a facturas, pero en un modelo lógico se pueden encontrar con que facturas se refiere a entradas de cuentas por pagar o por cobrar, y nada que ver con facturas.

1. 7 Como regla general, si una Tabla tiene menos de 100 registros, NO NECESITA INDICES.
2. 8 El número de indices debe de ser razonable. Alguno de ustedes recuerda aquellos programas originales de clipper, o el Sae de ASPEL que tenían indices hasta en la sopa? He manejado bases de datos de 700 megas con 4 indices, pero he visto sistemas con archivos de 10 registros y siete indices, y programadores que se quejan de que con Clipper/foxpro es dificil abrir mas de 15 indices a la vez.(¿?)
3. 9 Los procesos ABC deben estar en una sola pantalla del mismo catálogo. Los cambios y altas son muy parecidos, no tiene caso tenerlos en otra.
4. 10 Los reportes de preferencia deben estar en un archivo aparte TODOS; esto facilita usar un solo formulario de impresion de reportes, o hacer cambios rapidos a todos los reportes.
5. 11 Las pantallas para fijar acceso deben ser congruentes. Tener 10 pantallas para pedir diferentes tipos de acceso podría hacerse con una forma general bien hecha.
6. 12 Puede usarse una función global de contraseñas; para solicitar en diferentes lugares del programa, en lugar de tener tres formularios diferentes con distinto texto y contraseña Hard Coded.

Ahora les voy a describir el sistema principal de esa empresa. Era un equivalente a SAE, programa administrativo de control de chequeras, producción, bancos, insumos , cuentas por pagar y cobrar, busqueda de clientes , proveedores , etc etc etc.

Un total de 220 formularios MAS archivos FRX, haciendo una relación de que era que, resultó que 175 correspondían a busquedas, grids y reportes de ABC, que se podían reducir a 65. Además manejaban reportes casi idénticos para cuentas por cobrar y por pagar, pero en diferentes formularios. Y por ultimo… tenian que correr en maquinas con 256 MB de ram por la memoria disponible; programados por Accesos a funciones SDE y algo de RDO. ( esto lo vi en el año 2000 pero seguro que hoy por hoy hay programas equivalentes)

Y lo peor es que este tipo de programas no son nada infrecuentes. Como dato general, teniendo la estructura de base de datos, la conciliación bancaria quedó en dos tardes de trabajo, me embolsé 400 dolares, y les presenté una propuesta para pasar todo a ADO por 1000 dolares con una entrega a un mes.

El estimado que tengo es que ese sistema se puede hacer en 30 formularios, y eso porque controla una cantidad de procesos que tiene que ver con barcos y bodegas. Que creen que sea mas facil y rápido, controlar 30 formularios o 220 ?