Tech Radar Transverse

Aujourd'hui, le développement logiciel est le moteur des entreprises les plus performantes du monde. À titre d'exemple, que retrouvons nous de commun entre Amazon, Tesla et ING ?

La recherche (DORA) mène depuis 2013 une exploration des pratiques de développement, qui recense aujourd'hui plus de 2000 organisations et couvre tous les domaines d'application logiciel. Les découvertes et la recherche ont été publiées dans le livre Accelerate: The Science of Devops.

Cette étude scientifique, fondée sur la donnée brute, montre une corrélation forte entre le succès (productivité, profitabilité, croissance) et quatre métriques clés :

• fréquence de mise en production ;
• taux de mise en production sans erreur ;
• lead time pour qu'un code arrive en production ;
• lead time pour corriger un défaut en production.

L'étude elle-même, les KPIs ainsi que les mécanismes sous-jacents ont été décrits en profondeur dans un livre de Nicole Forsgren, Jez Humble et Gene Kim, intitulé Accelerate.

Dans notre pratique du Lean, nous avons trouvé une vraie résonance dans ces quatre métriques clés, qui promeuvent toutes les boucles de feedback rapide et l'amélioration continue au service du client et des équipes. 

‍

La force principale de ce framework est l'approche rigoureuse basée sur les statistiques de nombreuses entreprises qui le soutiennent et qui donne une grande légitimité pour convaincre les décideurs.

Notre application de ce framework nous a permis de constater sa puissance, comme un point de départ des changements organisationnels. Plusieurs équipes l'ont utilisé avec succès pour impliquer des stakeholders dans les discussions visant l'amélioration du processus de dév. Nous avons observé des impacts positifs sur les temps de déploiements, leurs fréquences et une implication plus importante des équipes dans le run et monitoring de leurs apps.

Le point difficile est la mise en pratique, qui nécessite souvent de challenger l'organisation en profondeur. Les KPI ne donnent pas forcément des outils pour mener ces changements, mais l'étude de cas dans le chapitre 16 de Accelerate donne une grille d'analyse qui est très utile. Ce schéma liste les pratiques à adopter par les équipes, le management et la direction pour améliorer la culture, la structure de l'organisation, l'innovation, les stratégies de déploiement et l'amélioration du flux via le Lean.

‍

NOTRE POINT DE VUE

Notre conseil, lisez Accelerate et testez-le dans votre contexte, mettez en place les indicateurs et utilisez la partie "Transformation" comme guide pour atteindre le prochain palier.

‍

HISTORIQUE 2022

Trial - Voir le Tech Radar 2022

Plusieurs implémentations de Scrum sont tombées dans le même travers en se concentrant sur les user stories et en laissant au second plan la notion de fonctionnalité. Dans ces conditions, une équipe peut régulièrement être amenée à enchaîner des user stories, sans avoir de vision globale du sujet dans lequel elles s'insèrent. Les résultats de ce biais nuisent beaucoup à la productivité :

• cela se traduit par l’oubli de cas limites, qui va conduire à des bugs et/ou à des fonctionnalités incomplètes ;
• les macro estimations qui en résultent sont peu fiables, car il y a beaucoup de retours d'un sprint à l'autre.

Le cœur du développement de la fonctionnalité est réalisé au cours d’un sprint, mais la gestion des cas limites ou de certains sous-parcours peut nécessiter plusieurs sprints. Cela est dû à un manque de vision commune et d'alignement entre le produit, le design et la tech. En effet, les POs manquent souvent de compétences tech pour spécifier la fonctionnalité et trouver les cas limites seuls.

Chez BAM, nous avons introduit depuis quelques années un atelier d’une heure, au lancement d'une fonctionnalité. Cet atelier réunit toutes les parties prenantes pour dessiner un schéma technico-fonctionnel. Avec un langage visuel inspiré de BPMN, nous dessinons tous les comportements utilisateurs, ainsi que leurs impacts techniques. Ce document constitue ensuite une base de départ commune pour écrire les user stories.

