There are two hard things in computer science: cache invalidation, naming things, and off-by-one errors.

Je crois qu’elle s’applique particulièrement bien aux événements émis par une application pour être stockés puis analysés ultérieurement.

Pourquoi choisir avec soin les noms, dès le début ?

Quand on commence à implémenter du suivi d’événements dans une application, on crée souvent rapidement les premiers événements, sans se poser trop de questions. D’une part, on souhaite accéder rapidement à la donnée, et d’autre part, s’il n’y a que 2 ou 3 événements suivis, ils sont en général très clairs !

On fait donc souvent l’impasse sur la définition d’une convention de nommage. Puis on finit par le payer le jour où l’on se retrouve avec des événements que l’on n’est plus capables de différencier sans lire le code pour comprendre leur déclenchement.

Et le coût du changement quand on a une grosse base d’événements suivis est assez lourd : ces événements sont générés par une application, puis stockés quelque part et utilisés par d’autres application. Il faut repenser le nommage de tous les événements, puis modifier le code qui les déclenche, migrer toutes les données existantes et réécrire les requêtes qui les utilisent.

C’est exactement la situation dans laquelle nous nous trouvons actuellement, donc prenons le temps de réfléchir un peu : qu’aurions-nous gagné à avoir une convention de nommage ?

Voilà les 3 principaux avantages qui remontent de nos discussions :

• produire des données claires, compréhensibles à la fois par les développeurs et par les équipes qui traitent les données (data analyst, équipes marketing, équipes produit…) ;
• écrire du code propre et sans surprise : les événements sont souvent des variables ou des paramètres de fonctions dans notre code, si leur nom est plus clair, le code est plus clair, on aime ;
• se poser moins de questions : si l’on souhaite mesurer un nouveau phénomène, on a déjà des règles simples pour nommer le nouvel événement à suivre.

Mais comment trouver des noms qui ont du sens ?

Avant de décider d’une convention de nommage, il faut prendre le temps de décrire ce qui constitue un événement.

Chacun se construit un modèle mental qui représente ce qu’est un événement. On n’y réfléchit en général pas trop, mais clarifier le modèle permet de s’accorder, en équipe, sur ce qu’on entend par événement, et ensuite de faire émerger une convention qui convienne à tous.

Chacun pourra adapter ce travail à son équipe et sa situation, mais voici ce qui constitue un événement selon nous :

• un acteur
• une action
• un objet
• un lieu
• un instant
• toutes sortes d’informations complémentaires, éphémères ou non

L’acteur

C’est l’entité qui réalise l’action représentée par l’événement.

Il peut s’agir d’un utilisateur (exemple : un visiteur s’inscrit), d’un programme (prélèvement automatique d’un abonnement mensuel), d’un phénomène naturel (le vent a fait pivoter la girouette), d’un animal (le chien mange) et bien d’autres, en fonction de l’univers de notre application.

En principe, il doit s’agir d’un nom commun.

L’action

C’est la nature de l’événement qui a eu lieu. On l’exprime par un verbe au passé ou participe passé. En général, le verbe représente une action ponctuelle et discrète (au sens mathématique).

Par exemple, “le visiteur s’est inscrit” : on peut considérer qu’il y a un avant et un après l’inscription, et qu’il y a un instant où l’inscription a lieu.

En revanche, “le client choisit un pack” manque de précision car le verbe ne représente pas une action ponctuelle. On ne sait pas trop si l’événement est déclenché quand le client a commencé à choisir ou à la fin : est-il déclenché quand il arrive sur la page ou quand il a sélectionné un pack ? L’événement n’est pas “discret”. Rien que “le client a choisi un pack” est plus précis, et donc plus compréhensible.

L’objet

L’entité à propos de laquelle l’action est réalisée. ça peut être par exemple un objet physique (le vent a activé la girouette), ou un élément visuel (le client a terminé son onboarding)

C’est souvent un nom commun. Il joue le rôle du complément d’objet (ou complément du verbe) dans la phrase en français. Un peu de grammaire ne fait pas de mal.

Le lieu

Où l’action a-t-elle eu lieu ? Si notre système s’étale sur plusieurs applications ou plusieurs espaces dans une seule application, il est intéressant de savoir sur laquelle l’événement est survenu.

C’est en général un nom.

L’instant

C’est la seconde ou la milliseconde à laquelle un événement survient. Elle est capitale pour extraire de l’information utile à partir de la liste des événements survenus.

Il est évidemment possible de ne stocker que la date ou l’heure, mais on perd alors de la précision, notamment si l’on veut étudier par la suite des événements qui se déclenchent séquentiellement, à quelques secondes d’intervalle.

Autres informations

On peut imaginer d’autres informations complémentaire, utiles pour caractériser l’événement, mais elles nous paraissent souvent optionnelles. Nous les renseignons souvent dans des propriétés optionnelles à attacher à un événement, plutôt que de les faire figurer dans son nom.

En bref

J’y ai fait allusion en parlant de l’objet, mais on remarque que les 6 éléments listés ci-dessus pour décrire un événement correspondent à des éléments de la grammaire française qu’on a tous étudiés.

• acteur = sujet
• action = verbe
• objet = complément du verbe
• lieu = complément circonstanciel de lieu
• instant = complément circonstanciel de temps
• informations complémentaires = autres compléments

Cela peut nous aider à définir la condition de nommage qu’on veut adopter : qu’est-ce qui est vraiment nécessaire, et qu’est-ce qui est du ressort de l’information complémentaire ?

On peut se dire par exemple que les compléments sont des informations complémentaires, et donc facultatives. 😮

Notre convention

Chez Captain Contrat, nous nous sommes mis d’accord sur la convention suivante :

Nomenclature : sujet_verbeaupassé_complémentdobjet

Le sujet peut prendre l’un des valeurs suivantes :

• “lawyer” si l’événement est toujours déclenché par une action d’un avocat
• “client” s’il est toujours déclenché par une action d’un client
• “admin” s’il est toujours déclenché par un équipier Captain
• “human” si ça peut être n’importe quel humain : avocat, client ou équipier
• “app” si c’est une action déclenchée automatiquement par notre application

Le verbe au passé peut être n’importe quel verbe, avec quelques “verbes réservés” :

• visited : s’il s’agit d’une visite de page
• clicked : s’il s’agit d’un clic sur un élément visuel sans conséquence importante sur les données, comme cliquer sur un tooltip d’aide

Le complément du verbe est un groupe nominal précis.

L’ensemble doit respecter la casse : snake_case.

Nos noms sont systématiquement définis en anglais, qui est la langue de travail de toutes nos applications.

Obsolescence

Au delà du problème initial, qui est de nommer correctement les événements quand on les implémente, nous nous posons aussi la question de leur obsolescence.

Ce problème n’est pas spécifique aux événements puisqu’il s’applique à l’ensemble du code, mais il se pose tout de même. Petit à petit, en fonction des évolutions du produit et du code, le nommage peut devenir obsolète.

Un événement trop vague devenu confus : question_asked

Quand cet événement a été implémenté, il était très clair qu’il correspondait à une question posée par un utilisateur qui possède un abonnement juridique chez nous et qui demande des renseignements à un juriste.

Les évolutions successives du produit ont ajouté de la confusion.

• Actuellement, une question peut aussi être posée par un juriste à un abonné, mais l’événement n’a pas changé. Il faut lire le code pour comprendre qu’il n’est déclenché que par les questions de l’abonné et pas par celles du juriste. Ou le contraire, je ne sais plus, il faudrait que je retourne lire le code 🤔
• Nous avons aussi dans l’application des questionnaires qui permettent aux utilisateurs (abonnés ou non) de générer des documents juridiques. On pourrait facilement croire que l’événement est déclenché lorsqu’un utilisateur doit répondre à une question, mais ce n’est pas le cas. Ce coup-ci, j’en suis sûr. Mais c’est parce que j’étais présent quand il a été développé et que j’ai accès au code.

Si cet événement n’est pas clair pour moi, qui l’ai implémenté et qui ai accès au code, j’imagine qu’il doit être frustrant pour les autres équipes.

Un événement trop précis : client_opened_payment_modal

Cet événement sert à mesurer le nombre de clients qui se retrouvent devant le formulaire de paiement. Cela nous permet ensuite de savoir quel pourcentage de clients laissent tomber au moment de payer.

Le jour où le paiement ne se fera plus dans une modale mais sur une page dédiée, le nom de l’événement deviendra obsolète.

