Comment pousser du code en faisant preuve d’empathie ?

Il est souvent tentant en tant que développeur de mettre en place des process, des outils, des raccourcis et des bonnes pratiques pour se simplifier la vie. Cependant, même avec les meilleures intentions du monde, il arrive que l’on oublie d’en faire autant pour nos pairs. Ci-dessous vous trouverez trois pistes pour faire de vous le prochain « teammate of the month ».

I/ Créditez vos pairs.

À la fin d’un film on peut voir toutes les personnes qui y ont contribué. A la fin d’un concert il est fréquent de remercier les musiciens. Qu’en est-il du pair-programming ?

Il arrive régulièrement de binômer et généralement les commits n’auront pour seul auteur que le propriétaire de la machine d’où ils ont été poussés. Et Git n’a pas la mémoire courte.

Heureusement Git nous permet de créditer la personne qui a contribué à l’écriture du code au travers d’un git-commit-template. Pour cela vous devez éditer votre fichier .config en ajoutant le fichier git-commit-template et dedans vous pouvez ajouter les développeurs de votre équipe comme ci-dessous:

# sauter une ligne pour laisser de la place pour vos futurs messages de commit
#Co-authored-by: Alfredo Doloa <alfredo@oload.fr>
#Co-authored-by: Sarah Lupita <lupita@mail.fr>

Ensuite vous devez indiquer dans votre fichier .git-config, quel template Git doit utiliser lors de vos commits, en ajoutant les lignes ci-dessous:

[commit]
   template = ~/.config/git-commit-template

C’est tout ! Lors de prochain commit tapez git commit et vous devriez voir l’écran ci-dessous. Vous n’avez plus qu’à décommenter la ligne de la personne concernée pour la créditer.

II/ Ménagez vos commits.

Une fois que l’on a ouvert notre pull request, arrive l’étape de la relecture. Cette étape peut être plus ou moins douloureuse pour notre collègue. Un des facteurs aggravants sera la cohérence de nos commits.

Plus simplement est-ce qu’un commit donné est responsable d’une partie définie de notre code ou bien est-ce qu’une partie définie de notre code est disséminée dans plusieurs commits ?

Ou encore, avons-nous un commit qui ne fait pas ce qui est indiqué dans son message ? Pire encore un commit qui supprime un focus !? 🤕

Imaginez-vous inviter un de vos amis dans votre appartement en bazar et en plus lui demander son avis sur votre intérieur ? C’est pareil avec notre branche. Faisons un rapide état des lieux avec le screenshot ci-dessous.

#notinmyname

Au delà des fautes d’orthographe on peut penser que tout aurait pu tenir en 2 commits. Peut-être même un seul si on avait une meilleure idée de ce qu’il y a derrière cet énigmatique « commit les petites avancées ». C’est plus propre et plus agréable pour nous, mais surtout pour nos collègues.

Sur le screenshot on aurait dû garder le premier commit « ajout du model prestation_facturé » et faire un

git commit --amend --not-edit #pousse les changements dans le commit précédent sans se poser de question
git --push --force-with-lease #permet de mettre à jour votre branche avec les derniers changements

pour merge les changements qui suivent (renommage et ajout du test) dans notre premier commit. Et simplement un amend sur notre dernier commit pour rendre le message plus explicite.

Volontairement je ne rentre pas dans les détails des commandes Git, vous avez compris le principe. Si vous souhaitez aller plus loin je vous invite à lire cet article détaillé de Gitlab sur le même sujet.

III/ Bref, j’ai fait une PR.

Dans la même lignée que le point précédent il est important pour le bien être de nos collègues d’éviter autant que possible les PR à rallonge et de limiter un ticket à une responsabilité prédéfinie.

Si je travaille sur l’envoi d’un email lors de l’inscription d’un utilisateur ai-je besoin de ré-organiser le Gemfile dans cette même PR ? Ai-je besoin de corriger une N+1 Query sur l’admin ?

Même si tous ces changements partent d’une bonne intention ils ont deux principaux effets de bord. Le premier, ils peuvent bloquer votre PR même si l’email de l’inscription (la raison d’être du ticket) est parfaitement exécuté. Le second est de générer du bruit inutile dans la relecture de votre PR.

Ask a programmer to review 10 lines of code, he’ll find 10 issues. Ask him to do 500 lines and he’ll say it looks good.

Cette citation explique à elle seule les dangers de réaliser une PR trop grosse, et la démotivation qu’elle peut générer lors de la relecture. Exactement comme une réunion interminable, mal cadrée et sans réel objectif. On commence à penser à autre chose, à décrocher et à vouloir en terminer le plus rapidement possible.

Une PR concise et précise dans son objectif sera plus attentivement relue et plus propice à une discussion productive. D’où également l’intérêt en amont, de découper les tickets en petits pas pour éviter de passer trop vite sur des sujets importants du fait de la complexité et la longueur de certaines pull request.

Si vous souhaitez aller plus loin sur cette différence de traitement selon la taille de vos pull request je ne peux que vous encourager à découvrir (ou redécouvrir) la loi de la futilité de Parkinson et la métaphore du « Bike Shed » popularisée par Poul-Henning Kamp (ancien membre de la core team FreeBSD)

Et voilà !

Si avec ça vous n’arrivez pas à vous faire apprécier par vos collègues développeurs il ne vous reste plus qu’à devenir sympa.

Clément.