‍

Un schéma partagé entre tous les membres de l'équipe permet à la fois de :

• se mettre d'accord sur le scope exact de la fonctionnalité et d’en améliorer la compréhension commune ;
• faciliter la levée d'alerte en mettant en avant des zones d’ombre ;
• visualiser la complexité fonctionnelle et technique ;
• améliorer la QA et faciliter le débogage ;
• Accélérer l'onboarding fonctionnel des nouveaux membres de l'équipe.

Les bénéfices sont flagrants :

• on constate moins de bugs ;
• le lead time nécessaire pour sortir une fonctionnalité diminue ;
• on remarque un meilleur alignement entre les équipes ;
• une meilleure fiabilité des estimations ;
• un partage de connaissance entre les équipes de différents projets plus rapide.

À titre d'exemple, sur l’un de nos projets, cet atelier nous a permis de détecter une mécompréhension fonctionnelle qui aurait coûté 5 semaines de retard à l'équipe, si elle avait été détectée au cours de l'implémentation.

‍

NOTRE POINT DE VUE

Nous utilisons cette approche pour toute fonctionnalité complexe et nous vous invitons à la tester sur tous vos projets.

‍

HISTORIQUE 2022

Il s'agit d'un nouveau blip cette année.

Pour s'assurer qu'une unité de code, telle qu'une fonction ou une classe, fonctionne comme prévu, les développeurs peuvent écrire du code qui vérifie son comportement, c'est ce qu'on appelle un test unitaire. À partir des ces tests, on peut mesurer quelle proportion du code fonctionnel est testée, c'est la couverture de test.

​Écrire des tests unitaires permet d'améliorer la qualité du code d'un projet, de documenter et de faciliter les modifications du code existant. Cependant, cela peut prendre du temps, en particulier au démarrage d'un nouveau projet, ainsi que pour leur maintenance tout au long du développement.

​Chez BAM, nous encourageons nos équipes d'ingénieurs à écrire des tests, au fur et à mesure des développements. Certaines équipes ont relevé le défi de tester 100% de la base de code. 

Voici nos apprentissages :

‍

• Premièrement, tester 100% du code n'est pas toujours un indicateur de qualité. Nous n'avons pas observé une réduction significative du nombre de bugs entre les projets qui testent environ 80% de leur code, et ceux qui le testent à 100%.
• Ensuite, en début de projet, les équipes sont ralenties par l'écriture des tests. Mais au bout d'un mois ou deux, les tests permettent aux équipes d'itérer rapidement sur les fonctionnalités à développer et de modifier le code existant en toute confiance.

Enfin, tester 100% du code nous a ouvert des opportunités d'apprentissage :

• chaque fois qu'un membre de l'équipe développe un module, il doit se poser la question suivante : "Comment est-ce que je vais le tester ?". Le code doit être testable, ce qui incite l'équipe à mieux découper les composants, à ré-utiliser leur code et à injecter proprement les dépendances. Cela nous a également permis d'identifier et de supprimer les lignes de code inaccessibles ;
• pour tester une fonctionnalité, il est nécessaire de comprendre comment son implémentation fonctionne. En écrivant des tests, les développeurs approfondissent leurs connaissances sur les outils qu'ils utilisent ;
• en testant 100% du code, on découvre plus de cas à la marge, notamment dans les bibliothèques que l'on utilise. Ce sont des occasions idéales pour participer à l'open source. Sur nos projets, c'est grâce aux tests que plusieurs développeurs ont fait leurs premières contributions.

NOTRE POINT DE VUE

Nous vous conseillons d'essayer de tester à 100% votre code sur vos projets de moyen ou long terme. Même si cette stratégie n'est pas suffisante pour garantir la qualité, elle permet de former efficacement les équipes aux bonnes pratiques de développement.

‍

HISTORIQUE 2022

Il s'agit d'un nouveau blip cette année.

Comment savoir si votre app a une bonne performance ? Cette question est complexe pour plusieurs raisons, notamment car diverses métriques entrent en jeu : FPS, CPU, TTI, RAM... 

