En tant que développeurs, ingénieurs, informaticiens (appelez-le comme vous voulez), nous essayons toujours de nous libérer au maximum de la complexité des applications.
En effet, au fur et à mesure des améliorations, l’architecture et le code deviennent de plus en plus complexes, et ce “tas” passe souvent sous nos coups de refactor… Mais pourquoi développons-nous toujours les applications d’un point de vue concepteur ? Cette complexité n’est-elle pas la conséquence de nos méthodes de développement ?
Lors de notre passage à dotJS, nous avons eu la chance d’assister au lightning talk de Thomas Belin, ce genre d’intervention de 5 minutes qui nous fait penser les choses différemment.
Son idée est relativement simple : mettez-vous dans la peau d’un programme, et agissons ensemble, comme le ferait l’ordinateur. Ensuite, réfléchissez à la scène qui est en train de se produire, là, maintenant : vous lisez mon article, et vous êtes certainement en train de regarder ce crayon…
Si la scène se produisait “en vrai” (je veux dire, physiquement), vous seriez donc en train de souscrire à ce que je dis, et observer ce que je fais. Je serais une fonction du temps, et vous seriez une fonction de ce que je produis.
Réellement, ce sont des fonctions de votre corps qui répondent à un certain type de message, c’est à dire, “la donnée” :
- vos yeux, au texte ;
- vos oreilles, à ce qui vous entoure…
Arrivés à ce stade, Thomas nous place face à un fait : ces parties fonctionnelles sont indépendantes les unes des autres, mais elles vous définissent, vous.
Nous nous rendons doucement compte qu’il agit devant nous comme une fonction du temps, mais que les éléments qui nous entourent le font aussi : nos téléphones sont probablement en train de récupérer le dernier tweet, le soleil se couche/se lève et notre fatigue va influer en fonction de ce temps…
On peut facilement en tirer d’autres exemple, afin de bien comprendre l’idée du talk : placez-vous dans la peau d’un conducteur de voiture. Dans ce cas :
- vous devez faire attention à la route (jusqu’ici, c’est logique),
- des passagers sont susceptibles de vous parler,
- le GPS indique une direction à prendre,
- il est grand temps de passer la 3ème vitesse.
Les interfaces, comme nous, ont donc plusieurs éléments à prendre en compte : le clic de la souris, la disponibilité d’Internet, le message en temps réel, etc.
Sans le temps, rien de tout ça n’arriverait. Vous ne recevriez pas d’images, de sons, de mouvements, et vos interfaces ne recevraient aucun signal, aucun message, aucune interaction. La donnée ne serait pas transférée.
Le temps est donc le facteur commun, et la conception de nos applications doit en dépendre. Le “functional reactive programming” est donc la clé, et les solutions sont nombreuses :
- vue.js
- ReactJS
- RxJs…
Ces outils nous permettent de concevoir des applications permettant de s’abstraire de “qui reçoit quoi”, “comment il le reçoit”… mais définissant les flux de données et leurs comportements dans la construction de nos interfaces.
Une autre solution que nous propose Thomas dans sa conclusion, est Cycle.js. Les interfaces deviennent ainsi des “pure functions of time”, grâce à une implémentation simple de la lib, légère et sans trop de magie. Sa puissance se ressent lors de la construction de dataflow complexes, où le “functional reactive programming” prend tout son intérêt.
Vous pouvez retrouver ce lightning talk sur son blog.
