Tech Radar Transverse

Chez Theodo, nous appliquons une approche Lean avec des déploiements continus et des tâches découpées pouvant être terminées en une journée, évitant les effets de batching. Le trunk-based development, où les développeurs intègrent fréquemment leurs modifications sur la branche principale, est au cœur de notre processus, mais reste difficile à appliquer dans le mobile à cause des cycles de validation des stores.

Pour mettre en place un flux de travail efficace et avoir un contrôle fin des applications en production, les feature toggles sont essentiels. Il existe plusieurs types de feature toggles, notamment les permissions toggles et les A/B testing toggles, qui ont une utilité métier spécifique. Ce sont les release toggles et les operational toggles qui facilitent les pratiques Lean de développement.

Les release toggles, intégrés directement dans le code, permettent de merger des fonctionnalités en cours de construction sans les activer pour les utilisateurs finaux. Cela facilite l'intégration continue et limite le nombre de branches et d'environnements nécessaires au développement.

Les operational toggles, configurés de manière distante et récupérés au runtime, permettent de désactiver rapidement une fonctionnalité problématique ou obsolète sans nécessiter un nouveau déploiement. Cette flexibilité accrue est cruciale pour réagir rapidement aux incidents en production et maintenir la stabilité de l'application.

Les feature toggles ajoutent de la complexité au code, surtout lorsqu'ils sont interdépendants, multipliant les scénarios de test possibles. Pour éviter que cela ne devienne ingérable, il est essentiel de suivre certaines bonnes pratiques :

• Pour se prévenir de l'interdépendance des toggles, il est recommandé de ne pas associer plusieurs toggles à la même fonctionnalité. De plus, il est essentiel de tester unitairement les différents chemins que peut prendre le code togglé, ce qui permet de s'assurer que chaque combinaison possible fonctionne correctement. Lors d'un déploiement, il est également judicieux de ne pas changer l'état de trop de toggles en même temps, afin de limiter les risques de conflits et de régressions.
• Pour garantir une intégration continue efficace, il est pertinent de changer un release toggle en operational toggle lorsqu'une fonctionnalité est prête à être déployée. Cela permet de maintenir une continuité fonctionnelle du toggle, facilitant ainsi les tests, les mises à jour et les déploiements sans interruption majeure.
• Documenter les toggles est essentiel pour une maintenance à long terme. La durée de vie des toggles peut varier de quelques semaines à plusieurs années, et sans une documentation adéquate, il peut être difficile pour les développeurs de comprendre leur utilisation et leur état.
• Connaître l'état des toggles en production est également crucial. Pour cela, il est important de versionner les release toggles, ce qui permet de garantir des builds d'application déterministes. Une console interactive, pour les operational toggles, telle que Firebase Remote Config, peut être utilisée pour surveiller et modifier l'état des toggles en temps réel.
• Enfin, choisir une fréquence des mises à jour adéquate côté applicatif des toggles dynamiques permet de maintenir la capacité de réagir rapidement en cas d'incident.

Comment savoir si votre app a de bonnes performances ? Cette question est complexe, notamment à cause de la multiplicité des métriques (FPS, TTI, RAM...), et du non déterminisme des mesures.

Flashlight, que nous développons, se veut être une réponse à cette question pour Android. Flashlight donne en temps réel un score de performance à votre app, sans aucune mise en place préliminaire dans l'app. Ainsi, à la différence de la plupart des outils existants, même les apps de production sont supportées, quelle que soit leur technologie.

Pour aller plus loin, Flashlight peut lancer vos tests E2E plusieurs fois, agréger différentes métriques et moyenner les résultats dans un rapport avec un score attribué. Avantages par rapport à d'autres outils : ce score donne une vue d'ensemble sur la performance facile à comprendre et la vue de comparaison permet d'évaluer l'impact d'un changement dans l'app.

Le cœur de Flashlight est open source. Vous pouvez donc effectuer vos mesures en local avec votre propre device, mais il existe également une version cloud qui tourne sur un vrai device Android et peut être intégrée à une CI pour récupérer un score régulièrement. Néanmoins, il faudra lui fournir vos propres tests E2E (seul Maestro est supporté), ce qui peut s'avérer fastidieux.