• les mesures de performance ne sont pas déterministes ; 
• les mesures sont coûteuses en temps et fastidieuses.

Flashlight se veut être une réponse à cette question (disclaimer : c’est un outil que nous développons). Flashlight donne un score de performance à votre app. Un peu comme Lighthouse mais pour les apps Android (iOS n’est pas supporté). Avec Flashlight, aucun setup dans l’app n’est requis pour mesurer sa performance. Ainsi, même les apps de production sont supportées, et ce, quelle que soit leur technologie (natif, React Native, Flutter...)

En revanche, Flashlight ne peut pas explorer l’app seul à ce stade. Par défaut, il délivrera facilement un score qui concerne le démarrage de l’app. Mais pour aller plus loin, vous aurez besoin de lui partager vos propres tests e2e. Flashlight va lancer ces tests plusieurs fois, agréger différentes métriques-clés et moyenner les résultats dans un rapport de performance.

Si vous n’avez pas de tests e2e, tirer profit de Flashlight peut s'avérer plus compliqué, mais nous recommandons l'usage de Maestro pour en mettre en place rapidement.

Le cœur de Flashlight est open source. Ainsi, vous pouvez l’utiliser sur votre propre device, mais une version cloud qui tourne sur un device bas de gamme Android est disponible en beta, pour simuler la réalité du marché. En quelques clics, Flashlight Cloud donne un score de performance à votre app et peut être intégré à une CI pour récupérer ce score régulièrement. La durée des tests peut être longue (plus de 10 min), ainsi nous ne conseillons pas de l’intégrer sur chaque pull request, mais plutôt de vérifier l’évolution du score sur le démarrage et quelques parcours critiques chaque semaine ou avant chaque release.

Nous vous invitons également à utiliser Flashlight pour évaluer l’impact de décisions technologiques majeures, ou comme indicateur pour vous aider dans une tâche d’amélioration de performances.

‍

HISTORIQUE 2022

Il s'agit d'un nouveau blip cette année.

Cet assistant de développement permet d'écrire du code plus vite, en proposant une autocompletion avec des bouts de code prêts à être utilisés.
En se basant sur OpenAI Codex, il analyse les commentaires et le code pour suggérer une implémentation.

Nous observons dernièrement une forte émulation autour de l'IA générative, notamment avec ChatGPT. Copilot fait partie de cette vague.

L'utilisation de Copilot est très efficace dans certains cas, notamment :

• l’implémentation d’algorithmes simples (ex : division, boucle, itération, tri) ;
• les tâches répétitives (ex : la création des serializers ou appels API) ;
• Les recommandations des interfaces ou modèles typiques (ex : Country, Person) ;
• la proposition des test cases standards dans les tests unitaires.

Depuis son apparition, nous évaluons ses impacts sur le quotidien des développeurs et tirons plusieurs apprentissages. Ce produit assure une forte rétention des utilisateurs. Parmi les développeurs interrogés, 80% ont attribué une note NPS de 9 ou plus sur 10. Parmi les retours obtenus, on relève un gain de temps sur les tâches récurrentes. 72% des interrogés ont attribué la note 5/5 à la question : "Trouves-tu que copilot t'aide à écrire plus vite ?". On note également 3 retombées positives sur l'apprentissage :

• Copilot facilite la productivité dans un environnement méconnu ;
• il favorise la découverte de nouvelles solutions, bénéfiques aux personnes déjà expérimentées pour leur progression ;
• il agit comme un premier lecteur de code, évaluant le naming grâce aux suggestions générées.

Le ralentissement de la formation des profils intermédiaires est observé car il est plus facile d'obtenir un code fonctionnel sans une réelle compréhension. Malgré cela, nous croyons aux impacts positifs de Copilot sur la productivité. Les risques peuvent être gérés efficacement avec l'aide d'un Tech Leader.

‍

NOTRE POINT DE VUE

