Descenso Hacia los Avernos del Software
Hola de nuevo, Javi. ¿Qué nos traes hoy? Lo digo porque acabo de leer el título, y nos da que se te ha ido la pinza. Esto, a ciencia, suena poco…
Sí, sí, perdón, lo reconozco. He puesto un gancho facilón y artificial, como si de un burdo clickbait se tratase, para atraer vuestro interés. Pero permitidme esta licencia, sólo pretendía dirigir vuestra curiosidad hacia una rama en la que se posan pocos pájaros, y, casi todos, solitarios: el software. Sí, como diría mi madre, hoy voy a trabajar de lo mío.
Pero no, tranquilos, no os voy a meter una chapa académico-profesional que os deje con el labio torcido y la baba caída cual película dominguera de Antena 3. No vamos a ver nada de Ingeniería del Software ni de nada que se acerque a algo mínimamente parecido. Aunque sé, traidores, que en el fondo os tragáis los capítulos de Mr. Robot como si fuesen cropanes…
Además, no me negaréis que hoy el software forma parte no sólo de nuestras vidas en su más amplio sentido (lúdica, personal, profesional, y en prácticamente cualquier ámbito), sino que también se ha hecho un hueco en nuestro imaginario colectivo, en el que se nos presenta como algo cotidiano pero complejo, útil pero peligroso, que nos despierta una curiosidad que no nos apetece satisfacer. Vamos a ver si hoy, con suerte, conseguimos entretenernos un poco a la par que logramos comprender de forma sencilla qué es lo que realmente ocurre en cada uno de los cacharros electrónicos que constantemente tenemos entre las manos. Hoy toca Ciencias de la Computación.
Al igual que Virgilio guía a Dante en un viaje a través de los nueve infiernos, una instrucción software hace un enorme descenso hasta el hardware. De la misma forma que en La Divina Comedia sólo se pasa un infierno para volver a encontrarse con otro más profundo hasta que por fin se alcanza el noveno y último, una instrucción software pasa por otro software que la procesa y genera otras instrucciones software que vuelven a ser procesadas por otro software que vuelve a generar otras instrucciones software, de que nuevo repiten este ciclo, cada vez más profundo, hasta alcanzar su último objetivo: hacer su trabajo a nivel electrónico 1. Cumplir con su orden.
_____________________
1 La metáfora del viaje descendente de Dante y Virgilio a través de los infiernos, y el descenso por las distintas capas del software por el que pasa una simple instrucción es, no lo niego, una metáfora atrevida, pero bastante más literal de lo que a priori puede parecer. La licencia no es tan grande como aparenta.
Espera, me diréis, ¿quieres decir que el software se procesa con software que ha sido escrito con software que es procesado por software, y así sucesivamente? ¿Hay quien usa un programa para programar un programa que va a servir para programar programas? Y os tendré obligatoriamente que responder: exacto. Y todo esto está pasando en este preciso instante en el dispositivo que estés utilizando para leer este texto.
Pero veamos cómo. Veamos qué viaje hace una única línea de código hasta poder llegar a cumplir con su cometido, y tener por tanto el impacto en el mundo que esperaba quien la escribió. Y esta vez, en contra de la norma, vamos a empezar por el final: por arriba.
Lo más cercano al usuario son los lenguajes de alto nivel. Estos lenguajes de programación son los que se han utilizado para desarrollar las aplicaciones que usas. Son, literalmente, los lenguajes en los que estas aplicaciones han sido escritas, y aunque no te haya interesado jamás el mundo del software, seguro que los has escuchado alguna vez. Sus nombres son C, C++, C#, Delphi, Java, Visual Basic, Javascript, PHP, Python, Cobol, y un largo etcétera. HTML no.
Al desarrollarse con ellos las aplicaciones que directamente usas, son muy demandados, y suponen un gran porcentaje de las opciones profesionales, ya que, al final, el usuario es el que paga, ya sea una persona o una empresa. Y con esto, y algo más 2, nos pagamos las cervezas los ingenieros de software.
Si Virgilio nos estuviese haciendo descender por las capas del software, este sería El Primer Infierno: Usuario. En este infierno se piensa única y exclusivamente en el usuario final. En el cliente. Y se prima muchísimo la apariencia, así que posiblemente pierdas horas aplicándole colorinches a una tabla hasta que quede como debe quedar. Es donde está la cara de nuestra app.
Un servidor odia este infierno, aunque sea el menos duro. Tengo serias limitaciones en hacer cosas bonitas.
_____________________
2 Con esto, y mucho más, esta licencia sí es más grande. El desarrollo o programación es tan sólo un pequeño porcentaje de lo que abarca la Ingeniería del Software, aunque sea el más representativo.
Veamos un ejemplo concreto: imaginemos que nuestro jefe nos pide para ayer hacer una pantalla en nuestra app, que muestre una tabla con los resultados de los votos de esta semana (o lo que narices se haga) de los concursantes de La Isla del Amor. Perdón, de Love Island, que suena menos guarrete.
¿Qué tendría que hacer? Pues muy muy sencillo, trabajo de becario: arrastraría con el ratón un componente tabla, le daría un nombre, pongamos tabla_resultados, y luego escribiría esta línea de código:
Y ya.
¡¡¿Y ya?!! ¡¡¿Y esto es lo que era tan difícil??!! Amos, no me j*d#s… Tranquilos, que hemos hecho una cosa hipersencilla, y sólo estamos en el mejor de todos los infiernos, no lo olvidéis.
Supongamos ahora que nuestro jefe, como nos ha visto sueltos, nos pide, con prioridad cero (no va a cambiar ahora ya de viejo), que ampliemos la información que esta tabla muestra, indicando también no sólo el personaje y el número de votos de la semana, sino otras dos columnas: el número de votos que el personaje obtuvo la semana pasada, y un cálculo que indica el porcentaje de aumento o descenso que ha experimentado.
Bien, en ese caso, pensarás: he de entrar dentro de la función CargaResultados de la clase objetoVotaciones, y cambiarla para que arroje otro resultado. Y con ello habrás descendido al Segundo Infierno: Lógica de Negocio.
En este infierno se piensa en los procesos. En que las cosas sean precisas, no fallen nunca, y supongan poca carga de procesamiento. Es donde está el músculo de nuestra aplicación.
Vaya. Problemas. Al bajar de capa no sólo hemos de pensar en los procesos además de en los usuarios, sino que puede que hayamos cambiado de lenguaje. De hecho, en este ejemplo de tan poco código, estamos utilizando 2 lenguajes: VB.net para la lógica, y SQL para componer los datos. Vaya, con el anterior, C#, ya van 3. Sólo soy un becario que ha empezado hoy a trabajar, y ya me están pidiendo 3 lenguajes de programación. Esto se empieza a complicar.
Pero como no queremos volver a vendimiar, que duelen mucho los riñones, nos esforzamos, y lo sacamos. Cambiamos el código de esta segunda capa (o infierno), y le damos a nuestro amado jefe lo que nos pide. En dos días, ascendido, ya verás.
Pero el comercial, al que no le caen especialmente bien ninguno de los ingenieros, sentimiento que es mutuo, ha vendido ya una nueva característica. Para fomentar el uso de los usuarios, la cadena quiere que al lado del porcentaje de ascenso o descenso, aparezca la cara del usuario que primero votó. De esta forma pretende asentar un comportamiento competitivo entre éstos que desemboque en una mayor interacción del público, y, a la postre, aumente la popularidad social del programa. La típica sensación de pertenencia, vaya. Mucho software, pero todo muy tribal.
Pagan una pasta. El comercial se lleva una pasta de comisión. Tu jefe, ingresa una pasta. Tú, eres becario. Adivina en quien ha pensado tu jefe…¡Bingo! En ti. En el chaval con aspiraciones que ya le ha sacado las castañas del fuego en dos ocasiones.
Pues venga, pa’lante. Te remangas, otro café, y al lío.
En esta ocasión no te va a valer cambiar un poco código, y lo sabes. Te falta información, por lo que habrás de generarla de la nada.
Como te tomaste en serio eso de estudiar, sabes que vas a necesitar hacer, mínimo, dos cosas. Una, generar un nuevo campo en la tabla de usuarios en la que se pueda almacenar la foto del susodicho. Y otra, establecer una relación en la base de datos, que permita de alguna forma relacionar al usuario con el concursante.
La forma de hacer todo esto dependerá de cómo esté diseñada la base datos. De su estructura.
Bienvenido al Tercer Infierno: Datos. En este infierno se piensa en estructuras, relaciones, arquitectura, y tipos de datos. En matrices y operaciones entre ellas. Supone el esqueleto de nuestra app.
Ves esto y empiezas a ponerte nervioso. Esto de ascender no va a ser tan rápido. Pero tienes mucha suerte: el mundo del software está lleno de colegas solitarios que no pagarán jamás una multa por saltarse el toque de queda, pero que les gusta ayudar en el trabajo. Es su única interacción social.
Así que uno de los senior que te ha visto llorar en la máquina de café (sí, te han visto), se te acerca rodando con su silla. Parece que viene a quedarse, pinta bien.
Empieza a hablarte con las ganas y la rapidez del que no tiene muchas ocasiones de comunicarse, y del que conoce lo que habla como la palma de su mano. Te das cuenta de que has sido el único asistente a una masterclass gratuita sobre arquitectura de datos que no volverá a repetirse, pero de la que no has pillado ni papa.
Por suerte, te ha dejado hechos los scripts que hacen los cambios necesarios, los has pasado, y funcionan.
Bien, ahora ya tienes los datos, puedes, sencillamente subir al infierno de la Lógica de Negocio, y cambiar el código de la consulta como hiciste la otra vez. Total, ya has estado allí. Tú, contento. Tu jefe, contento. El comercial, contento. El senior, contento. Miel sobre hojuelas.
Antes o después llegará el momento de liberar una versión para que los usuarios puedan actualizarse y disfrutar de las nuevas características que están esperando. Y el de cobrar. Que quizá tú y el senior seáis ingenieros de vocación, pero te puedo asegurar que ni tu jefe ni el comercial trabajan por amor al arte. Así que venga, la app en la calle, ya. Y que no pete.
Para, para, que te pierdes. Que te estás yendo del tema. Si sabíamos nosotros que se te había ido la pinza con sólo leer el título…
Que no, que no, lo prometo. Que ya entramos en barrena, en serio. Comienza la caída libre. Aquí empieza el verdadero descenso a los infiernos. Átense los valientes. A los inseguros: es el último aviso para la huida.
Todos sabemos que al final, esto del software son ceros y unos. Lo hemos escuchado cientos de veces, y lo cierto es que no nos han engañado. Es estrictamente correcto, y vamos a darnos de bruces con ello.3
Para sacar una versión, tendrás que necesariamente compilar, que no es otra cosa que utilizar un programa al que le pasarás el código de tu programa para que genere un programa ejecutable, el cual será de nuevo una colección de instrucciones. Es decir, habrás utilizado una aplicación ya programada para transformar tu código en código.
_____________________
3 Cuando un servidor tenía 8 o 9 años, su padre le dijo justamente esto: al final todo eso son ceros y unos. Me pareció tan incoherente e imposible que con sólo 2 números se hiciera lo que ya se hacía allá por el 85 u 86, que no paré de intentar encontrar una respuesta. A los 11 años estaba ya estudiando programación. Tengo 44. Toda una vida tirada a la basura.
Acabas de entrar en El Cuarto Infierno: Sistema Operativo. En este nivel se piensa de forma general, en que todo un gran ecosistema de software y hardware conviva con estabilidad y coherencia. Tu app es un minúsculo grano de arena en una playa llena de otro software ejecutándose. Pierdes interés, tú, tu jefe, y tu app.
Este nivel es el sistema nervioso. Se encarga de coordinarlo todo, sin hacer nada en particular.
Pero, esto no tiene sentido, me diréis. Y vuestra afirmación será lógica. Pero pensad lo siguiente: tu jefe quiere que la app corra (perdón, se ejecute), tanto en un móvil Android última generación como el tuyo, como en el iPhone nuevecito de tu colega con pasta, como en el iPhone 3 de tu tía la de Huelva, que no lo cambia pero ve el programa y vota, como en el Android de la abuela, que es mas antiguo que las pesetas pero aunque dice que no, le da caña, y en la tablet Windows de tu padre, que nunca ve Love Island pero se sabe los nombres, y vota. Fijo que vota.
Y esto supone un verdadero problema tecnológico, porque en el fondo, cada uno de estos sistemas operativos (que son programas también escritos con código) es capaz de entender o gestionar cierto software y cierto hardware. Pero es que el hardware que hay en cada uno de los dispositivos (su procesador, más concretamente) es capaz de comprender sólo ciertas cosas, y lo hace en idiomas diferentes. No se entienden. Para que comprendan tu app y se la puedan contar al usuario, se la tienes que contar en diferentes idiomas. A cada uno en el suyo. Son muy rápidos, pero no son muy listos.
¿Y cómo se soluciona esto? Muy sencillo: con aún más software, cómo no. Hacemos que nuestro compilador, basado en una tecnología, pongamos Microsoft, en lugar de intentar generar aplicaciones que puedan ser entendidas por la totalidad de los procesadores, lo cual es completamente inabordable hoy por hoy (lo fue en épocas de menor difusión tecnológica, pero en esas tampoco tenías el problema de tener que hacer una app de Love Island), genere una especie de código fuente intermedio que sólo entiendas tú. Es decir, que Microsoft compile código para generar otro código que sólo Microsoft sea capaz de interpretar.
Esto puede parecer absurdo, ya que si estás buscando que todos puedan conocer la historia que quieres contar para así poder difundirla (ejecutarla), no tiene sentido que el primer paso que des sea el de generar otro nuevo lenguaje que sólo entiendas tú. Pero Bill Gates no se hizo rico por tener viñas, así que algo de interés habrá en esto. Tampoco lo inventó él, seamos justos.
Dadle la vuelta, se ve mejor: si en lugar de intentar que los compiladores de tu tecnología conozcan multitud de juegos de instrucciones de multitud de procesadores basados en multitud de arquitecturas, que además están en constante evolución, pasen a no tener que conocer ninguno, no habrás conseguido aún tu objetivo, pero sin duda te habrás quitado un gran problema de encima. Te habrás abstraído. Podrás encapsular.
Podrás hacer un pequeño programa, uno por tipo de sistema operativo / arquitectura, que coja tu código intermedio y lo cambie a la arquitectura adecuada en cada caso, según en dónde se esté ejecutando.
Este programa, o middleware, o “software que está en el medio” es el que da paso al siguiente nivel. Bienvenidos al Sexto Infierno: Arquitectura.
Este es el nivel de los órganos. Aquí está el corazón, el hígado, los pulmones, todos ellos por separado, esperados a ser usados de la forma correcta.
Cuando el usuario vaya a abrir tu app, la cual está, recordemos, compilada en un lenguaje intermedio que sólo conoces tú, realmente no la ejecutará. El sistema operativo le dirá a tu middleware que la ejecute. Literalmente, un software le dirá al otro: encárgate tú de ejecutar este software que yo no lo entiendo. Lo vas ejecutando y me lo cuentas, que tengo yo que contárselo al usuario, que me lo ha pedido.
En este momento, tu middleware lee cada una de las instrucciones en las que está compilada la aplicación, las cuales, recordemos, sólo comprendes tú, y las traduce o interpreta a otras que conoce el procesador, denominadas código ensamblador. Es decir, ya comenzamos a hablar con el cacharro, con su hardware. Pero aún no hemos llegado.
Ejemplos de este middleware son la Máquina Virtual de Java o Java Virtual Machine, y .net Framework. Es muy probable que te suenen, ya que seguro que te han fallado los dos.
Cada procesador tiene su propio juego de instrucciones, es decir, cada modelo de pastilla comprende un número limitado, y mucho, de órdenes. De hecho, es normal que un procesador pueda cumplir una orden con tan sólo una instrucción de su repertorio, y que otro requiera más de una para exactamente lo mismo, obviamente del suyo. Es la combinación correcta en las que éstas se ejecuten, y la enorme velocidad a la que lo hacen, lo que al final se traduce en absolutamente todas las ventajas de la informática que conoces. Desde el placer de leer este texto (gracias por llegar hasta aquí), hasta la que consigue detectarte con un TAC una enfermedad de forma anticipada y permitir un tratamiento que te salve la vida, como la que hace que tu avión aterrice con seguridad permitiendo que no la pierdas.
Es decir, es la pericia combinada de la ingeniería del software y la ingeniería electrónica 4 la que en esencia permite la generación del valor que obtienes con la informática en cualquier ámbito.
Bien, pues ya está, ¿no? No. Casi, pero no. Estas instrucciones que genera tu middelware están ya muy cercanas al hardware, pero aún son software.
Bufff, esto es muy pesado... Y no os lo niego, pero si habéis llegado hasta aquí, dadme un minuto, estamos de verdad acabando. Acabamos de entrar en el Séptimo Infierno: Binario.
_____________________
4 Y alguna otra pericia más relacionada, perdón por la ausencia, pero la búsqueda de la simplificación justifica la omisión.
Es el nivel en el que se encuentra el ADN. De nuevo, este símil es mucho más literal de lo que parece.
En este, ya sí, otra capa de software traduce esta instrucción ya del juego de operaciones del procesador, en un código binario real. Y la lógica aquí es muy sencilla.
Supongamos que la instrucción es MOV a, b, la cual se encarga de mover la información que haya en el registro a al registro b. El procesador dispone de un listado en el que relaciona códigos de operación con códigos binarios, más o menos largos según el número de operaciones que sea capaz de ejecutar. Así pues, la instrucción MOV puede ser, por ejemplo el código 001.
De la misma forma, tendrá un número para identificar cada registro de que disponga en base a su diseño y arquitectura. Si tiene 8 registros, el a puede ser el 0001 (1 en decimal) y el b el 0010 (2 en decimal).
Así pues, la instrucción MOV a, b se codificaría como 001 0001 0010, o 00100010010.
Esto es un ejemplo sencillo de lo que es el código binario. Fácil.
Pero esto sigue siendo software. Aún no tenemos hardware trabajando. Y es que para que finalmente trabaje el procesador, hay que hablarle con impulsos eléctricos. Realmente no conoce otro idioma. Esto es así. Bienvenido al Octavo Infierno: Electrónica. Es el cerebro del sistema.
¿Y cómo funciona esto? También sencillo.
Nuestra instrucción binaria anterior tenía 11 bits (00100010010). Supongamos, por comodidad que todas nuestras instrucciones tienen la misma longitud, aunque no sea una longitud muy habitual en informática.
Pues bien, nuestro procesador tendrá al menos 11 patillas (más, de hecho), que son esas patas que vemos en los chips. Pues cada pata se corresponderá con una posición de la secuencia de bits de nuestra instrucción, de tal forma que si la excitamos con un cierto nivel de corriente (5V o 12V, por ejemplo), se interprete como 1, y si lo hacemos con otro menor (0V o 5V, por ejemplo), se interprete como 0. Los procesadores llevan sus drivers que es otro software que se encarga, ya sí, directamente, de hablar con el hardware, de forma que cuando detectan que a nuestra pastilla se le está pasando un 00100010010 (el último bastión del software), se encargue de poner los niveles de corriente adecuados en las patillas correctas (la primera línea del hardware). Esta es la frontera en la que la lógica se convierte en física. El álgebra se hace mundo.
El procesador tiene, evidentemente, un diseño o arquitectura. Estas son muy diversas y dependen directamente del uso que vaya a tener el procesador en cuestión. No tiene el mismo diseño una pastilla cuyo objetivo es servir aplicaciones empresariales, que la pastilla de un móvil, que la que lleva el controlador primario de un caza. El caso es que, ya dentro del diseño específico de cada uno, el cual implica disponer de un juego de instrucciones concreto, estos procesadores vienen microprogramados. Con esto metemos el pie en el último nivel, el Noveno Infierno: Microcableado.
Aquí están las células del sistema, sus ladrillos básicos.
Cables 5 realmente pequeños, tanto que hoy por hoy hablamos ya de apenas un puñado de átomos en las escalas más altas, se interconectan y generan monstruosas autopistas de ceros y unos (realmente voltios yendo y viniendo), y que, en base al diseño exacto y la microprogramación, ejecutan finalmente la instrucción.
Es decir, leen los voltios que haya almacenados en cada posición del registro a, y ponen exactamente los mismos valores de corriente en el registro b. El cómo se hace esto sería ya demasiado por hoy.
Bueno, pues ya hemos llegado. ¿Cuántas bajas ha habido? ¿Estamos todos? ¿Me he quedado ya solo?
Algunos quedamos, pero hay caídos en el frente…
Bien, pues gracias todos, tanto quienes hayáis podido aguantar hasta este punto, como a quienes lo intentaron y ahora mismo yacen plácidamente en el mundo de los sueños.
_____________________
5 Hoy no entraremos en transistores, puertas lógicas, lógica cableada, etc., así que cables es un buen símil.
Hoy ha sido algo duro, lo sé. El proceso que permite que, con sólo ceros y unos, puedas jugar al Minecraft y sientas que estás explorando mundos alternativos no es sencillo.
En esta ocasión hemos visto la parte dura, aquella en la que una simple línea de código, de las millones que componen las aplicaciones de medianas en adelante (sí, sí, millones), acaba siendo ejecutada.
Sin embargo, para dar valor a toda esta secuencia, y hacerte creer que eres un explorador con cuerpo de tipo Lego descubriendo nuevos mundos, o permitirte manejar un negocio, hay muchísimo recorrido adicional que va más allá de la simple técnica de ejecución a lo largo de las distintas capas. La Ingeniería de Software aporta valor porque enlata conocimiento. Es decir, alguien que ve esos mundos, los plasma. Alguien que sabe analizar un negocio, lo plasma. Alguien que sabe cómo funciona tu cuerpo, lo plasma.
Para hacer un buen software, es necesario conocer el dominio del problema. El software clásico es, literalmente, conocimiento encapsulado. Son latas de saber.
Por eso, al final, a los ingenieros de software nos toca aprender sobre todo aquello que queremos entregar al usuario, y, con los años, acabamos como acabamos.
Bueno, y hasta aquí por hoy. De nuevo hemos pretendido amenizar e intentado divulgar. Como siempre, con haber conseguido algo de alguna, nos quedamos satisfechos y si además hemos despertado algún interés, pues entonces, felices.
Sentíos completamente libres de plantear cualquier duda en la sección de comentarios, así como cualquier propuesta de temas a tratar en próximas entregas. Si el mobiliario de nuestras cabezas nos lo permite, la abordaremos. No podemos garantizar que podamos, pero sí que las tendremos en cuenta y lo intentaremos.
¡Nos vemos!
Entusiasta del software, la música, y la ciencia, llevo desde chaval metido en los tres tinglados todo lo que mi tiempo y mis capacidades me permiten. Estudié Ingeniería Técnica Informática en la Universidad de Castilla – La Mancha, Máster Universitario en Tecnologías Informáticas Avanzadas en la misma universidad, y Máster Universitario en Inteligencia Artificial por la Universidad Internacional de la Rioja, y me he dedicado al software durante toda mi vida profesional, así como a leer toda la divulgación posible sobre ciencia, especialmente en las ramas de la astrofísica y astronomía, e interiorizarla al paso de alguien con más paciencia que entendederas.