Nous utilisons Flashlight comme indicateur dans des tâches d'amélioration de performance, qui nous a permis d'améliorer la fluidité du scroll d'une app React Native ou de réduire le temps de démarrage d'une app Flutter.

Flashlight nous a aussi permis d'éviter des régressions de performance sur nos projets, en détectant par exemple une consommation CPU anormale suite à l'installation d'un SDK.
Enfin, Flashlight est utilisé en collaboration avec Meta pour le suivi des performances du framework React Native.

L'écriture manuelle d'un client d'API REST est une tâche chronophage, qui apporte peu de valeur ajoutée aux utilisateurs. Ce temps qui n'est pas passé à des occupations plus créatives ou utiles est souvent source de frustration pour les développeurs. De plus, la répétitivité de cette tâche peut entraîner des pertes d'attention et des erreurs dans la traduction des spécifications d'API en code fonctionnel.

Des outils comme OpenAPI Generator permettent de résoudre ces problèmes. Cette approche permet de générer automatiquement le code client à partir de spécifications d'API en se passant de toute intervention manuelle.

Cette pratique présente quelques limitations :

• Les outils de génération ne supportent pas toujours l'entièreté des spécifications OpenAPI, c'est le cas par exemple des oneOf/allOf lors de la génération de client Dart.
• Le code généré peut être incorrect ou incomplet, notamment lorsque le générateur est confrontée à des spécifications partielles ou déphasées par rapport à l'implémentation réelle de l'API spécifiée.

Cependant, cette dernière limitation ouvre en réalité la voie à une meilleure collaboration et compréhension entre les équipes de développement : en sachant que leurs spécifications seront utilisées pour générer automatiquement du code client, les développeurs backend sont incités à respecter rigoureusement les normes OpenAPI et à fournir des spécifications claires et précises. Cela améliore la qualité du code généré, la documentation et la maintenabilité des API en plus de favoriser une culture de collaboration et de qualité au sein des équipes.

Les designers incorporent de plus en plus d’animations dans leurs interfaces pour augmenter la qualité perçue d’un produit et générer de l’émotion chez les utilisateurs.

Cependant, créer des animations 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.

Une autre approche consiste à intégrer des assets animés, mais la plupart des solutions existantes ne permettent pas d’interagir directement avec les animations via le code, rendant impossible (ou très compliqué) 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 par une fine compréhension du processus de production des interfaces digitales, en proposant notamment un pipeline de production unifiée entre designers et développeurs.

• Côté design, Rive élimine la nécessité d’utiliser plusieurs outils comme illustrator ou After Effect. L’éditeur permet de concevoir et d’animer au sein d'une même interface et facilite la transmission d’assets.
• Côté technique, Rive réduit les allers-retours avec les designers, élimine les problématiques de fichiers corrompus et simplifie l’intégration d’animations interactives avec des state-machines intégrées.

Rive rend la collaboration entre designers et développeurs plus fluide, réduit les erreurs et accélère le processus de production.

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. Rive optimise ses fichiers pour les rendre jusqu’à 10 fois plus légers que les fichiers Lottie. De plus, il limite l’impact sur la codebase en intégrant la state-machine directement dans le fichier.

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 API 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.

Nous sommes constamment à la recherche d'outils qui simplifient le développement backend tout en offrant des fonctionnalités robustes. Supabase a retenu notre attention en tant que plateforme open-source de backend-as-a-service (BaaS) qui facilite considérablement l'intégration de systèmes d'authentification complexes et la gestion de l'infrastructure backend.

Supabase se distingue en utilisant PostgreSQL, offrant une flexibilité pour des requêtes complexes et la gestion des données. Son système d'authentification est hautement configurable, prenant en charge les emails/mots de passe, les liens magiques et les fournisseurs tiers. La qualité de ses SDK garantit un développement fluide sur diverses plateformes, et son intégration avec les frameworks front-end améliore l'accessibilité pour les développeurs.

