Catégories
Astuces et Design

Avantages, astuces et conseils pour le faire fonctionner – SitePoint

Programmation par paire – une paire supérieure à la somme de ses parties. Vous avez peut-être entendu parler de la programmation par paires et vous êtes demandé si cela valait la peine d'essayer sur votre lieu de travail. En apparence, cela semble simple, mais deux développeurs assis ensemble ne sont pas tout ce qu'il faut pour obtenir un appariement productif.

Les obstacles logistiques et personnels tels que la planification, les choix d'outils et les distractions peuvent vous empêcher de tirer le meilleur parti de l'association. Mais les avantages potentiels peuvent rendre la peine de reconnaître et de surmonter ces défis.

Pourquoi jumeler?

Comment pourrait-il être plus productif de prendre deux programmeurs qui travaillaient auparavant sur des projets distincts et de les faire travailler ensemble sur un seul projet? Tout ne prendra-t-il pas deux fois plus de temps? Pour un étranger, l'idée de l'association peut sembler contre-productive au début, mais les avantages deviennent apparents lorsque vous commencez à réfléchir à la raison pour laquelle nous codons et à ce que nous essayons d'accomplir.

La programmation ne consiste pas à produire le plus de lignes de code dans les plus brefs délais, ni même à fournir le plus de fonctionnalités dans des délais de plus en plus serrés. Vous pouvez avoir des ingénieurs travaillant 24 heures sur 24 pour mettre en production de nouvelles fonctionnalités, mais à quel point sont-elles vraiment productives si ces fonctionnalités sont lancées par des personnes travaillant isolément selon leur propre compréhension unique de l'architecture globale? Le code résultant est susceptible d'être criblé de dettes techniques telles que des bogues cachés, des problèmes de performances, une syntaxe idiosyncrasique et des conceptions inefficaces qui peuvent ne pas utiliser efficacement les ressources et rendre la modification du code beaucoup plus difficile et plus longue lorsque l'un de ces éléments défauts des surfaces.

Vous avez besoin que votre code soit significatif et bien écrit afin qu'il fonctionne de manière transparente et puisse être modifié facilement. Vous en avez besoin pour encapsuler les fonctionnalités souhaitées afin que votre produit final se comporte correctement et fonctionne comme prévu. Vous en avez besoin pour être résilient afin qu'il puisse résister aux changements organisationnels qui font naturellement partie de la collaboration, ainsi qu'aux changements environnementaux et aux nouvelles attentes des clients qui peuvent rendre la solution viable d'aujourd'hui obsolète sans trop d'avertissement.

Pour que cela soit possible, les développeurs doivent être en mesure de s'entendre clairement sur les exigences fondamentales, de se familiariser rapidement avec les technologies nouvelles ou établies qui peuvent être nécessaires et de se concentrer sans interruption pour tester des solutions créatives et développer un produit qui mérite d'être mis devant le client.

Ce sont les défis du monde réel que la programmation par paires aide à relever. Lorsque deux développeurs travaillent ensemble dans une paire, la qualité du code qu'ils produisent s'améliore avec leur compréhension commune de la façon dont il fonctionne. Cela permet à la prochaine personne qui lit le code de le récupérer et de le modifier si nécessaire, et cela réduit le risque que la seule personne de l'équipe qui sache comment fonctionne une partie du code puisse gagner à la loterie et quitter l'équipe. , emportant cette précieuse connaissance avec eux.

Le coût du temps en heures de travail mythiques est loin d'être le 50% qui peut sembler intuitif si vous essayez d'assimiler l'art complexe du codage au travail répétitif sur la chaîne de montage. Certaines études empiriques ont conclu que la programmation par paires pourrait entraîner une augmentation d'environ 15% du temps nécessaire à deux programmeurs pour accomplir les mêmes tâches s'ils avaient travaillé seuls, mais le code résultant sera également de bien meilleure qualité, avec environ 15% moins de défauts observables à corriger. Combinez cela avec la propriété partagée, un engagement plus profond et une résolution de problèmes plus rapide qui vient du fait que plus d'un esprit est engagé dans la résolution d'un problème, et il est clair pourquoi la programmation par paires est une approche populaire.

Qu'est-ce que le jumelage exactement?