Nous vous recommandons d'explorer l'utilisation de Copilot dans votre organisation. Il est important de noter que ce secteur dynamique compte plusieurs concurrents, comme Tabnine, qui méritent également d'être évalués.

‍

HISTORIQUE 2022

Assess  - Voir le Tech Radar 2022

Nous avons mentionné Appium dans notre précédent Tech Radar, comme framework de tests e2e. Maestro se présente comme une nouvelle solution alternative qui tire profit des apprentissages de ses prédécesseurs. Et contrairement à une simple promesse, Maestro garde les avantages majeurs d'Appium sans ses inconvénients. En effet, contrairement à Appium, la documentation de Maestro est excellente, ce qui permet de créer un test e2e assez poussé en moins de 30 minutes. L'API est bien pensée et fournit de base les fonctionnalités essentielles à l'écriture de tests e2e (scroll, click, attendre une apparition d'élément). De plus, Maestro fonctionne (à l'instar d'Appium) en mode boîte noire. En d’autres termes, vous pouvez lancer un script de tests Maestro sur n'importe quelle app, sans aucune setup préalable. Cela inclut votre release candidate ou même votre app de production depuis les stores.

Maestro dispose également d'une version cloud, qui permet d'avoir rapidement et simplement une CI avec tests, enregistrements d'écrans et logs

Maestro est encore jeune, et nous avons parfois rencontré quelques bugs dans certaines versions, ainsi que des lenteurs sur iOS. Maestro est par ailleurs moins facilement extensible qu'Appium pour rajouter des comportements qui sortent de l'ordinaire (comme lancer une commande adb ou simuler un scroll ultra-rapide).

‍

NOTRE POINT DE VUE

Maestro pourrait rapidement devenir le standard du marché car l'équipe ajoute constamment des nouvelles fonctionnalités qui révolutionnent l'écriture de tests. Notre nouveauté préférée ? ++code>maestro studio++/code> qui permet quasiment d'écrire les tests à notre place ! Nous vous recommandons donc son utilisation si vous n'avez pas déjà de tests e2e mis en place. C'est d'ailleurs la solution recommandée par Flashlight pour effectuer des tests e2e de performance.

‍

HISTORIQUE 2022

Il s'agit d'un nouveau blip cette année.

Notre démarche de post-mortems QRQC nous a permis de constater que les bugs sont détectés bien trop tard. Les problèmes simples à détecter sont adressés dans le processus de validation et la QA, mais les défauts formateurs sont souvent découverts après quelques mois ou années. Cela limite les opportunités d'apprentissage et d'amélioration.

Nous avons été inspirés par le livre The Toyota Way of Dantotsu Radical Quality Improvement de Sadao Nomura. Il propose une classification des défauts selon le stade de leur détection allant de A (détecté pendant une tâche) à D (détecté par un utilisateur en production).

Alors que nous ne focalisions notre approche QRQC que sur les défauts de type D, la démarche Dantotsu propose de réagir sur les défauts détectés à chaque étape : plus il est détecté tard dans le flux, plus il devient coûteux de le corriger et d'empêcher la mauvaise pratique de se diffuser dans le code.

Nous avons adopté cette classification et expérimenté une démarche d'analyse des défauts de type A, que nous avons nommé "Right First Time". Elle se compose de 3 étapes clés :

• préparer la stratégie technique avant de coder ;
• écrire tout le code, préférablement en TDD ;
• lancer le simulateur pour tester la fonctionnalité une fois la stratégie technique implémentée.

Si le code ne fonctionne pas du premier coup, il s'agit d'un défaut de type A. Nous notons ce défaut et le nombre d'essais requis pour valider les besoins fonctionnels attendus. À la fin du ticket, la personne qui l'a implémenté identifie les apprentissages à en tirer (ex : en analysant les hypothèses erronées de la stratégie initiale).

Les premiers résultats sont encourageants :

• les projets présentent moins de bugs ;
• l'équipe progresse plus vite ;
• elle délivre les fonctionnalités plus vite en limitant le context switching.

