gravatar

Cómo mejorar la calidad de sus programas - Parte 1



La mayoría del software actual se parece mucho a una pirámide egipcia conformada por millones de piedras apiladas sin integridad estructural, hecha gracias a la fuerza bruta y a miles de esclavos.

Alan Kay


El lenguaje BASIC (Beginners All Purpose Symbolic Instruction Code) se desarrolló originalmente en 1964 como una herramienta de enseñanza (para principiantes como indica su nombre) que permitiera reducir la complejidad de los lenguajes existentes en esa época y así facilitarles a los estudiantes el aprendizaje de los fundamentos de la programación. Paralelamente, gracias a la constante disminución de su costo de adquisición, comenzó un proceso de introducción de la computadora en las pequeñas empresas y en los hogares, lo que permitió la popularización del lenguaje BASIC, ya que las microcomputadoras de la época generalmente incluían un intérprete BASIC en su memoria ROM.

Con este nuevo lenguaje, que prescindía de ciertas características existentes en lenguajes destinados a programadores profesionales, muchos estudiantes y entusiastas hicieron sus primeras experiencias en el ámbito de la programación y ésta es, básicamente, la razón por la que durante mucho tiempo se consideró que BASIC era un lenguaje no apto para el desarrollo profesional, de hobby o de bajas prestaciones.

Al igual que muchos lenguajes de la época que respondían al paradigma de programación imperativa, BASIC posibilitaba el control del flujo de los programas a través de la sentencia GOTO. El problema con esta sentencia es que permitía derivar el flujo de los programas de forma incondicional, lo que frecuentemente conducía a producir código difícil de comprender (hasta el punto de ser inmanejable) y, en consecuencia, a gran cantidad de errores en la lógica de los programas (y el consabido esfuerzo para corregirlos). Además, y por la misma razón, era bastante frecuente que el mantenimiento de los programas fuera una tarea realmente difícil.

No fue sino hasta la formalización del método de programación estructurada que el problema comenzó a solucionarse en el ámbito profesional. Pero muchos de los usuarios de BASIC no eran programadores profesionales, por lo que el código desestructurado continuó durante mucho tiempo presente en los programas desarrollados con distintos dialectos de BASIC.

El término “código espagueti” se acuñó para designar a los programas que abusaban del uso de la sentencia GOTO o la usaban de forma incorrecta, debido a que sus diagramas de flujo mostraban una maraña de saltos que fácilmente hacían recordar a un plato de espagueti.

La introducción de estructuras de control y la “filosofía” de la programación modular (particularmente gracias al impulso que le infundió el célebre científico computacional Edsger Dijkstra) significó un cambio paradigmático en la forma de desarrollar software que permitía solventar parcialmente los problemas antes mencionados. No obstante, debido a que su uso fue opcional, en la mayoría de los lenguajes esta clase de problemas persistieron durante mucho tiempo.

Muchos de los dialectos actuales de BASIC, los lenguajes que de él se derivan o los que comparten con él ciertas características (parte de su sintaxis, por lo general) poco tienen que ver con el BASIC original. Varias de las implementaciones actuales tienen un amplio rango de características que se asemejan mucho a las de cualquier otro lenguaje imperativo. En particular, Gambas dispone de una gran variedad de características que lo convierten en una herramienta de programación apta para el desarrollo de diversos tipos de software para la plataforma GNU/Linux y otros derivados de UNIX.

Por otra parte, el uso de la sentencia GOTO casi ha desaparecido, por lo que la mayoría de aquellas objeciones ya no son válidas respecto de los dialectos actuales del lenguaje BASIC. Sin embargo, el mal uso de las características esenciales de un lenguaje de programación aún hace posible escribir código espagueti y Gambas no es la excepción.

En efecto, aún es posible escribir código espagueti sin importar qué paradigma de programación se utilice, qué lenguaje o qué herramientas. Es muy difícil que una herramienta, del tipo que sea, se diseñe de una forma restrictiva para evitar malos usos porque, frecuentemente, ello significaría hacerla inflexible y así dificultar en gran medida su uso correcto.

El paradigma de programación a objetos no es ajeno a estos problemas. No es difícil encontrar programas supuestamente orientados a objetos cuyo código evidencia la carencia de conocimientos o lagunas en la formación de sus programadores y que hacen que ese programa probablemente contenga muchos errores, su código sea difícil de comprender y su mantenimiento un desafío absurdo.

Escribir programas nunca ha sido algo sencillo: si alguien le dice que programar es fácil, probablemente querrá venderle algo. De hecho, la historia de la programación de computadoras da cuenta de una gran crisis del software que tuvo su punto álgido en los años sesenta y como respuesta a estos problemas se promovieron herramientas como la programación estructurada y la ingeniería del software.

La gran crisis del software se evidenció a partir de problemas como el alto incumplimiento en los plazos de entrega, programas con altas tasas de errores o grandes excesos en los costos de desarrollo, altas tasas de proyectos cancelados y programas que no solucionaban la totalidad de los problemas para los que fueron escritos.