Alors, que faut-il pour que deux développeurs travaillent ensemble pour atteindre les améliorations de productivité et de qualité qui découlent du jumelage? Il s'agit principalement d'apprendre à travailler en collaboration, ce qui n'est pas nécessairement la façon dont la plupart d'entre nous ont appris à coder.

Par définition, la programmation en binôme ne démarre que lorsque deux personnes travaillent ensemble sur un même ordinateur. Mais comment cela fonctionne-t-il dans la pratique?

Deux personnes …

L'élément fondamental de la programmation par paire est de travailler avec votre paire. Lorsqu'une tâche est acceptée, elle doit être partagée entre les deux personnes qui y travaillent et elles doivent toutes deux être pleinement engagées dans la tâche pendant qu'elles sont associées. Cela signifie qu'ils doivent tous deux comprendre les exigences de la même manière et travailler ensemble pour parvenir à une compréhension commune de la façon dont ils veulent s'y prendre.

Le jumelage aide les gens à mieux verbaliser leurs idées et leurs attentes. La compréhension implicite que vous avez dans votre tête lorsque vous travaillez seul doit être communiquée afin que vous et votre paire sachiez que vous êtes sur la même longueur d'onde. Être aussi explicite que possible sur le travail et l'approche à l'avance aidera à rendre l'expérience de jumelage beaucoup plus agréable. Le jumelage implique beaucoup de discussions, car c'est la meilleure façon de garder deux esprits activement impliqués dans le problème en même temps.

Pour cette raison, le couplage est souvent associé à l'écriture d'histoires agile, dans laquelle les exigences pour une fonctionnalité sont définies dans un langage clair et cohérent qui peut être aussi bien compris par les gens du produit et de l'ingénierie avec peu de place pour l'ambiguïté. Souvent, les paires demanderont des histoires à épeler dans Gherkin, qui est un moyen d'utiliser des phrases courantes et non techniques qui sont faciles à traduire en tests automatisés, afin que la paire puisse vérifier et démontrer que chaque fonctionnalité fonctionne comme prévu.

Écrire dans Gherkin signifie prendre une fonctionnalité et la décomposer en un simple récit sur un client qui veut quelque chose que cette fonctionnalité offrira:

As 
I want 
So that 

Ensuite, tous les critères d'acceptation sont écrits dans une syntaxe cohérente, définissant les permutations et les scénarios anticipés associés à cette histoire:

Given 
When 
Then 

Given 
When 
Then 

etc.

Bien sûr, il n'est pas obligatoire d'utiliser cette formulation exacte, mais si les exigences d'une fonctionnalité ne peuvent pas être exprimées de cette manière minimaliste, il est possible que les attentes soient ambiguës. Il s'agit d'un indicateur potentiel qui est plus facile à détecter pour une paire de programmeurs lorsqu'ils commencent à discuter de ce dont ils ont besoin.

Dès qu’une paire accepte une histoire sur laquelle travailler, elle doit être en mesure de définir comment elle saura qu’elle est terminée et comment elle va la prouver. À partir de là, ils peuvent commencer à trouver ensemble la meilleure façon d'aborder le travail.

En fait, la paire travaillant sur une fonctionnalité doit en savoir suffisamment à l'avance pour pouvoir commencer par écrire un test automatisé basé sur le premier critère d'acceptation avant d'écrire un code, en vous assurant que le nouveau test échoue, puis en écrivant juste assez de code pour réussir ce test avant de refactoriser puis de commencer sur le critère d'acceptation suivant. Cette approche est connue sous le nom de développement axé sur le comportement, et bien qu'elle ne fasse pas partie de la définition de la programmation par paires, elle s'harmonise magnifiquement avec le développement piloté par les tests.

Travailler ensemble …

Lorsque deux personnes ou plus essaient de travailler ensemble, la première chose à faire est de convenir d'un horaire de travail. Ce n'est pas vraiment le jumelage si deux développeurs ne travaillent pas ensemble en même temps. Pour cette raison, il est essentiel que les développeurs qui envisagent de travailler ensemble coordonnent leurs plannings et s'assurent qu'ils conviennent tous les deux d'un moment et d'un lieu où ils travailleront.