La principale limite constatée est l'extrême rigueur requise pour appliquer cette méthode, ce qui complique son application quotidienne par les équipes.Nous étudions comment la simplifier et quels supports créer pour faciliter son adoption.

NOTRE POINT DE VUE

Malgré ces freins, nous vous encourageons à mener des tests chez vous sur des défauts de type A et observer les discussions et apprentissages que cela génère. Pour en savoir plus sur cette méthode, vous pouvez lire le livre de Sadao Nomura et regarder la conférence de Fabrice Bernhard.

‍

HISTORIQUE 2022

Il s'agit d'un nouveau blip cette année.

Créer des animations uniquement avec du code représente un défi pour les développeurs mobiles, en raison de la complexité liée à la synchronisation de nombreux éléments et à la gestion d'un important volume de code. La variété des plateformes et frameworks complique également la création d'animations cohérentes et réutilisables. De plus, la plupart des solutions existantes ne permettent pas d'interagir directement avec les animations via le code, rendant impossible les réactions aux interactions de l’utilisateur et aux éventuels changements d'état de l'application.

Rive est une solution qui répond à ces besoins et simplifie l'intégration d'animations pour les développeurs, compatible avec la plupart des frameworks et plateformes. De plus, l'éditeur propose une interface utilisateur intuitive et supporte l'import d'animations provenant d'autres logiciels tels que Lottie.

Les animations créées avec Rive peuvent réagir aux clics, aux mouvements ou aux changements d'état en fonction des données reçues, offrant ainsi une expérience utilisateur dynamique et immersive. Un autre avantage de Rive est l'optimisation de la taille des animations, qui peuvent être 10 fois plus légères qu'un fichier Lottie, garantissant des performances améliorées pour les applications mobiles.

L'outil Rive se positionne comme un compétiteur solide face aux autres solutions de création d'animations grâce à ses meilleures performances et APIs plus développées. Le moteur de rendu et les lecteurs étant open source, ils offrent une flexibilité et adaptabilité accrues pour répondre aux besoins spécifiques des projets.

‍

NOTRE POINT DE VUE

Malgré certains aspects financiers et techniques liés à l'utilisation de Rive, tels que l'abonnement de 14$ par utilisateur par mois et la compatibilité avec iOS 14 minimum pour les applications natives, nous vous recommandons d'utiliser Rive pour créer des animations interactives de haute qualité.

‍

HISTORIQUE 2022

Il s'agit d'un nouveau blip cette année.

Les IA génératives ont connu une adoption croissante ces derniers mois. En tête du peloton : ChatGPT. Il existe de nombreux cas d'utilisation, les plus répandus sur internet sont les suivants : co-création d'articles marketing, écriture et synthèse automatique d'emails ou encore création de code. ChatGPT n'est pas un outil de code à proprement parler, il y a des modèles spécialement conçus pour cela :

• A titre d’exemple, OpenAI Codex qui est derrière GitHub Copilot. De nombreuses personnes ont néanmoins réussi à obtenir des résultats très intéressants.
• Pour citer quelques cas : un plugin Chrome qui permet d'afficher ChatGPT ou un bot de trading codé en Python. Tous les deux codés grâce à ChatGPT. 
  

Les réussites partagées sont néanmoins sujettes au biais de sélection : nous voyons les quelques résultats impressionnants, mais nous ne voyons pas forcément tous les échecs. Dans nos tests, nous avons observé que plusieurs solutions ne sont tout simplement pas fonctionnelles, ou alors qu'elles contiennent des bugs subtils. Toute solution donnée par ChatGPT doit donc être relue et validée attentivement. Sans parler de la pertinence de la réponse, étant donné que le contexte de la codebase actuelle n'est pas forcément facile à inclure. L'amélioration de la productivité est donc limitée à des cas d'usage bien précis. Les cas qui s'y prêtent bien sont soit des solutions standards dans une technologie (formulaire de login, image centrée) soit des questions haut niveau sur les pratiques adoptées par la communauté.