Son nom est trop précis. Il est couplé à l’élément UX permettant de payer alors qu’ils n’est pas lié directement à cet élément dans l’intention. On aurait pu choisir client_displayed_payment_form qui est plus générique.

Comment lutter ?

Il est difficile de lutter contre l’obsolescence : un produit qui évolue crée nécessairement de la nouveauté et de l’obsolescence. En revanche, il me paraît important d’avoir quelques réflexes.

La première chose est de détecter l’obsolescence du nom de nos événements pour éviter les quiproquos. Pour cela, quelques pistes :

• quand je vais consulter le code pour savoir à quoi correspond un événement, c’est qu’il n’est pas clair, au moins pour moi
• quand les autres équipes nous demandent ce que représente un événement, c’est qu’il n’est pas clair pour eux
• si un événement n’est pas utilisé, peut-être que c’est parce que personne ne le comprend

Par la suite, pour limiter les conséquences des noms inappropriés, il est possible de mettre en place quelques actions :

1. documenter les événements pour que tout le monde puisse les comprendre
2. éviter de développer des fonctionnalités qui ont des noms proches (facile à dire)
3. être prêts à renommer un événement si c’est nécessaire. Si ça se produit souvent, semi-automatiser ?
4. assumer cette confusion et miser sur la connaissance accumulée par les équipiers pour s’y retrouver. Cette solution a l’avantage d’être peu coûteuse à court terme, mais bon…

Pour résumer

La difficulté de nommage des événements suivis vient de leur utilisation : ils sont émis par notre application, puis stockés ailleurs pour être utilisés par d’autres applications. Il est donc difficile de les modifier. Les nommer correctement est donc important.

Se mettre d’accord avec toutes les parties prenantes sur ce qui définit un événement ouvre la voie à une convention de nommage qui convienne à tous. Les noms des événements créés par la suite sont alors plus clairs et plus simples à utiliser par tous.

Enfin, pour revenir à la citation initiale, n’oublions pas non plus les bonnes pratiques de base pour le nommage :

• éviter l’ambiguïté : ne pas utiliser le même mot pour deux choses différentes
• éviter les abréviations (user_SU pour user_signed_up)
• éviter les mots réservés (“event” par exemple…)
• respecter les conventions de casse (snake_case, camelCase, kebab-case…)

Une fois que l’on parvient à suivre des événements dont le nom est à peu près clair, une nouvelle question se pose : comment clarifier les propriétés qui accompagnent chaque événement ?

Mais c’est une autre histoire…

Utiliser une convention de nommage pour clarifier la collecte de données was originally published in Captain Contrat Tech on Medium, where people are continuing the conversation by highlighting and responding to this story.

Avec la croissance de l’entreprise, la volonté d’avoir quelque chose de plus cohérent s’est renforcée. L’équipe design a décidé de mettre en place un design system pour unifier l’aspect de l’application, nous avons précédemment expliqué pourquoi cette décision a été prise et comment ce design system a été conçu. Nous allons ici nous concentrer sur l’implémentation de ce design system, en expliquant comment nous avons procédé pour le mettre en place de façon progressive, en essayant de ralentir le moins possible le reste des travaux.

Le design system

Nos designers l’ont expliqué mieux que moi dans leur article dédié, mais pour résumer, en terme d’éléments à implémenter, ils ont défini :

• une liste officielle des couleurs, avec leurs cas d’usages
• une police officielle, avec sa taille recommandée
• des tailles et couleurs par défaut pour les titres et les paragraphes
• une librairie d’icônes
• des tailles, couleurs et formes standardisées pour nos formulaires
• de nombreux composants comme les boutons, modales et autre champs de texte à appliquer aux différents espaces de notre application

L’implémentation de tous ces éléments est chronophage et nous ne souhaitions pas ralentir tous les développements.

Afin d’avoir un plan de migration solide, nous avons pris un peu de recul et analysé les différents éléments de ce design system. On peut différencier des éléments qui vont se retrouver sur la quasi totalité des pages, et ceux qui vont être plus épars dans l’application. Pour nous, il s’agit presque de la différence entre variables et composants.

Les variables

Toute règle qui traite de couleur, taille et famille de police est omniprésente dans l’application. Nous nommons ces éléments des variables étant donné que dans notre code, nous stockons ceci dans des variables scss (qui pour l’instant sont désordonnées et sans grande cohérence entre elles, mais ont le mérite d’exister). Pour ces variables, un changement progressif est assez illusoire et compliquerait vraiment notre code. Nous avons donc réalisé un fichier de correspondance entre les anciennes variables et celles du design system avec l’aide de l’équipe design, puis refactoré le code pour ne plus utiliser que les nouvelles variables (réunies dans un seul fichier). Quelques jours en staging nous ont permis de détecter les éventuels ratés (du doré sur fond doré à un endroit, une taille trop grosse à un autre…) mais dans l’ensemble le travail préparatif n’avait pas trop de trous dans la raquette. Une mise en production nous as permis de passer de 5 variations de notre couleur principale à une seule, apportant déjà un semblant d’homogénéité à l’application.

Les composants

Le reste des éléments du design system sont ce qu’on peut nommer des composants : des briques unitaires représentant des éléments réutilisables dans notre application. Ils sont beaucoup trop nombreux pour qu’on s’y attaque d’un coup, donc nous avons décidé d’appliquer une règle proche du boy scout sous stéroïdes.

Dans chaque user story qui traite un peu du front, nous avons un design associé, et dans ce design on retrouve évidemment des composants du design system. La règle est simplement qu’au moment où on implémente ce design, on en profite pour faire un composant réutilisable (si ce n’est pas déjà fait) et on essaie de remplacer toutes les anciennes versions de ce composant par la nouvelle. Les premières user stories qui utilisent des composants très fréquents (barre de navigation, boutons, modales) sont évidemment plus coûteuses, mais c’est rapidement amorti quand on a juste à appeler un composant ou ajouter une classe pour avoir directement le bon design. Comme l’a dit notre équipier le moins enthousiasmé par le front-end :

C’est cool, j’ai plus besoin d’écrire du css, j’ajoute juste une classe et c’est ok pour les designers.

Gérer plusieurs applications

Captain Contrat possède deux applications (une pour le front de notre espace client, une pour le reste comprenant notamment le funnel d’achat), donc nous devons implémenter nos changements sur deux applications différentes. Des questions émergent :

• Que faire quand un composant est ajouté dans une application mais pas dans l’autre ?
• Que faire quand le design system a changé un peu et qu’on intègre ce changement ?

Si un composant est ajouté dans une application, notre approche progressive nous encourage à ne pas l’intégrer dans l’autre application tant qu’on n’en a pas besoin. En revanche, le fait d’implémenter des composants à des moments différents par des personnes différentes peut mener à du code assez différent, ce qui peut provoquer des mauvaises surprises. En effet si le composant modale s’appelle captain-modal sur une application et modal sur l’autre, nous n’allons pas nous en sortir. Pour résoudre ce problème, nous utilisons tout simplement la documentation du design-system fournie par les designers qui, en plus de détailler le css des différents composants, comporte nos propres contributions détaillant quelles applications implémentent le composant et quels sont les noms à utiliser.

Quand un élément du design-système change, on veut rester cohérent, il faut donc apporter les changements dans les deux applications en même temps. C’est obligatoire pour tous les éléments que nous qualifions de variables, nous avons en effet eu à changer des icônes à une occasion. Pour des composants, nous n’avons pas encore eu à le faire et il serait plus sûr de tout changer, mais des contraintes business fortes face à un petit changement nous feront potentiellement prendre le choix de mettre en production un premier changement et de faire attendre la seconde application.

Conclusion

Pour implémenter le design system de façon progressive, nous l’avons divisé entre les parties vitales, à implémenter au plus vite et ce qui pouvait être fait au fur et à mesure. En acceptant de ne pas être dans un état parfait dès le début et avec quelques jours de tests pour repérer les incohérences majeures, nous avons pu nous lancer très vite. Une fois ce lancement fait, il s’agit surtout de bien distinguer les User Stories où il y aura besoin d’implémenter des morceaux du design system de celles où au contraire, beaucoup d’éléments seront réutilisables.

Cette approche nous a assez bien réussi, le site est vite devenu plus cohérent grâce à l’unification des couleurs et polices et une identité visuelle se constitue petit à petit, sans trop gêner le développement de nouvelles fonctionnalités. De plus, délivrer quelque chose qui apporte de la valeur au client tout en augmentant notre productivité a permis de faire adhérer le reste de l’entreprise à ce design system.

Implémenter un design system dans une application existante was originally published in Captain Contrat Tech on Medium, where people are continuing the conversation by highlighting and responding to this story.