Une erreur que j'ai vue faire par des paires est d'essayer de maximiser le temps de travail en tant que paire en programmant huit heures ensemble, et parfois en essayant de travailler ensemble au-delà. Le jumelage est un travail intensif qui nécessite un niveau accru de concentration et de participation. Il est très éprouvant d’essayer de s’appairer pendant plus de cinq ou six heures par jour, et même cela pourrait s’étirer même pour les plus résistants d’entre nous. Lors de la configuration d'un programme d'appariement, essayez de vous mettre d'accord sur un temps fixe et limité qui correspondra à une journée de travail typique de huit heures, en laissant du temps pour le déjeuner, le courrier électronique, les tâches personnelles, etc. Ces tâches personnelles sont essentielles à notre journée de travail, mais ce sont aussi des distractions qui ne devraient pas être tentées pendant une session de jumelage.

Il peut également être socialement gênant de rappeler à votre paire lorsque le temps de couplage convenu a pris fin. Pour cette raison, ce peut être une bonne idée de régler une alarme qui va vous annoncer la nouvelle sans mettre le fardeau de l'un ou de l'autre.

Le niveau de compétence est un autre domaine où les paires peuvent avoir des problèmes. Il est juste de supposer que, peu importe sur quoi vous travaillez, la personne avec laquelle vous travaillez a une expérience, une expérience et une aisance différentes avec le sujet. Reconnaître qu'il est important à l'avance, donc aucun de vous ne ressentira le besoin d'essayer de cacher ce fait. L'un des avantages du jumelage est que travailler ensemble fait naturellement naître les compétences de quiconque apprend quelque chose de nouveau, qu'il s'agisse d'un langage de programmation ou d'un style de communication.

Soyez courtois si vous sentez que vous êtes plus habile que votre paire. Traitez-les comme vous voudriez être traités en apprenant quelque chose de nouveau. Et rappelez-vous que le but n'est pas seulement de faire le travail, mais de vous assurer que vous avez tous les deux suffisamment de connaissances et d'appropriation du résultat final.

À cette fin, il est essentiel que chaque programmeur ait la possibilité de s'asseoir au clavier et de conduire pendant que l'autre observe et navigue dans le code. Le concept de la relève à tour de rôle peut être nouveau pour toute personne dont l'expérience exclusive en tant que programmeur a été un travail en solo, il y aura donc une courbe d'apprentissage à mesure que vous vous adapterez à verbaliser vos intentions lors de la navigation ou à réaliser les idées de quelqu'un d'autre au volant.

Un programmeur novice dans le jumelage, mais à l'aise avec la tâche à accomplir, peut facilement adopter un schéma de maintien du rôle de pilote aussi longtemps que possible. De même, si vous ne conduisez pas au clavier et que vous n'êtes pas familier avec le code, il est facile de retrouver votre esprit errant vers votre téléphone, votre e-mail et vos autres tâches. Lorsque cela se produit, vous vous retrouvez avec une personne codant seule et l'autre personne assise dans la même pièce faisant défiler les médias sociaux.

L'un des indices qu'une paire pourrait avoir du mal à alterner est le silence. Le jumelage est un processus bruyant, impliquant beaucoup de questions, de commentaires, de discussions et de collaboration. Lorsqu'une paire se retrouve à partir pendant plus d'une minute ou deux sans dire un mot, il est probable que l'association se soit arrêtée.

Une technique utile qui peut empêcher les paires de tomber dans cet anti-modèle consiste à utiliser une minuterie Pomodoro. Ces minuteries garderont un compte à rebours des secondes pendant que vous travaillez par incréments de 25 minutes, puis vous diront de faire une pause de cinq minutes. En changeant de rôle entre le pilote et le navigateur pendant ces pauses, une paire peut éviter de tomber dans des sessions prolongées avec un seul pilote.

Sur un ordinateur…

Le jumelage ne fonctionne que lorsque deux personnes consacrent toute leur attention à un seul ordinateur. Il est préférable d'éviter la distraction d'avoir deux écrans actifs (ou plus) pendant une session de jumelage. Même si une personne souhaite simplement rechercher des exemples de code pertinents ou vérifier l'état d'un processus d'arrière-plan, il est préférable de le faire sur le même ordinateur partagé. S'il s'agit d'une recherche, les deux développeurs peuvent voir comment la recherche est construite et quels résultats potentiels se présentent. S'il s'agit d'une mise à jour de statut, aucun développeur ne doit être laissé pour compte.

