por Sergio Montoro Ten, 20 junio 05

Hace un par de meses pusimos en marcha un website con un gestor de contenidos por detrás. Como el website tenía que estar online para ayer, escogimos uno de los populares gestores escritos en PHP. Al poco de tenerlo operativo nos dimos cuenta de que el gestor en cuestión lanzaba una media de 15 consultas contra la base de datos al servir cada página. Por suerte, nos habíamos anticipado a la situación encargando una cantidad desproporcionadamente grande de hardware para el tráfico estimado (a fin de cuentas el hardware es muy barato como solución de fuerza bruta). El cliente ni se ha enterado y anda feliz con su sitio web dinámico que le funciona tan ricamente.

Un par de años atrás, en cambio, no fuimos tan afortunados. Cometimos el error de encargar a un programador inexperto la traducción de unas páginas. El especialista en cuestión cogió todos los literales en castellano y los puso en una columna en base de datos y luego creó otra columna con los literales en inglés y se hizo una función Java llamada traducirLiteral(“pepe�) que se conectaba contra la base de datos, buscaba el literal el castellano con una consulta SQL y devolvía la cadena de texto en inglés. Para una página típica esto eran como 70 conexiones a base de datos por página. Como había un pool de conexiones y la tabla de literales era lo bastante pequeña para que la base de datos la cacheara en RAM, incluso esta implementación por fuerza bruta le hubiera salido bien; de no ser porque en vez de usar el driver JDBC apropiado, usó un puente JDBC-ODBC con un bug que le hacía perder 30 bytes de memoria en cada desconexión, lo cual, a la postre, acababa tumbando irremediablemente el servidor.

De las experiencias anteriores me surgió una pregunta profunda: ¿hasta qué punto importa programar bien? La experiencia me dice que para aplicaciones de andar por casa (que son la mayoría) el programador medio se las puede apañar razonablemente bien con un gestor de contenidos de calidad mediocre. Existen, empero, dos especimenes de terroristas del compilador especialmente peligrosos: el codificador descerebrado y el hombre abstracto.

El rasgo fundamental que caracteriza al codificador juntalineas es que no piensa. Escribe código como esos generadores verborreicos de poesía o notas de prensa que producen textos sintácticamente válidos pero sin ningún sentido.
El codificador juntalineas no puede escribir más de 100 líneas de código sin perderse. Su ámbito de alcance en el diseño abarca los que le cabe en la pantalla, 100 líneas más o menos. A partir de ahí se pierde y es incapaz de recordar lo que estaba haciendo.
El codificador juntalineas carece de ninguna consideración por el uso de recursos físicos de la máquina, lo mismo te carga en RAM una tabla hash de 1 millón de elementos que te manda 10 megas de datos en un post de HTTP.
Las pantallas del codificador juntalineas son un rompecabezas. Nunca se sabe dónde hay que pinchar, ni en qué orden.
No hay dos fragmentos de código del programador descerebrado que sean iguales, ni siquiera parecidos porque como no tiene memoria, no se acuerda de la nomenclatura que empleó ayer y reinventa una nueva cada mañana.

El hombre abstracto es el antagonista puro del codificador juntalineas. Se le reconoce porque sus programas tienen tantas clases de objetos como instancias y, además, las dos terceras partes de las clases son interfaces abstractos que no hacen realmente nada.
El hombre abstracto jamás empieza un programa con el compilador. Siempre tiene una herramienta de diseño en la que emplea horas y horas modelando antes de escribir ni una sola línea de código.
Si el codificador juntalineas su siente en su salsa con la chapuza diaria, el hombre abstracto detesta las reuniones con cliente porque cada nuevo requisito arruina la belleza del diseño y obliga a una refactorización de código. Uno debe armarse de paciencia para hacer ingeniería inversa del código del hombre abstracto. Es posible recorrer 8 ó 10 clases anidadas buscado donde está la funcionalidad que buscas, sólo para llegar después de una hora a un comentario que dice “pendiente de implementar�. El hombre abstracto a menudo es un subproducto típico de la formación académica realizada por maestros que nunca tuvieron experiencia real en un proyecto de uno o dos millones de líneas de código, y llenan de pájaros la cabeza de los estudiantes con la forma ortodoxa de hacer las cosas.
Puede ser gente que tenga algo visceral contra los depuradores o contra los modernos sistemas expertos que revisan el código y hacen sugerencias según lo escribes.
Si las pantallas del codificador juntalineas eran un invento para usuarios masoquistas, los programas del hombre abstracto directamente no tienen interfaz gráfico porque el sujeto no tuvo tiempo de implementar algo tan banal. El hombre abstracto no programa para solucionar problemas, escribe código para un concurso de pureza estilística.