Supabase permet d'écrire des edge functions serverless basées sur Deno et de gérer la sécurité de manière fine avec les RLS. Cela améliore les performances, la sécurité et la scalabilité, ce qui le rend adapté aux exigences des applications modernes. Les capacités d'auto-hébergement de Supabase offrent potentiellement un contrôle total sur les données et l'infrastructure, répondant aux besoins de confidentialité et de personnalisation.

Compte tenu de ces atouts, nous plaçons Supabase dans la catégorie Adopt. Ses fonctionnalités robustes, sa facilité d'utilisation et son caractère open-source en font un choix exceptionnel pour les développeurs. Supabase simplifie non seulement le développement backend, mais offre également des fonctionnalités avancées essentielles pour les applications à grande échelle. 

Le défi d'assurer la cohérence de l'UI d'une application mobile est un casse-tête pour tous les développeurs. Cette difficulté est accentuée par la multitude d'appareils (téléphones, tablettes, téléviseurs, ...), d'orientations et de tailles d'écran, rendant les tests de régression manuels presque impossibles. Le Snapshotting UI offre une solution moderne à ces défis.

Le Snapshotting UI consiste à capturer des snapshots de l'UI de votre application dans divers états et à les stocker dans votre codebase. Lorsqu'un changement est apporté, ces snapshots sont comparés à l'interface actuelle pour détecter toute modification non intentionnelle.

Nous avons utilisé le Snapshotting UI sur plusieurs plateformes, chacune ayant un degré de maturité différent :

• Flutter : La plus avancée, offrant des tests de snapshots intégrés avec Flutter goldens. Cela ne nécessite pas d'émulateurs, rendant les tests extrêmement rapides.
• Android natif : Nous utilisons la bibliothèque Paparazzi qui capture des snapshots d'UI et teste les régressions sans utiliser d'émulateurs.
• iOS natif : Bien que la bibliothèque swift-snapshot-testing repose sur des simulateurs, elle est suffisamment rapide pour avoir un impact minime sur notre CI.
• React Native : Cette plateforme manque d'une solution mature. Les tests de snapshots de l'UI nécessitent une configuration supplémentaire et s'appuient généralement sur des tests end-to-end sur émulateurs associés à jest-image-snapshot.

Un défi majeur que nous avons rencontré est l'incohérence des snapshots entre les différentes architectures CPU, simulateurs et systèmes d'exploitation, ce qui peut entraîner des écarts dans l'environnement de CI. Pour atténuer cela, nous pouvons réduire la précision de la configuration afin d'obtenir des snapshots cohérents sur la CI.

Dans Dantotsu Radical Quality, Sadao Nomura propose de classer les défauts selon leur étape de détection, plutôt que leur gravité ou leur urgence. Nous avons développé ses idées dans The Lean Tech Manifesto, en suggérant cinq étapes :

A. Détecté avant la mise en production par le développeur

B. Détecté avant d'atteindre un client interne (revues de code, intégration continue)

C. Détecté avant la mise en production (revues fonctionnelles)

D. Détecté après la mise en production mais avant une plainte (déploiement continu, monitoring)

E. Détecté par un utilisateur

Cette approche contraste fortement avec la pratique courante de l'industrie, où les bugs sont classés par gravité, et où seuls les plus critiques sont traités et analysés.

Détecter les défauts tôt et en discuter présente plusieurs avantages :

• Les bugs récents sont frais dans l'esprit du créateur, facilitant l'analyse et l'apprentissage.
• On évite que la personne ayant introduit le bug soit partie, empêchant tout apprentissage.
• Les bugs mineurs révèlent souvent des méconnaissances pouvant causer des problèmes plus graves; les traiter améliore la stabilité globale.

Chez Theodo, nous avons progressivement inclus les étapes 1 à 3 dans notre analyse et visons à réduire les bugs détectés tardivement (4 et 5) en les identifiant plus tôt. Nous pensons qu'une augmentation des détections aux premières étapes est positive, si cela permet de réduire celles des étapes ultérieures. Cela présente plusieurs avantages :

• L'équipe traite les obstacles plus tôt, améliorant la productivité globale.
• Nous réduisons le coût de correction des défauts.
• L'équipe génère des connaissances plus rapidement.
• La qualité du produit final s'améliore.