Votre produit est fonctionnel mais vous ne le trouvez pas très séduisant ? Alors, nous nous sommes sans doute posé les mêmes questions ! Pourquoi chercher à rendre beau un produit qui fonctionne très bien tel qu’il est ? Comment garantir la meilleure expérience à nos utilisateurs tout en simplifiant la conception produit ? Chez Captain Contrat, designers et développeurs se sont alliés pour mettre en place Shipyard, notre Design System.

Dans cet article, je reviens sur la façon dont l’équipe Design de Captain Contrat a créé son Design System.

Si vous vous demandez pourquoi nous en avons créé un, Martin, développeur chez Captain Contrat, vous explique les raisons qui nous ont poussé à créer notre Design System.

Si vous êtes intéressé.e par l’implémentation du Design System du côté de l’équipe tech, il va falloir patienter, l’article arrive bientôt 😉

Vous n’avez pas les bases

Quand je suis arrivé chez Captain Contrat, la première chose qui m’a frappé, c’était le manque d’homogénéité entre les interfaces. L’expérience était relativement la même entre chaque écran, mais les polices d’écriture pouvaient varier d’un écran à l’autre, tout comme le rouge qui symbolise notre marque. Il en était de même dans nos outils : à chaque nouvelle maquette, les couleurs, les espaces ou les typographies étaient nouvelles.

Il étaient donc temps de repartir sur des bases simples.

Les couleurs

La décision fut radicale sur ce point : nous avons décidé de nous séparer de toutes nos couleurs existantes à l’exception de 2, le rouge et le doré de notre marque.

Puis, nous avons décidé de créer 7 palettes de couleurs de 10 nuances chacune :

• Neutre
• Rouge
• Doré
• Bleu
• Vert
• Orange
• Violet

Si vous avez bien suivi, nous avons parlé de créer des bases simples et nous nous retrouvons avec 70 couleurs différentes. On a connu plus clair !

Pourtant, c’était le meilleur choix pour nous : il nous permet d’avoir dès le début l’ensemble des couleurs que nous utiliserons pour nos interfaces, mais également les couleurs pour l’aspect “marketing” (illustrations, code couleurs pour nos offres, etc.).

D’un point de vue purement produit, nous n’utilisons que 9 de ces couleurs pour nos interfaces.

Ce que nous avons retenu de la création de nos couleurs :

• Le naming est TRÈS IMPORTANT.
  Il servira à vous comprendre entre designers, mais il vous permettra surtout de parler la même langue avec les développeurs. Nous avons très vite abandonné le système “darker-red > dark-red > red >…” qui était incompréhensible (et très peu scalable), pour nommer nos couleurs comme la graisse des polices d’écriture : Red900 > Red800 > Red700… Ce choix n’est pas sorti de notre chapeau, il a été le fruit de longues discussions avec les développeurs pour aligner tout le monde en amont.
• Pour chaque couleur, choisissez une couleur principale (par exemple Red500). A partir de cette couleur vous pourrez trouver vos variantes plus claires et plus sombres facilement.
• N’oubliez pas l’accessibilité. Chez Captain Contrat, plusieurs équipiers sont daltoniens. Vous imaginez donc bien qu’avez le rouge comme couleur principale, nous devons faire attention à ce que chacun puisse lire notre interface facilement.

Pour vous aider dans votre travail, je vous recommande l’outil Leonardo.

Les polices

Nous avons été encore plus radicaux en ce qui concerne les polices d’écriture. Nous les avons toutes remplacées au profit d’une unique : Nunito. Nous avons limité le nombre de graisse à 3 : Regular, Semibold & Bold.

Puis nous avons posé 3 règles :

• La police de base a une taille de 16px — pour être facilement lisible sur desktop et mobile — et les autres tailles varient de 2 à 4px en fonction de cette taille de base
• La hauteur entre chaque ligne a un ratio de 1:1.5, afin de faciliter la lecture des personnes atteintes de déficience visuelle ou de troubles de la lecture comme la dyslexie. Pour les titres, ce ratio est de 1:1.25.
• Une ligne de texte doit faire de 80 à 100 caractères maximum, là encore pour simplifier la lecture.

Grâce à ces règles, nous avons pu déterminer la taille de nos titres sur mobile et desktop.

Ce que nous avons retenu de la création de nos polices :

• Réfléchissez bien à la taille de votre police de base et aux hauteurs de ligne. Ces points peuvent sembler anodins, mais ils vous feront gagner un temps précieux par la suite. Tout en rendant votre interface plus lisible !

Les espacements

Les espacements sont un enfer. Surtout pour les développeurs. Il suffit d’un décalage, même insignifiant, sur une maquette pour créer une multitude de questions. C’est aussi un enfer pour les designers pour créer une régularité et une facilité de lecture sur les interfaces.

Pour cela, nous avons décidé de partir sur une grid de 8px. Je ne vais pas m’étendre sur ce choix, la littérature est déjà largement suffisante là dessus.

• Intro to The 8-Point Grid System
• 8-Point Grid

Maintenant, il faut déterminer les espacements que l’on va intégrer dans nos designs. Nous en avons choisi 5:

• 4px
• 8px
• 16px
• 32px
• 64px

Nous avons opté pour une progression exponentielle des espacements, plutôt que linéaire pour une bonne raison : ne pas nous prendre la tête entre 16, 24 et 32 px lorsque l’on fait une maquette. Ces espacements sont très proches et ne permettent pas de faire un choix facilement. En supprimant 24px de la liste, tout devient plus simple.

Pour en savoir plus sur notre choix :

Space in Design Systems

Ce que nous avons retenu de la création de nos espacements :

• Les espacements sont probablement la chose la plus essentielle pour vos interfaces et pourtant ils sont souvent négligés. Ce sont eux qui vont rendre vos interfaces lisibles et respirables ou au contraire illisibles et compactes.
• Prenez le temps de faire des tests et de vous renseigner. C’est ce que nous avons fait et nous n’avons désormais plus de questions entre designers et développeurs sur les espacements voulus.

• A framework for creating a predictable & harmonious spacing system for faster design-dev handoff
• Generating Design System Spacing

Les ombres et les icônes

Passons rapidement sur les deux dernières bases de notre design system.

Pour gagner du temps nous avons décidé de suivre les recommandations du livre Refactoring UI pour l’implémentation des ombres.

En ce qui concerne les icônes, nous avons décidé de créer les nôtres afin d̶’̶e̶n̶ ̶f̶i̶n̶i̶r̶ ̶a̶v̶e̶c̶ ̶F̶o̶n̶t̶ ̶A̶w̶e̶s̶o̶m̶e̶ renforcer la personnalité de Captain Contrat sur notre interface. Pour faire comme nous, je vous recommande l’article suivant :

Nucleo Icon Guidelines - Introduction

Et maintenant ?

Maintenant que nous avons les bases, il est temps de créer des composants ! Rassurez-vous, je ne vais pas rentrer dans le détail de la création de chaque composant. Je vais plutôt vous expliquer, dans les grandes lignes, la méthode que nous avons suivi :

• Nous avons appliqué la méthode de EightShapes pour choisir les composants que nous devions réaliser en priorité, ceux qu’il faudrait que l’on ait à terme et ceux qui ne nous serviront jamais.

Picking Parts, Products & People

• Nous nous sommes enfermés dans une salle avec Guillaume, également Product Designer chez Captain Contrat, et nous avons créé ensemble chaque composant sur Figma.
• Nous avons ensuite documenté l’ensemble des composants pour expliquer à quoi ils servent, quand et comment les utiliser, et comment les intégrer côté devs. Ne négligez pas cette partie, elle vous évitera par la suite des casse-têtes du type “Ah mais on ne devait pas utiliser ce composant comme ça ?” → Non c’est expliqué dans la documentation.

• Pour l’intégration, nous avons décidé de la faire progressivement. A chaque fois qu’un écran évolue, nous en profitons pour intégrer les nouveaux composants créés. Mais ça nous en parlerons dans un autre article 😉

Au moment où j’écris ces lignes, cela fait 5 mois que nous avons mis en place notre Design System. Ce dernier nous a déjà permis de gagner un temps précieux lors de la conception et l’implémentation de nouvelles fonctionnalités. Il nous a également permis de réduire drastiquement nos débats sur des détails insignifiants d’interface pour nous focaliser sur l’amélioration de l’expérience de nos utilisateurs.

Bien sûr, tout n’est pas encore parfait et nous aimerions aller plus loin : ajouter les illustrations à notre Design System, le tone of voice et bien plus encore. Mais cela arrivera et on écrira un nouvel article à cette occasion !

