C'est Quoi La DX Et Pourquoi Cela Est Important ?
La Developer Experience (DX) est une discipline récente, mais qui mérite que l’on s’y attarde.
Paradoxalement, le développeur est souvent le parent pauvre du mouvement Agile alors que la cible première
était bien ce dernier. Là où la User Experience (UX) se propose d’améliorer l’expérience utilisateur en la rendant
la plus simple et cohérente possible, la DX remplace l’utilisateur final par le développeur. La DX fait partie de la
philosophie DevOps mais centrée sur le Dev au lieu de l’Ops. Elle vient en complément du “CraftmanShip” où le développeur
agit sur la qualité du code. Avec la DX, c’est l’entreprise qui agit pour améliorer l’expérience utilisateur de ses développeurs.
L’intérêt d’une bonne DX
Avoir une expérience du développeur au top va avoir les effets suivants :
- Une augmentation de la productivité
- Une meilleure rétention des développeurs.
- Une intégration plus rapide des nouveaux développeurs.
Meilleure productivité
Limiter les frictions au quotidien pour les développeurs leur permet de se concentrer sur le métier de l’application. La charge mentale et les changements de contexte (véritables ennemis du développeur) diminuent. Gagner 10 minutes par jour peut sembler peu, mais répéter tous les jours sur une équipe de 5 développeurs équivaut à 2 jours de travail par mois pour un développeur.
Une meilleure rétention des développeurs.
Un développeur qui travaille avec moins de frictions et qui peut se concentrer sur l’apport de valeur dans son application est un développeur heureux. Un environnement propice est suffisamment rare pour donner à l’entreprise un avantage considérable lors du recrutement et limiter l’effet de “turn over”.
Une intégration plus rapide des nouveaux développeurs.
L’intégration d’un nouveau développeur dans une équipe n’est pas une tâche aisée. Ce dernier doit apprendre le plus rapidement possible le fonctionnel de l’application. S’ajoute à cela l’ensemble de la partie technique nécessaire au lancement, à la modification et à la mise en production du projet pour être autonome. Chaque projet étant différent, un développeur devra prendre ses marques en passant sur un nouveau projet, même si ce dernier est également dans sa technologie de prédilection. La DX agit sur deux leviers pour faciliter cette intégration. Le premier est de réduire au maximum ce temps de montée en compétence technique au démarrage d’un projet en proposant une configuration du poste la plus standard possible, documentée et automatisée. Le second est de faire en sorte que le projet soit le plus standard possible avec le marché et que l’ensemble des personnalisations et choix fait par l’équipe au cours de la durée de vie du projet soient documentés.
Paradoxalement, sur les projets ayant un gros “turn over” de développeurs, souvent des projets déjà en difficultés, cette étape d’intégration est la plus négligée alors que c’est précisément ce qui pourrait faire gagner énormément de temps.
Axes d’approches de la DX
Un architecte DX va principalement agir sur 3 axes pour améliorer l’expérience du développeur :
- Le poste de développeurs
- Les outils (choix et intégration)
- Les processus
Le poste du développeur
Le poste du développeur est son outil de travail au quotidien. Il doit être adapté, configurable et automatisable. Cela suppose d’avoir des postes matériellement en adéquation avec le projet. Par exemple, il est illusoire de donner des ordinateurs avec 8go de mémoire vive en 2023. Le simple fait de lancer un navigateur, quelque conteneurs Docker et un IDE entraine un dépassement de cette limite.
La configuration du poste pour le fonctionnement dans l’entreprise et sur le projet doit être automatisée. Tous les développeurs ne savent pas comment configurer des certificats racine pour accéder au dépôt de code de l’entreprise par exemple. Si un projet à des pré-requis logiciels (Java, docker, git, …), ces derniers doivent être installés et configurés automatiquement.
Pour autant un développeur doit pouvoir choisir ses outils si cela n’entre pas en conflit avec les autres membres de l’équipe. Un développeur pourra par exemple préférer VSCode à IntelliJ ou Gnome à KDE. Afin de ne pas avoir à maintenir une infinité de variantes, l’entreprise ne maintiendra d’une configuration recommandée.
Les outils
Les outils à disposition du développeur vont de l’IDE à la forge de développement en passant par les services annexes (RH). Ils doivent être choisis avec soin et intégrables les un avec les autres. Toute double saisie/action est une perte de temps et source d’erreur et doit être évité. Dans cet objectif, un compte unique permettant au développeur de se connecter une fois et d’accéder à l’ensemble des outils/services est une bonne pratique.
Les processus.
Chaque entreprise dispose de ses processus accumulés au fil du temps. Le rôle de l’architecte DX est d’identifier les processus complexes et/ou superflus qui peuvent entraver la productivité des développeurs. Certain processus, bien qu’obligatoire, peuvent être simplifié ou complétement automatisés. Par exemple, est-ce que la mise à disposition d’une nouvelle version d’une librairie nécessite vraiment la validation d’un supérieur et l’ouverture d’un ticket auprès de l’équipe en charge du nexus/artifactory de l’entreprise ? Cette procédure ne pourrait-elle être avantageusement remplacée par la mise en place de test de vulnérabilités automatisé et et d’un d’un proxy vers le dépôt publique ?
Conclusion
Nous avons vu les apports d’une bonne expérience de développeur ainsi que les axes d’action d’un architecte DX. L’expérience du développeur est un vaste sujet, peut toujours être améliorée et qui évolue en même temps que les technologies et systèmes utilisés par les développeurs. Une entreprise investissant dans l’expérience du développeur aura tout à y gagner.