¿"Ingeniería" del software?

El mayor reto de ingeniería del software nunca ha sido la IA. Siempre se ha tratado de convertir un "desarrollo artesano", en un proceso de ingeniería similar a la construcción, a la mecánica, o cualquier otra. Y si se quiere obtener esto, necesitamos exactamente aquello en lo que nadie está invirtiendo esfuerzo: estandarización. Porque inevitablemente, si quisiéramos apuntar a un proceso de ingeniería, necesitaríamos de algún proceso de montaje o composición de piezas. Y esas piezas son precisamente lo que no tenemos.

El primer proceso de ingeniería del software era el top-down, o también llamado "divide y vencerás", de manera que el algoritmo se divide en procedimientos y funciones. Se presentan dos problemas: el primero, que nadie coincide en qué procedimientos utilizar, y el segundo, que las aplicaciones, al margen de que la construcción de software, siguieron requiriendo más funcionalidad, haciéndose más y más complejas.

El siguiente hito fue el de los módulos. Los módulos serían colecciones de funciones y procedimientos, agrupando funcionalidad común (recordemos, alta cohesión, y bajo acoplamiento). Por ejemplo, en nuestra aplicación podemos crear módulos matemáticos, otros de interfaz de usuario, otro de creación de logs... Y lo mejor es que, para futuros proyectos, podemos reutilizar estos módulos.

No es que el proceso de divide y vencerás debiera eliminarse, sino que tenemos agrupamientos de más alto nivel que son los propios módulos.

Pero la cosa no cuajó: el problema es que cada uno tenía una idea distinta sobre qué módulos crear, y si estos debieran ser de alto nivel o bajo nivel... ¿los de alto nivel deben componerse a partir de aquellos de alto nivel? Con el tiempo, se crearon repositorios de módulos, pero difícilmente se extendió una reutilización de estos módulos.

Y además, volvemos a la problemática anterior: independientemente de que el proceso de ingeniería de software estuviese maduro o no, las aplicaciones seguían subiendo en cuanto a funcionalidad y complejidad.

El siguiente hito fue la POO (programación orientada a objetos). Los módulos se transforman así en clases, que aúnan no solo procedimientos y funciones, sino también los propios datos. La encapsulación inherente del paradigma iba a resolver automáticamente el problema de la cohesión y acoplamiento. Se podrían tener repositorios de clases que podrían reutilizarse para cada funcionalidad.

Sin entrar en detalles, la POO no fue la panacea que se esperaba. Los problemas seguían siendo los mismos: al final, cada programador tenía una idea distinta de qué clases debían componer la aplicación, del nivel de abstracción necesario, y sí, las aplicaciones siguen evolucionando en cuanto a funcionalidad y complejidad.

Y sorprendentemente, se descubrió que la POO no evitaba automáticamente, como se esperaba, que no hubiera acoplamiento entre clases, o que las clases fueran piezas genéricas que podrán transportarse de un proyecto a otro. De nuevo, la reusabilidad emergió como un problema, sin que la POO pudiera evitarlo. No, tampoco aparecieron los repositorios de clases. Aparecieron principios de programación como los SOLID, o los patrones de diseño, que tratan de guiar al programador para intentar mitigar estos problemas.

Finalmente, estamos en el hito de la programación ágil. Se asume que el desarrollo del software es un proceso artesano, y lo que se intenta es delimitar y controlar para que no "se vaya de madre". Pero, ¿hemos alcanzado algún hito de reutilización? No en mi opinión.

Ahora que hemos repasado (muy por encima), la evolución del desarrollo práctico de software, ahondaremos en próximas entradas sobre si los desarrolladores de software tienen este problema interiorizado y están haciendo algo o no.