J'ai toujours senti que l'une des caractéristiques d'un bon responsable est une personne qui fournit la formation supplémentaire nécessaire au cours de chaque cycle de développement. Pour moi, cela signifie que je ne suis pas seulement en train de me coder ou de réviser du code, mais que je suis assis avec des développeurs plus juniors, jumelez la programmation avec eux pour les aider à éviter le genre de mines terrestres sur lesquelles j'ai marché.
Surtout, je ne me fais aucune illusion que notre objectif principal est éducatif - ce n'est pas le cas. Que vous soyez senior, lead ou développeur junior, l'objectif n'est pas votre édification. L'objectif est toujours de fournir un code de qualité au client. De préférence à temps, en respectant le budget, en faisant ce qu'ils veulent. Je reconnais, cependant, qu'il m'est impossible de faire tout le travail moi-même, il m'incombe donc de diriger pour aider tout le monde à aider l'équipe à réussir. Et cela signifie reconnaître les opportunités de formation lorsqu'elles apparaissent dans la nature.
Donc, à votre question de savoir si les demandes de tirage sont l'endroit idéal pour la formation des juniors, je dois dire qu'il n'est pas rare que des moments d'apprentissage se produisent pendant ces moments. Hé, vous allez devoir gérer votre premier conflit de fusion, revoyons cela après la revue. Oh, regardez, vous n'avez inclus aucun test unitaire pour votre DAO, nous reporterons votre examen jusqu'à ce que nous ayons eu la chance de couvrir ces nouvelles méthodes. Pourquoi pensiez-vous qu'il serait préférable d'utiliser des doubles primitives dans ce calcul financier que BigDecimals? Ouais, ce n'est pas vraiment rare.
Donc, même si je dirais que cela peut certainement se produire, mais ce n'est clairement pas l'objectif principal d'une demande de retrait. Je ne pense pas non plus que l'on s'attende à ce que le code d'une demande d'extraction soit prêt pour la production. Ce n'est souvent pas le cas.
Si vous utilisez des branches de fonctionnalités et de versions dans une stratégie de branchement de style gitflow, vos demandes d'extraction deviennent quelque chose de plus comme des versions candidates. Pas prêt pour la production, mais quelque chose de plus approximatif. Vous savez que votre code se compile (à droite) et vous disposez de suffisamment de tests pour faire une déclaration décente selon laquelle il répond aux objectifs de la user story. Et puisque vous avez déjà effectué plusieurs tests d'intégration dans votre environnement de développement, vous avez une grande démo prête à l'emploi si l'on vous demande de démontrer vos modifications, ce que vous ferez, lors de la révision de votre PR.
En fin de compte, je pense que nous devrions fournir une assistance lors des révisions du PR, mais cette assistance ne concerne pas le codage général. Au lieu de cela, il est associé à la préparation du code proposé pour l'inclusion avec une base de travail de code de qualité de production. Le PR est une opportunité pour les développeurs de démontrer qu'ils ont une justification et une solide compréhension de chaque changement qu'ils ont inclus dans le PR. Et même alors - même après les avoir pesés avec des tests unitaires, des démos et des tas de questions - il n'y a toujours pas d'attente que les changements proposés soient prêts pour la production.
Le code est proche après tout ça. Mais ensuite, nous avons laissé QA le torturer.