Avantages, astuces et conseils pour le faire fonctionner –

Programmation par paire – une paire supérieure à la somme de ses parties. Vous avez peut-être entendu parler de la programmation en binôme 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.

Des 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'appariement. Mais les avantages potentiels peuvent rendre la peine de reconnaître et de surmonter ces défis.

Pourquoi associer?

Comment pourrait-il être plus productif de prendre deux programmeurs qui travaillaient auparavant sur des projets séparés et de les faire travailler ensemble sur un projet unique? 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, ou même de 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 longue à effectuer lorsque l'un de ces

Vous avez besoin que votre code soit significatif et bien écrit pour qu'il fonctionne de manière transparente et puisse être modifié facilement. Vous en avez besoin pour encapsuler la fonctionnalité souhaitée afin que votre produit final se comporte correctement et fonctionne comme prévu. Vous avez besoin qu'il soit résilient pour 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 beaucoup d'avertissement.

Afin de rendre cela 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 présenté au 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 une partie du code fonctionne puisse gagner à la loterie et quitter l'équipe.

Le coût en temps des heures de travail mythiques est loin des 50% qui peuvent sembler intuitifs 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 paire 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 beaucoup plus élevé. qualité, avec environ 15% de défauts observables en moins à corriger. Combinez cela avec la propriété partagée, un engagement plus profond et une résolution plus rapide des problèmes qui découlent 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 pairage 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 par paires ne démarre pas tant que deux personnes ne travaillent pas 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 jumelage est souvent associé à l'écriture d'une histoire 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 demandent que des histoires soient énoncées dans Gherkin qui est un moyen d'utiliser des expressions 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 une simple histoire au sujet d'un client qui veut quelque chose que cette fonctionnalité offrira:

 
Je veux 
Pour que 

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

 Étant donné 
Quand 
Puis 

Compte tenu 
Quand 
Puis 

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. C'est un drapeau rouge potentiel qui est plus facile à repérer pour une paire de programmeurs lorsqu'ils commencent à discuter de ce qui est nécessaire.

Dès qu'une paire accepte une histoire sur laquelle travailler, elle devrait être en mesure de définir comment elle saura que c'est fait. et comment ils vont le 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é devrait 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 s'assurant que le nouveau test échoue, puis en écrivant juste assez de code pour que ce test réussisse 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 horaires et s'assurent qu'ils conviennent tous les deux à une heure et à un lieu où ils travailleront.

Une erreur que j'ai vue faire par des paires est d'essayer de maximiser le temps ils travaillent ensemble comme une paire en programmant huit heures complètes ensemble, et en essayant parfois 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 de jumelage, 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 difficile de rappeler à votre paire lorsque le temps de jumelage 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 sur l'un ou 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 ce sur quoi vous travaillez, la personne avec laquelle vous travaillez a une expérience, une expérience et un confort différents 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 qualifié 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 à le clavier et le lecteur tandis que l'autre observe et navigue dans le code. Le concept de la transmission à tour de rôle peut être nouveau pour quiconque dont l'expérience exclusive en tant que programmeur a été un travail en solo, il y aura donc une courbe d'apprentissage au fur et à mesure que vous vous adapterez à la verbalisation de vos intentions lors de la navigation ou à la réalisation des 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 conducteur 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 à se relayer est le silence. Le jumelage est un processus bruyant, impliquant beaucoup de questions, de commentaires, de discussions et de collaboration. Quand une paire se retrouve à marcher pendant plus d'une minute ou deux sans dire un mot, il est probable que l'appariement s'est arrêté.

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 basculer dans des sessions étendues avec un seul pilote.

Sur un ordinateur…

L'appairage 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 couplage. 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 être en mesure de 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.

L'appairage à 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 intégrés qui prennent en charge le partage d'écran, les conférences téléphoniques ou les deux, permettant à deux personnes 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 au siège suivant 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 partagés, claviers, souris, etc. un 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 une version système de contrôle 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 sont 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 commencez à vous associer à un autre développeur, vous ' va remarquer quelques différences dans la façon dont chacun aborde ses 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 ce qui concerne le code lui-même, vous pouvez également avoir chacun 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.

L'appariement est l'occasion de faire ces variations inconscientes de la technique visible pour que tout le monde 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 commencer le couplage

Il y a souvent une période d'adaptation pendant la construction de la mémoire musculaire et l'apprentissage de l'expression à haute voix d'idées qui étaient une fois juste des pensées à l'arrière de la 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 cela fonctionne, vous pouvez essayer d'étendre le processus à l'ensemble de l'équipe avec des améliorations telles que la programmation de mob pour les groupes, ou l'appariement promiscuité pour donner à tous les membres de l'équipe un

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 tout le monde à être plus productif.

J'ai travaillé en tant qu'ingénieur Web, rédacteur, responsable des communications et Directeur marketing dans des sociétés comme Apple, Salon.com, StumbleUpon et Moovweb. Mes recherches sur les sciences sociales des télécommunications à UC Berkeley, et tout en obtenant un MBA en comportement organisationnel, m'ont montré que l'instinct humain de réseauter est suffisamment vital pour prospérer sur tout support permettant à une personne de se connecter à une autre.