Rockola.fm tiene un claro ejemplo de este conflicto en la implementación de la funcionalidad “Ahora en Rockola.fm están escuchando”. Se trata de una lista que aparece al final de nuestra home mostrando qué escuchan los seis últimos usuarios con actividad. Esta información se refresca cada cinco minutos.

Siguiendo el lema “mantenlo simple”, la primera implementación se limitaba a realizar una consulta sobre la BBDD cada vez que vencía un temporizador JavaScript. Asombrados por la rapidez del desarrollo (como media jornada) la nueva funcionalidad subió a producción en el siguiente pase. En esa época descorchábamos botellas de cava cada vez que superábamos los cien usuarios concurrentes. Nuestras infraestructuras estaban en consonancia con esa audiencia (una máquina para todo) y el riesgo de tener problemas de rendimiento era muy pequeño.

Sin embargo, con 1.000 usuarios concurrentes, esta petición se realiza casi dos veces por segundo que no te tira el servidor pero te lo ocupa de forma absurda.

Conscientes de que la BBDD sería uno de nuestros cuellos de botella (con  “los de sistemas” identificando entradas sospechosas en el mysql-slow.log), afrontamos nuestra segunda refactorización incluyendo una gestión de cacheo de contenidos. El resultado fue espectacular hasta el punto que en algunos momentos las graficas para los servidores de BBDD (dos en balanceo por entonces) daban “respuesta plana”.

La gestión de cache complica el desarrollo pero la codificamos una sola vez en las clases base de nuestro patrón MVC. Para usarla basta implementar dos funciones virtuales que informan sobre la localización física de fichero y la duración del mismo. El cambio se limito a copiar el antiguo código sobre las nuevas clases y definir cinco minutos como duración del caché.

Sin embargo, con unos 5.000 usuarios concurrentes, el vencimiento de la caché ocurre símultáneamente para entre 20 y 50 usuarios que lanzaban a la vez una consulta bastante pesada generando picos innecesarios en la BBDD.

En esta ocasión, resolvimos el problema añadiendo un valor aleatorio al tiempo de vencimiento de la cache de modo que la función virtual para gestionar esto devolvía algo así como 300+rnd(50). De esta forma, limitamos las peticiones de refresco de caché entre 1 y 5 simultaneas. Una idea tonta pero efectiva y que seguro que empieza a dar problemas con 10,000 usuarios simultáneos.

Actualmente el “Ahora en Rockola.fm están escuchando” se genera mediante un proceso planificado lanzado cada cinco minutos. Muchas vueltas para llegar a la solución mejor y también la más sencilla.

He repartido por algunos proyectos código monstruosamente complejo para una solución general que nunca llegará más allá de resolver un simple caso particular. Muchas horas perdidas y quien lo mantenga sufrirá para entenderlo.

También soy un convencido de las metodologías ágiles porque las he probado y realmente funcionan. Presentan resultados rápidos con un nivel de tensión razonable en el equipo y sin exigir heroicidades.

Son dos razones que me obligan a darle una vuelta al tema del desarrollo especulativo o al menos buscar donde está el límite.

Aunque un proyecto es irrepetible y comienza con una gran indefinición, hay que disponer de las herramientas mínimas para afrontarlo y que son necesariamente especulativas. Estas herramientas definen modos generales de hacer las cosas como USDP y algunas veces afectan directamente al código como el MVC. Ambos ejemplos están en la parte superior de mi pirámide de proyecto cuya base ocupan los desarrollos específicos:

Arriba lo especulativo, abajo la cruda realidad del código

La metodología general de gestión del proyecto y la arquitectura de desarrollo puede ser definida por el equipo técnico pero no debería ser puesta en cuestión durante la codificación pura. Un poco más abajo, parece razonable que decisiones como usar Prototype, Mootools o jQuery para framework de JavaScript no dependa de cada programador sino que sea consenso de todos.

Los beneficios derivados de la homogeneidad y capacidad de reutilización diría que están fuera de toda duda. La definición de soluciones generales y librerías reutlizables son críticas para facilitar futuros desarrollos y hacer el código mantenible. La dificultad está en saber cuando tomar la decisión de abordar una solución general (y por lo tanto especulativa) o limitarse a cubrir los requerimientos funcionales de la forma más ajustada y simple.

La solución está en tomarse muy en serio la palabra refactorización y asumir todo lo que conlleva. Entender que no sólo significa estar dispuesto a modificar tu código para mejorarlo en aspectos como el rendimiento sino como una forma de extraer soluciones genéricas en base a sistemas que están funcionando.

Basta con la experiencia de un par de proyectos para comprender que gran parte del conocimiento necesario se adquiere durante el propio desarrollo y que, al final, siempre le queda a uno la sensación de que si pudiera empezar de nuevo lo haría mucho mejor. Esa segunda oportunidad la ofrece cada refactorización y la programación no especulativa acelera los resultados de forma espectacular.

Es importante recordar que lo construido funciona y que su refactorización no es obligatoria para el siguiente ciclo. De hecho, en Rockola.fm vamos por nuestra tercera refactorización y parte del código sigue en la primera versión. Probablemente ese código, que funciona perfectamente, siga así hasta el próximo ciclo.

Por ejemplo, creo que el blog de Rockola.fm no es lugar para:

• Escribir un artículo tostonazo sobre metodología de gestión de proyectos ya que, probablemente, sólo interesará al 1% de los lectores.
• Incluir fotos de mi perro y sus aventuras que sólo van dirigidas a mi familia y amigos
• Cualquier otra cosa politicamente incorrecta no relacionada, aunque puede que si, con música o tecnología

Si escribo algo aquí que crea merece estar en Rockola.fm lo copiaré allí también.