Parafraseando a Edsger Dijkstra (The Humble Programmer), a medida que las computadoras se hicieron más y más potentes, se comenzaron a usar para resolver problemas cada vez más complejos. Esto resulta paradójico, ya que mientras la potencia de cálculo de las computadoras ha aumentado en menos de 50 años varios órdenes de magnitud, permitiendo resolver problemas mucho más complejos, las capacidades cognitivas del ser humano para abordar esos problemas siguen siendo las mismas.

Además, esos problemas más complejos muchas veces se intentaron resolver usando las mismas herramientas y técnicas de programación que antes se usaron para resolver problemas que eran mucho más simples. En consecuencia la forma de mejorar la situación sería difundir una correcta concepción sobre cuál es la naturaleza de las dificultades para desarrollar software, la alta profesionalización de los programadores, la creación de lenguajes y herramientas de mayor nivel de abstracción, y (para algunos) la formalización de métodos.

Pero el beneficio que se puede lograr mejorando esos aspectos son marginales al decir de Frederick Brooks (The Mythical Man/Month: Essays on Software Engineering) ya que ataca el problema de la complejidad accidental. El problema radica en la complejidad esencial o intrínseca del desarrollo de software, es decir, de los problemas cada vez más complejos que se desean resolver mediante un programa de computadora.

Esto implica que en el desarrollo de software no es posible de ninguna manera emular el crecimiento exponencial que experimenta la potencia del hardware y la correlativa disminución de sus costes. Para Brooks "no hay balas de plata" que permitan "matar al monstruo" de la complejidad esencial en el desarrollo de software, algo que parece haber sido comprobado en innumerable cantidad de proyectos.

El problema reside en la diferencia de magnitud entre la complejidad de los problemas a resolver (la complejidad esencial) y la limitada capacidad cognitiva de los seres humanos. Es por ello que hoy en día para desarrollar un programa de complejidad media se necesita un equipo de desarrollo de varios programadores (entre cinco y diez para dar una aproximación subjetiva) trabajando durante varios meses (aproximadamente diez, otra estimación tan subjetiva como la anterior).

Sin embargo, esto no significa que dentro de veinte, treinta o cincuenta años la situación continúe siendo la misma. Posiblemente el problema de la complejidad esencial se pueda atacar mejorando las capacidades cognitivas de las personas y ello no implica necesariamente pensar en aspectos típicos de la ciencia ficción. Las soluciones pueden provenir de avances en pedagogía y psicología cognitiva (en comprender con mayor profundidad cómo es que las personas aprenden) y su correlato en la didáctica (nuevos métodos de lectura, aprendizaje, análisis de problemas, fomento de la creatividad, etc.) o de otras áreas que hoy ni siquiera somos capaces de imaginar.

La ganancia en productividad que se puede lograr al usar un lenguaje de mayor nivel de abstracción, una metodología de desarrollo adecuada y otras herramientas de apoyo, no suele ser despreciable, aunque ciertamente es marginal si se piensa en la productividad que se podría alcanzar si fuera posible atacar la complejidad esencial.

No obstante, la tecnología de objetos ataca precisamente a la complejidad esencial en el desarrollo de software, siempre que se la entienda como un paradigma que promueve una nueva forma de desarrollar software: de pensarlo, de analizarlo, de diseñarlo, de corregirlo y de mantenerlo.

A veces se entiende la POO como un conjunto de técnicas de programación basadas en la indirección que se apoya en "mecanismos" de abstracción de un lenguaje de programación, pero esta noción es extremadamente reduccionista. Podríamos decir que la orientación a objetos no es sólo programación, sino también análisis y diseño AOO + DOO + POO, pero probablemente caeríamos en la misma trampa. La tecnología de objetos también es pensamiento orientado a objetos OOT e incluso una nueva cultura disciplinar que debe ser adoptada por los desarrolladores.

La manera en que la tecnología de objetos ataca la complejidad esencial reside fundamentalmente en la posibilidad de modelar el mundo (el problema a resolver) en sus propios términos y de trasformar de forma directa ese modelo en un programa ejecutable.

Pero más importante que discernir si la tecnología de objetos responde a los cuestionamientos de Brook, es comprender que constituye un avance extremadamente importante respecto de la calidad del software que es posible obtener y de la productividad que es posible alcanzar.

La productividad en el desarrollo de software es algo que debe importar a todo nivel. Aún cuando el lector sea un programador aficionado que dedica parte de su tiempo libre a la creación de algún programa, es seguro que desea hacerlo del mejor modo posible y al menor costo, es decir, insumiendo la menor cantidad de ese tiempo en la programación, para invertirlo en cosas más vitales como brindarle más tiempo a su propia familia.

Pero probablemente es más importante conocer cómo desarrollar software de alta calidad: tener la seguridad y la confianza de ser capaces de escribir programas que cumplan sus cometidos.

Este cómo se centra en enseñar conceptos y técnicas de probada eficacia que le permitirán mejorar la calidad de los programas y a la vez su productividad como programador.


Los comentarios están habilitados para que los lectores puedan participar en la corrección del libro, realizar preguntas puntuales o sugerencias. Todo comentario fuera de estos objetivos será eliminado. Por favor, tenga en cuenta lo siguiente:

- Cumpla las normas de etiqueta.

- Realice críticas constructivas.

- No sea redundante.