Les dérives du Pull Request
Le Pull Request est un concept provenant de GITHUB permettant de réguler dans un projet donné les contributions de codes provenant de plusieurs développeurs.
Après avoir travaillé sur son code le développeur demande l’autorisation de l’intégrer dans le projet. Un certain nombre de personnes sont habilités à valider le code pour l’intégration, cependant, avant de valider ils peuvent demander des éclaircissements aux développeur et lui demander de modifier certains points de son développement. Cette opération se fait dans un forum public visible de tous.
Vu comme ça la méthode est très intéressante dans le cadre de projets open source sur le web. Mais ça commence à se compliquer lorsqu’elle est utilisée en entreprise ! J’ai recueilli plusieurs témoignages qui montrent les dérives de cette méthode dans de grandes ou petites sociétés.
Tout d’abord, qui valide le Pull Request dans une équipe ? Il y a une notion de responsabilité, par conséquent ce sont les leaders techniques ou leader de développement qui valident réellement le code (même si l’on fait croire que n’importe quel développeur peut valider). Et là on entre dans la problématique des relations humaines dans un forum public. Ça peut vite dégénérer ! Certains lead dev ou développeurs ont tendance à vouloir s’affirmer dans l’équipe en imposant leur autorité ou leur supériorité technique et méthodologique. Ça donne sur le forum du Pull Request des phrases comme « Enlève-moi ça ! ». Certains abusent de leur autorité pour ordonner au développeur de modifier son code simplement parce que cette façon de faire ne lui plait pas, alors que le code ne présente aucun point de contention et fonctionne très bien. Cette façon de faire engendre un sentiment d’anxiété, de colère et de découragement chez le développeur qui à besoin d’un minimum d’autonomie et de reconnaissance pour rester motivé.
Pour moi le Pull Request doit rester une revue de code rapide dont l’objectif est de vérifier le respect des nomenclatures et la présence ou non de points de contentions. La validation ne devrait pas prendre plus d’une journée à moins de soulever un problème de conception majeur. En outre il est très important de respecter le travail du développeur qui apporte son savoir-faire ; Il a besoin de sens et d’autonomie pour rester motivé. Le leader technique doit motiver et protéger son équipe afin d’obtenir de ses développeurs leur confiance et leur soutien.