Cet article vous a plu ? N’hésitez pas à 👏👏👏

Découvrez également pourquoi nous avons mis en place notre Design System :

Gagner en cohérence et en productivité avec un design system

Comment avons-nous conçu Shipyard, notre Design System was originally published in Captain Contrat Tech on Medium, where people are continuing the conversation by highlighting and responding to this story.

Devant notre moue hésitante, Gautier a décidé de faire preuve de pédagogie. Il nous a présenté les opportunités qu’aurait le design system à la fois pour les développeurs et les designers : travailler ensemble plus efficacement et donc in fine apporter de la satisfaction à nos utilisateurs. Puis il a pris le temps de détailler la démarche que l’on pourrait adopter pour mettre en place ce design system sans perdre en productivité. Convaincus par ses arguments, nous nous sommes lancés.

En prenant un peu de recul après 2 mois de travail, je crois que Gautier a bien fait d’insister un peu.

C’est quoi un design system ?

Un design system est une bibliothèque de styles et de composants réutilisables, documentée et soumise à des normes claires et détaillées. Il sert aussi bien aux designers qu’aux développeurs ou au marketing pour construire une expérience utilisateur cohérente plus rapidement.

Il comprend plusieurs briques, dont les 3 principales sont :

• une charte graphique, qui définit des éléments de style (couleurs, typographies, icônes…) et leur utilisation
• un kit UI qui rassemble les composants réutilisables (boutons, inputs…) en se basant sur la charte graphique afin de garder un style uniforme entre les composants
• une documentation qui explique la façon dont chaque composant doit être utilisé

Si vous voulez en lire plus sur le sujet, cet article écrit (en anglais) par Audrey Hacq définit plus précisément ce qu’est un design system.

Quels avantages à mettre en place un design system chez Captain Contrat ?

Un gain de clarté pour nos utilisateurs

Notre application a maintenant 7 ans, un âge tout à fait respectable pour une application web. Avec plusieurs lignes produits (place de marché, abonnement) et plusieurs types d’utilisateurs (créateurs d’entreprises, dirigeants d’entreprises, experts comptables, avocats…) elle est devenue relativement complexe d’un point de vue graphique.

Jusqu’à présent nous avons conçu chaque page au moment où nous avons eu besoin de l’implémenter, sans nous soucier de la cohérence avec celles déjà existantes. Nouvelle couleur, nouveaux boutons, nouvelle taille de texte, etc. La diversité graphique de nos interfaces utilisateurs était très pénalisante.

Quand Gautier a posé sur la table la question du design system, il est devenu évident pour nous que cette situation était problématique pour nos utilisateurs, qui avaient parfois du mal à utiliser notre application.

En rassemblant au sein du design system nos règles de conception, nous évitons que les différentes pages proposent des interfaces obéissant à des règles qui sortent de la norme. Elles restent cohérentes entre elles et nos utilisateurs se sentent à l’aise pour naviguer sur toute notre application sans mauvaises surprises.

Un gain d’efficacité pour les designers

Une autre conséquence directe du désordre graphique de notre application était le coût de conception de nouvelles pages. A chaque nouvelle conception, le designer s’interrogeait pour finalement prendre des décisions semblables à celles prises pour d’autres pages. Nous ne prenions pas en compte les enseignements tirés du passé. On aurait pu réutiliser l’existant, mais quelle couleur choisir parmi les 8 qui existent déjà ?

Avec une bibliothèque de composants et une charte graphiques documentées, les designers peuvent s’appuyer directement sur les éléments définis par le passé pour gagner du temps dans la conception : “Je veux un texte d’aide pour accompagner l’utilisateur, donc je vais utiliser directement le texte d’aide par défaut de notre design system”

Au delà de la conception d’une nouvelle page, nous avions aussi du mal à faire évoluer nos interfaces existantes car il était difficile de décliner une modification partout sur le site d’un coup. On peut parler de dette graphique, par analogie à la dette technique.

Avec un design system unifié, on peut facilement modifier un élément sans avoir de surprises sur l’impact pour toutes les vues dans lesquelles il est utilisé.

Un gain de temps pour les développeurs

Du point de vue des développeurs, l’utilisation d’un design system est également venue apporter de l’efficacité dans notre travail.

Toutes les maquettes étant différentes auparavant, nous devions systématiquement implémenter de nouveaux composants, ou des versions modifiées de composants existants. Ce temps de développement était mal utilisé et nécessitait par ailleurs beaucoup d’aller-retours avec les designers pour valider le travail réalisé.

Maintenant que nos designers utilisent notre design system, les interfaces sont proches. Une fois les composants définis et documentés, et dès lors qu’ils ont été utilisés et implémentés une fois, nous pouvons les réutiliser sur les différentes pages sans avoir besoin de les réimplémenter. Nous avons déjà constaté un gain de temps conséquent.

Conclusion

Vous l’aurez compris, après deux mois de mise en place et d’utilisation de notre design system, je considère qu’il s’agit d’une bouffée d’air frais, à la fois pour nos utilisateurs et pour nos équipes de conception et de développement. Il nous a aidé à résoudre un problème structurel et douloureux : notre application n’avait pas d’unité graphique.

Nous avons progressé sur les deux axes que nous avions identifiés :

• côté utilisateur : nos interfaces ont gagné en cohérence et donc en clarté.
• côté designer et développeur : nous avons gagné en productivité car la réutilisabilité des éléments qui composent nos interfaces utilisateurs se traduit par un gain de temps sur la conception et l’implémentation.

La décision de mettre de place ce design system correspond aussi à l’arrivée d’un deuxième designer dans l’équipe. Cette arrivée aurait pu augmenter l’entropie graphique de notre application. En nous forçant à documenter l’existant et les décisions prises, nous avons probablement gagné un temps fou.

Un chouette projet !

Article co-écrit avec Gautier.

Pour les curieux, notre design system est documenté ici.

Vous êtes convaincus de l’utilité d’un design system, mais vous ne savez pas comment le concevoir, ou gérer la transition ? Cet article de Gautier précise comment notre design system a été conçu.

Gagner en cohérence et en productivité avec un design system was originally published in Captain Contrat Tech on Medium, where people are continuing the conversation by highlighting and responding to this story.

De toute évidence, il ne s’agit pas d’une session de piano, d’un duo jouant simultanément sur le même clavier. Le pair programming peut être abordé de différentes façons, chacune avec ses avantages et ses défauts. Faisons le point ensemble dans cet article.

La dictée

Lorsque l’un des deux participants se révèle d’avantage expert sur la technologie utilisée ou le programme en lui-même, c’est à lui que revient naturellement le rôle d’énoncer les différentes étapes à effectuer. Il donne ses directives, un peu comme une dictée (ou une recette de cuisine).

Cette méthode s’avère utile pour présenter à l’intéressé une partie du code qu’il ne connaît pas, et plus généralement pour enseigner des méthodes aux profils plus juniors.

Le niveau de détail dicté peut évidemment varier. D’une simple explication des fonctions à implémenter au détail du code ligne par ligne, la dictée ne sera pas la même.

Pour accompagner ces instructions, il est recommandé d’en profiter pour faire une visite guidée du code. Par exemple en ouvrant différents fichiers, le mentor pourra expliquer les tenants et aboutissants des différentes méthodes. En particulier à l’occasion des premiers jours d’un nouveau junior, la session peut aller jusqu’à faire les commits et la pull request.

Le superviseur

Dans la même veine, mais avec une approche plus “apprentissage par la pratique”, le mentor peut prendre du recul en donnant juste les grandes lignes de la fonctionnalité. C’est alors au junior, qui écrit le code, de commenter son travail en expliquant ses choix. Le mentor pourra répondre aux questions, donner des conseils et éventuellement les solutions pour les problèmes les plus ardus.

Cette approche perd le côté visite guidée de la précédente, mais les leçons apprises seront probablement mieux retenues, au prix d’un rythme moins soutenu et peut-être d’un peu plus de stress chez certains. Elle a aussi pour autre bénéfice de mieux appréhender la façon dont un nouveau venu construit son image mentale du code et cherche des solutions.

Bien entendu, cette méthode peut se cumuler avec la précédente ou s’alterner selon le niveau de fatigue des participants. Il suffit seulement de bien garder en tête leurs bénéfices respectifs.

Le clavier tournant

Au premier abord, cette méthode peut sembler similaire aux précédentes. La distinction ? Toutes les 10 minutes, le clavier change de mains et les rôles tournent.

