Travailler au sein d'une équipe multilingue

En tant que développeurs travaillant au sein d'une équipe, nous sommes souvent habitués à ce que tous les membres de cette équipe maîtrisent les mêmes langages, les mêmes technologies et les mêmes outils. Selon le contexte, cela peut impliquer de travailler avec plus d'un langage de programmation.

Si vous travaillez sur le front-end, vous devrez probablement "parler" HTML, CSS et JavaScript. Dans un contexte de pile complète, vous pouvez également ajouter l'un des nombreux langages de programmation back-end. En dehors de toute spécialisation ou de toute focalisation sur une partie particulière de la pile, les développeurs d'une telle équipe auront un vocabulaire technique commun et un cadre de référence partagé défini par la pile technologique qu'ils utilisent. Depuis que j'ai rejoint l'équipe chargée des relations avec les développeurs chez Vonage, j'ai dû m'habituer à une réalité bien différente de celle que je viens de décrire.

Pour situer le contexte, l'un des principaux objectifs de notre équipe est d'aider et de soutenir les développeurs dans l'utilisation des nombreuses API de communication de Vonage. L'une des façons d'y parvenir est de fournir des kits de développement logiciel (SDK) qui font abstraction d'une partie de la complexité de bas niveau de l'utilisation des API afin de les intégrer plus facilement dans une application. Bien entendu, les développeurs qui utilisent les API de Vonage le font à l'aide d'une grande variété de langages de programmation et de piles technologiques. Nous fournissons donc des SDK pour de nombreux langages et environnements différents : SDK serveur pour Ruby, PHP, Python, Java, Node et .net ; SDK client pour JavaScript, iOS et Android.

En tant que défenseur des développeurs Ruby de l'équipe, une partie de mon rôle consiste à maintenir et à améliorer nos SDK Ruby. Lorsque je dois corriger un bogue ou ajouter une fonctionnalité, je le fais en écrivant du code Ruby. Mes coéquipiers, cependant, n'écrivent pas de code Ruby. Ils écrivent plutôt du PHP, du Python ou du C#. Il se peut que nous travaillions à l'implémentation de la même fonctionnalité, mais que nous le fassions dans des langages complètement différents.

J'aime à penser que mes compétences en JavaScript sont plutôt décentes, mais ce n'est pas mon langage principal. J'ai écrit un peu de PHP dans le passé (bien que notre défenseur de PHP, Jim, m'assure que le langage a beaucoup changé depuis cette époque !) et je connais un peu de Python, mais je ne me considérerais pas comme un expert dans l'un ou l'autre de ces langages, et je me sens définitivement plus à l'aise lorsque je travaille avec du code Ruby.

Cependant, si je veux être un bon membre de l'équipe et être en mesure de soutenir mes collègues dans leur travail, je dois de temps en temps sortir de ma zone de confort Ruby.

Depuis que j'ai rejoint l'équipe, il y a environ sept mois, je me suis retrouvé à servir de caisse de résonance ou de deuxième paire d'yeux pour des collègues qui travaillaient sur des bogues ou des fonctionnalités pour leurs SDK (non-Ruby). J'ai participé à l'examen des demandes d'extension pour les bibliothèques PHP, Python et .net. J'ai même apporté quelques petites modifications à l'un des dépôts Python.

Être mal à l'aise (parfois), c'est bien, en fait

Travailler au sein d'une équipe multilingue peut certainement présenter certains défis. Cependant, j'aimerais suggérer que cela présente également de nombreux avantages.

En tant que développeurs, nous nous efforçons de maîtriser notre métier. Nous développons notre expertise jusqu'à ce que nous nous sentions à l'aise dans un domaine de connaissances particulier. La construction de cette "zone de confort de la connaissance" présente de nombreux avantages : nous pouvons travailler en toute confiance, rapidement et efficacement sans avoir à revérifier ou à vérifier les choses en permanence. D'un autre côté, cela peut nous rendre paresseux et enclins à faire des suppositions. Lorsque nous sommes confrontés à un nouveau problème ou à une nouvelle situation, nous pouvons parfois nous rabattre sur des schémas familiers et penser que nous connaissons déjà la solution sans avoir clairement réfléchi au problème.

Dans le bouddhisme zen, il existe un concept appelé Shoshinqui se traduit par "l'esprit du débutant". Il s'agit essentiellement de l'idée d'être ouvert aux possibilités et sans idées préconçues lors de l'étude d'un sujet ou de l'approche d'un nouveau problème. L'acquisition d'une expertise fait disparaître l'"esprit du débutant", mais le fait de quitter occasionnellement sa zone de confort linguistique peut contribuer à le rétablir.

Par exemple, si je travaille sur une fonctionnalité pour l'une des bibliothèques Ruby et que j'y réfléchis dans un contexte purement Ruby, je risque de prendre la mauvaise habitude de me concentrer uniquement sur la solution et de ne pas réfléchir clairement au problème. En revanche, si je discute de cette même fonctionnalité avec des collègues dans un contexte PHP ou Python, cela m'oblige à me débarrasser de toute hypothèse spécifique à Ruby concernant la solution et à me concentrer sur le problème.

En plus d'éliminer les idées préconçues, le fait de travailler au quotidien avec des développeurs issus d'autres langues peut élargir vos horizons de bien d'autres manières. Cela vous ouvre à d'autres approches et à d'autres façons de faire les choses et, en fin de compte, à d'autres façons de penser.

Il existe une théorie linguistique connue sous le nom de relativité linguistique ou l'hypothèse Sapir-Whorf. Cette théorie suggère que la structure d'une langue peut influencer notre façon de penser et de voir le monde. Cette théorie a été élaborée en tenant compte des langues humaines plutôt que des langages de programmation. Cependant, comme les langages de programmation sont conçus par des humains, la même théorie peut être appliquée.

La conception des langages de programmation peut créer certaines orthodoxies sur la manière dont les logiciels doivent être écrits. Les langages peuvent être fortement ou faiblement typés. Certains langages se prêtent à une approche impérative, d'autres à une approche déclarative. Ces caractéristiques du langage peuvent vous amener à penser d'une certaine manière lorsque vous écrivez du code.

Si vous n'avez connu qu'une certaine façon de penser, vous risquez de tomber dans le piège de croire que cette façon est la bonne. L'expérience de langages et d'approches différents vous ouvre aux différentes façons de penser suggérées par la conception de ces langages. Cela peut vous montrer qu'il n'y a pas nécessairement une "bonne" façon, mais seulement différentes "façons", chacune avec ses propres compromis.

Par exemple, bien que Ruby ait toujours été (et soit toujours par défaut) un langage à typage dynamique, nous avons maintenant la possibilité d'introduire une vérification statique des types dans nos programmes Ruby. Des bibliothèques comme Sorbet existent depuis quelques années et, plus récemment, Ruby 3 a introduit cette option en natif. Penser d'une manière statiquement typée semble probablement encore un peu étrangère à la plupart des développeurs Ruby, et nous pouvons apprendre beaucoup en regardant du code dans un langage statiquement typé tel que C#.

private static void ValidSmsResponse(SendSmsResponse smsResponse)

Lorsque nous examinons la signature d'une méthode dans un langage inconnu comme celui-ci, nous n'avons pas d'idées préconçues sur le langage. Pour comprendre ce que fait le code, nous devons nous demander à quoi sert à quoi sert chaque élément de la signature, et pourquoi pourquoi elle a été écrite ainsi. Nous pouvons tirer des enseignements de ce processus et les appliquer à notre code Ruby.

Points d'apprentissage et conseils

Au cours des derniers mois, j'ai appris quelques méthodes utiles pour travailler au sein d'une équipe multilingue, et je tenais à en partager quelques-unes ici.

Zoom arrière pour établir le contexte

Il y a quelques mois, Jim travaillait à la dépréciation et à la suppression de plusieurs Traits d'une des bibliothèques PHP, et souhaitait que quelqu'un lui explique les changements qu'il apportait à la base de code. Au début de notre conversation, je me perdais dans les méandres de la syntaxe spécifique à PHP. Ce qui m'a vraiment aidé dans cette situation, c'est de faire un zoom arrière et de discuter des changements à un niveau d'abstraction plus élevé. Plutôt que de réfléchir à ce que faisait une ligne de code spécifique, il était plus facile de comprendre le contexte des changements en posant des questions telles que "quel est l'objectif de ce Trait ?", "quelle est la relation entre ces classes", et ainsi de suite. Une fois que vous avez établi un contexte clair pour ce que fait un code peu familier, il est beaucoup plus facile de revenir aux détails de l'implémentation.

Réutilisation des modèles mentaux

Une autre chose qui peut s'avérer utile lorsque l'on se trouve en terrain inconnu est de réutiliser ou de réaffecter les modèles mentaux existants. Au cours de notre apprentissage en tant que programmeurs, nous avons tous passé beaucoup de temps à établir des modèles mentaux solides pour les nombreux concepts techniques avec lesquels nous travaillons. La bonne nouvelle, c'est que nombre de ces modèles peuvent être réutilisés ou réaffectés dans le contexte d'autres langages de programmation.

Un exemple serait d'essayer d'expliquer quelque chose comme les blocs Ruby à un développeur non-Ruby. D'un point de vue syntaxique, les blocs sont assez particuliers au langage Ruby, mais si je dois expliquer ce qu'ils sont à, disons, un développeur JavaScript, je peux dire quelque chose comme "ils fonctionnent un peu comme des fonctions de rappel". Bien sûr, si vous creusez dans les détails de l'implémentation du langage, ce n'est pas la même chose, mais en tant que modèle mental général pour expliquer ce qu'ils font et comment ils sont utilisés, c'est probablement assez proche.

Conceptuellement, passer un bloc à map en Ruby :

[1, 2, 3].map do |num|
  num + 1
end

n'est pas vraiment différent du fait de passer une fonction de rappel à map en JavaScript :

[1, 2, 3].map(function(num) {
  return num + 1;
});

En fonction de nos choix syntaxiques dans les deux langues, ils peuvent même ressembler assez similaires :

# Ruby
[1, 2, 3].map { |num| num + 1 }

// JavaScript
[1, 2, 3].map(num => num + 1)

Identifier les similitudes pour comprendre les différences

Pour continuer sur ce thème, une autre chose à faire est de rechercher les similitudes entre les différents langages et les différentes piles technologiques. J'ai mentionné plus haut les avantages que l'on peut tirer de l'exploration et de l'ouverture aux différentes approches que les langages de programmation peuvent adopter. En fin de compte, ces langages et les outils qui les accompagnent visent généralement à résoudre les mêmes problèmes.

Par exemple, il existe des bibliothèques de tests pour la plupart des langages de programmation. La syntaxe qu'elles utilisent diffère d'un langage à l'autre ; certaines, comme RSpec, peuvent même utiliser leur propre DSL. En fin de compte, les bibliothèques de test résolvent toutes le même problème. D'une manière générale, elles utilisent toutes des assertions d'une manière ou d'une autre.

Minitest et PyTest sont deux bibliothèques de test, l'une pour Ruby et l'autre pour Python. L'identification de leurs similitudes peut fournir un contexte de base qui peut ensuite aider à mettre en évidence les différences intéressantes dans leur fonctionnement ou dans la manière dont elles ont été mises en œuvre.

Un monde au-delà de Ruby

Je pense que ce que j'essaie de dire avec tout ça, c'est que même s'il peut être tentant de rester dans sa zone de confort et de s'en tenir à ce à quoi on est habitué, ce que j'ai vécu ces derniers mois m'a rappelé qu'il y a tout un monde de choses vibrantes et intéressantes qui se passent dans d'autres langages que Ruby. J'adore Ruby, et je n'ai certainement pas l'intention de m'en éloigner en tant que langage principal, mais je suis très enthousiaste à l'idée de me plonger dans ces autres langages et de les explorer plus en profondeur.