Les pull pulls sont-ils le lieu idéal pour l'entraînement des juniors


11

Nous avons un concept selon lequel tout le code d'une demande Pull dans le maître doit être prêt pour la production. Cela a du sens et est une déclaration juste à mon avis.

L'idée ici est qu'une fois que vous avez créé le PR, vous déclarez que vous auriez mis cela dans le maître, mais que certains examinateurs `` approuvent '' simplement et repèrent tout ce que vous manquez.

Comme nous ne sommes qu'humains, nous commettons des erreurs et espérons que d'autres examinateurs pourraient trouver des éléments que les tests unitaires n'ont pas pu trouver - fautes d'orthographe, javadocs incorrects, etc.

MAIS, est une demande Pull l'endroit où nous devrions fournir un certain niveau d'assistance / formation aux développeurs et si oui, à quel niveau?

Chaque fois que vous introduisez de nouvelles modifications, les réviseurs doivent réexaminer vos modifications, ce qui prend de leur temps de développement et entraîne une nouvelle révision des modifications.

Alors, combien de formation est attendue, devrait être autorisée, dans les demandes de tirage? Une partie de moi pense que cela varie des juniors aux seniors. Cependant, je pense également que cela ne devrait pas être le lieu de trouver de grandes quantités de problèmes - même pour les juniors.

Quelqu'un d'autre a-t-il du mal à essayer de faire en sorte que les développeurs atteignent l'objectif de "Ma demande de tirage doit être prête pour la production"?

Réponses:


13

Non. Les requêtes Pull ne sont pas le lieu de formation. Votre équipe a la bonne idée. Un PR signifie "Je pense que c'est bon d'y aller. Puis-je avoir un deuxième coup d'œil sur cela au cas où j'aurais raté quelque chose. Je suis humain après tout." Et je suppose que c'est exactement ce que fait votre apprenti. Ils pensent honnêtement que c'est bon d'y aller.

Voici une idée extrême (jeu de mots voulu). Programme de jumelage avec l'apprenti qui vous donne les brûlures d'estomac. En tant que membre de l'équipe plus senior, c'est votre travail de les soulever et de les rendre productifs.


Merci @RubberDuck. Le programme de paires est une excellente idée et nous le faisons - sorta. Je soupçonne que nous devrions faire plus. Cependant, certaines mesures ou outils appropriés pour mesurer si l'une de vos «gouttes» dans l'océan fait à plusieurs reprises les mêmes erreurs aideraient à savoir qui a également besoin de cette programmation de paire. Je suis certain que ce problème s'aggrave avec de plus grandes équipes!?
Riaan Schutte

2
Eh bien, je dirais que nous devons tous nous associer la plupart du temps. Un de nos apprentis a détecté plusieurs de mes erreurs et je suis l'un des plus expérimentés de l'équipe. Vous pourriez probablement demander le nombre de commentaires sur les demandes de tirage, mais je ne le recommanderais pas. Quelque chose au sujet des individus et des interactions ... Sérieusement cependant. C'est votre travail de lever ce développeur. Obtenez-leur une copie de Clean Code ou quelque chose.
RubberDuck

1
Dans un lieu de travail où chaque développeur travaille sur un travail cité pour un client (pas de projets internes qui se financent), la programmation en binôme n'est pas si simple, mais reste importante! Il semble que la société doive simplement débourser et investir si nous voulons des développeurs plus productifs sur le travail cité.
Riaan Schutte

1
Hmm ... pourquoi n'est-ce pas si facile? Le client n'obtient-il pas autant d'heures de travail et, plus important encore, une meilleure valeur pour son dollar? Bonne chance mec. Calmez-vous avec l'enfant.
RubberDuck

3
C'est une idée fausse courante @Andy. Ce n'est tout simplement pas vrai cependant. Oui, c'est contre-intuitif, je sais.
RubberDuck

9

Si du code qui enfreint les principes de conception ou les normes de base de l'équipe parvient à l'étape de la demande d'extraction, il doit certainement y être adressé. Et les revues de code peuvent être un bon moyen de communiquer les normes et les pratiques de conception de l'équipe.

Mais est-ce le meilleur endroit? Voici quelques raisons pour lesquelles je dirais que non:

  1. S'il faut plusieurs itérations de révision de code pour résoudre un défaut de conception fondamental ou un problème à grande échelle, il y aura une forte tentation d'ignorer les problèmes plus mineurs mentionnés ci-dessus, en raison des délais ou de l'épuisement général de la révision. Idéalement, l'équipe serait suffisamment résiliente pour résister à cette tentation, mais il est probablement préférable de ne pas créer une situation qui y conduirait.
  2. Recevoir une revue de code avec un grand nombre de commentaires n'est pas une grande expérience pour un développeur débutant / débutant. Oui, répondre aux commentaires est une compétence qu'ils devront développer, mais il est également vrai que les développeurs ne sont pas toujours compétents pour répondre avec tact au code qu'ils n'aiment pas.