Cette méthode peut être utilisée lorsque les deux participants ont suffisamment confiance en la capacité de l’autre à résoudre un problème, ou qu’au moins tout le monde a les idées claires sur la façon dont un problème va être résolu.

La force de cette méthode ? Les deux participants remplissent deux rôles. On se retrouve avec virtuellement quatre paires d’yeux sur le code, ce qui devrait augmenter les chances de repérer les passages délicats et les résoudres plus aisément, tout en évitant la frustration de bloquer seul face à un problème.

La fonctionnalité en parallèle

Quand on implémente une fonctionnalité qui peut être découpée facilement (back et front, modèle et service, deux classes filles différentes…), on peut parfois s’assoir à côté de son collègue, diviser le travail en deux et travailler en parallèle sur la même branche. Une bonne communication est alors la clé du succès, pour savoir qui fait quoi. Des commits réguliers assureront que tout le monde est à jour sur les parties communes dès que possible. Le but de cette méthode est plus d’augmenter la vitesse de développement que de partager des connaissances.

Mon avis sur cette méthode ? Je trouve qu’elle fonctionne mieux lorsque la différence de niveaux entre les participants n’est pas trop grande, mais surtout lorsque la fonctionnalité est claire et divisée proprement. Mon conseil : discutez longuement avant de commencer à procéder de cette façon, puis continuez à communiquer très régulièrement sur les avancées de chacun.

Le debug en tandem

Comme pour la méthode précédente mais avec un côté exploratoire, le debugging peut se faire en paire. Chacun a son environnement de développement opérationnel et va explorer indépendamment les différentes parties de l’application à la recherche de la cause exacte du bug. Cette méthode a l’avantage de permettre d’avancer plus rapidement sur plusieurs fronts en même temps, augmentant les chances de trouver la source du bug plus vite. L’implémentation du correctif pourra alors se faire avec une des méthodes précédentes si la situation s’y prête, sinon à vous de trouver qui va se charger de corriger le bug.

Conclusion

Il y a plusieurs façons d’aborder le pair programming, chacune avec ses propres bénéfices. On ne devrait pas se mettre à faire du pair programming par effet de mode, mais bien prendre en compte la situation pour choisir la méthode la plus adaptée.

Envie de tester ça avec nous ? On recrute !

Captain Contrat recrute !

Cinq façons de concevoir le pair programming was originally published in Captain Contrat Tech on Medium, where people are continuing the conversation by highlighting and responding to this story.

Pourtant, bien que ce métier soit reconnu comme l’un des meilleurs métiers, il n’est pas exempt de “risques” sur la santé (aussi bien sur le plan physique que psychologique) si l’on ne prend pas quelques mesures.

Cet article propose quelques pistes permettant à la fois de préserver votre santé (voir de l’améliorer pour certains) et d’être plus efficace dans votre travail. Des principes que notre équipe de dev appliquent et en lesquels nous croyons à 100%.

Bien choisir sa boîte

Ce conseil peut paraître évident, mais beaucoup de jeunes diplômés choisissent leur première entreprise en ayant comme critère principal la rémunération.

Un bon salaire permet un certain confort de vie, mais ce n’est pas ce qui va le plus peser dans votre confort mental à terme.

Ce qui va le plus impacter votre moral et votre humeur du jour sera votre cadre de travail, vos collègues ainsi que vos tâches quotidiennes.

En effet, pourquoi intégrer une SSII qui vous envoie chez un nouveau client tous les 2 mois pour faire du Java si vous adorez coder en Ruby et améliorer un produit sur du long terme avec une équipe soudée ?

Prenez donc le temps de bien vous renseigner sur le descriptif du poste, l’organisation de la boîte, ainsi que ses valeurs.

Permettez-vous d’être exigeant, ce ne sont pas les offres qui manquent.

Savoir s’équiper

Le combo chaise et écran

La première image qui nous vient à l’esprit lorsque l’on parle de bons outils pour développeur, est sûrement celle d’un MacBook dernier cri avec un clavier mécanique. Une bonne machine est certes agréable, mais ce n’est pas le plus important pour votre bien-être. Une chaise réglable et un écran externe est en effet le combo indispensable pour préserver votre santé.

Lorsque l’on reste assis une bonne partie de la journée, une chaise entrée de gamme (“confort en option”) peut vite devenir handicapante. En effet, si cette dernière n’est pas réglable et qu’en plus vous ne disposez pas d’écran externe, il y a de forte chance que vous finissiez dans cette position :

Voir celle là :

Si vous avez ce genre de position sur votre chaise, il y a fort à parier que c’est parce que votre setup chaise/écran n’est pas optimal.

Pour votre santé physique, une chaise réglable ainsi qu’un écran externe (ou un support permettant de mettre en hauteur votre PC portable) est donc primordial, afin d’avoir un bon alignement tête écran, comme ci-dessous.

En cas d’urgence, si vous n’avez pas d’écran, pensez au carton !

Le casque d’asocial

Quel joie de travailler en open space ; on peut discuter avec un collègue qui est à l’autre bout de la salle, tirer au nerf sur un autre. On entend les discussions intéressante des autres pôles, le doux bruit de la machine à café toutes les 10 mins… Bref, pour une grande partie d’entre nous, cela peut rapidement devenir un enfer, surtout lorsque l’on a besoin de se concentrer sur un problème complexe.

Si vous n’avez pas la chance de pouvoir travailler au calme (et si vous ne pouvez pas vous isoler), la solution est d’investir dans un casque à réduction de bruit. Onéreux certes, mais c’est le prix de la tranquillité.

Notez que la réduction de bruit, en plus de pouvoir vous isoler des bruits ambiants, vous permettra d’écouter votre musique avec un volume inférieur à celui d’un casque normal, ce qui est plus sain pour votre santé auditive.

Les lunettes

Personnellement, j’ai toujours cru que j’avais une bonne vision. Une visite chez l’ophtalmo m’avait confirmé que tout allait bien… en 2001.

Plus tard, je me suis amusé à essayer les lunettes d’un ami qui avait une légère correction. J’ai été surpris car j’avais l’impression d’avoir une meilleure vision. Curieux, j’ai à nouveau pris rendez-vous chez l’ophtalmo. Résultat, j’ai maintenant des lunettes de travail dont je ne peux plus me passer.

Pour comparer, c’est comme de passer du Full HD au Retina ; tant que vous n’avez pas testé le Retina, le Full HD vous semble correct, mais une fois que vous avez testé le Retina, vous prenez conscience que le Full HD n’est pas si détaillé que ça.

Un grand nombre de personnes pensent ne pas être concernés par les problèmes de vision, et pourtant… Ce n’est pas parce que vous avez la sensation de bien voir que votre vision est parfaite.

Optimiser son espace de travail

La distance chaise-écran

Même avec vos lunettes fraîchement acquises vous avez les yeux qui brûlent en fin de journée ? Il y a de grande chance que vous soyez trop loin de votre écran.

La distance parfaite est compliquée à estimer car elle dépend de plusieurs facteurs (taille de l’écran, DPI…). Mais une bonne règle base est d’avoir une distance d’environ la longueur de votre bras à partir de votre position assise.

Le plus important est que vous n’ayez pas le sensation de devoir vous concentrer lorsque vous lisez les caractères sur votre écran, car plus vous devez vous concentrer pour déchiffrer les caractères, moins vous allez cligner des yeux et plus vos yeux s’assècheront.

Le spot idéal

Sans pour autant partir dans du Feng Shui, sachez que l’emplacement de votre poste de travail peut fortement influencer votre bien-être.

L’emplacement idéal se trouve non loin d’une fenêtre et loin d’un collègue aigri.

Se trouver proche d’une fenêtre permet de regarder de temps en temps au loin pour relâcher vos muscles oculaires qui ont tendance à rester tendus si vous fixez votre écran pendant une longue période.

Être loin d’un collègue aigri permet de ne pas élever votre niveau de cortisol (l’hormone du stress). Cela peut sembler surprenant, mais être proche de quelqu’un qui a tendance à trop râler va affecter votre concentration, votre humeur (vous serez irritable à votre tour) et votre santé (conséquence d’un niveau élevé de cortisol).

Savoir être raisonnable

En tant que développeur, nous restons souvent de longs moments sur des problèmes et finissons même parfois par en être obnubilés : qui n’est pas resté avec un bug non résolu en tête sur son temps libre ? Durant ces moments, on ne voit pas le temps passer. C’est ce que l’on appelle être “In the zone”.

