Simpleton (un post a cuatro manos)

Ya van un par de veces que diferentes amigos me cuentan de una entrevista de trabajo en la que se han visto enfrentados a interrogatorios casi policiales al estilo de los que siguen (con comentarios del que la vivió, que nos deleita con su sarcasmo):

¿Qué patrones de diseño utilizás habitualmente? ¿Qué GRASPs reconocés en este código? ¿Qué Microsoft Application Blocks conocés? ¿Cuáles utilizaste? ¿Conocés WPF, WCF?

-Uno piensa: "¿Te pagaron un cursito de Microsoft y querés demostrar que estabas prestando atención?"

Luego continúan preguntando por una lista interminable de productos de Microsoft, estándares, tecnologías... la chancha, los veinte y la máquina de hacer chorizos...

-De acuerdo, uno no está siempre en la cresta de la ola, pero no es necesario hacernos sentir unos buzos de profundidad.

Entonces uno se pone a pensar... ¿realmente utilizan todo eso? Están el horno... no quiero ver lo que son esos proyectos.

-...si es que existen proyectos ya implementados y funcionando con todas esas nuevas tecnologías.

-Me da la sensación de que en teoría son unas bestias avezadas, pero no sé si sabrán nadar en el caos de un sistema funcionando (sí, nadar, hoy estoy acuático).

-Ni hablar del caso de que tengan que hacerse cargo de un muerto (flotando, para el caso) con el código atravezado de heridas abiertas, cuando hay que resolver el asesinato para ayer porque la viuda (el dueño de la empresa y del barco) quiere cobrar el seguro de vida.

-Y aunque se implementen en distintos proyectos, luego hay que pensar en la rotación de personal: no todos los marineros saben remar con remos nuevos, y hay viejos piratas (como el dueño de éste blog) que programa mejor con su vieja brújula que cualquier nuevo almirantito con sus aparatos GPS.

Gracias por eso último... creo... encima que estoy perseguido con la edad...

Volviendo al tema de la entrevista, en vez de evaluar la capacidad para dirigir el barco, la experiencia piloteando en tormenta, la muñeca aceitada para dar un giro de timón sin que la nave zozobre preguntan si sabemos apretar los botoncitos del nuevo panel de comando.

Literal de la entrevista:

YO: - "Tá bien, pongo los application blocks, ¿y cuando fallen?"

EL: - "Son de Microsoft, están recontraprobados..."

YO: - "Lo mismo dicen de cada Windows que sale..."

EL: - "Pero tenes el código abierto, podés entrar, leerlo y tocarlo."

YO: - "Microsoft no programa como yo, no programa como vos, no programa como mi equipo o tu equipo. ¿Alguna vez probaste leer código de otro, sin saber qué reglas sigue para codificar?"

EL: - "Las reglas de Microsoft están escritas por toda la web."

YO: - "O sea que para arreglar un error (que no espero que ocurra, por lo tanto va a fallar cuando menos lo espere) tengo que además de leer el código de MS leerme toda la web para entender qué es lo que hace? ¿No es más fácil si lo hacemos nosotros y después lo corregimos nosotros, sabiendo cómo lo escribimos?"

EL: - (Sonrisita socarrona, pensando) "Este no tiene idea."

YO: - (Sonrisita socarrona, pensando) "Grumete con barquito nuevo, cuántas horas te quedás fuera de horario tratando de que el portaaviones funcione con aparatos que no hiciste ni conocés... aparatos que cuando quieras aprender en medio de la tormenta te van a hundir mientras pedís que te salve con mi barquito de madera. GIL."

Corolario: no estoy en contra de las nuevas tecnologías, pero no todo lo que sale es bueno. Podría nombrar COM, Atlas, DLL Hell, y muchas otras que prometían balas de plata, y quedaron en el camino. Sepamos discernir lo útil de lo novedoso, lo maduro de lo experimental... y seremos mas felices, aunque sigo buscando la manera de comprarme un yate.

Pero dejemos el sarcasmo de lado para analizar más fríamente la situación. Un par de aclaraciones:

No estoy muy de acuerdo con el estilo confrontativo en entrevistas de trabajo. Creo que es mejor tratar de mostrarse como uno es, y si no cuadramos con el tipo de proyecto, saludar con una sonrisa y hasta luego. Pero me encanta el sarcasmo, así que dejo esos afilados comentarios tal cual los recibo.

