La abstracción correcta

En programación nos enfocamos mucho en la correcta abstracción, estructura de datos, algoritmo o patrón de diseño. Pensamos mucho sobre la API o la interfaz, el contrato con nuestro usuario, pero ¿acaso pensamos en el contrato con negocio, con nuestro programa y el stack técnico?

Estamos dando a los usuarios varias capacidades visuales o programáticas para poder interactuar con nuestro programa y datos, nuestra abstracción del negocio. Estos datos que nos da el usuario tienen que guardarse en algún sitio, ya sea usando un caché, base de datos, en memoria o en un fichero. Las herramientas que utilizamos para guardar los datos nos dan una interfaz para interactuar de manera simple con su abstracción de lectura o escritura en disco, que al mismo tiempo son abstracciones de giros (en caso de discos duros de toda la vida) o de unos y ceros (SSDs); todo son datos hasta el final.

No hay manera simple de crear la correcta estructura, objeto o clase, mucho menos las funciones que deberíamos exponer para interactuar con ellos, pero somos los que trabajamos con el código en el que esta solución debería vivir; somos nosotros los que deberíamos crear estas abstracciones. Quizás estamos lidiando con código existente o legacy y tenemos que trabajar alrededor de lo que ya existe, o tenemos que sacar esa funcionalidad que el negocio tanto necesita (o cree que necesita); muchas veces no podemos enfocarnos en lo que realmente importa: datos.

Muchas veces, si tenemos una buena representación de los datos con los que el negocio trabaja, los problemas y funcionalidades se vuelven mucho más fáciles de encontrar una solución y más fáciles de mantener. La deuda técnica puede ocurrir por hacer las cosas rápido o no pensar dos veces sobre la solución a la que hemos llegado y si hay una mejor manera. También puede ocurrir porque el negocio evoluciona y sus necesidades cambian. Las soluciones dependen del espacio y el tiempo. Lo que una vez fue bueno, quizás ya no lo sea, y está bien. El código debería vivir como las soluciones, evolucionando y cambiando, pensando qué es lo mejor para el negocio y para el producto, pero llega un momento en que debemos parar y preguntarnos si estamos creando código desfasado y si deberíamos refactorizar, o como me gusta llamarlos a mí, mi mujer: refactores (por su nombre en inglés refactor). Los refactores existen por un motivo y deberíamos utilizarlos de vez en cuando. A veces, si pasamos un poco de tiempo pensando en el todo, podríamos conseguir que estas refactorizaciones no sean tan caras ni que nuevas funcionalidades tomen mucho más tiempo del que deberían.

No soy bueno en esto ni en programación en general. La programación es una artesanía que debemos practicar y cuidar más. No es solo nuestra habilidad la que mejora, es nuestra manera de pensar en los problemas y en las soluciones; la programación es solo resolución de problemas en papel digital. La próxima vez que intentes resolver algo, pregúntate a ti mismo: ¿es esta la abstracción correcta?

En programacion nos enfocamos mucho en la correcta abstraccion, estructura de datos, algoritmo o patron de disenyo. Pensamos mucho sobre la API o la interfaz, el contrato con nuestro usuario, pero acaso pensamos en el contrato con negocio, con nuestro programa y el stack tecnico?