(continúa)
El oficio del informático, así podría dividirse en dos clases: como aquellos que se limitan a ser escribas de léxicos tan exóticos como híbridos del inglés y otros, los menos, que no sólo son escribas: tratan de aprehender lo que están haciendo. Esto se debe, en gran medida , a una de las más graves vicisitudes del transcribir un software: el tiempo. Los que sabemos como se hace un programa y los pasos a seguir, en la práctica muchas veces desdeñamos la importancia de un análisis somero sobre el problema a tratar, debido a que los problemas que se plantean en el ambiente universitario son muy distintos a lo que se espera fuera de las aulas: se da más prioridad a salir del paso y cumplir con el requisito que a comprender qué es lo que se pide.
Por ello, el informático, debido a la naturaleza de su trabajo, debería ser más orfebre que obrero, puesto que si un jarrón o una escultura requieren de tiempo y de paciencia para su culminación, el software de manera análoga tendrá que ser provisto del ingrediente original propio de las obras de arte: la creatividad, aunado a la técnica y al método. Para subsanar el obstáculo del tiempo, connotados académicos en la ciencia de la computación, crearon una especie de recetas de cocina que conocemos como metodologías o pasos a seguir.
Guillermo Levine en su obra “Computación y programación moderna” hace mención de un “paso cero” en la creación de software: entender el problema o la situación1,esto es, previamente a pasar a la construcción del programa tratar de establecer los parámetros sobre los que se va a trabajar con el fin de lograr un panorama más amplio. Parafraseando a las ideas de Platón, formar “el molde” sobre el cual vamos a imaginar, comprender y después resolver la problemática que se nos propone.
Posteriormente, el autor plantea hacer un análisis, ya en función de variables y constantes propias de la programación lineal, ya en función de los objetos y procedimientos que propone la POO, cuyo resultado es un esbozo casi siempre esquematizado del cómo resolver el problema. En este paso, huelga decir que se asume que se ha imaginado y comprendido lo que se desea hacer; lo que sigue es en sí mismo un juego de idas y vueltas: el esquema se hace de manera inteligible a un determinado software compilador, que al momento de ejecutar el programa, traduce del compilador a “lenguaje intermedio” y de ahí, a unos y ceros el resultado final, requiriendo incluso de un desdoblamiento hacia el compilador y viceversa. Programa habemus.
Y de ahí surge la paradoja del oficio: si sabemos que la aplicación de prácticamente cualquier ciencia lleva consigo el inevitable sendero de seguir un método que, evidentemente, implica tiempo y esfuerzo, ¿no es una ironía que gracias al mismo tiempo muchas de las veces el método no se siga al pie de la regla?
Hay muchas metodologías al respecto de como se debe hacer un software, tantas que un espacio como éste sería insuficiente para abarcar todas, pero huelga hacer mención de dos técnicas que han estado en boga desde hace algunos años: la programación extrema (o eXtreme Programming en inglés) que en teoría pinta como para facilitar las cosas al informático promedio al dar prioridad al hacer sobre el indagar, pero en la práctica considero una apuesta arriesgada, debido a que se puede lograr funcionalidad en el software sacrificando el “paso cero” debido a la premura del procedimiento, y si un programa cojea del pie del “paso cero”, todo lo demás será en vano.
La otra técnica, cuyo uso particular se centra en el desarrollo de sistemas en Web es el ciclo de vida denominado sashimi, en analogía a la presentación del sushi en forma de rodajas que se traslapan unas con otras. Así, los diferentes pasos del procedimiento suelen mezclarse unos con otros, pudiendo hacer el “paso cero” junto con el análisis e inclusive codificar durante el diseño conceptual, por lo que sobra hacer mención de las serias dificultades que implica el programar hasta la anarquía.
Tanto la “extreme programming” como el ciclo de vida sashimi, ejemplifican de manera contundente las desventajas del hacer sobre el indagar, ya que no sólo el tiempo se muestra como obstáculo, sino que entra en juego un factor más: la confianza entre dos partes, la que toma las decisiones sobre lo que quiere, encarnada por el cliente y la otra que debe cubrir los requerimientos, encarnada en el programador de carne y hueso. ¿Qué pasa cuando no hay acuerdo entre lo que se quiere y lo que se tiene?
Por consiguiente, no debe concebirse la metodología como una panacea para eficientar el proceso de escribir, sino inducir al programador a hacer previamente un análisis detallado y tomar de ahí los elementos contingentes para plasmar, en un léxico exótico, lo que se desea hacer. El detalle es que, de acuerdo a Levine, en la formación superior del informático este es un aspecto que se cuida poco, dando prioridad al “codificar” cayendo en el síndrome del simple escriba sobre el “programar” mediante una serie de pasos rigurosos.
Otro aspecto a señalar tocante al quehacer informático es el siguiente: ¿Dónde empieza el desarrollador a aprehender el léxico en el que está trabajando? En el lenguaje de programación, como en la vida, puede haber más de una manera de decir las cosas. ¿Cómo determino yo, programador, que debo usar un “for” en vez de un “while” para hacer y dejar hacer que una instrucción se ejecute correctamente?; la elección quizás se reduzca a una mera cuestión de estética o de eficiencia. Esta constituye una analogía crucial entre el escribir con dígitos y el escribir con palabras, puesto que en el desarrollo de software hay más de una vía para expresar una idea, al igual que en el ámbito humano.
Tomemos como ejemplo la palabra “gato”. Dicha palabra por sí sola me remitiría al concepto que muchos de nosotros tenemos de estos animales: del género felino, domesticables, que maullan, entre otras características. Aunque también alude al instrumento para cambiar las llantas de los automóviles, hay una exigencia de por medio: representar, mediante una palabra, el mismo concepto del gato como felino; así tenemos las palabras minino, micifuz, etc.
En la programación promedio, nuestro “gato” sería aquello que el cliente nos solicita que haga o deje de hacer el software o página de Internet que nos ha encomendado. A diferencia de las metodologías, que tienen en común un trayecto casi semejante para hacer las cosas, el programador cuenta con el libre albedrío de llegar al quid de lo que se pide por el camino que desee, siempre y cuando cuente con el respaldo de los cánones del lenguaje que está explotando.
Finalmente, para agotar el punto relativo a las experiencias del proceso de programación, cabría hacer mención también del como el aspirante a desarrollador aprende a codificar las instrucciones, siendo este punto sin duda uno de los más cruciales para llevar a buen término en el arte de plasmar en el léxico exótico las soluciones. La interpretación que se puede construir respecto al lenguaje, a diferencia del ámbito formal de la comunicación escrita, es unívoca y cerrada, lo que constituye una peculiaridad de la programación por si misma. Tomo otro ejemplo trivial: si yo digo “el perro azul corre por la pradera”, el léxico exótico reconoce varias clases de perros pero ninguno azul, por lo que descarta la expresión. Así, el lenguaje de programación se asemeja al humano en la construcción de vías para decir las cosas, pero deja de lado la metáfora, quedando sólo en el plano de la realidad.