Retour sur SC London 2019 – Jour 1

Les 3 et 4 octobre derniers, j’ai eu la chance de participer à la conférence SC London 2019. Au programme : 14 speakers, 350 participants sur 2 jours en plein cœur de Londres. J’y ai appris beaucoup de choses et vais partager avec vous mes découvertes, surprises et coups de cœur.

J’ai commencé cette première journée par un petit-déjeuner local au London Bridge BreakFast Club (mmmm, pancakes !) et une petite balade à pied avant de rejoindre CodeNode, le lieu qui nous accueillait.

Aligning Product & Software Design

Lors de cette première présentation de la journée, Sandro Mancuso, que j’avais déjà eu l’occasion de rencontrer en Janvier 2018 lors de la formation Crafting Code, est parti du constat qu’aujourd’hui une grande majorité de logiciels sont développés sous la forme de Projets qui s’articulent autour d’une stratégie « métier » et d’une stratégie « technique » élaborées indépendamment l’une de l’autre par le Métier d’une part et les Développeurs d’autre part.

Sandro nous propose de prendre en compte le fait que les logiciels ne sont pas des biens comme les autres et qu’ils nécessitent un investissement continu et une vision que la notion de Projet ne met pas assez en avant : un Projet a un début et une fin, à la différence d’un Produit, qui pourra évoluer dans le temps pour s’adapter aux demandes de ses utilisateurs. #noprojects

Sandro fait ensuite un rappel des différentes étapes de la conception d’un Produit, dans un cadre traditionnel et dans une démarche agile. Il souligne que la plupart des équipes de développement ne se trouvent que très rarement en mesure de donner du Feedback et d’influer sur la définition du Produit et subissent les choix « métier » faits en amont.

Sandro nous présente alors une alternative basée sur la collaboration et les boucles de Feedback où les aspects techniques sont pris en compte dès le premier jour et permettent de guider les décisions tout au long de la vie du Produit.

 J’ai beaucoup apprécié le « futur idéal » et les outils présentés (Impact Mapping, Value Proposition Canvas). Je pense qu’ils pourraient aider à résoudre certaines difficultés que nombre de mes clients rencontrent au quotidien. Si je ne devais retenir qu’une chose de cette présentation, ce serait cette citation :

In a Software Product, Software Design should be an explicit part of the Business Strategy

Sandro Mancuso

BDD in action: testing modern web applications at scale

Lors de ce live-coding John Smart nous a présenté sa façon d’aborder les tests automatisés, avec Cucumber (qu’on ne présente plus) et Serenity, un outil très prometteur que j’ai découvert à cette occasion. Il utilise le Screenplay Pattern, dont j’avais déjà entendu parler très brièvement, mais que je n’avais jamais pris le temps de creuser jusqu’à présent. #screenplay-pattern

John nous a montré comment écrire nos tests à la manière d’une pièce de théâtre, en utilisant le Domain-Specific Language de Serenity qui définit (entre autres) les notions d’Acteur, de Scène, de Lumière, de Questions et de Conséquences.

Cette façon d’écrire les tests end-to-end (puisque c’est bien ce dont il s’agit) a pour avantage de clairement mettre en valeur le scénario métier que l’application devra implémenter tout en définissant explicitement la relation à l’interface utilisateur, mais sans encombrer le scénario de détails inutiles pour autant. On écrira par exemple « Quand Sally enregistre une note » plutôt que « Quand Sally clique sur le bouton #btnSave de la page /note ». Ce n’est évidemment pas magique et il faudra bien créer ce lien à un moment, mais j’ai trouvé la façon de faire particulièrement élégante. Je veux lire plus de tests comme ceux-ci ! 😊

Il est d’ailleurs intéressant de noter que Serenity n’utilise pas de Page Objects. John nous invite à raisonner en termes de « morceaux d’écran » plutôt que de « pages ». À l’heure des Single-Page Applications et des Progressive Web Apps on ne peut que saluer ce choix d’implémentation !

The lost art of Software Design

Simon Brown a quant à lui décidé de nous parler d’architecture et, chose un tantinet surprenante au premier abord, de Design Up-Front !

Aujourd’hui de moins en moins de personnes semblent prendre le temps de formaliser leur architecture et se contentent de griffonner des schémas périssables sur des coins de tableau blanc, en interprétant un peu trop littéralement la valeur « un produit qui fonctionne plutôt qu’une documentation exhaustive » du Manifeste Agile. C’est dommage car une bonne architecture permet d’aller vite longtemps !

Restreindre l’impact des changements n’est certes ni simple ni automatique et demande un travail de réflexion qu’il ne faut pas négliger. On ne cherchera cependant pas à prendre toutes les décisions mais seulement les décisions significatives, c’est-à-dire celles qui induisent un important coût de changement !