Bien que l’on se sente plein d’énergie durant cet état, ce n’est pas sans conséquence pour notre corps et notre mental. La fatigue peut s’accumuler sans que l’on ne s’en aperçoive.

Profitez de ces moments d’énergie (c’est durant ces moments que nous sommes le plus productif) mais n’en abusez pas ; ne restez pas jusqu’à 22h au boulot, encore moins de manière répétitive, car vous le paierez tôt ou tard et cher.

Même si vous adorez coder, lâchez le clavier et pratiquez d’autres activités pour vous aérer l’esprit ; jouez à la PS4, allez au cinéma avec votre copine ou faites des bébés, buvez des bières avec vos amis…

En codant moins souvent, vous allez encore plus apprécier les moments où vous reprenez le clavier, et ainsi devenir plus efficace.

Si un bug vous obsède, rappelez-vous que votre cerveau continue de travailler de manière inconsciente. Ça ne vous est jamais arrivé de vous réveiller le matin en ayant la solution au problème de la veille ?

Avoir une bonne hygiène de vie

Bouger

La vie moderne nous rend de plus en plus sédentaires ; nous passons plus de temps enfermés, assis devant nos écrans, même sur notre temps libre. Ce n’est pas sans conséquences pour le corps et l’esprit.

Un esprit sain dans un corps sain.

Rester en position assise trop longtemps n’est pas sain, voir carrément dangereux (risque de développer des problème cardiaques, du diabète… etc).

Vous l’aurez compris, pratiquer une activité physique est primordial pour votre santé.

Adopter de bonnes habitudes comme :

• Prendre les escaliers plutôt que l’ascenseur ;
• Vous déplacer à pieds et en vélo plutôt qu’en trottinette électrique ou en voiture ;
• Rester debout dans les transports en commun ;
• Aller voir un collègue plutôt que lui envoyer un message sur Slack .

Manger

Saviez-vous que le principal carburant du cerveau est le sucre ?

Troquez vos tasses de café de 10h et 16h par un fruit, et ce pour 2 raisons :

• Vous buvez sûrement déjà trop de café dans la journée ;
• Le fruit, en plus de vous apporter un coup de boost, vous apportera des vitamines et minéraux dont vous avez sûrement besoin.

Cependant, même si le sucre est bon pour votre cerveau, ce n’est pas une raison pour vous enfiler un paquet de M&M’s. Le sucre contenu dans ce genre de produits à index glycémique (IG) bien trop élevé produira l’effet inverse : vous endormir.

En effet, lorsque vous consommez un aliment à IG élevé, le glucose (sucre) présent dans ce dernier va brutalement entrer dans le sang en grande quantité, déclenchant une réponse insulinique du corps, qui, en plus d’avoir d’autres effets néfastes, va vous rendre somnolent. Ce n’est pas le cas avec un fruit car les fibres présentes dans ce dernier permettent de diffuser le glucose de manière plus douce.

S’hydrater

Sachez également que la deuxième chose dont raffole votre cerveau après le sucre est l’eau. C’est d’ailleurs l’organe du corps le plus sensible à la déshydratation. Prenez l’habitude de bien vous hydrater tout au long de la journée (la bière ne compte pas, car l’alcool déshydrate).

Un autre avantage à boire fréquemment : l’envie fréquente d’aller aux toilettes, ce qui vous obligera à vous lever et à dégourdir vos jambes plusieurs fois dans la journée. En plus, c’est l’endroit idéal pour une épiphanie.

Se supplémenter

Souvent malade ? Le moral dans les chaussettes ? Il y a de fortes chances que vous soyez carencé en Zinc et en vitamine D, surtout si vous vivez dans une région qui manque de soleil.

Vous avez remarqué qu’en été vous êtes généralement de meilleure humeur et moins malade ? C’est en grande parti dû au fait que votre corps synthétise naturellement de la vitamine D grâce aux rayons du soleil, vitamine qui a un impact sur le système immunitaire et l’humeur.

Combiné à la vitamine D, le Zinc va donner un coup de boost à votre système immunitaire et permettra également de guérir plus vite d’un rhume, voir de ne pas en attraper du tout.

Oubliez les multi-vitamines, vous n’avez pas besoin des autres vitamines si vous mangez correctement.

Dormir

On vous dit souvent qu’il faut dormir entre 7 et 8 h par jour, ce qui est vrai. Mais ce que l’on vous dit moins, qui est pourtant le plus important, c’est d’avoir un rythme de sommeil régulier. Cela permettra de respecter votre cycle circadien, entraînant entre autre une amélioration de la qualité de votre sommeil (en facilitant l’endormissement) et un réveil plus aisé.

Pour ceux qui souhaitent perdre du poids, sachez qu’une étude récente a trouvé que les personnes au régime avec un cycle régulier de sommeil perdaient plus de gras que les personnes au sommeil irrégulier. Pourtant, les 2 groupes avaient la même quantité de sommeil.

N’oubliez pas la sieste

Contrairement au Japon où c’est très bien vu et même encouragé, la sieste en France est mal perçue, ce qui est bien dommage.

Vous avez remarqué que vous vous sentez fatigué en début d’après midi, même si vous avez mangé léger ? C’est normal ! Votre corps est fait pour se reposer en début d’après-midi. Plutôt que de lutter contre vos paupières lourdes, optez pour la sieste éclair ; dormez au moins 10 min mais ne dépassez pas 20 min. Cela sera plus efficace qu’un café.

Bonus : avoir un (ou plusieurs) chat(s)

Pour ceux qui ont la chance d’être en télétravail, sachez que le chat peut être votre meilleur allié bien-être durant la journée. En plus d’être mignon et doux, avoir un chat vous aidera à vous sentir plus détendu et à mieux dormir.

Quoi de mieux qu’une petite boule de poils chaude sur les jambes en hiver ?

Pour ceux qui n’ont pas la chance d’en avoir un, regarder des vidéos de chats est aussi bénéfique !

Si vous voulez rejoindre une équipe en pleine santé, rejoignez-nous !

Captain Contrat recrute !

Un développeur efficace est un développeur en bonne santé was originally published in Captain Contrat Tech on Medium, where people are continuing the conversation by highlighting and responding to this story.

Tout d’abord, une compréhension basique de React et Redux est nécessaire. Je considère qu’on en est au point où on se demande si l’état d’un composant devrait être exposé par le store ou non.

Redux en deux mots : état partagé

Les bénéfices de Redux sont multiples, mais là n’est pas notre propos. Rappelons seulement ce qui nous intéresse : le fait que Redux fournisse un état (state) partagé dans lequel tous les composants qui le souhaitent peuvent extraire des informations à connecter à leur propres propriétés (props).

Cet état est le store. Il est composé par des reducers qui vont le modifier en fonction des actions diffusées par les composants.

Quand utiliser le store ?

Les personnes ayant travaillé sur des applications de taille moyenne avec React nous comprendront. Regrouper tous les états de tous les composants dans un store commun s’avère rapidement être une mauvaise idée (même si ce store est correctement divisé entre plusieurs fichiers). En effet, certains composants sont suffisamment indépendants, si bien qu’il n’y a finalement aucun bénéfice à partager leur état au regard de tous, ça ne rendrait les choses que plus complexes.

Mais alors, quand doit-on partager un état dans le store ?

Mon avis est le suivant : ce partage doit avoir lieu dès qu’un état est transmis comme props à d’autres composants de façon trop complexe, que ce soit pour des raisons de profondeur (on veut transmettre l’état à ses petits-enfants) ou de largeur (on utilise une prop et un callback pour la modifier afin de la partager aux composants frères). Un reducer peut aussi servir dans des cas particuliers tel qu’un besoin de contrôle externe, ce qui arrive quand on utilise des librairies externes non adaptées à React par exemple.

L’exemple de la barre de navigation

Prenons un exemple concret pour illustrer et clarifier mon propos : nous sommes en train d’ajouter une barre de navigation (navbar) dépliable à notre application.

Nous disposons donc d’un composant NavBar, avec un état qui contient le booléen displayed. La barre de navigation contient elle-même un bouton pour se replier mais au sein même du composant. On peut donc garder tout dans le composant NavBar sans soucis.

Pour pouvoir déplier la barre de navigation, il faut ajouter un bouton (OpenNavButton) à l’extérieur de celle-ci, mais qui va pouvoir agir sur son état. Nos deux composants ont heureusement un parent direct en commun. C’est donc ce parent qui va stocker un état displayNav (booléen) et le transmettre à ses enfants avec en prime une méthode de modification :

Mais que se passe-t-il si OpenNavButton n’est pas directement appelé par AppLayout, mais par un de ses enfants ?