Faire des tests E2E pour des applications mobiles, en particulier pour React Native et Flutter, est fastidieux. Appium (et Detox) ont leurs atouts, mais ils sont souvent complexes à utiliser, peu intuitifs et peuvent être difficiles à automatiser sur la CI/CD.

Maestro est un nouveau framework de test d'interface utilisateur mobile très efficace. Bien qu'il ne dispose peut-être pas d'un ensemble de fonctionnalités aussi complet qu'Appium, c'est un choix idéal pour ceux qui débutent dans les tests E2E grâce à son setup minimal et à sa mise en œuvre rapide. Vous pouvez faire tourner votre premier test en seulement 15 minutes. Maestro comprend aussi une interface graphique (Maestro Studio) qui vous permet de sélectionner visuellement des éléments de l'interface utilisateur et propose des suggestions sur la manière d'interagir avec ces éléments dans vos tests. De plus, Maestro possède son propre service cloud intégré appelé Maestro Cloud. Pas besoin de configurer des simulateurs, il vous suffit d'uploader votre application et vos tests, et ils se chargent du reste (rapports, exécution parallèle, prévention des erreurs intermittentes, enregistrements d'écran, logs, etc.).

En 2023, la sécurité des applications mobiles est plus que jamais une priorité, face à des menaces en constante évolution. Avec 7 milliards de souscriptions aux réseaux mobiles et un tiers des entreprises subissant des interruptions ou des pertes de données dues à des compromissions sur des appareils mobiles, il est essentiel pour les développeurs d'intégrer la sécurité dès la phase de conception de leurs applications.

Le Mobile Application Security Verification Standard (MASVS) d'OWASP, un standard incontournable pour la sécurité des applications mobiles, a récemment évolué avec les versions 2.0 et 2.1. MASVS 1.5 se composait de 84 points de contrôle répartis en 7 catégories couvrant des domaines critiques tels que le stockage des données, l'authentification, et les communications réseau.

La version 2.0 de MASVS a apporté des simplifications significatives, éliminant les redondances et adoptant des terminologies standardisées comme OSCAL. Le résultat est une liste rationalisée de 22 points de contrôle, offrant une approche plus claire et concise.

L'une des innovations majeures de MASVS 2.0 est l'introduction des profils MAS. Ces profils configurent les tests de sécurité en fonction des exigences spécifiques de l'application, en tenant compte de son niveau de sensibilité. Les tests associés sont décrits en détail dans le guide de test (MASTG), qui fournit des conseils techniques pratiques pour valider les 22 points de contrôles de sécurité.

La version 2.1 a enrichi le standard avec la catégorie MASVS-PRIVACY, essentielle pour aider les développeurs à se conformer aux réglementations de protection des données, comme le RGPD.

Pendant le développement d'une fonctionnalité, la relecture du code est cruciale pour garantir sa qualité et sa conformité aux normes de l'équipe. Toutefois, un contrôle systématique peut ralentir les développeurs.

Pour éviter cela, Rouan Wilsenach propose 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.

Nous avons parlé de cette pratique l'année dernière et elle fait partie désormais de nos standards. Nous avons diminué le temps passé sur les code reviews sans pour autant diminuer la qualité du code.

Tout comme la relecture de code, le pair / ensemble programming, Ship / Show / Ask est un moyen de communication entre un manager et un managé. C'est au Tech Lead d'utiliser cette méthode à bon escient pour garantir la cohérence du code, la progression des développeurs et la capacité de l'équipe à délivrer des fonctionnalités rapidement. Il lui revient la responsabilité de définir des règles pour améliorer la qualité.

Gérer une équipe technique en croissance est un défi. À mesure qu’elle se développe, avec plusieurs projets, différentes technologies et différents contextes, il devient difficile de s’assurer que tout le monde est aligné sur le plus important, et encore plus difficile d’assurer la collaboration et le partage des connaissances inter équipes. Chaque Engineering Manager travaille dur avec son équipe, tandis que d’autres rencontrent les mêmes problèmes de l'autre côté de l’open space.

Le Weekly Engineering Review est un rituel qui rassemble tous les Engineering Managers et Staff Engineers de l’entreprise. Ce principe est fortement inspiré par le Weekly Business Review d’Amazon. L’objectif est de garantir un alignement fort de tous les leaders techniques sur des indicateurs de performance communs et de favoriser le partage des connaissances et la collaboration entre les différentes équipes. La réunion est structurée autour d’un ensemble de KPIs qui agrègent la performance de toutes les équipes techniques dans différents domaines : livraison, qualité, santé de l’équipe… Les KPIs dépendent du contexte, ils peuvent donc et doivent évoluer au fil du temps pour refléter les défis actuels et s’aligner avec les enjeux business de l’entreprise. L'aspect hebdomadaire permet à chaque leader technique de maintenir un focus fort sur les objectifs et les aide à aligner le travail quotidien de leurs équipes avec ces derniers. Un responsable est assigné à chaque KPI pour s’assurer que les données sont collectées, que le KPI est mis à jour chaque semaine en amont de la réunion et commenter les variations. Enfin, la WER est structurée par un facilitateur qui veille à ce que chaque KPI soit préparé et que la réunion se déroule efficacement.

Chez Theodo Apps, nous avons mis en place la WER depuis 6 mois. Nous avons suivi des KPIs tels que le nombre de bugs non résolus, le coût de chaque écran développé dans nos projets, le nombre de CFP envoyés par nos ingénieurs pour des conférences, le nombre de partages d’apprentissages inter équipes ou encore le nombre d’ingénieurs ayant participé à des bootcamps ou formations.

Après quelques mois de fonctionnement de la WER, nous avons constaté un impact mitigé. Certains KPIs ont été efficacement impactés à la hausse, comme la participation aux formations ou le nombre de défauts analysés par les chefs d’équipe pour mieux comprendre l'origine de bugs. D’autres KPIs, comme le nombre de CFPs envoyés, n’ont pas connu d'évolution significative.

Indépendamment de son impact direct, la WER se révèle être un moyen efficace pour créer une véritable équipe de leaders techniques qui opéraient auparavant dans des silos. Le retour de tous les participants est très positif quant au sentiment d’appartenance à une équipe générée.

En développant pour Kotlin Multiplatform (KMP), les développeurs doivent jongler entre Android Studio pour Kotlin et Xcode pour Swift, ce qui perturbe le flux de travail, augmente les changements de contexte et peut entraîner des conflits de synchronisation lors de l'édition de fichiers dans l'un des éditeurs. Fleet, un IDE de JetBrains, a été créé pour faciliter l'utilisation de KMP. Il résout ces problèmes en permettant aux développeurs de gérer le code des deux langages dans un seul IDE sans avoir besoin d'utiliser d'autres éditeurs.

En tant que fournisseur de confiance d'outils comme IntelliJ et Android Studio, JetBrains garantit une meilleure efficacité pour les développeurs multiplateformes avec Fleet. L'IDE offre des fonctionnalités telles que l'auto-complétion et une navigation dans le code qui surpassent même celle de Xcode. Cependant, Fleet est encore en version préliminaire et présente certaines limitations, notamment l'absence de fonctionnalités et des problèmes de stabilité. Par exemple, il n'est pas possible d'ajouter des plugins, ce qui signifie que vous ne pouvez pas utiliser Copilot, mais JetBrains propose une alternative d'auto-complétion basée sur l'IA.

Il y a quelques années, les Progressive Web Apps (PWA) étaient très en vogue. Certains allaient même jusqu'à prédire la fin des applications mobiles, et quelques études de cas ont présenté des arguments convaincants en faveur des PWA.

Cependant, les applications universelles ont mûri entre-temps, tandis que les PWA n'ont jamais vraiment décollé. Leur adoption a été freinée par un manque de support sur iOS, des problèmes de découvrabilité, des difficultés à gagner la confiance des utilisateurs et des fonctionnalités manquantes pour les développeurs.

Le fait que le PWA Summit n'ait eu lieu que deux fois et n'ait pas été reconduit en 2023 est un signe que les PWA perdent de leur élan. Certains acteurs les utilisent encore avec succès, et de nouvelles PWA sont régulièrement déployées, mais nous pensons qu'elles ne constituent plus une stratégie mobile solide.