En principio dejo de lado por obvio el tema de las nuevas tecnologías. Hay que tenerles un ojo encima, pero cuidado con apurarse en la implementación, o en embarcarse habiendo probado sólo un "Hello World!". Concentrémonos en el tema patrones y bloques de código.

Está claro que tanto los patrones, guías de diseño, buenas prácticas, application blocks, librerías de clases, ejemplos, experiencias y demás son esenciales en nuestro trabajo, y que debemos conocerlos y aplicarlos... donde y cuando corresponde, y siempre teniendo en cuenta los objetivos reales del código que estamos creando.

Y es que muchas veces se pierde esto último en medio de una maraña teórica: el objetivo, el negocio. Y el hecho de que la mejor solución es siempre la más simple que lo satisface. Ojo, no la más rápida de implementar, sino la más simple.

Por dar un ejemplo: los application blocks. Están muy bien como referencia, para analizarlos, para tomarlos como ejemplo, para conocer todos los recovecos del lenguaje y del framework. Pero, dado que están enfocados a soluciones generales, a dar un ejemplo de perfección teórica, suelen ser demasiado complejos para cualquier proyecto que encima tendrá sus particularidades si es que busca diferenciarse de alguna manera.

Está bien utilizarlos siempre que los conozcamos en profundidad (no teóricamente, sino que conozcamos realmente bien el código) y que tomemos la precaución de encapsular la funcionalidad que nos ofrecen. Esto último es importante ya que de otra manera un factor externo como es la estructura de un application block condicionaría la estructura de nuestro propio proyecto, haciéndonos perder el control del mismo.

¿A qué me refiero con "control"? Es claro que lo perdemos cuando empezamos a dar respuestas del tipo "Hagamos esto de esta manera (mucho más complicada) para poder utilizar... [tal o cual pedazo de código que saqué de xxx]".

Son respuestas que en épocas de apuro se aceptan (todo vale), pero que no pueden convertirse en lo normal y cotidiano. Yo diría "salgamos con esto en esta versión y apenas esté en firme hacemos el refactory" (y lo hago, ojo). Porque puedo hacerlo una vez, pero si lo hago dos y tres y cuatro y no voy arreglando los "ajustes" (enchastres) termino, como decía antes, adoptando una gran estructura que vuelve demasiado complejo al desarrollo. O peor, varias estructuras diferentes, cada una enfocada a la utilización de tal o cual "code block".

El uso concurrente de todas esas herramientas y patrones en un sólo proyecto puede dar lugar a conocidos anti-patrones (ver la entrada Antipatrones de diseño):

Simpleton Pattern: Código extremadamente complejo para llevar a cabo la más simple y rutinaria de las tareas. Es una medida precisa de la habilidad de su creador.

Para más y mejor referencia, recurro una vez más a Guido van Rossum que con sus conocidísimos principios de diseño viene a aportar claridad al tema:

Simple es mejor que complejo.
Complejo es mejor que complicado.
Si la implementación es difícil de explicar, es una mala idea.
Si la implementación es sencilla de explicar, puede que sea una buena idea.

Creo entonces que una interminable lista de tecnologías a utilizar en un proyecto dan buena cuenta de qué tan mal estructurado está, o de qué tan desesperados estarán sus responsables por conseguir un salvador que pueda meter mano en todo eso al mismo tiempo (y cuanto más complejo, más difícil conseguirlo).

La historia terminaría con nuestros entrevistadores deslumbrados por un postulante que los supera en capacidad para recordar siglas (e inventar significados para las que no conoce), al que intentan captar disfrazando el terrible desastre mencionado arriba como una juguetería llena de novedades brillantes... postulante que se suma al proyecto en calidad de "oráculo" sólo para demostrar una absoluta inoperancia, falta de experiencia y de sentido práctico.

A uno de los mejores programadores que conozco (no te pongas colorado) tengo que recordarle todos los santos días alguna tarea trivial en C#, que olvida tan rápido como aprende. Y me imagino que eso le pasa simplemente porque no está pensando en el código, en cómo se hacen las cosas, sino en qué es lo que hay que hacer.

Para decirlo claramente: las herramientas no son importantes. Lo importante no es el código (ni el nombre) de los application block, ni el código de ejemplo (ni el nombre) de los patrones. Lo importante es su estructura, que tomamos de base para buscar la más apropiada en cada caso particular sin perder nunca de vista el negocio para el cual estamos programando.