Donc, dans n'importe quelle paire, les deux développeurs doivent pouvoir voir clairement l'écran sur lequel ils travaillent ensemble. L'un des outils essentiels pour l'association est un moniteur suffisamment grand pour que les deux développeurs puissent voir clairement ce qui est écrit. Selon les circonstances, cela peut être accompli avec un ordinateur portable partagé si cela ne vous dérange pas de vous regrouper et que vous utilisez une police suffisamment grande avec un contraste adéquat. Une meilleure solution est un moniteur de bureau ou mural plus grand où le code peut être affiché et visualisé ensemble plus confortablement.

Le pairage à distance est une option très viable de nos jours. Il existe un certain nombre d'excellentes solutions allant des outils Slack ou Zoom aux environnements de développement intégrés et aux processeurs de texte qui prennent en charge le partage d'écran, les conférences téléphoniques, ou les deux, permettant à deux personnes situées sur des côtés opposés du bureau ou des côtés opposés du monde de travailler ensemble. Même si vous êtes à la place suivante dans un bureau ouvert, le partage d'écran peut vous permettre de voir et d'interagir plus facilement avec le code à l'écran plus confortablement. (Je vous encourage simplement à rester concentré et à résister à l'envie de faire apparaître votre e-mail dans une fenêtre séparée pendant que vous vous associez à distance. C'est irrespectueux, cela sera évident pour la personne avec laquelle vous vous associez, et votre distraction vous fera manquer des occasions d'apprendre ensemble et de produire des résultats de qualité.)

Si une paire colocalisée partage une seule machine, elle devra se mettre d'accord sur la configuration de ses ordinateurs, claviers, souris, etc. partagés. Ce clavier ergonomique avec toutes les macros matérielles personnalisées n'est peut-être pas le meilleur choix pour le partage . Mais si cela ne vous dérange pas d'utiliser le même ordinateur portable ou le même clavier et la même souris, l'échange de rôles du navigateur au pilote dans une paire peut être aussi simple que de changer de place.

Une solution populaire et très robuste consiste à utiliser activement un système de contrôle de version comme Git. Enregistrez fréquemment votre code dans un référentiel partagé afin que chaque développeur puisse extraire la dernière version et travailler sur son propre appareil lorsqu'il change de rôle. L'utilisation du contrôle de version pour gérer l'échange par paires présente l'avantage supplémentaire de créer un historique plus détaillé des modifications de code pour la journalisation future et les annulations potentielles. Si les journaux Git deviennent trop encombrés, il est toujours possible de revenir en arrière et de réduire ces commits supplémentaires en un seul et plus significatif avant de faire une demande de tirage.

À un niveau supérieur, une fois que vous aurez commencé à vous associer à un autre développeur, vous remarquerez des différences dans la façon dont vous abordez chacune vos tâches. L'un d'entre vous connaît peut-être des raccourcis clavier fantastiques, possède des alias spéciaux pour les commandes shell courantes, ou préfère utiliser un IDE spécifique en raison de ses fonctionnalités uniques. En termes de code lui-même, vous pouvez également avoir une compréhension implicite différente de la façon dont les variables sont nommées, comment structurer un message de validation, quand utiliser des commentaires, etc.

Le jumelage est l'occasion de rendre visibles ces variations inconscientes de la technique afin que chacun puisse bénéficier de la richesse cachée de l'expérience et des connaissances sur la façon dont nous codons plus efficacement.

Comment démarrer l'appairage

Il y a souvent une période d'adaptation tout en développant la mémoire musculaire et en apprenant à exprimer à haute voix des idées qui n'étaient autrefois que des pensées à l'arrière de votre tête. Il est également nécessaire de mettre en place une logistique viable pour permettre à deux personnes de travailler ensemble, ce qui pourrait nécessiter des ajustements en termes d'horaires, d'emplacements et d'équipements. Et une fois que vous avez réussi, vous pouvez essayer d'étendre le processus à toute l'équipe avec des améliorations telles que la programmation en masse pour les groupes ou le jumelage promiscuous pour donner à tous les membres de l'équipe une chance de se jumeler sur toutes les histoires de l'équipe.

Faire l'effort de passer par les étapes d'apprentissage est généralement payant en améliorations significatives, tant pour la qualité du code que pour le bonheur et la durabilité des personnes qui le créent. Et si toute votre équipe ou organisation adopte le pairage, la courbe d'apprentissage deviendra encore plus facile pour les nouvelles personnes, améliorant le processus d'intégration et aidant chacun à être plus productif.

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *