Près d'un an s'est écoulé depuis que j'ai déménagé pour vivre et travailler à Erevan depuis Moscou. Dans cette histoire, je ne vous parlerai pas de ma vie dans cette merveilleuse ville (c'est très cool ici), mais de choses plus banales. À savoir, les pratiques que nous appliquons lors du développement de notre produit chez Vineti.
Si vous êtes toujours intéressé, alors bienvenue au chat.
Chez Vineti, nous utilisons
une méthodologie de
programmation extrême et utilisons activement la programmation par paires. Quand je suis arrivé chez Vineti, la programmation extrême était quelque chose de nouveau et d'inconnu pour moi, mais après une année de développement dans ce style, je peux dire que maintenant écrire du code pour moi est devenu quelque chose de pas trop pratique et productif.
Lorsqu'une personne à côté de vous regarde attentivement ce que vous écrivez, le code est extrêmement lisible. En outre, lors de la rédaction du code, une formation et un transfert de connaissances entre les participants ont lieu, et cela, de mon point de vue, se déroule sous la forme la plus efficace.
Il arrive que ceux qui n'ont jamais utilisé cette approche dans la pratique éprouvent de l'embarras et de l'inconfort, car vous devez constamment communiquer avec votre partenaire et écrire du code sous étroite surveillance, mais au fil du temps, cela passe et vous comprenez que le partenaire est ici, pour vous aider, pas vous blesser.
Avantages de l'approche
Les avantages de la programmation par paires par rapport à l'approche standard sont multiples, mais, de mon point de vue, le plus important est le transfert constant de connaissances sur le code d'application entre les participants au processus. Vous pouvez créer des paires et des rotations (changement d'ingénieurs participants) afin que chaque ingénieur ait une connaissance complète de toutes les parties de l'application. Ceci est particulièrement important si vous avez besoin de maintenir une grande base de code.
Le prochain avantage est un processus d'apprentissage assez efficace. Vous pouvez vous associer afin que les plus expérimentés soient toujours associés aux ingénieurs les moins expérimentés. Pour le développeur senior, la règle est «si vous voulez bien connaître quelque chose, essayez d'en enseigner un autre». Il y a aussi la possibilité de resserrer vos compétences en communication, comme vous devrez l'expliquer beaucoup et souvent.
Chez Vineti, nous utilisons
TDD dans le processus de programmation par paires, ce qui nous permet de diviser initialement une tâche grande et complexe en petites parties et de réfléchir à l'architecture de la solution avant d'écrire le code. De plus, la présence d'un partenaire avec lequel vous pouvez discuter de l'approche choisie pour résoudre le problème et analyser son optimalité en cours de travail sans avoir besoin de planifier des réunions supplémentaires au sein de l'équipe aide beaucoup à résoudre des problèmes complexes.
Et enfin, la programmation par paires est bien combinée avec la méthodologie
TDD . Dans Vineti, généralement un ingénieur écrit des tests et essaie de décrire autant de situations que possible. Le deuxième ingénieur écrit le code de fonctionnalité, lorsque le premier ingénieur vous explique comment simplifier le code, mettant ainsi en œuvre un cercle de refactorisation rouge-vert.
Inconvénients
Les inconvénients de cette approche, j'attribuerais probablement la complexité de la mise en place du processus lui-même et la nécessité d'une sélection appropriée des participants par paires, ce qui nécessite des efforts supplémentaires de la part du chef d'équipe et une compréhension approfondie des compétences et des habitudes de tous les membres de son équipe.
Si nous parlons du facteur humain, il est important que les ingénieurs qui sont actuellement jumelés pour la période de travail en commun aient un mode commun de venir au bureau, déjeuner, etc. Ce n'est pas toujours facile à faire et il faut former des paires en tenant compte de cette caractéristique.
Maintenir une norme commune
L'une des conditions pour une programmation efficace des paires est la présence d'une approche strictement et la plus standardisée pour écrire du code dans les commandes. Par exemple, nous utilisons eslint, prettier, rubocop pour que le code soit du même style en cours d'écriture. En tant qu'environnement de développement, nous utilisons VS Code et le terminal iTerm c zsh. Cette standardisation vous permet de faire tourner rapidement les ingénieurs par paires tout en minimisant la période d'adaptation.
À mon avis, les couples doivent être alternés après avoir terminé une tâche. Ceci fournit la rotation efficace la plus faible possible. Le changement de rôle peut se produire en une journée, mais cela reste à la discrétion d'un ingénieur plus expérimenté dans une paire. Il est important de ne pas se laisser emporter, de ne pas essayer de résoudre tous les problèmes soi-même, car l'absence de changement de rôle peut affecter négativement l'efficacité du couple dans son ensemble.
Jumeler la programmation avec San Francisco
Personnellement, j'ai eu l'expérience de la programmation de paires à distance avec un collègue du bureau américain de Vineti, pour cela nous avons utilisé le plugin Live Share pour VS Code. L'expérience est intéressante, mais cette situation présente plusieurs inconvénients par rapport à la programmation par paire standard. Le premier est le manque de communication personnelle directe. Dans mon cas, c'est aussi une grande différence de fuseaux horaires. J'ai dû écrire du code après presque une journée complète, ce qui, pour moi personnellement, était très fatigant.
Comment s'adapter à la programmation par paires
Essayez d'utiliser l'expérience d'autres entreprises et éventuellement développer votre approche au sein de l'entreprise. L'option idéale pratique et fonctionnant pour tous, malheureusement, n'existe pas.
Je ne suis pas sûr non plus que cette méthodologie soit adaptée à toutes les entreprises. Par exemple, si vous n'avez que 3 développeurs dans une équipe, vous ne pourrez évidemment pas tirer grand profit de l'implémentation de la programmation par paires. Ou, si vous avez trop d'avantages pour les jones de l'équipe, il vous sera très difficile de construire de bonnes paires.