Como evitar errores futuros al programar en Excel

Te gusta programar con calidad, sin errores, te gusta hacer la vida fácil al usuario, y aún así tienes problemas, porque siempre ocurre el error y dicen que es tu culpa.  ¿Qué hacer para cerrar portillos?  Es que aunque tu trabajo es excelente, y buscas la eficiencia absoluta, ocurren los errores y los problemas por vías que no suelen ser intuitivas.  Hablemos que cómo evitar esos errores.

Cuando piensas en errores, generalmente piensas en atrapar las conductas que puedan hacer que tu software se caiga en desastre, y eliges atrapar errores sin que se caiga el programa.  Pero quieres ir más allá, y tratas de hacer programación de manera que el mantenimiento se facilite, y haces que los cambios sean fácilmente configurables, y tratas de acortar tiempos de desarrollo, y en lugar de menos errores, tienes más errores.  ¿Qué está ocurriendo?

• Programador: Normalmente cuando diseñas software, como programador tratas de que no haya errores dentro del software, y esa es tu relación personal con el código, que sale sin errores.  Esa parte parece ir bien, y crees que por ello todo va bien. Cumpliste con requerimientos del usuario, sin errores, y crees que por ello todo va bien.  Pero siempre habrá cosas que pueden ir mal, como cuando cierras sesiones de SAP y el Excel se cae al desktop sin que puedas hacer nada, o cuando debes crear truculencias para acceder a ventanas de Windows abiertas por SAP, donde la intervención del usuario puede botar tu programa. Es un fastidio trabajar con SAP en Excel.
• Usuarios: Por cada software a prueba de usuarios hay un usuario a prueba de software.  Normalmente piensas en atrapar todas las bobadas de los usuarios para evitar una situación embarazosa donde te echan la culpa del fallo.  Las comprobaciones deben ir desde la verificación de los datos de entrada, tanto en tipo de información, rangos de valores, como en consistencia, hasta operaciones de diagnóstico del sistema del usuario para ver si tiene algo mal configurado que impide la ejecución en un momento dado.  Uno de los problemas más comunes es cuando lees fechas y no están en formato MM/DD/YYY (formato americano) y cuando no se usa el punto para indicar decimales.  Puede haber otros problemas como caida o falta de accesos a un sharepoint (si tu macro hace uso de alguno), o problemas de red.  A veces encontrarás que hay características de Excel, como cuando se usa un "Name" para desplegar fotos en otro libro de Excel abierto, y eso interrumpe la ejecución de tu programa que se ejecuta al abrir el libro de Excel.  No parecen cosas relacionadas, pero ocurren. Nada intuitivo, culpa de Excel.
• Salidas: Validas que las salidas sean las que el cliente requiere, de la manera en que lo requiere.  Que le quites esto, que le agregues aquello, que los cálculos reflejen lo que el cliente entiende, para que no haya números malos.  Allí encontrarás toda clase de problemas con Excel, porque si metes fórmulas en una celda sencilla de Excel, no da el mismo resultado que si tratas de meter la misma fórmula dentro de una celda dentro de una tabla de Excel.  Excel no te va a hacer la vida fácil.
• Mantenimiento: Cuando empiezas a crear código genérico y reutilizable aceleras mucho los desarrollos, especialmente si tratas de mantener compatibilidad hacia atrás, de modo que al meter una versión más actualizada de tu librería de código no va a hacer diferencia al reemplazar la librería vieja de código.  Lo que hiciste fue crear una capa de abstracción para reducir la cantidad de código en el programa principal.  Además hiciste que el código se adapte a cambios en datos de entrada, como cambios de columnas en los reportes que lee, reconocer la presencia o no del reporte que debe leer, o errores por cambios efectuados en un sharepoint.  Y además tratas de que el usuario a cargo del mantenimiento pueda configurar el software para que no te estén llamando para hacer pequeños cambios. Pero este usuario será igual a todos los demás.  Se va a equivocar, y debes asumir que es el usuario más incompetente de todos, que va a configurar mal, y esto te puede traer muchos dolores de cabeza.

Normalmente los grandes costos de mantenimiento vienen cuando ocurre el mantenimiento.  El costo es de tiempo.  Tener código genérico en una librería te ayuda a que en lugar de escribir montones de código, solo debas hacer un llamado a un proceso al que le pasas parámetros.  