Nous pensons que ces problèmes seront à terme résolus car l'écosystème évolue rapidement. Certaines solutions pourraient par exemple composer ChatGPT avec de l'IA spécialisée dans le code ou ajouter des systèmes de vérification automatiques. L'utilisation des outils tels que ChatGPT est donc sûrement une tendance à observer attentivement.

‍

NOTRE POINT DE VUE

Entre-temps, nous vous conseillons de chercher à renforcer vos compétences en Prompt Engineering et fine-tuning, les deux compétences clés pour profiter pleinement de cette vague de l'IA.

‍

HISTORIQUE 2022

Il s'agit d'un nouveau blip cette année.

En 2022, on enregistrait 6.6 milliards de souscriptions aux réseaux de téléphonies mobiles. Sur cette même période, un tiers des entreprises ont subi des temps d'arrêt importants ou des pertes de données en raison d'une compromission liée à un appareil mobile. Face à ce constat, il est primordial pour les développeurs d'applications mobiles d'intégrer la sécurisation de leurs apps dès la phase de conception.

L'an dernier, nous avons présenté CVSS, une norme évaluant la gravité des vulnérabilités sur une échelle de 0 à 10. Toutefois, cette norme ne fournit pas d'indications sur les éléments à rechercher. Sans une solide expérience en matière de sécurité, il est difficile de savoir par où commencer. 

Le Mobile Application Security Verification Standard (MASVS) d'OWASP est une norme de sécurité pour les applications mobiles. Sa version 1.5 est séparée en 2 niveaux, chacun couvrant des contrôles de sécurité de plus en plus avancés :

• Niveau L1 : Sécurité Standard ;
• Niveau L2 : Défense en profondeur destinée aux apps manipulant des données hautement sensibles.

Ces niveaux peuvent être complétés par un ensemble de contrôles (le niveau R) visant à renforcer la résilience face à la rétro-ingénierie, la manipulation et le modage de votre application. On obtient ainsi 4 niveaux de sécurisation : MASVS-L1, MASVS-L1+R, MASVS-L2 et MASVS-L2+R.

Ils regroupent au total 84 points de contrôle de sécurité touchant différents domaines, comme le stockage des données, l'authentification et les communications réseau. Pour chaque point de contrôle, des guides et des outils sont proposés pour explorer et corriger les éventuelles failles de sécurité. Actuellement en cours de déploiement, la version 2.0 simplifie les points de contrôle et aligne la définition des niveaux de sécurité avec le format OSCAL.

‍

NOTRE POINT DE VUE

Nous avons introduit MASVS v1.5 par le biais d'un projet où la sécurité est un enjeu majeur. Cette solution permet notamment de mieux collaborer avec les auditeurs sécurité. Cet essai nous a convaincu de la pertinence du standard et nous sommes en train de le déployer à plus grande échelle afin de renforcer la sécurité de l'ensemble de nos applications.

‍

HISTORIQUE 2022

Il s'agit d'un nouveau blip cette année.

Il y a encore quelques années, no-code mobile était une fausse piste. Très souvent basées sur du web, les solutions laissaient à désirer en termes de qualité et de performance. Elles étaient appropriées surtout pour des POC ou des outils internes à faibles enjeux où l'expérience utilisateur n'était pas la priorité.

L'écosystème a récemment connu une belle avancée avec de nouveaux outils basés sur Flutter (comme FlutterFlow) ou React Native (comme draftbit). 

Même s'ils ne sont pas encore très matures, nous avons déjà eu des expériences très positives avec, comparé à la génération précédente. Les interfaces offrent une flexibilité suffisante pour les cas d'usage standards et la possibilité d'exporter le code permet d'éviter le lock-in.

‍

NOTRE POINT DE VUE

Avoir des alternatives à des solutions basées sur des WebViews permet de mieux répondre aux attentes des utilisateurs. Nous vous recommandons de les regarder et essayer pour des projets à petit budget, cela vaut le détour.

‍

HISTORIQUE 2022

