Un Programa Exitoso es un Programa Sencillo

A través del paso del tiempo los programadores tendemos a querer hacer cada vez más complejos los programas que escribimos. Puede ser porque busquemos usar algoritmos más complejos, o bien porque los estándares y soluciones “universales” de modelado exigen mayor cantidad de líneas en el mismo tiempo para lograr la misma funcionalidad. Si a esto le sumamos un sin fin de “arquitecturas y modelos” al parecer inventados para un futuro de ciencia ficción, siempre declarado en grandes conferencias de analistas que le dicen a la gente de negocio lo que quieren realmente escuchar: “si usas mi suite RumbaConcert integrada de análisis, modelado, diseño y construcción, el código automágicamente se generará y casi ni necesitarás programadores.”
Desgraciadamente estas mágicas suites provocan que existan programas más grandes y complejos que resuelven la misma problemática en pos de una aparente “ventaja de modelado”. Por lo consiguiente,
programadores con menos experiencia, producen menos funcionalidad en una tasa de líneas de código mucho mayor a la que programadores con experiencia y sin magia producirían.

Alguna vez alguien dijo: si sigo optimizando este código me quedaré con una línea de código y no me querrán pagar, mejor lo dejo como está. Algunos dirán que cada vez escriben menos líneas de código manualmente, gracias al uso de frameworks. Sin embargo dichos frameworks al final del día le suman al programa mucho más código del necesario y el resultado real es que el programa tardará mas en ejecutarse. Los ciclos de reloj parecen insignificantes pero no son gratuitos.

En el caso particular del modelado, con mucha tristeza, he presenciado que casi siempre que se introduce una “herramienta” para resolver el problema de cómo imaginar la estructura de un sistema,
confundimos la utilidad de un modelo como una herramienta de análisis para convertirlo en un intento de “generador” de código de un sistema. Si es que el modelado formal tiene alguna utilidad, no es otra que como una estrategia de comunicación de ideas al equipo de desarrollo. Buscar que un modelo sea en si una representación de un sistema es tan equivocado como aquel celebre dicho “el mapa no es el territorio”. El modelo de un sistema no se puede diseñar, el modelo “emerge” a partir de un ejercicio iterativo e incremental de construcción y pruebas.

En el otro lado de la moneda existen las complejidades agregadas a los programas, por considerar que el uso de patrones es la respuesta a la correcta programación para la solución de un problema, incluso a pesar de haber otras soluciones. En ese contexto, pareciera ser que mientras más patrones tenga un programa es mucho mejor. Debemos tener cuidado con que nos de uno de estos ataques de “patronitis” y rellenemos nuestra aplicación de patrones sin que hagan falta.

En el caso de Java, lenguaje con el que he trabajo los últimos años, encuentro que la programación es simple, a pesar de que se basa en componentes bastante complejos como el JVM y Garbage Collector. Sin embargo su utilización es transparente para nosotros y por lo tanto óptima; siempre que sigamos los lineamientos básicos de estilo, algoritmia y sentido común al momentod e programar. Las APIs de soporte en sí no son tan sencillas como las anteriores, pero precisamente es lo que le da la robustez a las aplicaciones generadas con ésta tecnología y permite a los programadores la especialización.

Por favor, la próxima vez que generen una sola línea de código, pregúntense: “¿mi programa sigue siendo lo suficientemente simple para resolver de forma adecuada el problema?” Si la respuesta es sí, continúen. En caso contrario, les pido que replanteen la solución de una forma más sencilla. Quizás les tome algunos minutos encontrar la solución, pero está justo ahí enfrente del teclado

Acerca del Autor
Emilio Osorio colabora actualmente como Consultor Asociado para Sun Microsystems México. Ha trabajado en desarrollos basados en Java desde 1996 y actualmente se dedica a ayudar a equipos de desarrollo a aprovechar las ventajas del Software Libre y los métodos ágiles en sus organizaciones.
Ferviente entusiasta de la aplicación social de la tecnología, a últimas fechas está involucrado con Organizaciones de la Sociedad Civil. Emilio estará encantado de recibir sus comentarios y quejas en oemilio@gmail.com

Jorge Vargas es un consultor Java desde el 2000, es uno de los Java Champion fundadores y promueve en su trabajo diario el uso del Software Libre y la utilizacion de los métodos ágiles.