Читать книгу Computación y programación funcional - Camilo Chacón Sartori - Страница 22

La especificación tiene como objetivo «pensar antes de programar». Esto hace hincapié en que, si no se piensa ni se analiza en detalle el problema X a solucionar, solo nos estamos embarcando en una lucha para entender una tecnología Y sin comprender el problema X. La importancia del qué sobre el cómo. Esto forma fanáticos de la herramienta, no así de resolver problemas.

Pensar, en primer lugar, en la tecnología a usar, agrega varias capas de dificultad para comprender el problema, ya que un lenguaje de programación trae consigo muchas cuestiones que no tienen nada que ver con la solución a un problema en sí, por ejemplo: cómo tratar con la memoria, la elección del tipo de datos o estructuras de datos, la refactorización, elegir correctamente el nombre de las variables, etc. Algunas de ellas, obviamente, son valiosas si queremos construir software de calidad y sostenible en el tiempo, pero no atacan al problema en cuestión. Todas esas cosas son parte de la implementación. En cambio, pensar en qué solucionar, de manera adecuada, lógicamente, es la labor de la etapa —olvidada y omitida— de especificación.

Debemos pensar antes de programar. Para esto se puede hacer uso de diferentes técnicas, algunas ya presentadas, como la verificación formal. O, en otros casos, podemos simplemente definir la solución a nuestro problema haciendo una demostración matemática que indique su comportamiento para cada argumento de entrada junto a su salida.

Leslie Lamport comenzaba diciendo su provocador artículo «If You’re Not Writing a Program, Don’t Use a Programming Language» («Si no estás escribiendo un programa, no uses un lenguaje de programación») lo siguiente:

He trabajado con varios ingenieros informáticos, tanto de hardware como de software, y he visto lo que sabían y lo que no. He descubierto que la mayoría de ellos no entienden algunos importantes conceptos básicos. Estos conceptos son oscurecidos por los lenguajes de programación. […] Consideraré los algoritmos, no los programas. Es inútil tratar de distinguir con precisión entre ellos, pero todos tenemos la idea general de que un algoritmo es una abstracción de nivel superior que es implementada por un programa. (Lamport, 2018)

Lamport se da cuenta de una falencia en la era actual del desarrollo de software, y es que la mayoría de los informáticos piensan en programas (una implementación) y no en algoritmos (una abstracción de nivel superior, es decir, especificación). Esto, él mismo lo atribuiría a una débil formación en matemáticas en comparación con otras carreras del ámbito de las ciencias.

Aunque nosotros agregaríamos un factor más a esta ecuación: el tiempo. Porque en la actualidad la cantidad de desarrollo de software ha crecido en una magnitud tal que hace casi imposible dar respuesta a cada nuevo proyecto que se comienza; es por esto que siempre se dice que faltan desarrolladores de software para una demanda que crece cada día. Cuando se necesita desarrollar más software en menos tiempo, la calidad se ve afectada y, era de suponer, la especificación tiende a verse más como un enemigo en contra del tiempo en busca de un objetivo que como una fase que asegura la calidad de lo que hacemos.

En la actualidad, la industria de software se mantiene embarcada solo en la verificación dinámica, o sea, en las pruebas unitarias o cualquier otro tipo de prueba a posteriori. Se crean departamentos de QA («Quality Assurance» en inglés [«Aseguramiento de la calidad»]) y a algunos programadores y programadoras ya ni les interesa realizar pruebas de lo que hacen, más bien, prefieren terminar rápido en lugar de terminarlo bien. Esto viene provocado por su falta de rigor y por la variable tiempo.

Debemos volver a los fundamentos, no igual que antes, ya que la industria ha evolucionado, pero sí con un enfoque renovado que no omita la teoría en desmedro de la calidad. En desmedro de, por así decirlo, nosotros mismos.