Programmation Réactive, une entrée en matière

Lorsque l’on s’interroge sur la programmation réactive et que l’on commence à faire des recherches sur le sujet, on se heurte à beaucoup de confusions et c’est bien dommage.
Ce n’est pas si compliqué que cela et surtout on peut en tirer des bénéfices immédiat qui vont faciliter notre vie de développeur.

Découvrons dans un premier temps ce qui ce cache réellement derrière ce terme et pourquoi il génère un engouement aussi fort ces derniers temps ci.
Le principe de programmer en terme de gestion de flux est aussi vieux que le pipe Unix. Le concept n’est pas nouveau, loin de là.
La programmation réactive est un paradigme de programmation qui gagne en popularité depuis quelques années. Aucune spécification commune n’avait vu le jour avant le manifeste réactif.
Il se trouve que les paradigmes “classique” comme la programmation impérative deviennent vite difficile à lire et ne peuvent exprimer certains aspects facilement comme la modélisation de flux d’évènements, la programmation d’opérations asynchrones ou le temps-réel.

Approche sémantique et état des lieux de la programmation réactive.

On vous propose de découvrir l’écosystème actuel et à venir.
En guise d’introduction, nous commencerons pas une approche sémantique du paradigme de la programmation réactive, puis nous dresserons un rapide état des lieux.

Changeons de paradigme, maintenant !

Vous l’aurez compris, Olivier vous encourage à changer de paradigme pour adopter celui de la programmation réactive. En effet, que ce soit côté front ou côté back, nous sommes de plus en plus amenés à raisonner en terme de “réaction” à des évènements qu’ils soient synchrone ou asynchrone et ce de façon “disponible” [http://www.reactivemanifesto.org/fr].
Pour le front, ce sont des click souris, des caractères clavier, des timers, des échanges réseaux.
Côté back, on orchestre maintenant nos services au travers de multiples appels REST sur des API tantôt synchrone, tantôt asynchrone. Tout en continuant d’interagir avec des BDD, le système etc …
Les applications sont souvent composées de plus petits composants et par conséquent dépendent des propriétés réactives de chaque composant.
Les Systèmes Réactifs emploient des méthodes de conception qui permettent d’appliquer les propriétés réactives à toute échelle, les rendant “composables” selon ces quatre aspects. Il est temps d’appliquer ces principes de conception systématiquement dès le début de la conception de nouveaux systèmes au lieu de les redécouvrir à chaque fois.

Olivier Huber, un passionné de création logicielle.

Pour lui, notre métier est l’un des rares à nous donner la capacité de matérialiser une idée rapidement et quasiment gratuitement. Initié il y a plus de dix ans à l’agilité par la pratique de l’eXtrême Programming, il devient Agiliste convaincu et Scrum Master par la suite. Il intervient pendant 16 ans en développement / conseil / formation chez des grands comptes sur des besoins Java, JEE et Web de façon générale, à la fois côté serveur (Spring, Hibernate, JPA et leurs amis…) ou client (AngularJS, GWT, Wicket, jQuery, Twitter Bootstrap).
Il rejoint Zenika en septembre 2008 pour évoluer parmi des collègues qui ont la même ferveur et afin de partager au maximum ses connaissances (formations, conférences, …).
En 2014, il passe meta-formateur comme responsable pédagogique et accompagne les formateurs tout en continuant d’intervenir sur divers évènements techniques.

Pourquoi la programmation réactive ?

Quoi de plus agréable pour un développeur que de revenir sur du code et pouvoir rapidement y apporter des modifications afin d’ajouter de la valeur au produit final sans crainte de casser quelque chose ou de perdre un temps fou à en comprendre la logique.
Olivier a été confronté comme chacun à des besoins utilisateurs et/ou technique changeants et à devoir introduire de plus en plus de code asynchrone pour accélérer les traitements et fournir plus de valeur plus vite.

J’étais parti comme à l’habitude en raisonnant de manière impérative et en introduisant petit à petit des API avec des callback etc … Résultat des courses : Du code qui fonctionne mais très difficile à relire puis à modifier sans changer les API clientes. Sans parler de la gestion des erreurs lors de plusieurs appels asynchrone. Après avoir compris que “tout est flux” 😉 j’ai pu appréhender ce nouveau paradigme et en retirer les bénéfices. – Olivier Huber

Dans l’esprit Craftsmanship, la programmation réactive améliore la lisibilité de votre base de code ainsi que sa maintenance et facilite avec élégance la résolution de scénarios complexe et ceci avec peu d’opérations. Elle permet une gestion des erreurs asynchrone adaptée et une facilité de programmer de façon concurrente avec un niveau d’abstraction plus élevé.
Mais le plus important est que la programmation réactive permet de construire une interface stable et transparente sans se soucier de l’aspect de la concurrence ou du cache etc …
Les détails d’implémentations peuvent être modifiés après coup sans affecter les API utilisées.

Conclusion

La programmation réactive apporte des boites à outils permettant de décrire des scénarios complexes de programmation concurrente et événementielle d’une manière déclarative et avec une API simple et bien documentée. Les systèmes réactifs permettent aux utilisateurs une interaction accrue et ainsi une plus grande satisfaction.
Cela demande en effet d’appréhender un nouveau paradigme ce qui amène un nouveau niveau d’abstraction mais petit à petit cela devient naturel. Une difficulté peut venir au début sur la capacité à débugger simplement notre code réactif car les évènements par définition se déclenche à n’importe quel moment et non linéairement. Mais là encore des opérateurs permettent d’interagir avec nos flux afin de voir ce qui se passe pour faciliter le debug.
Et pour en savoir plus, voici la suite de cette vidéo sur ReactiveX / RxJava.

Pour aller plus loin, quelques références

+15000 personnes ont déjà signé le Manifeste Réactif
Reactive Streams Specification for the JVM
ReactiveX