¿Que es programar por coincidencia?

imagen_coincidencia

Una practica 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 linea 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 esta intentando leer un directorio que no existe?, ¡listo!, con unas lineas que agreguen el directorio si no existe es mas que suficiente. Pero, ¿alguna vez te has puesto a pensar si esto es benéfico para tus sistemas?. A esta practica de programar para resolver el error, sin analizar el que lo causa se le conoce como programar por coincidencia. A continuación te explico mas:

Cada linea de tu sistema es conocimiento adquirido.

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

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 lineas de código 3 capas mas abajo para reparar  el error en un método, entonces. Estas distribuyendo y multiplicando tus problemas en lugar de resolverlos. Eso sin contar que esas lineas 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 porque no funciona algo, mucho menos vas a saber porque 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 linea 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 a el mismo estado funcional. Vas a necesitar aprender que estados son los correctos y cuales 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 practica 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 practica no es mala, tampoco voy a satanizar. Como todos los recursos que tienes como programador es una herramienta mas del cinturón. Tiene consecuencias que se deben evaluar antes de usarla. Si se entiende y aceptan los riesgos a corto y largo plazo. Entonces, no tiene nada de malo en usarla 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. Solo 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