por Sergio Montoro Ten, 17 octubre 05

Hace unas semanas que vengo pensando en relación entre el empirismo de Hume y la razón pura de Kant aplicada a la programación.
Por eso me sorprendió este post de Ali Arsanjani sobre la factibilidad de diseñar una infraestructura SOA a priori .
La raíz de la idea me había surgido de una presentación de Adam Bosworth (VP de ingeniería en Google) titulada Intelligent Reaction en la cual afirma que el diseño a priori ha cedido paso a la habilidad para adaptarse a las necesidades cambiantes del usuario.
De esto van un poco todas las nuevas metodologías como Extreme y Agile : de reaccionar.

Bosworth cita SalesForce como ejemplo de lo que todos hemos experimentado de una forma u otra de un tiempo a esta parte: la versión de producto clásica ha muerto, al menos para la web, dando paso a un sistema de builds diarias en las cuales se mejora gota a gota la experiencia de usuario cada 48 horas.

Especificar y diseñar, dejan paso a escuchar e implementar en un tiempo récord para ganar la partida a las aplicaciones competidoras.

Esto abre una interesante cuestión de arquitectura: cómo diseñar un sistema para ser modificado.

1º) El sistema debe tener el mínimo de código duplicado.
Casi todos los programadores trabajan haciendo copiar/pegar de un un conjunto de subrutinas que conocen y con las que se sienten cómodos. Eliminar código duplicado es una de las métricas habituales de calidad de software, pero nunca había sido tan importante como en los sistemas reactivos, pues, eliminando duplicidades se reduce el trabajo necesario para hacer cambios a´si como la probabilidad de errores por omisión en las modificaciones.

2º) El sistema debe tener un núcleo blindado.
No hay nada peor para un sistema reactivo que una build rota. Una build rota implica una parada de servicio, que en un website es el equivalente a un terremoto de fuerza 8.
La mejor forma de prevenir una build rota es separar mediante programación defensiva la funcionalidad esencial de los complementos. De forma que un defecto software en los complementos nunca pueda llegar a afectar al núcleo.

3º) El sistema debe ser autoexplicativo.
Tiene que ser sencillo comprender lo que está haciendo el programa leyendo el código de corrido.
Si el sistema está organizado como una cebolla, con capas y capas de abstracción, el pobrecito programador que tenga que mantenerlo se volverá loco. No va a haber ninguna documentación por falta de tiempo, y, aunque la hubiese, estaría obsoleta, de modo que la única alternativa es que el código sea fácil de entender.

4º) Las ñapas deben ser fáciles de trazar.
A medida que se introduzcan cambios será preciso hacer ñapas, apaños y todo tipo de triquiñuelas sucias en el código del estilo: todos los contratos deben estar asociados a un cliente excepto aquellos cuyo código empieza por “F” que son “Contratos Fantasma”. Lo mejor es llegar a un convenio para trazarlas. A mi me gusta poner el comentario /* # Ñapa */ en el código. Así cada vez que hacemos una build sólo tengo que coger el UltraEdit y buscar todas las chapuzas de builds anteriores de las que debería acordarme antes de subir el código a producción; aunque cada maestrillo tiene su librillo.

5º) El sistema debe notificar eventos mejor que delegar el comportamiento.
Básicamente, hay dos formas de comunicar objetos: que el objeto A le diga al objeto B lo que tiene que hacer o que el objeto A le comunique al objeto B algo que ha sucedido. En un sistema reactivo lo segundo suele ser mejor porque existe una alta probabilidad de que lo que el objeto B deba hacer cambie con el tiempo.

6º) Las pantallas deben tener espacio libre.
Los usuarios tienen tendencia pedir cosas que se amontonan sobre la misma pantalla, estilo ponme una checkbox aquí o amplíame esa combo a ¡200 caracteres! de ancho.

7º) El hardware debe estar sobredimensionado.
Las aplicaciones reactivas evolucionan como yonquis de los gigas.
Donde había una consulta SQL hará falta poner cuatro. Será preciso recoger estadísticas de todo. La regla del dedo gordo es poner al menos 10 veces la cantidad prevista. Donde se estimaron 30 gigas poner 300. Donde se estimó 1 procesador barato, poner 4 de doble núcleo.

En el plano organizativo un proyecto reactivo debe tener en cuenta que:

1º) La comuncación interpersonal es lo más importante.
Los sistemas reactivos no suelen tener fallos garrafales de diseño. Al menos desde la perspectiva del usuario, porque se va validando el prototipo incrementalmente según se introducen mejoras. Lo que si sucede habitualmente es que se producen malentendidos entre lo que el cliente desea y lo que se realiza realmente. A menudo, el cliente incluso pide reglas de negocio que son inconsistentes entre si.

2º) La trazabilidad de las conversaciones es crucial.
Esto ya lo vivimos más o menos todos en el día a día. En forma de gigas y gigas de correo archivado o de procedimientos de trabajo estilo “aquí todo por escrito”.
El sistema ideal de recogida de peticiones debe ser un poco fastidioso aunque no demasiado. El problema del e-mail es que es demasiado fácil pedir algo estilo: “Paco esto para mañana”. Lo mismo que es importante tener una herramienta de control de bugs, cuando se trabaja en modo reactivo es crítico tener otra herramienta que recoja y priorice las constantes peticiones del cliente.

3º) Los programadores deben organizarse ellos mismos lo más posible.
Los programadores suelen tener una relación de amor-odio con sus gerentes. Por una parte detestan la falta de visión del gerente, pero, por lo general, detestan aún más tener que hablar directamente con el cliente. La única forma de que los programadores entiendan y sientan empatía por las necesidades reales es que hablen directamente con el cliente.
Idealmente, el rol del gerente debe ser controlar que el proyecto transcurra según los plazos y las funcionalidades previstas, pero no dictar el calendario de acciones a los desarrolladores.

4º) La usabilidad es una piedra angular.
Muchísimas aplicaciones informáticas acaban en el cajón del olvido porque realmente la vida es más sencilla sin ellas. Es muy complicado batir a Excel y al tándem boli+typex en la productividad diaria. Pero no tiene sentido añadir mejoras que el usuario no utiliza.

En definitiva, el modelo reactivo es entender esa frase tan buena de Collin Powell: “No battle plan survives contact with the enemy”.