Cette boucle de rétroaction très rapide code-construction-test est souvent appelée la boucle interne du développement logiciel. Elle ne nécessite aucune contribution de la part d'autres personnes et la durée d'une boucle complète peut être aussi courte que le temps d'exécution de l'analyse statique, qui peut n'être que de quelques centaines de millisecondes. Les seuls obstacles à la boucle interne sont la vitesse du compilateur ou de l'interprète et la vitesse à laquelle le développeur peut programmer.
La boucle externeen revanche, fait généralement référence au processus de déploiement du code dans un environnement réel et à l'itération basée sur l'intégration avec le système global, les tests d'acceptation, les tests de performance, etc. différentes sources ne sont pas d'accord sur quelles étapes devraient être incluses dans la boucle extérieure). Cette boucle est beaucoup plus complexe et, par conséquent, prend beaucoup plus de temps pour fournir un retour d'information au développeur. Selon la rapidité de votre pipeline CI / CD et selon que vos tests d'assurance qualité sont automatisés ou manuels, cela peut prendre de quelques minutes à quelques jours.
Mais je propose qu'il y ait une boucle intermédiairequi est souvent confondue à tort avec la boucle extérieure : la boucle de revue de code.
La boucle intermédiaire
La boucle de développement intermédiaire consiste à recueillir les commentaires des développeurs et des autres parties prenantes, à ajuster le code en fonction de ces commentaires, puis à demander d'autres commentaires. Elle se distingue de la boucle interne, qui est tracée par un seul développeur dans une seule base de code dans un seul environnement, ainsi que de la boucle externe, qui est tracée par de nombreux développeurs dans de nombreux environnements. La différence essentielle est que c'est la première fois que plusieurs parties prenantes examinent le même nouveau morceau de code.
Cela se produit souvent lors de la revue de code, mais le retour d'information peut prendre de nombreuses formes : programmation en binôme, programmation en équipe, revue de code synchronesynchrone, ainsi que la revue de code asynchrone traditionnelle. Cette dernière est, dans de nombreux lieux de travail, la norme : vous créez un PR, ajoutez quelques réviseurs et partez faire quelque chose d'autre en attendant le retour d'information.
C'est généralement une bonne chose, à condition que vous ayez beaucoup de tâches à accomplir et que vous puissiez passer facilement de l'une à l'autre pendant que vous attendez l'avis des évaluateurs. Bien que ce soit souvent le cas, mon expérience m'a montré que l'inverse se produit tout aussi souvent : vous construisez une fonctionnalité sur plusieurs bases de code, ou en plusieurs étapes, et vous avez besoin de révisions et d'approbations à chaque étape. Dans ce cas, chaque fois qu'une révision est nécessaire, elle devient un obstacle.
Les développeurs peuvent se sentir frustrés d'attendre les révisions et regrouper plusieurs correctifs dans un seul PR afin de réduire le nombre de révisions nécessaires, ou ils peuvent envoyer un message direct à d'autres développeurs pour demander des révisions. Ceux qui sont pingués peuvent être sortis de leur état de fluxou même se sentir harcelées si elles sont contactées à plusieurs reprises.
Pour toutes les parties concernées, il peut s'agir d'une expérience très frustrante.
Si vous avez le pouvoir de le faire dans votre organisation, encouragez les revues de code synchronessynchrones, qui réduisent considérablement la taille de la boucle médiane, ou pour un codagecomme la programmation en binôme ou en équipe, qui élimine complètement la boucle médiane. Pour beaucoup de ceux qui lisent ces lignes, je sais que ce n'est pas une option. Vous avez des revues de code asynchrones et vous êtes coincés avec elles. Dans ce cas, essayons de tirer le meilleur parti d'une situation qui n'est pas idéale : qu'est-ce qui rend la revue de code asynchrone frustrante ?
Le problème de la revue de code asynchrone est qu'elle gonfle souvent inutilement la durée de la boucle centrale.
L'examen du code peut être un travail ingrat. Quand avez-vous entendu pour la dernière fois que quelqu'un avait été promu parce qu'il était l'examinateur le plus minutieux de l'équipe ? De plus, il est facile de se cacher dans la foule, et si 10 développeurs sont ajoutés en tant que réviseurs à un PR qui n'a besoin que de 2 approbations, ils peuvent ignorer la demande, en supposant que leurs coéquipiers prendront le relais. Même lorsqu'un développeur le fait réviser du code, il peut retarder le moment de le faire. Le fait d'attendre d'avoir terminé votre tâche en cours, ou d'avoir déjeuné, ou même d'avoir assisté à votre prochaine réunion, pour réviser un PR peut ne pas vous sembler un délai. En fait, cela peut même sembler rapide. Mais pour le développeur qui attend une révision pour poursuivre son travail, il est bloqué.
La prochaine fois que vous vous mettrez en place un PR, vous également vous aurez également besoin d'évaluations. Et tout comme vos collègues, vous voudrez les obtenir le plus rapidement possible. Rappelez-vous donc que lorsque quelqu'un demande une revue de code, la chose la plus courtoise à faire est de Tout laisser tomber et réviser (DEAR).
Minimisez la boucle médiane
Après avoir géré les incidents de production actifs, la première chose à faire pour un développeur est d'abandonner tout ce qu'il a à faire. // TODO d'un développeur devrait toujours être la révision du code.
Si vous venez de vous asseoir à votre bureau et que vous cherchez quelque chose sur quoi travailler, vérifier les pull requests auxquelles vous avez été assigné devrait devenir un réflexe.
Ne commencez pas cette petite correction de bug, ne lisez pas le prochain article de blog (sauf si c'est celui-ci), ne vérifiez pas votre boîte de réception.
Souvenez-vous DEAR et faites preuve de courtoisie : abandonnez tout et révisez.