Dans tous les cas il sera primordial de bien communiquer les décisions, prises et les raisons qui ont conduit à les prendre, faute de quoi elles ne seront pas respectées et réduiront l’évolutivité du système. Pour cela on peut avoir recours à des outils comme la notation UML (eh oui !), le modèle d’architecture C4 ou encore Structurizr.

Ces outils de visualisation nous fournissent différentes cartographies de nos systèmes d’information et permettent de provoquer des discussions significatives et de recueillir du Feedback pour guider nos décisions. Le Design Up-Front n’est donc pas incompatible avec un processus itératif et incrémental ! 😮

Sans conteste la présentation qui m’a le plus bluffé de la conférence, voire bien au-delà. Simon est vraiment un speaker exceptionnel. J’ai adoré sa façon de présenter, ça m’a vraiment inspiré et je vous invite chaudement à regarder la vidéo de son talk quand elle sera disponible. #amazing-speaker

What does great architecture look like?

James Birnie, ancien de Thoughtworks maintenant chez Codurance a lui aussi décidé de nous parler d’architecture et… d’architectes !

James commence par rappeler qu’il est très difficile de trouver une définition universelle des termes « architecture » et « architecte » tant ce qu’ils désignent varie drastiquement selon le contexte dans lequel ils sont employés.

James nous donne ensuite une définition de ce qu’est un Anti-Pattern : « une solution commune à un problème récurrent, qui est souvent inadaptée et risque même d’être contre-productive ». Il présente ensuite des Anti-Patterns courants : interdire d’essayer de nouvelles choses sous prétexte de « standardisation », le « framework maison » comme solution imposée pour palier un manque de confiance ou d’empathie, la personne « incontournable » qu’il faut contacter avant d’envisager le moindre changement…

J’ai beaucoup aimé l’expression « Risk Management Theatre » que James a employé pour désigner une situation malheureusement trop courante où « les règles » priment toujours sur l’objectif poursuivi (« outcome »). #risk-management-theatre

James encourage les architectes à adopter une posture de Conseillers plutôt que de Dictateurs. Il a également insisté sur la nécessité de comprendre les problèmes qu’on souhaite résoudre avant de conclure sa présentation en donnant les caractéristiques d’une bonne architecture, puis d’une « super » architecture.

Il est primordial d’intégrer le fait que « tout changera » et de faire des choix qui permettront que cela se concrétise. Un bon moyen d’y arriver est d’évaluer concrètement et systématiquement nos architectures à l’aide de « fitness functions », afin de permettre de réagir au plus tôt quand l’issue obtenue n’est pas conforme aux objectifs poursuivis. Pour plus d’information sur ce sujet je vous invite à lire Building Evolutionary Architectures: Support Constant Change de Neal Ford, Rebecca Parsons, et Patrick Kua et Accelerate : Building and Scaling High Performing Technology Organizations de Nicole Forsgren, Jez Humble et Gene Kim.

The Gordian knot

Alberto Brandolini, l’inventeur de l’Event-Storming, a souhaité mettre en avant le fait que les solutions dont nous disposons aujourd’hui (devops, micro-services…) ne sont pas des solutions universelles aux problèmes que nous rencontrons.

Certaines équipes sont très heureuses de travailler avec un monolithe. D’autres extrêmement malheureuses alors qu’elles travaillent avec des micro-services ! Les micro-services ne sont pas une fin, mais un moyen d’obtenir un couplage faible qui nous permettra de réagir favorablement au changement.

Les choix d’Architecture ou de Conception que nous faisons influencent nos Interactions et façonnent notre Culture. Alberto définit la Culture comme « l’effet cumulatif d’un comportement avantageux dans un contexte donné ». Selon le contexte la Culture pourra donc aussi bien encourager l’innovation que la rendre difficile, voire impossible. Pour nous aider à améliorer notre Culture, Alberto nous propose deux outils : le « Pink Check » et le « Feedback Check ». #culture-matters

Le « Pink Check » est une référence à Daniel Pink, l’auteur de Drive. Alberto mentionne donc les trois piliers du livre que sont l’Autonomie, la Maîtrise et l’Impact (« purpose »). Il nous invite à évaluer les situations à l’aune de ces trois critères et à réagir dès que l’un d’eux n’est plus respecté.

Le « Feedback Check » traite de notre capacité à apprendre. Il nécessite de mesurer des indicateurs, mais aussi et surtout de prendre en compte le fait que « les individus n’amélioreront un système que s’ils restent assez longtemps pour constater les conséquences de leurs actions ». Il est donc primordial de s’assurer qu’il n’y a pas de conflit entre des objectifs à long terme et des objectifs individuels à court terme et de gérer le turn-over.