Por ejemplo, si vas a leer varias listas de sharepoint, puedes escribir el código cada vez que accedes al sharepoint para leer o grabar, o puedes escribir código genérico al que le dices cual sharepooint, y lo que hay que hacer.  

De esta manera se acorta el código del programa principal.  Ese código genérico tiene la ventaja de que se convierte en un solo punto de falla, y al acortar el programa principal, es más fácil revisarlo.  Eso sí, la fiabilidad del código genérico debe ser total, sin fallas.

Sin embargo siempre hay cambios imprevistos, de modo que tratas de hacer que el usuario pueda configurar esos cambios por sí msmo.  

Entonces en lugar de leer un reporte de Excel, que lea un sharepoint.  O en lugar de un cierto encabezado de columna, ahora hay otro.  O en el reporte que ingresa para ser leido por el programa, se agregó una columna y todo el contenido se ha movido de columna, o le han agregado un encabezado y los datos ahora empiezan en otra fila.  Todos esos cambios es mejor que el usuario los defina.  

Puede haber toda clase de cambios que se te ocurra, que serán efectuados por un usuario.

Acostumbrado a ser tu el que realiza los cambios, piensas en simplificar la configuración, creyendo que el usuario no cometerá errores porque la configuración es simple, y es solo un usuario el que configura, y así como tu no cometes errores al hacer mantenimiento, crees que ese usuario no los cometerá.  Ese es un gran error de tu parte.  Debes imaginar que el usuario que va a configurar va a ser el peor de todos.

Lo que pasa con los sistemas altamente automatizados es que el operador se vuelve menos competente.  Mientras más simple hagas la tarea, el nivel de alerta del usuario se reduce, lo que obliga a más automatización, o en este caso, validación de los errores de configuración del usuario que configura los cambios en el proceso de mantenimiento.  A como ese usuario se equivoque, y todo deje de funcionar o funcione mal, dirán que el software no sirve, o que hiciste mal el trabajo.  

Entonces, al trabajo de agregar esa capa de automatización para acortar la programación, y la capa de automatización para responder de manera flexible ante cambios, facilitando la reconfiguración, debes agregar la validación de la configuración que el usuario ingresa, encontrar todos los errores antes de que funcione mal.  En el diagrama que se muestra arriba, debes poner filtros para atrapar los errores donde se muestra las flechas rojas.

Aún así, entre bugs de SAP o de Microsoft o de cualquier otro software que uses para hacer tus programas, encuentras que Microsoft es un buen sistema para uso casero, pero en ocasiones no sirve para uso corporativo.  Y si quisiste moverte a .NET para automatizar Excel desde allí, vas a encontrar que si tratas de crear código reutilizable, y el código que maneja un libro se separa en distintos procedimientos, tendrás un error al insertar valores en celdas, pues te pedira que metas valores enteros solamente, nada de fórmulas ni texto.  

Y si quisiste usar Power BI desktop para automatizar tus dashboards, que se ven más bonitos, vas a tener que revisar que los datos que el programa subió no contengan basura, cada vez que publicas, porque ya me ha tocado ver que al publicar se actualizan unos dashboards y otros no.  Y de vez en cuando encontrarás errores que no estaban y que aparecen un día de repente, haciendo que algo que funcionaba no funcione, y a los pocos días desaparecen con una actualización.

Y con SAP generas un reporte, y a la hora de salvarlo aparecen menos líneas de las que aparecen en la pantalla.  O tienes aquella ventana de Windows lanzada por SAP a la que sólo puedes acceder con la API de Windows y mandar teclazos por medio de código, y mientras efectúas la tarea, si el usuario está haciendo otra cosa, el proceso te deja de servir por la interferencia del usuario.  Estos problemas que parecen pequeños, significan horas o días de reescribir código para adaptarte a la mala conducta de SAP.

 Y no tienes cómo explicarle eso a los usuarios y clientes.  Para ellos, el error es tuyo.

Microsoft es bueno para uso casero.  Para uso empresarial puede servir, si no te importa la implementación casera y los errores ocasionales o permanentes que vienen de la compañía por añadidura.  Y con SAP es lo mismo, ingeniería alemana con implementación casera.

De esta manera te ahorrarás muchos disgustos y problemas que yo ya he sufrido al programar con Microsoft y SAP y usuarios que hacen mantenimiento.  Que lo que yo he sufrido, te sirva a tí para no sufrir.  Y pasa el balón, para que lo que tu sufras no lo sufran otros.