Nous avons désormais de nombreux composants qui transmettent la fonction toggleNav dans leurs props pour leurs enfants, et ce dans l’unique finalité de la transmettre à OpenNavButton. Non seulement la complexité est assez grande, mais AppRouter et BusinessComponent n’ont pas du tout l’usage de toogleNav. Ils se contentent seulement de le transmettre sans vraiment savoir pourquoi. Travailler sur ces composants de façon indépendante (pour une autre raison que notre barre de navigation) va poser beaucoup d’interrogations sur ce sujet.

C’est alors le moment idéal de changer le code et y ajouter un reducer Redux afin d’exposer l’état de la barre de navigation ainsi qu’une action pour changer cet état. Lorsqu’au moins deux composants se contentent de transmettre des propriétés qu’on leur donne, sans en avoir un quelconque usage, il est alors temps de déplacer l’état à l’origine de ces props dans le store Redux.

Migration progressive vers Redux

Pour finir, il ne faut pas oublier que cette méthode de décision n’est sûrement pas la seule et l’unique. Cependant, elle brille particulièrement à mes yeux comme stratégie de migration. En effet, quand on part d’une grosse application qui devient de plus en plus complexe à maintenir en terme de props à transmettre, on en revient à la situation pré-Redux. Pour une transition progressive, nous avons d’abord listé tous les composants ayant des props uniquement transmises à leurs enfants. En comptant le nombre de composant par propriété, nous avons pu prioriser les state et props à extraire vers notre store Redux. Cette façon de faire est très efficace pour maximiser l’impact des premières étapes de migration. Idéal dans un premier temps quand on sent qu’on ne va pas avoir le temps de tout migrer que se prévenir de futures difficultés est primordial.

Envie de faire du React avec nous, on recrute !

https://jobs.captaincontrat.com/

Le bon moment pour transférer un state dans Redux was originally published in Captain Contrat Tech on Medium, where people are continuing the conversation by highlighting and responding to this story.

Toutes ces raisons incitent à instaurer une ambiance saine dans une équipe. De bonnes conditions de travail qui donnent envie de s’investir.

On attaque le code, pas le développeur

La code review est une étape importante et nécessaire de notre git flow durant laquelle notre code est relu par deux autres développeurs. Elle permet notamment de ne pas faire passer n’importe quoi en production. Après tout, Martin est tellement tête en l’air qu’il a forcément oublié de retirer des instructions de debug dans son code !

Non. Ce n’est définitivement pas le bon état d’esprit.

L’erreur est humaine comme on dit, et tout le monde peut faire des étourderies. La force de l’équipe c’est justement de pouvoir s’appuyer sur chaque membre, consulter les différents points de vue et augmenter ainsi la pertinence d’un bout de code. Ce n’est pas le développeur que nous jugeons, mais ce qu’il écrit et ce qui existe déjà dans la base de code. Nous pouvons toujours faire mieux, et il vaut mieux donner des pistes pour aller en ce sens plutôt que de se lamenter des compétences de son équipier.

Nous appliquons une autre règle en interne sur Github. Il faut deux validations pour pouvoir fusionner son code, donc il n’est pas utile d’être trop prohibitif. Plutôt que d’interdire une fusion après la relecture, nous laissons des commentaires pour demander des évolutions. Cela évite de voir apparaître une grosse icône rouge après chaque passage d’un relecteur, ce qui pourrait jouer sur le moral. Il n’y a rien de plus déprimant que d’essuyer une série de refus.

Nous appliquons l’interdiction seulement si le code s’apprête à être fusionné, et qu’une erreur vient d’être remarquée.

Il revient à l’auteur de la Pull Request l’honneur et le privilège de merger lui-même sa branche un fois que tous les voyants sont au vert.

Une responsabilité partagée

Il est trop simple de remettre la faute sur une seule et même personne. Alors que la porter à plusieurs épaules la rendrait moins lourde mais tout aussi importante.

L’étape de la code review nous permet de partager la responsabilité entre les développeurs. Si un problème survient sur la plateforme suite à la fusion d’une branche, alors ce n’est pas seulement la faute de celui qui l’a écrite ou celui qui a cliqué sur le bouton pour la merger. Deux autres développeurs sont passés par là, donc ils ne sont pas moins fautifs.

Il en va de même pour les mises en production. Si une action particulière doit être effectuée lors de la procédure, ça ne se devine pas ! Il faut que l’information soit renseignée quelque part. Et cela doit être fait par celui qui envoie sa branche sur le serveur de staging. Les relecteurs aussi peuvent le rappeler au développeur.

Chercher un fautif est une perte de temps et d’énergie et cela peut créer de la frustration dans l’équipe. Ce qui importe, ce sont les leçons que nous en tirons pour ne pas répéter l’erreur une seconde fois. Réaliser un post-mortem est une solution pour historiser l’incident et creuser le contexte du problème : pourquoi est ce que c’est arrivé (personne ne doit être visé), et qu’aurions nous pu faire pour l’éviter.

La responsabilité se manifeste encore d’une autre manière chez Captain. Notre particularité ? Nous sommes 10 développeurs et 1 QA, mais nous n’avons pas de CTO. Pas de manager technique ; notre supérieur direct est l’un des co-fondateurs qui joue principalement un rôle de coach. Notre équipe s’auto-gère, et la parole de chacun vaut autant que la parole des autres car nous prenons les décisions tous ensemble. Les tâches habituellement traitées par un CTO sont réparties entre les membres de l’équipe selon leur bon vouloir : participer à la définition des objectifs trimestriels, recruter, réaliser les perf reviews, formaliser un de nos process…

Au delà de responsabiliser un équipier, cela permet de l’engager et de le valoriser par une participation active à la vie d’équipe.

Accompagner les nouveaux

Accueillir un nouvel équipier prend du temps, qui s’étire en fonction de ses expériences passées. Il est en effet plus coûteux d’onboarder un junior qu’une personne plus expérimentée car elle aura besoin d’être plus encadrée.

La tolérance et la patience sont de mise à cette étape. Il y a des éléments à prendre en compte lors de son arrivée :

1. Il ne produira pas de valeur tout de suite ;
2. La bande passante des autres sera en partie allouée à son onboarding ;
3. Il va devoir s’adapter à une nouvelle base de code, une nouvelle organisation, de nouveaux objectifs, potentiellement de nouveaux outils.

L’arrivée d’un nouveau s’accompagne donc d’une baisse de productivité qu’il faudra anticiper. En abaissant l’engagement du prochain sprint notamment, dans le cas d’une méthodologie Scrum.

Mais il apporte avec lui un regard neuf, de quoi recycler l’air au sein de l’équipe. Certaines des briques de codes lui évoqueront une assiette de spaghettis sauce béchamel, quelques process lui sembleront bancals, ou il trouvera sans doute à la documentation un style très épuré.

C’est l’occasion de remettre les choses en question. Que faisait il dans son ancienne boîte ? Est ce que ça fonctionnerait mieux que ce notre méthodologie actuelle ? Comment pourrait-on transformer, adapter nos méthodes pour que tout le monde soit à l’aise, et donc augmenter notre productivité ?

Ne pas avoir honte de demander de l’aide

Il y a ces nouveaux tout timides qui n’osent pas déranger les développeurs plus anciens ou plus expérimentés pour demander de l’aide. Il y a aussi ces développeurs seniors qui coincent mais qui ressentent le besoin de justifier leur légitimité.

Ils vont bloquer sur un problème plus longtemps que nécessaire, alors que demander de l’aide et / ou faire du pair programming aurait pu les dé-coin-cer.

Oui, ça arrive à tout le monde de faire des erreurs d’inattention, et il n’y a pas de honte à ne pas comprendre quelque chose du premier coup. Le fait d’exposer son problème à quelqu’un, en reprenant depuis le début, nous permet de voir les choses sous un nouvel angle. Très souvent, la solution arrive d’elle même avant même que le deuxième développeur n’ait eu le temps de dire quoi que ce soit.

Et au delà de n’importe quel étourderie, ce blocage, si ça se trouve, c’est une bizarrerie de l’application qui est connue de tous, mais qui n’a été documenté nulle part ! Et ça, ça ne se devine pas.

Alors sors de ta bulle, ravale ton amour propre, et sollicite les autres. Ils hésiteront moins eux aussi à te demander de l’aide en retour.

Le mot de la fin

Des petites choses simples peuvent être mises en place dans une équipe. Quelques défis rigolos, comme réussir à aligner 100 build verts sur notre outil d’Intégration Continue avec la promesse d’une bière à la clé. Des 1–1 entre équipiers, en sortant se balader une demie-heure régulièrement.