Alberto propose enfin de tenter de remplacer dans nos organisations la Peur, la Colère, la Culpabilité, la Frustration et le Désespoir par la Sécurité, la Responsabilité et la Fierté. Pour lui tout est connecté : Culture, Organisation et même Plaisir ! Il faut faire fi des attitudes tayloristes malheureusement trop répandues et prêter attention aux émotions positives comme négatives : il s’agit de Feedback ! 😊

C’est l’une des présentations qui m’a le plus intéressé au cours de cette première journée, même s’il est très difficile de les hiérarchiser.

Testing Microservices: from Development to Production

Daniel Bryant partage avec nous son expérience sur le test de micro-services. Il a commencé par lui aussi rappeler que les micro-services (au même titre que tout outil ou pattern) ne sont pas une fin mais un moyen, et qu’il ne faut pas les utiliser à moins d’en avoir besoin. La raison est qu’il est difficile de bien tester des micro-services, notamment lorsqu’ils ont des dépendances vers des services tiers (ce qui est très fréquent).

Daniel indique que la Pyramide de tests n’est plus suffisante et qu’il est très compliqué de tester de bout en bout un service et ses dépendances. Il nous parle de « Software Testing Funnel », une notion présentée dans l’article Testing Microservices, the sane way de Cindy Sridharan. D’autre part, comme le souligne l’article End-to-end testing considered harmful de Steve Smith, il vaut mieux isoler nos tests des composants qui ne sont pas sous notre contrôle.

Pour pouvoir tester nos composants en isolation, nous allons devoir faire appel à des « doublures de test ». Daniel nous rappelle les différents types de doublures et insiste sur l’importance d’utiliser les bons termes. On parle souvent à tort de mocks ou de « bouchons » alors que d’autres termes plus précis existent et seraient plus appropriés.

Après avoir évoqué Testcontainers et Localstack qui aident à développer en local, Daniel nous parle de Contract Testing et nous montre qu’il est possible de créer des « Consumer-driven Contracts » en utilisant Pact. Je ne connaissais pas cette approche et je l’ai trouvée très intéressante, elle permet d’appliquer une démarche TDD au niveau d’une API ! 😮

Daniel conclue sa présentation en nous rappelant qu’il faut également tester la tolérance aux pannes, inclure des données de test semblables aux données de production pour éviter les mauvaises surprises, et bien évidemment s’assurer de la sécurité tout au long des développements ! Suivre les recommandations de l’OWASP est un bon début.

Reading code is harder than writing it

Trisha Gee, Developer Advocate chez Jetbrains, nous parle de l’importance de savoir lire du code, une compétence essentielle, mais souvent négligée, y compris par les pontes du Software Craftsmanship. On parle beaucoup plus souvent de l’importance de savoir écrire du code « lisible », mais sans toujours accorder assez d’attention à ce que savoir lire du code veut dire.

Comme n’importe quelle compétence, lire du code demande de la pratique. Trisha nous invite à développer cette compétence en tant que « deliberate practice », notion que j’avais découverte pour la première fois dans l’excellent Turn the ship around ! de L. David Marquet.

Trisha insiste sur la distinction qui existe entre lire du code (« read code ») et relire du code (« review code »). La lecture vise simplement à comprendre le code, à la différence de la relecture qui vise à l’améliorer. 

On ne devrait pas modifier du code quand on cherche à le comprendre ! On peut par contre utiliser le debugger pour nous aider à comprendre ce que fait le code, y compris en modifiant des valeurs pendant l’exécution pour voir ce qu’il se passe.

Panel discussion: Architecture in an Agile environment

La journée se termine par une séance de questions / réponses avec les speakers de la journée sur le thème de l’Architecture dans un environnement Agile.

Voici ce que je retiens des échanges :

• ArchUnit permet de tester (et donc documenter) une architecture, et recueillir du Feedback
• Une architecture ne devrait pas être une contrainte, mais devrait au contraire permettre des choses, être un « enabler »
• « Souvent, il vaut mieux demander pardon que demander la permission »
• « Si vous ne pouvez pas changer la situation, changez de situation… partez ! »
• « Aujourd’hui vaut mieux que demain »
• Il faut se concentrer sur là où sont les plus gros problèmes et les corriger
• Les Soft Skills sont excessivement importants ! Il faut savoir communiquer, influencer et écouter.

Cette première journée était vraiment une très chouette expérience, très enrichissante, mais aussi très fatigante ! On se retrouve bientôt pour un second article. 😊