TL; DR : Je ne pense pas que la programmation par paires fonctionnerait pour vous. Au lieu de cela, vous devriez essayer de sensibiliser les gens à la qualité à long terme de leur code et de leur donner envie de trouver des réponses. Cela doit être fait de manière informelle.
Sur la culture et la qualité
Je pense que ce problème ne concerne pas la méthodologie de programmation mais plutôt la culture . D'après mon expérience, la culture est possible de diriger, mais rarement en en parlant aux gens. C'est-à-dire qu'essayer de forcer un certain flux de travail sur des personnes qui n'ont pas évolué naturellement ou qui sont trop éloignées de la pratique existante est susceptible d'avoir des conséquences négatives.
En d'autres termes, vous ne voulez pas ressembler au costume qui résonne avec les derniers mots à la mode, même quand vous l'êtes finalement. La plupart des programmeurs que je connais vous identifieraient mentalement comme du bruit de fond. Ne soyez pas une abeille d'entreprise.
À mon avis, la principale question que vous devriez vous poser est: "suis-je satisfait de la qualité et de la valeur commerciale du code que mon organisation publie?" et si la réponse à cette question est négative, vous devriez vous demander "comment puis-je changer cela?".
En fin de compte, la qualité et la valeur sont des définitions humaines auxquelles seuls vous ou quelqu'un d'autre dans votre organisation pouvez (et devriez) penser.
Programmation en binôme et microgestion
Donc, au risque de paraître un peu avancé et sévère, il me semble que la lecture de la programmation par paires vous a fait penser à une forme de microgestion , ou l'inverse. MM est une recette infaillible pour aliéner la plupart des gens.
Pour la défense de la programmation par paires: la programmation par paires ne concerne pas un gars qui regarde par-dessus l'épaule d'un autre gars. C'est aussi micro que la direction. PP est sur l' utilisation de deux esprits penser à deux niveaux en même temps - une personne traite de haut niveau , vue d'ensemble des problèmes tandis que l'autre prend soin des écrous et des boulons nécessaires pour produire le code de travail. Et à mon humble avis, cela fonctionne rarement bien si les deux participants ne sont pas en mesure de changer de place. Ils devraient avoir une expérience similaire pour avoir un arsenal professionnel similaire de concepts et un vocabulaire professionnel partagé (nous ne sommes pas liés à l'esprit - pour l' instant , muhahaha).
Pour votre situation, je dirais que puisque vous êtes une petite équipe et que vous êtes la seule à avoir une expérience réelle (c'est à quoi ressemble votre message pour moi), la programmation par paires ou la révision de la plupart du code la plupart du temps ne le ferait pas ça marche pas. Vous n'avez que 24 heures par jour. Au lieu de cela, certaines solutions que vous pourriez envisager:
Encouragez-les à participer à SO sous la balise de langue appropriée, ou à publier des extraits de code pour révision sur Code Review SE. Lancez un petit concours informel pour savoir qui peut gagner le plus de points de répétition SO par semaine.
SO peut faire des merveilles pour les développeurs débutants car il fournit une rétroaction constante et suit le rythme cardiaque de la communauté.
Jetez un œil à certains des codes qu'ils archivent et mettez-les au défi de manière informelle avec des questions concernant son évolution à long terme. La plupart des programmeurs débutants ne sont tout simplement pas habitués à penser à rendre leur code lisible et maintenable. Une fois que vous aurez saisi ces problèmes, ils rechercheront eux-mêmes plus d'informations auprès de vous ou d'autres sources.