Dans une méthodologie Scrum, il ne faut pas oublier que l’équipe ne se limite pas aux développeurs. La team Scrum est la fusion entre cette équipe, et celle du Produit. S’il y a des bienfaits à maintenir une ambiance saine entre devs, il y en a d’autant plus à travailler sur cette symbiose Produit / Dev.

Si vous cherchez une équipe avec des process vertueux, rejoignez-nous !

Captain Contrat recrute !

Quelques astuces simples pour créer une super ambiance dans votre équipe dev was originally published in Captain Contrat Tech on Medium, where people are continuing the conversation by highlighting and responding to this story.

Il y a deux ans, je ne savais pas coder, pourtant j’ai décroché un job de développeur il y a un an, en rejoignant Captain Contrat.

Comme de plus en plus de monde, j’ai découvert le plaisir de coder en faisant un bootcamp; c’est à ce moment là que mon projet de devenir développeur s’est dessiné.
Seulement voilà, lorsqu’on sort d’un bootcamp, l’écart peut être grand entre l’envie de devenir développeur et le fait d’en faire son métier.

Voici donc mon retour d’expérience et mes conseils afin de maximiser vos chances de réussir à trouver le job de développeur qui vous correspond et prendre du plaisir dans votre nouveau métier.

Bien choisir son entreprise

Il y a une pénurie de développeurs en France et dans le monde en général, c’est un fait, et si c’est une super opportunité pour trouver du travail malgré une faible expérience, cela peut également être un piège.

En effet qui dit peu d’expérience dit nécessité de monter en compétences, il est donc extrêmement important de trouver l’environnement de travail qui vous permettra d’y parvenir.
Trouver un job est facile, mais trouver un travail en accord avec ce dont vous avez réellement besoin et envie l’est beaucoup moins.
Il est donc essentiel de se poser la question de ce que vous recherchez et de vous donner les moyens de l’obtenir.

Lorsque j’ai commencé à chercher du travail après le Wagon, mon cahier des charges était le suivant :

• Intégrer une équipe suffisamment grande pour qu’elle ait de la bande passante me permettant de progresser
• Rester sur la techno que j’ai apprise pour avoir des bases plus solides (en l’occurrence Ruby on Rails)
• Éviter les agences pour travailler sur un seul produit et l’améliorer en suivant de bonnes pratiques
• Intégrer une boite en laquelle je crois grâce au produit qu’elle offre mais également grâce à sa vision d’entreprise

J’ai finalement décidé de rejoindre Captain Contrat car ce qui m’a été présenté correspondait parfaitement à ce que je cherchais :

• Une équipe de 6 devs avec 2 expérimentés pour 1 junior qui restent à l’écoute pour nous aider et nous permettre de monter en compétences rapidement.
• Une stack Rails pour ne pas être dépaysé et une partie React que je voulais apprendre
• Un workflow avec de la code review pour shipper du code propre et toujours meilleur
• Une boîte qui aide les entrepreneurs français avec une vraie culture d’entreprise et des valeurs que je partage

Bien s’intégrer à l’équipe

Une fois l’entreprise trouvée, le plus difficile commence.

Quand on arrive au sein d’une équipe de développeurs expérimentés en sortant d’un bootcamp, le syndrome de l’imposteur peut vite arriver, mais il faut relativiser : quand on fait une formation en trois mois il y a beaucoup de choses que l’on ne peut pas apprendre.
On maîtrise l’essentiel pour réussir à coder une app qui tienne la route à la fin, mais lorsque l’on devient développeur il y a beaucoup plus de choses à découvrir comme écrire des tests, maîtriser son terminal, coder dans une app bien plus complexe que ce qu’on a connu etc…

Tout cela fait qu’on peut se prendre une petite claque et se sentir assez nul au début, c’est une étape normale qu’il faut savoir accepter surtout lorsqu’on se reconvertit.
On peut alors avoir l’impression de repartir à la case départ et cela demande de faire preuve d’humilité et d’avoir très envie de progresser, et c’est là que le choix de l’entreprise et de l’équipe jouera un rôle essentiel.

Personnellement, j’ai eu la chance d’intégrer une équipe qui a été extrêmement bienveillante et qui a pris le temps de m’accompagner, de me former et dont l’organisation m’a permis de progresser vite.
Aujourd’hui j’ai encore plein de choses à apprendre mais si je regarde en arrière, Captain Contrat m’a permis d’atteindre un niveau qui n’a plus rien à voir avec celui que j’avais en sortant du Wagon.

Derniers conseils

Ne surtout pas hésiter à appeler à l’aide

Quand on arrive dans une équipe, on veut faire ses preuves et se prouver qu’on peut y arriver seul, seulement cela peut prendre beaucoup de temps et donc en faire perdre à l’équipe. Il vaut mieux demander de l’aide rapidement pour éviter de rester bloqué trop longtemps.
En plus cela permet de progresser plus vite et le pair programming est une super occasion d’avoir des tips pour être plus efficace.

Lever le nez de son code

Quand on fait partie d’une équipe de devs, on est intégré dans un process où on ne se contente pas uniquement de coder. Souvent il faut aussi faire de la code review par exemple et cela veut dire prendre le temps nécessaire pour ne pas ralentir les autres en ne se préoccupant que de son travail. En plus faire de la code review est un super moyen de progresser en lisant le code de devs plus expérimentés. Restez donc attentifs à ce qui se passe à côté !

Prendre du plaisir

C’est essentiel car on a la chance de faire un métier où l’on apprend chaque jour de nouvelles choses et où les challenges ne manquent pas, il est donc difficile de progresser si on ne s’amuse pas !

Si ça vous tente de rejoindre une entreprise où on apprend chaque jour avec plaisir, rejoignez nous !

Captain Contrat recrute !

Réussir son premier job de développeur après un bootcamp was originally published in Captain Contrat Tech on Medium, where people are continuing the conversation by highlighting and responding to this story.

Avec Active Record

Active Record se repose en interne sur Arel, et la façon la plus classique d’utiliser Arel est au sein d’Active Record. Pour des requêtes simples dont le résultat se traduit en liste d’instances de models, on obtiendra ainsi directement les mêmes type de résultats qu’avec Active Record.

Ainsi, si on a un model Cat, on peut faire :

cat_arel = Cat.arel_table
soft_fur = Cat.where(cat_arel[fur_quality].gt(5))

La plupart du temps, on utilise ça quand la requête Arel se résume à une (ou plusieurs) conditions de type where.

Par l’exécution d’une requête SQL

Parfois, on souhaite optimiser nos requêtes de façon à ce que le résultat ne corresponde à aucun model. Dans ce genre de cas, il faut se rabattre sur l’exécution directe de la requête sql. Pour ce faire, il suffit de convertir la requête Arel en sql avec la méthode to_sql et l’exécuter.

ActiveRecord::Base.connection.exec_query(my_query.to_sql)

Les tuples issus de la requête sont présentés sous forme d’itérables de hashes, avec pour clé les colonnes nommées dans la requêtes SQL. Il est donc conseillé d’utiliser des alias pour ces colonnes de façon à faciliter la manipulation future du résultat.

Si on veut avoir par exemple à la fois le minimum et le maximum d’une colonne au sein d’une même requête, cela ressemble à :

cat_arel = Cat.arel_table
query = cat_arel.project(cat_arel[:price].minimum.as(‘min’), cat_arel[:price].maximum.as(‘max’)).to_sql

records = ActiveRecord::Base.connection.exec_query query

puts records.first

>>> {“min”=>0.0, “max”=>72.0}

Si je n’avais pas mis d’alias min et max, le hash aurait valu {“MIN(`cats`.`price`)”=>0.0, “MAX(`cats`.`price`)”=>72.0}, ce qui n’est vraiment pas pratique. Si la requête renvoie plusieurs lignes, il suffit d’itérer sur le résultat d’exec_query.

Conclusion

Arel permet de réaliser des requêtes plus complexes qu’Active Record. Si le résultat reste traitable en tant que model, c’est votre jour de chance et il suffit d’insérer des expressions Arel au sein d’une requête Active Record classique. Si on fait quelque chose de plus complexe qui ne renvoie pas de models, il faut alors exécuter directement la requête sql préparée par Arel.

Envie de travailler avec nous, on recrute?

https://jobs.captaincontrat.com/

Comment exécuter des requêtes Arel was originally published in Captain Contrat Tech on Medium, where people are continuing the conversation by highlighting and responding to this story.