3 minutes pour (enfin) comprendre un développeur

Jeudi matin. 10h00. Vous prenez votre deuxième petit déjeuner de la matinée lorsque vous apercevez près de la machine à café le développeur qui travaille sur la nouvelle fonctionnalité que vous avez demandé la semaine dernière. Vous y voyez une occasion en or pour connaître l’avancement de ce développement que vous attendez tant. Après un très classique (mais toujours efficace) « Salut, ça va ? », vous vous lancez. Seulement voilà, impossible de comprendre sa réponse. Vous avez beau le faire répéter, c’est le néant. Besoin d’aide ? On vous aide à comprendre les réponses possibles de votre développeur, Google Translate style !

Réponse possible n°1 : « Je ne peux pas rester, j’ai stand-up meeting »

Les stand-up meetings, appelés aussi réunions debout ou daily scrums sont une composante fondamentale des méthodologies agiles, très populaires dans les équipes techniques.

Cette réunion a généralement lieu à une fréquence quotidienne et est de courte durée (il est recommandé de ne pas dépasser les 15 minutes). Elle inclut généralement des développeurs, des Products Owners et le CTO et a pour objectif de permettre à chaque développeur d’expliquer ce qu’il a fait le jour précédent, ce qu’il a prévu de faire ce jour et de faire remonter ses éventuels points de blocage.

Mais au-delà de ces retours individuels, les stand-up meetings sont surtout l’occasion pour les développeurs d’échanger sur les difficultés rencontrées et de s’entraider. Cela se révèle particulièrement utile quand une partie de l’équipe travaille à distance, par exemple.

Cela vous semble une approche intéressante ? Sachez qu’elle peut être appliquée à n’importe quelle équipe, qu’elle soit technique ou pas.

Réponse possible n°2 : « J’ai un problème de merge sur la branche Master »

Bon là le développeur ne vous fait pas de cadeau ! Il fait en fait référence à Git, un logiciel de gestion des versions qui permet de consigner toutes les modifications réalisées sur le code mais également de travailler à plusieurs développeurs sur un même dossier. Ce n’est en fait rien d’autre que la version (très) améliorée de vos fameux v1, v2, v2bis…v42 pour vos fichiers Excel.

Ainsi, lorsqu’un développeur se mettra à coder pour résoudre une anomalie remontée ou développer une nouvelle fonctionnalité, il utilisera un environnement à part afin de ne pas impacter directement le code existant. Une fois le travail terminé, il fusionnera son code avec le code source.

Et si deux développeurs ont modifié les mêmes lignes de code, des conflits peuvent alors apparaître ! Il convient dans ce cas de résoudre ces conflits un par un en sélectionnant le code qui va l’emporter. Cela est, comme vous l’aurez compris, un travail souvent long et fastidieux.

Réponse possible n°3 : « J’ai du refactoring à terminer avant de commencer ce nouveau dev »

Le développeur est en train de vous expliquer qu’avant de commencer à coder votre nouvelle fonctionnalité, il doit prendre le temps de revoir du code qu’il a produit et qui fonctionne pourtant parfaitement. Cela vous semble être une perte de temps ?

Cette étape de refactoring est pourtant primordiale. Elle permet de nettoyer le code en le rendant plus lisible pour les autres développeurs qui seraient amenés à travailler dessus et, dans certains cas, à en améliorer les performances. Se priver de cette étape pourrait à terme rallonger le temps de traitement d’une anomalie ou d’une fonctionnalité puisque le développeur prendra plus de temps pour comprendre le code existant.

De manière plus concrète, le refactoring pourra par exemple consister à commenter les parties les plus complexes du code ou encore renommer certains éléments.

Réponse possible n°4 : « J’avance plus lentement car ce code legacy est en Ruby alors que je travaille normalement en PHP »

Pas de panique devant ces termes qui peuvent paraître barbares. Ruby et PHP ne sont que des langages de programmation dits de back-end.

Il existe aujourd’hui de très nombreux langages qui ont chacun leurs caractéristiques et leur application. Un développeur va ainsi être amené à en apprendre plusieurs durant sa carrière et devra continuer à se former tout au long de sa vie afin d’apprendre d’éventuels nouveaux langages. Parmi les derniers langages créés, on peut par exemple citer le langage Swift qui date de 2014 et qui est utilisé pour créer des applications mobiles natives pour iOS, ou encore le langage Go créé en 2009 par Google.

Chaque langage a une syntaxe et une logique qui lui est propre. Apprendre un nouveau langage nécessite donc de s’approprier cette syntaxe et les outils liés.

Réponse possible n°5 : « J’attends toujours les credentials de l’API »

Une API est l’acronyme de “Application Programming Interface” et désigne tout simplement une interface pour des applications tiers. Votre développeur sera amené à utiliser une API soit pour récupérer des données provenant d’un tiers (Google Maps, par exemple) soit pour utiliser le service d’un tiers (comme le service mis à disposition par Visa pour vérifier la validité d’une carte bancaire).

Or utiliser une API, qu’elle soit gratuite ou payante, nécessite de récupérer les autorisations nécessaires. Une documentation est également presque systématiquement fournie pour expliquer aux développeurs comment utiliser l’API. Il se peut aussi que votre entreprise possède sa propre API qui sera utilisée par vos clients ou interlocuteurs.

Et si vous ne comprenez toujours pas la réponse du développeur, ne fuyez pas pour autant ! N’hésitez pas à lui demander de vous expliquer ce qu’il veut dire avec des termes simples voire à vous le montrer. Il sera sans doute ravi de voir que vous portez un intérêt à son travail et cela ne pourra qu’améliorer votre relation avec lui !

Suivez Welcome to the Jungle sur Facebook pour recevoir tous nos meilleurs articles dans votre timeline !

Photo by WTTJ inspirée de Pour les nuls