Este es un proyecto cancelado que no recibe actualizaciones. No obstante, puedes acceder a su archivo como referencia.

Versión Cero

El modelo de desarrollo reactivo

Sergio Montoro

Los ciclos de liberación de versiones de meses o años han muerto. Los usuarios quieren mejoras diarias, que reaccionemos a sus peticiones en horas. Veamos las bases del desarrollo reactivo.

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”.

Comentarios
1 Nekar
17 octubre 2005, 16:52

Ojalá alguien me hubiera hecho una introducción a la programación web como esta el día que entré a programar webs de logística.

El día a día sin tener esto presente puede ser muy frustrante tanto para el programador como para los clientes.

Intentaré asegurarme de que mi reemplazo (me cambio de curro) se lea esto en primer lugar.
2 Rastafari
17 octubre 2005, 22:00

Me parece interesante el concepto de programación “reactiva”, la realidad es que en el día a día la mayoría de tiempo se dedica a desarrollar nueva funcionalidad o bien arreglar errores con una base de código previa. De todos modos no estoy de acuerdo en algunas cosas:

1) y 2): obviamente el “copypaste” no es una tecnica de programación con mucho futuro.. estos dos puntos son el prncipio open-closed de siempre, es decir, hacer un sistema abierto a ampliaciones y cerrado a modificaciones. Quizas esto sea lo más importante de todo en este tipo de desarrollos, el problema es que hay pocos diseñadores capaces de aplicar este principio con habilidad.

3) coincido en que el código debe ser facil de leer, en lo que no coincido en absoluto es en señalar a la abstracción como enemigo de la legibilidad, creo que es todo lo contrario, la abstracción es indispensable para conseguir un código legible. Para este objetivo también me parece fundamental que todo el mundo siga una guia de estilo, y si además disponemos de un mecanismo automatico para comprobar que el código se ajusta a la guia de estilo mejor que mejor.

4) no creo que el objetivo sea tener las “ñapas” controladas, el objetivo es no hacer ñapas, de nuevo el principio open-closed y por supesto refactorización. Si vamos por este camino en pocos meses tendremos un bonito spageti ilegible de ñapas y ñapas, además en un código con ñapas ¿que más da una más?. Con las ñapas pasa como con las drogas, “ehh tio.. que yo esto lo controlo”, hay que asumirlo, nadie controla las ñapas.

5) Lo que dices sobre eventos y mensajes en principio sólo plantea una diferencia semantica en el nombre de los métodos, llamar a un método “hazX” o llamarlo “HaPasadoX” y luego que haga lo que le de la gana el receptor del método, esto es importante pero falta reseñar la cualidad más importante de los eventos, A no tiene porque conocer a B, es decir, conseguir un diseño más desacoplado y ortogonal es el verdadero objetivo. No existe una regla fija para utilizar eventos o enviar mensajes, depende de nuevo de la habilidad del diseñador.

6) Yo me conformo con, de nuevo, un diseño ortogonal que permita rediseñar el interfaz sin miedo a cargarse ninguna funcionalidad.

En lo demás basicamente estoy de acuerdo en todo, sobre todo en el tema de que los programadores deben hablar con el cliente, y si es posible desplazarse en persona y ver como el cliente utiliza el sistema, esto es fundamental para que se impliquen en el proyecto lo más posible y programen y diseñen en la dirección correcta.
3 Oliverio
21 octubre 2005, 22:20

El articulo me parece excelente, coincido en gran medida con el autor menos en el punto 3 (el sistema debe ser autoexplicativo). Últimamente he estado involucrado en un proyecto “terrible� (no se me ocurre otro adjetivo dadas las circunstancias) donde ha habido de todo, desde dualidad en el cliente (uno paga y el otro usa, y ambos están enfrentados) hasta que el grupo de desarrolladores se haya renovado en un 100% y ya no quede ni uno de los programadores que “comenzaron ‘la fiesta�.

Y en medio de estos acontecimientos el sistema ha sido “llevado y traído� de una forma realmente espectacular. Por estos motivos se ha hecho necesario obviar el paso de redacción y se han realizado numerosos cambios directamente en el código. Esto es permisible para un proyecto de 10 tablas y 20 formularios, pero cuando estamos hablando de 80 o mas tablas y 100 y mas formularios (con un flujo de negocios bien complejo además) pues se vuelve impracticable. Es preferible entonces perder 30 minutos escribiendo algo así como: “Cuando el cliente de tipo A realiza un pedido del producto de categoría B las facturas no deben ser enviadas hacia su dirección de facturación sino hacia…� y luego poder dormir tranquilos. La ley de Murphy es 100% aplicable en estos casos y por lo tanto esa información seguramente nos hará falta dentro de dos semanas cuando el cliente pida agregar una nueva categoría de productos y en caso de no haber hecho una nota de este tipo tengamos que “bucear� en el código.
Acerca - Contacto - Información legal y técnica - Condiciones de uso - Noticias sobre el mundo del Desarrollo de Software.