Les revues de programmation et de conception de paires sont des lieux privilégiés pour une rétroaction à plus grande échelle.

Cela dit, il serait encore pire de laisser passer le code par crainte que son traitement lors des révisions de code ne soit «incorrect», et il peut y avoir des circonstances (par exemple des équipes distantes) où c'est le mieux que vous puissiez faire. Dans ce cas, résolvez les problèmes dans la révision du code, et résolvez également les problèmes dans votre processus de développement qui sont arrivés jusqu'ici.

Bien que la recherche du problème lors d'une demande d'extraction ne soit pas idéale, elle est certainement meilleure que lors d'un test ou d'un problème de production.


5

Je le dirais plus car les demandes de tirage ne devraient pas être le seul endroit où vous formez des gens. De plus, les développeurs juniors ne sont pas les seuls à avoir besoin d'une formation dans une demande de tirage. Les entrepreneurs, les contributeurs open source, les développeurs d'autres départements qui ne connaissent pas le code ou les normes locales, et même les programmeurs chevronnés ont besoin de rappels occasionnels lorsqu'ils deviennent complaisants.

Il y a très peu de frais pour maintenir une demande de pull ouverte pendant un certain temps. Donnez-lui autant ou aussi peu de commentaires que vous le souhaitez, par autant de personnes que vous le souhaitez, puis laissez-le tranquille jusqu'à ce que les auteurs vous informent à nouveau qu'ils pensent qu'il est prêt pour la fusion. Une demande d'extraction est un excellent outil central pour communiquer sur les modifications de code proposées, qu'elles soient entièrement prêtes ou nécessitent beaucoup de travail.

Certains examens des demandes de tirage s'avèrent un peu plus qu'un tampon en caoutchouc, et certains qui sont des soumissions externes à une équipe peuvent prendre un mois d'avant en arrière. Le premier type est agréable quand vous pouvez l'obtenir, mais cela ne signifie pas que le second type n'a pas de valeur. Essayer de faire en sorte que les gens soumettent des demandes de tirage parfaites tout le temps va être frustrant pour tout le monde.


Merci pour votre réponse @ Karl-Bielefeldt. Convenu qu'une certaine formation peut être attendue mais la question est de savoir combien est approprié, à quel niveau. Votre déclaration "... qu'ils soient entièrement prêts ou nécessitent beaucoup de travail." Je dirais qu'un PR à maîtriser ne devrait jamais avoir besoin de beaucoup de travail. Beaucoup de travail implique des défauts de conception, des défauts d'implémentation plutôt que de m'aider à repérer ce que j'ai manqué. Cependant, je suis d'accord et j'ai expérimenté "Essayer de faire en sorte que les gens soumettent des demandes de tirage parfaites tout le temps va être frustrant pour tout le monde."
Riaan Schutte

2

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.


Merci pour votre réponse @ Michael-Peacock. Ce que vous dites sonne vrai pour les entreprises qui ont un service AQ distinct ou des testeurs qui passent par sa prochaine phase. Mais lorsque les développeurs sont également les testeurs, le PR accompagne tout, du développement aux tests, en passant par la fusion en master. Dans ce workflow, le code doit être prêt pour la production une fois le PR approuvé. Je suppose que la question est également chargée d'une hypothèse sur le flux de travail que vous utilisez.
Riaan Schutte

Je dirais que même si vous ne disposez pas d'une équipe QA dédiée, il est encore plus important de vous assurer d'ajouter des tests d'intégration et / ou d'acceptation à votre flux de travail, et de laisser du temps pour une reprise éventuelle si le code fusionné échoue à vos tests. Vous pouvez automatiser certains des tests d'acceptation en utilisant Selenium et Cucumber pour alléger la charge des développeurs, mais je pense qu'il est important de ne pas supposer que le code est prêt pour la production tant que vous ne l'avez pas démontré par le biais de tests.
Michael Peacock

Je suis entièrement d'accord, d'où la raison pour laquelle nous avons tous besoin du code associé aux tests. Si vous rebasiez ensuite master avant de fusionner, vous pouvez être certain que les tests réussissent et que le code doit fonctionner comme prévu.
Riaan Schutte

2

Je tiens à remercier tout le monde pour leur contribution et à m'aider à comprendre ce que les gens ont à dire sur ce sujet.

