GoTo 2.0:

Hay algo de simple en lo complejo,
así como hay algo de complejo en lo simple.

La entrada de hoy va dedicada a un antiguo colaborador; gracias a él introduje este concepto en mi letanía al revisar los avances de mi equipo de trabajo.

Hoy nos centraremos en el principio KISS.

Kiss: acrónimo de Keep It Short and Simple.

Describir a lo que se refiere sería contradictorio al propio principio por lo que me limitaré a explicar por qué se hace bueno tener eso en mente al momento de construir un sistema de cómputo. A esto, la respuesta más simple es que las partes pequeña se controlan (y por lo mismo se mantienen y administran) mejor y más fácilmente que las partes grandes.

Esto debería ser simple;  sin embargo he notado que existe una curiosa dificultad por estructurar una solución compleja como la suma de pequeñas soluciones sencillas y más pequeñas. Y muchas veces esto puede deberse a falta de experiencia, a falta de visión,  de análisis, de abstracción o quizá sólo de experiencia, y por lo mismo se termina con una construcción mucho más compleja de lo que el problema realmente amerita.

Seamos honestos: como programadores muchas veces comenzamos a visualizar el código desde que se hace el primer planteamiento del problema y nos ganan las ansias de empezar a escribir lineas de ciclos y condiciones sin antes siquiera tener una visión completa del problema... Esta naturaleza nuestra es el peor enemigo y obstaculiza el análisis.

Sin más preámbulo, tomemos de ejemplo un fragmento de código con el que me tropecé hoy. El objetivo: detectar si entre un rango de fechas se encuentra o no un 29 de febrero. Estas fechas pueden pertenecer o no al mismo año, por lo que el problema se podría complicar... Un problema de este tipo podría resolverse de diferentes y muy variadas formas. Así pues, luego de haber superado el trauma de reescribir dicho fragmento de código -que además no cubría todos los casos por lo que generaba resultados erróneos- me dediqué a censar entre algunos colaboradores de qué manera lo habrían resuelto. 

A continuación describiré algunas de las opciones de tan entretenido problema, que al igual que los acertijos, siempre son divertidos y simples cuando ya tienes al menos una respuesta.

• Versión 1 (la que se tuvo que corregir)
1. identificar si la fecha de inicio es menor al primero de marzo
2. en caso afirmativo verificar si el año de inicio es bisiesto
3. verificar si el año de la fecha final es diferente al año de la fecha de inicio
4. en caso afirmativo verificar si la fecha final es mayor al primero de marzo
5. en caso afirmativo, verificar si el año de la fecha final es bisiesto
6. si el año de inicio es mayor al primero de marzo y el año de la fecha de fin es mayor al año de la fecha de inicio recorrer desde la fecha de inicio hasta la fecha final
7. para cada fecha entre el inicio y el final, si el mes es febrero y el primer día de marzo del año en curso menos un día es día 29 entonces sí hay una fecha 29 de febrero.
8. La rutina para verificar si el año es bisiesto valida si el año es divisible entre 4 excepto si es divisible entre 100 pero no entre 400 (y este es otro tema del mismo debate)
• Versión 2 (que definitivamente tampoco funciona)
1. verificar si el año de inicio es bisiesto
2. verificar si el año final es bisiesto
3. si la fecha de inicio es menor al primero de marzo y el año de inicio es bisiesto o si la fecha final es mayor al primero de marzo y el año final es bisiesto entonces hay sí hay un 29 de febrero.
• Versión 3 (Variación del anterior pero más enrevesada)
1. recorrer cada año desde el año de inicio y el año final
2. verificar si el año en curso es bisiesto
3. si la fecha de inicio ajustada al año en curso es menor al primero de marzo y el año es bisiesto y la fecha final es mayor al primero de marzo del año en curso entonces sí hay un año bisiesto
4. si la fecha de inicio ajustada al año en curso es mayor al primero de marzo y el año es bisiesto y el año de la fecha final es mayor al año de la fecha de inicio y el año de la fecha final es bisiesto entonces sí hay un un 29 de febrero .
5. en cualquier otro caso no hay un 29 de febrero.

Podría continuar listando al menos otras 3 versiones distintas de esta implementación, pero nos desviaríamos del tema central.

Existe una gran contradicción a este principio y es justamente esto lo que nos convierte en buenos o malos programadores: Resulta demasiado complejo proponer una implementación simple.

La real complejidad de este principio radica en la habilidad de visualizar todas las partes del problema y ponerlas juntas, por lo que haré hincapié en la importancia de lo que ya algunos siglos atrás nos enseño el buen Napoleón: ¡Divide y vencerás!

Al final, sólo se trata de práctica; de no quedarte contento con haber encontrado una solución, sino de insistir en  mejorarla, en optimizarla hasta estar seguro de que no puede ser mejor; y con esto me refiero a la elegancia del código, a la claridad con que se escribe, a la simpleza de su estructura, y más importante aún: a la eficiencia de cómputo.

Para terminar, sólo quiero agregar que la versión implementada se puede ver en un elegante y claro ciclo escrito en no más de 6 líneas de código con las condiciones de parada necesarias y suficientes para no procesar de más. ¡Ah! también hay que mencionar que mi acepción favorita del acrónimo de este principio  es -sobre todo cuando es en alguna revisión-: Keep It Simple, Stupid!

Happy Codings!