Développeurs, il est temps de penser à vous

Nous développeurs avons énormément d'éléments à prendre en compte. Il nous faut considérer des aspects techniques, logiques, fonctionnelles, UX, sécurité, et j'en passe. Au final, nous en oublions de nous prendre en compte nous-même. Dans ce marasme de contraintes, nous en oublions de prendre soins de nous, comme si le confort était une sorte de "hasard" de notre métier. Il est temps de faire entrer en jeu un nouveau paradigme. Prenons le temps de penser à nous.

C'est quoi la DX ?

La DX (Developper Experience) comme son nom l'indique, consiste à recentrer le travail des développeurs sur l'humain qui développe, prendre en compte la personne qui code pour améliorer son expérience. Attention, il ne faut pas confondre le confort de travail avec le confort de l'environnement de travail. En effet, à la différence du dernier mug Star Wars ou de la table de ping pong dans la salle de réunion que met en place votre Happiness Officer dans votre environnement de travail (en dehors des temps de production), la DX a pour objectif de limiter votre frustration quand vous développez (au coeur de votre activité). Quand l'un facilite une relaxation suite à des phases de stress, l'autre vise à éviter/limiter les phases de stress.

Même si la notion de confort de travail peut paraitre évidente au premier abord elle n'en reste pas moins assez peu généralisée dans son ensemble. A première vue, la DX consiste en effet à utiliser des outils qui limitent la frustration. Par exemple, on peut parler d'un IDE qui convient à votre utilisation (il n'y a pas que VSCode dans la vie), ou d'un bon workflow gulp pour automatiser certaines tâches récurrentes, coûteuses et ennuyeuses (vous pouvez faire tellement d'autres choses que minifier des css).

Mais la DX ne s'arrête pas là. Elle passe aussi par votre propre méthode de développement. En effet, les développeurs sont eux mêmes des générateurs de frustrations pour les autres développeurs ainsi que pour eux-même. L'organisation du code, l'absence de commentaire, le bad naming, le non respect des conventions, tout ça peut générer du stress sous jacent. Et c'est même la partie la plus importante du stress d'un développeur. Par exemple, un développeur va se tirer les cheveux en essayant d'utiliser une API qui a été pensée uniquement pour son fonctionnement et pas du tout pour son utilisation. Un comble pour une API me direz-vous, et pourtant c'est un exemple tellement répandu. Or, qui d'autre qu'un développeur est susceptible de comprendre les besoins d'un autre développeur ?

Man vs machine

Nous sommes en effet les mieux placés pour prendre en compte les besoins des autres développeurs. Alors il est temps de délaisser le technique et de faire du social en pensant à la manière dont pourrait être utilisé notre travail. L'exemple de l'API n'est pas forcément le bon exemple parce que, malheureusement, la définition du contrat d'interface d'une API n'est généralement pas déterminé par un développeur lui même. Soit ! Ne nous arrêtons pas sur le contrat d'interface, arrêtons nous plutôt sur tout le reste. 

La prise en compte de la DX amène une nouvelle question dans la phase de développement : "à qui est destiné le code de l'application". Il y a plusieurs réponses possibles à cela. Vous pouvez estimer que votre code est à destination d'un compilateur, d'un processeur, mais aussi d'une communauté de développeurs ou de vous même. En gros, il reste deux types : machine ou humain ? Il n'y a pas de bonne réponse. Cette question ne va pas impacter le fonctionnel. En revanche elle va orienter la manière dont vous allez développer. 

Coder à destination d'une machine va vous orienter vers la performance à tout prix : moins de code, (moins de commentaire), développer en fonction du langage et du processeur qui va interpréter votre code. C'est une manière de coder qui a de nombreux avantages en terme de performance et qui nécessite une expertise importante du langage utilisé pour avoir une véritable plus value. L'inconvénient est que l'expertise à ce niveau est rare et très peu partagée. Il en découle une évolutivité limitée de votre application car elle dépend essentiellement de l'expertise propre du développeur.

En revanche, le développement à destination des humains (sous entendu des développeurs) consiste à organiser et écrire son code de manière à le rendre lisible en premier lieu par un humain. Il ne faut pas pour autant penser que ça ne nécessite pas de connaissances approfondies de l'interpréteur (c'est toujours un plus évidemment). De cette manière, on anticipe dès la phase de production une phase d'évolution et de maintenance en réduisant systématiquement les coûts d'interventions futures. La recherche de la performance doit alors être pondérée par la recherche de la compréhension, de la lisibilité.

Attention, encore une fois il ne s'agit pas de faire fi des performances. Non, au contraire, il s'agit de prioriser : d'abord l'humain ensuite la machine. Il s'agit de se poser la question "En cas d'évolution de cette fonctionnalité, quelle est la meilleure organisation pour que le coût engendré par une intervention humaine reste plus faible que le gain de performance apporté par un développement orienté machine ?"

Les gains de performance vous permettent de limiter les coûts de fonctionnement. Cependant il faut également prendre en compte les coûts d'évolution potentielle. Le gain qu'a engendré la performance d'une fonctionnalité doit resté supérieur au coût que pourrait engendré une évolution sur cette même fonctionnalité.
Prenez une feature de ouf qui fait gagner 0,5 micro secondes sur le temps de chargement d'une page que personne ne visite. Ajoutez le fait qu'elle sera en ligne 12 mois parce qu'une évolution est prévue mais rendue impossible parce que personne ne comprend comment et pourquoi elle a été implémentée. Au final, il y a des chances pour que le coût de cette évolution (qui devient une reconstruction) soit nettement supérieur que ce que le gain de performance a permis, ne serait-ce qu'avec la mise en place d'une nouvelle équipe et des voyages en avions pour les réunions avec le client. Effectivement, je prends un exemple volontairement extrême, tout cela pour vous dire que nos développements ont des impacts plus larges que ce que l'ont peut penser, et il faut prendre en compte ces impacts pour les limiter.

Quel bénéfice?

Pérenniser son application

L'objectif de la prise en compte de l'humain est la pérennisation de votre application. Le temps des applications à courte durée de vie est terminé, car beaucoup trop coûteux et beaucoup trop instable sur le moyen terme. Aujourd'hui, nous utilisateurs, nous clients et nous développeurs devons nous inscrire dans une logique de durée.

La philosophie qui consiste à développer des applications dont on sait quelles seront obsolètes dans 18 mois s'est révélée contre productive. Si le budget initial alloué à ce genre d'application se révèle plus faible que celui d'une application à durée de vie illimitée, il n'en demeure pas moins que ce même budget devra être alloué de manière récurrente pour conserver un service efficace dans le temps. En effet, quand la pérennité d'un projet n'est pas un objectif initial, il est souvent (pour ne pas dire toujours) plus avantageux financièrement de refaire un projet dans son ensemble quand celui-ci nécessite un rafraîchissement. Pour une raison simple, l'analyse du code montre qu'une évolution n'est pas possible car pas prévue, voire l'analyse du code elle même est trop coûteuse car il est illisible.

La où le code pensé pour l'humain intervient c'est qu'il facilite la lecture, donc l'évolution. Faciliter la compréhension c'est faciliter l'évolution. Et un projet qui évolue, c'est un projet qui vit. D'autre part, et c'est un effet positif que va amener l'orientation du développement pour l'humain, c'est qu'il fait naître des questions plus larges que le pur fonctionnel. En général il amène, en plus de la question "comment cela doit fonctionner", les questions "Si la feature était déjà existante, comment devrais-je intervenir dans tel ou tel cas" et "Pourquoi cela doit fonctionner de cette manière". Ces questions, dont les réponses ne sont pas absolues, vont apporter des solutions qui vont dans le sens de la pérennisation.

Par exemple, lorsque vous développez une fonctionnalité, il arrive que vous ayez plusieurs méthodes possibles pour arriver à vos fins. Le premier réflexe peut être d'emprunter le chemin de la simplicité et coder de manière jetable en pensant que ce développement, une fois finalisé, n'évoluera plus. Cette solution peut paraître bénéfique du point de vue du temps d'intervention. Développer quelque chose en 2h et basta, ça marche, on n'en parle plus. 
Sauf qu'en réalité, on y revient toujours. Que ce soit le lendemain, le surlendemain ou dans deux ans. Et l'intervention sur ce genre de méthodes s'avère systématiquement plus coûteuse. On peut facilement passer 3 à 4 fois plus de temps d'intervention de maintenance et évolution que de production initiale. Sans compter que les évolutions sont souvent peu robustes et alimentent une dette technique. Ce n'est pas acceptable.

Si dès le départ, on ne choisit pas le jetable mais le réutilisable, on passe certes plus de temps en développement et en conception, mais on facilite grandement le temps d'intervention ultérieure. Dans ce cas, on va inverser le ratio et le temps d'intervention peut être 3 à 4 fois inférieur au temps de production. Effectivement, si on part du principe qu'on ne doit pas revenir sur un code considéré comme finalisé, le coût initial est moins intéressant. Mais il ne faut pas oublier qu'un code n'est jamais finalisé et ne doit jamais l'être. Penser qu'il n'évoluera plus c'est estimer qu'il est mort, donc quasiment inutile. Je vous conseille, à ce propos, l'écoute d'un podcast qui parle du problème du "vite et bien" par Benoit Gantaume (artisandeveloppeur.fr). Si le podcast vite et bien ne traite pas directement du sujet du développement pour les développeurs, il évoque en revanche l'une des conséquences de la non prise en compte de cette approche et la perte de temps que peut engendrer l'absence d'appréhension du long terme.

Si on revient à la question du coût, on compare ici un coût initial de production, celui qui en général est estimé et vendu, à un coût d'évolution / maintenance. Il est donc plus rentable de privilégier un temps de production qu'un temps d'intervention ultérieure, dont l'estimation nous échappe souvent et est difficilement justifiable auprès d'un client.  

Coder pour les autres c'est aussi coder pour soi

En raccourci, on voit que coder à destination des développeurs c'est avant tout orienter son code de manière à ce qu'il soit évolutif. C'est à dire qu'il sera plus facilement maintenable par les autres développeurs en charge du projet dans le futur. D'autres développeurs oui, mais pas uniquement. Développer pour les autres ce n'est pas que de l'altruisme. Il ne faut pas négliger que la plupart du temps, vous serez la première personne à qui on fera appel pour faire évoluer votre propre développement. Inutile de vous parler de la situation où on se retrouve en train de se prendre la tête sur des lignes de code incompréhensibles pour lesquelles on serait prêt à étriper l'auteur, avant de se rendre compte que l'auteur... c'était nous il y a deux ans. Coder pour les autres, c'est aussi coder pour soi, coder de manière à faciliter nos prochaines interventions. Et ce, qu'elles aient lieu d'ici 2 ans, 2 jours ou 2 heures.

Comme le disait Raimbaud, "Je est un autre", et il est risqué (voire dangereux) de penser que le "je" de demain se souviendra des raisons et méthodes que le "je" d'aujourd'hui met en place en considérant qu'il sera le même dans le futur. L'avantage d'orienter dès le départ son code pour les autres développeurs, c'est que par la même occasion vous incluez votre "je" du futur parmi les autres. Ainsi, en facilitant le travail des autres en orientant votre code pour l'humain, en pensant pérennisation de votre application, en incluant votre code dans une vision globale et non personnelle, vous vous rendez service à vous-même.

Comment coder pour les autres?

Organiser votre code pour une relecture

Coder pour les autres ce n'est pas uniquement penser en mode API. Effectivement, penser API est déjà une très bonne chose cependant il ne suffit pas de définir des interfaces pour que votre code soit lisible. Il faut aussi penser lisibilité dans le core fonctionnel de votre application. Pour cela, il n'y a pas de recette miracle. Cela peut dépendre de votre langage, de votre framework, de l'existant etc... Dans tous les cas, il est important de respecter les bonnes pratiques (coding standards, SOLID, etc...), et allier ces notions avec des regroupements fonctionnels plutôt que de type. Je vous renvoie à ce sujet vers un de mes articles précédents sur la réutilisabilité.

L'organisation n'est pas uniquement une affaire de fichiers, et votre code doit également être correctement organisé. Atomiser au maximum, évidemment, éviter la duplication sont des manières simples de concentrer les futures interventions à des endroits précis. Dans la mesure du possible, il faut prévoir qu'une évolution doit pouvoir être faite dans un champ d'action limité et éviter d'éparpiller les points d'entrée nécessaires à la maintenance.

Multiplier les points d'entrée mais limiter les expositions

Une manière de conforter les utilisateurs qui vont se frotter à vos développements est de leur donner la main. Même si dans un premier temps une fonctionnalité n'a pas vocation à être ouverte et accessible, il est profitable dans une vision à long terme de proposer des points d'entrée avec lesquels va interagir le potentiel futur intervenant. Que ce soit par le biais d'events, de hooks, d'API ou que sais-je, un code ouvert et accessible permet une meilleure prise en main et donc une plus grande évolutivité. Et encore une fois, codons pour nous! Lorsque nous créons un point d'entrée, utilisons le. Cela facilitera encore une fois la compréhensibilité du code. N'éparpillons pas les processus et utilisons pour nos propres besoins les points d'entrée que nous offrons aux autres intervenants.

Concernant, l'ouverture, il faut toutefois faire attention à la sécurité. Si l'accessibilité ne signifie pas systématiquement exposition à des failles, il ne faut pas non plus négliger l'aspect de robustesse et fiabilité que peuvent engendrer certaines ouvertures. Plaçons un maximum de garde-fou.

L'un des autres éléments qui facilite les interventions est de ne pas surcharger vos utilisateurs d'informations. Cela peut paraître contradictoire avec l'idée de donner la main à vos utilisateurs, mais cela veut surtout signifier qu'il est important de bien hiérarchiser et grouper les niveaux d'interactions. En effet, fournir un nombre trop important de points d'entrée sans hiérarchie se révèle contre productif. Trop de choix, trop de combinaisons pour une action prépondérante et vous perdez votre utilisateur. C'est pourquoi le principe de façade est à recommander systématiquement pour faciliter et simplifier les interactions. Pour autant, une façade ne doit pas devenir un rideau derrière lequel on cache un système opaque. Si elle facilite l'utilisation en proposant des raccourci, elle ne doit pas empêcher l'accès au core de la fonctionnalité. 

Nommer, commenter, documenter

Dernières choses et non des moindres : le naming, les commentaires et la documentation. On sous-estime beaucoup trop le naming lors de nos développements, cependant, il est probablement l'élément le plus important quand on veut fournir un code utilisable. Si la lecture de la documentation avant de se plonger des évolutions sur un développement est une bonne pratique, il ne faut pas se leurrer, elle est rarement suffisante pour connaitre les tenants et les aboutissants. Elle nous en apprend beaucoup sur les généralités, c'est son rôle. Dans les faits, la lecture du code sur lequel on doit intervenir est le seul moyen réel de tout comprendre.

On peut dire qu'il y a une sorte de hiérarchie entre ces trois éléments qui est inversement proportionnelle entre la quantité d'information et l'accès. En effet, la première chose qu'on va voir est le nom d'un élément (une méthode par exemple). Ce nom doit déjà nous renseigner sur ce à quoi sert l'élément. Cependant, si l'information n'est pas suffisante, on va, dans un second temps, regarder le commentaire associé (s'il existe). Le commentaire va nous fournir de plus amples informations techniques. Là encore, si ce n'est pas suffisant, on va s'en référer à la documentation. Celle-ci, nettement plus exhaustive, va nous fournir des éléments de contexte supplémentaires qui vont nous aider à mieux appréhender le développement.

L'accès à ce genre d'information se fait donc via la suite nom, commentaire, documentation. L'une des manières de fournir un environnement de travail confortable est donc de délivrer l'information le plus tôt possible. Si le nom est cohérent et réfléchi, il y a des chances pour qu'il soit suffisant à votre lecteur pour qu'il n'ait pas besoin d'aller lire un commentaire ou la doc. De même pour un commentaire bien rédigé et exhaustif. C'est pourquoi, il est important de ne pas négliger chacun de ces éléments afin de limiter les frustrations en apportant les informations rapidement.

Conclusion

Même si cet article ne traite pas de DX dans son ensemble, il évoque dans les grandes lignes les moyens que chaque développeur peut se donner, simplement, pour limiter le stress des autres. Même si malheureusement, ce n'est pas toujours évident, on se rend rapidement compte que ce paradigme supplémentaire qui tant à prendre en compte l'humain, est  bénéfique pour la viabilité d'un projet, pour la cohésion d'une équipe, mais aussi pour la satisfaction personnelle d'un individu. Limiter les frustrations pour les autres, c'est aussi limiter les frustrations pour soi-même.