C'est ma réponse après les commentaires donnés et ma compréhension maintenant basée sur les réponses et commentaires reçus. Merci tout le monde.

Sommaire

  • Ne pas attendre ou appliquer des demandes de tirage parfaites de la batte, car cela ne deviendra frustrant que pour toutes les personnes impliquées.
  • Mais continuez à en faire notre objectif pour des demandes de tirage parfaites.
  • Attendez-vous à une certaine collaboration / assistance dans les demandes de tirage. Après tout, c'est ce que vous demandez essentiellement en créant une demande d'extraction.
  • Si cela devient un peu dû à des défauts de conception ou d'implémentation, passez du temps avec ce développeur et faites de la programmation par paires pour les construire et rapprocher leur code de l' objectif . C'est le rôle de tous les développeurs seniors.
  • Les juniors auront besoin de plus de sessions de programmation par paires que les développeurs intermédiaires. Attendez-vous donc à ce que les demandes de tirage reflètent cette exigence.
  • Encouragez les développeurs à organiser des réunions de conception / mise en œuvre avant de toucher au code afin de réduire les retouches identifiées dans les demandes d'extraction.

1
Magnifique résumé et réponse. Je ne serais pas du tout offensé si vous vous donniez la coche.
RubberDuck

Merci @RubberDuck, mais mon résumé ne pourrait exister sans les réponses et les commentaires de tout le monde à ma question. À votre santé.
Riaan Schutte

0

Pouvez-vous nous en dire plus sur votre culture d'entreprise en termes d'équipes techniques? Si vous avez du mal à l'idée que le code soit prêt pour la production lorsqu'un développeur souhaite fusionner avec la ligne principale, que dites-vous vraiment à vos développeurs? Vous leur dites que lorsque leur travail est "terminé", ça va si ça ne marche pas? Ça va si ça casse le système? S'ils ajoutent de la dette technique, c'est peut-être bien s'ils peuvent le justifier et sont conscients de ce qu'ils font, et montrer qu'ils peuvent revenir et refaire le refactoring plus tard. Mais s'ils ignorent pourquoi ils font quelque chose de dangereux, combien de fois allez-vous le laisser passer?

Si vous avez un développeur junior, leurs premières demandes d'extraction auront évidemment des problèmes. Finalement, ils devraient comprendre. Si vous constatez qu'ils continuent d'avoir des problèmes, vous leur attribuez peut-être un travail pour lequel ils ne sont pas encore prêts?

Ou peut-être devez-vous engager un remplaçant junior et licencier celui qui n'a pas pu le comprendre?

Tu sais ce que j'ai vu? Les gens qui ne sont pas des développeurs compétents continuent de travailler dans une entreprise pendant des années simplement à cause du népotisme. Donc, bien sûr, leurs demandes d'extraction nécessitent plusieurs examens. Dans le langage Lean, ce sont des «déchets» - un frein à l'équipe et un frein à la ligne du bas.

Vous devez donc décider par vous-même: combien de demandes de tirage faudra-t-il pour que vos juniors montrent leur compétence, et avez-vous le courage de laisser aller ceux qui ne le font pas?


Merci pour votre réponse @RibaldEddie, nous nous attendons à ce que les développeurs aient écrit des tests unitaires, testé et revu manuellement leur propre travail au point où ils affirmeraient que ce code est génial et s'il leur était laissé, ils le fusionneraient en maître, mais obtiendra 2 examinateurs pour l'examiner et, espérons-le, confirmer cette déclaration. Nous n'acceptons aucune dette technique et nous nous éloignons totalement des solutions en faveur de solutions. On s'attend donc à ce que le code réponde à ces exigences.
Riaan Schutte

@Riaan qui sont les critiques?
RibaldEddie

N'importe qui, des techniques mène aux juniors. Normalement, il s'agit d'un examinateur principal / intermédiaire et d'un examinateur junior / intermédiaire. (2 critiques)
Riaan Schutte

@Riaan puis avec le temps, je m'attendrais à ce que les membres juniors de l'équipe se différencient. Vous serez en mesure de dire qui est consciencieux et qui est insouciant. Je trouve que le développement de logiciels bien fait est une activité bien adaptée à une mentalité de détail. Certaines personnes ne seront peut-être pas en mesure de réussir cela. Vous devrez décider quoi faire avec eux. Mais fondamentalement, vous devez vous attendre à ce que les développeurs qui soumettent du code à fusionner soient convaincus qu'il fonctionne comme prévu et qu'il est prêt pour la production. Même si vous avez une grande équipe d'AQ sophistiquée, vos développeurs devraient toujours utiliser du code prêt pour la production.
RibaldEddie
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.