Il s'agit d'un nouveau blip cette année.

Dans le processus de développement d'une fonctionnalité, la relecture du code est une étape clé pour garantir sa qualité et sa conformité aux normes de l'équipe.

Toutefois, ajouter une étape de contrôle pour chaque relecture bloque le développeur et nuit à la productivité. Pour éviter cela, Rouan Wilsenach propose (sur ce blog) une approche intitulée "Ship, Show and Ask". Elle consiste pour chaque changement à choisir parmi ces trois options :

• Ship : créer une branche poussée sans relecture pour les changements mineurs et standardisés ;
• Show : créer une branche avec une pull-request et merger sans attendre la relecture pour les changements qui ne sont pas critiques, mais nécessitent une relecture ultérieure ; ainsi que pour les changements faits en équipe (duo ou ensemble programming) ;
• Ask : créer une branche avec une pull-request et attendre la relecture avant de merger pour les changements critiques ou incertains qui nécessitent l'avis d'un collègue.

Récemment, nous avons testé cette approche sur trois projets avec des équipes expérimentées. Elle a permis de réduire le temps de relecture des pull-requests, de favoriser une réflexion plus approfondie sur le sens de chaque pull-request en redonnant la responsabilité au développeur et de chercher le consensus de la solution avant de coder plutôt qu’après. Les demandes de relecture Ask systématiques sont descendues à près de 50% depuis cette mise en place. Nous n'avons pas constaté de baisse de la qualité du code. 

Cette expérimentation est limitée par le manque de recul de par son utilisation récente chez BAM, la qualité déjà élevée du code et de la conception technique ainsi que la maturité de l’outillage (CI, tests unitaires) mis en place.

‍

NOTRE POINT DE VUE

La relecture de code est une étape intéressante pour aligner l'équipe sur le code à fournir. En revanche nous vous encourageons à réfléchir à la qualité de façon globale et sélectionner les outils (code review, tests, intégration continue, conception, pair programming, ensemble programming, etc.) les plus aptes à garantir la qualité de chaque changement selon la maturité de vos équipes et de vos process.

‍

HISTORIQUE 2022

Il s'agit d'un nouveau blip cette année.

Dans le cycle de développement d'une feature, l'étape de relecture (ou code review) est une étape essentielle. Elle permet de s'assurer que le code produit est de bonne qualité, et qu'il est conforme aux standards de l'équipe.

​

Une dérive courante est de pousser cette standardisation à l'extrême, et d'instaurer une liste toujours plus longue de règles à respecter. Les développeurs finiront par ne plus lire les règles, cocher machinalement les cases et ne plus réfléchir aux impacts de leur code.

Pour éviter cette dérive, nous avons testé de remplacer la liste de règles par une section "test plan" dans laquelle les développeurs doivent décrire les tests qu'ils ont effectués pour valider leur code. Cette section est inspirée des pratiques de "test plan" popularisées par Meta pour contribuer aux projets open source. 

​

Comme la section "test plan" est libre, les développeurs peuvent décrire ce qui fait le plus de sens dans le contexte du projet et du ticket : en pratique, nous avons vu par exemple des études de query plan PostgreSQL pour assurer la performance des index, des tests d'accessibilité d'une page mobile à un lecteur d'écran ou encore des tests de performance de la page web. Ceci crée des discussions intéressantes entre le développeur et le reviewer lors de l'étape de code review d'une part, et permet d'autre part d'apprendre plus lors d'un post-mortem sur un bug (QRQC).

​

Mais, comme la documentation, la section "test plan" demande un effort et une rigueur supplémentaires. Au fil du temps, la qualité de cette section est devenue de plus en plus variable sur nos projets.

‍

NOTRE POINT DE VUE

Nous pensons néanmoins que cette section est un bon compromis entre la liste de règles obligatoires et l'absence de “check qualité” documenté dans la pull-request. Nous recommandons donc d'essayer cette approche sur vos projets, et de l'adapter à vos besoins.

‍

Il s'agit d'un nouveau blip cette année.