L'écosystème logiciel est en constante évolution : langages, infrastructures et outils de gestion du logiciel (sources, intégration, dépendances, déploiement, tests, etc.) sont mis à jours constamment, si bien qu'il est souvent impossible d'avoir une stack logicielle à jours. À cela s’ajoute la démocratisation de paradigmes majeurs, tels que la virtualisation, le cloud computing, les conteneurs légers, l’intégration continue, le devops, les orchestrateurs, les micro-services, etc. Lesquels vont jusqu'à remettre en cause les fondements de nos architectures. Le développement logiciel fait face à une course à l'évolution, au sein de laquelle il faut, entre autres, choisir « le bon outil ou la bonne technologie », mettre à jours régulièrement toutes les couches logicielles, se tromper... et recommencer. Parfois, on doit même calculer la rentabilité de tout reprendre « from scratch ».
Face à ce constat, en 2017, Neal Ford, Rebecca Parsons et Pat Kua font naître le concept d'« architecture évolutive » : un type d'architecture logicielle, qui peut supporter des changements, même profonds, afin d'accompagner le logiciel qu'elle supporte à travers des avancées technologiques permanentes. L'originalité de l'architecture évolutive réside dans l'utilisation de « fitness functions ». Plutôt que de décrire les qualités principales d'un logiciel (interopérabilité, vérifiabilité, transparence, scalabilité, réactivité,...) et de bâtir un cadriciel pour contraindre à les respecter, une architecture évolutive utilise des tests non-fonctionnels, qui sont joués de façon récurrente et automatisée. Ce sont les fameuses « fitness functions ». Aussi, une collection de fitness functions bien choisies permet de définir une architecture dite « évolutive », qui va guider les développeurs durant tout le cycle de vie de leur logiciel. Pour faire simple, c'est du TDD appliqué à l'architecture logicielle.
Tout ceci est bien théorique... ou pas ! En effet, avec la démocratisation de l'intégration continue, la plupart de nos usines logicielles disposent déjà des outils nécessaires à l'élaboration de tests automatisés. Alors pourquoi ne pas chercher ensemble quelques un de ces tests ? Ils pourraient grandement améliorer notre sérénité dans l'évolution de notre stack logicielle, et de fait, sa qualité. Je propose, dans ce talk de vous présenter brièvement les concepts de l'architecture évolutive et des fitness functions, enrichis de quelques exemples. Ensuite, je vous propose de discuter, d’échanger, entre devs, PO, UX designer, utilisateurs, manager, ... afin de trouver les fitness functions les plus pertinentes pour nos logiciels.
Bénéfices de la session :
Prendre du recul sur la façon d'architecturer du logiciel. Pousser les méthodologies à base de test (TDD) encore plus loin, jusqu'à l'architecture. Participer à la conception d'une architecture logicielle, même en temps qu'équipier non technique (PO, chef de projet, manager). Découvrir le principe des fitness fonctions (tests non fonctionnels).
