¿Que es programar por coincidencia?

Una práctica muy común en el rubro de la programación es intentar resolver problemas inmediatamente, sin un análisis. Se ejecuta el debugger, o se leen los logs e inmediatamente después se busca la línea problemática, algunos pases mágicos y por arte de magia se resuelve el problema. ¿Hay un objeto nulo en medio de mi método?, con un if se arregla el problema. ¿Se está intentando leer un directorio que no existe?, ¡listo!, con unas líneas que agreguen el directorio si no existe es más que suficiente. Pero, ¿alguna vez te has puesto a pensar si esto es benéfico para tus sistemas?. A esta práctica de programar para resolver el error, sin analizar el que lo causa, se le conoce como programar por coincidencia. A continuación te explico más:

Cada línea de tu sistema es conocimiento adquirido.

Todas las líneas de código de tus sistemas representan conocimiento adquirido acerca de como funciona o debe funcionar la empresa. Es importante conocer el cómo funciona cada unidad, y es más importante entender como funciona el conjunto. En sistemas grandes o muy viejos por los cuales ya han pasado muchos programadores, este conocimiento se ha perdido.  Esto es un síntoma de decadencia en los programas, pero también es un síntoma de decadencia en las prácticas como programadores. Si el entender el conjunto del sistema está representando un gran esfuerzo mental. Significa que el diseño y la arquitectura del sistema no está logrando su objetivo. Hay que hacer cambios, tanto en el código como en las prácticas.

La importancia del contexto a la hora de codificar.

Solucionar un problema fuera del contexto es una actividad peligrosa. Tus sistemas deben de agrupar preocupaciones y responsabilidades. Si debes de aplicar algunas líneas de código 3 capas más abajo para reparar  el error en un método, entonces. Estás distribuyendo y multiplicando tus problemas en lugar de resolverlos. Eso sin contar que esas líneas adicionales pueden tener un efecto no deseado en todo el sistema. La programación por coincidencia suele venir acompañada de pocas o nulas pruebas de regresión. Cada problema debe resolverse en el contexto que se ocasiona el error, solo casos verdaderamente excepcionales, se cuentan con los dedos de tu mano, deberían resolverse en contextos externos.

Si no sabes por qué no funciona algo, mucho menos vas a saber por qué funciona. Aprende antes de modificar tu código.

Modificar sistemas complejos debe de ser una labor quirúrgica. Debes tener ciertas preparaciones antes de tocar una sola línea de código. No basta con reparar el bug. Tienes que  asegurarte de que dejas el código como lo encontraste. Y por esto me refiero al mismo estado funcional. Vas a necesitar aprender que estados son los correctos y cuáles los incorrectos. Es muy seductor el reparar un problema evidente. Una reparación rápida de un caso que te reportaron, puede ocasionar graves problemas productivos si no tienes  claro como debía de funcionar esa pieza de código inicialmente. Y te recuerdo, que en el momento que modificas un componente, es práctica habitual volverte el responsable directo. Las pruebas unitarias y de regresión son tus mejores aliadas para estos casos. Si careces de ellas consigue un buen set de casos de pruebas que puedas usar para validar tu cambio.

A veces hay que programar por coincidencia.

No siempre podrás hacer las cosas bien. Es posible que tengas recursos limitados, o poco tiempo, posiblemente no controles todos los componentes del sistema. Esta práctica no es mala, tampoco voy a satanizar. Como todos los recursos que tienes como programador es una herramienta más del cinturón. Tiene consecuencias que se deben evaluar antes de emplearla. Si se entiende y aceptan los riesgos a corto y largo plazo. Entonces, no tiene nada de malo en emplearla, solo debes recordar algo.

Conclusiones. Programar por coincidencia no servirá para dejar algo por terminado. Es una solución temporal.

Si te ves obligado a programar por coincidencia, aun cuando hayas solucionado el problema. Esto no quiere decir que se debe dar por terminado el asunto. Solamente has comprado tiempo, debes de seguir con la investigación, codificar pruebas. Si aun buscando en todos los rincones de tu proyecto no logras encontrar el causante. Deja documentado el caso para que el próximo en encontrar el problema no vuelva a descubrir la rueda.

 

Autor imagen: William Brawley

 

 

Gustavo Sánchez
Últimas entradas de Gustavo Sánchez (ver todo)

Soy especialista en escribir software de calidad. Mediante el uso de marcos de trabajo, técnicas y automatización de procesos he podido reducir los costes operativos de los sistemas de la empresa. Sistemas confiables y adaptables producen clientes felices.

2 comments On ¿Que es programar por coincidencia?

Comments are closed.