Vos meilleurs programmeurs devraient-ils vérifier le code de tout le monde dans le contrôle de code source?

L'une des différences entre svn et git est la possibilité de contrôler l'accès au référentiel. Il est difficile de comparer les deux car il y a une différence de point de vue sur qui devrait être autorisé à commettre des changements!

Cette question concerne l'utilisation de git comme référentiel centralisé pour une équipe d'une entreprise quelque part. Supposons que les membres de l'équipe ont des niveaux de compétences différents, comme ils le sont dans la plupart des entreprises.

Git semble supposer que seuls vos meilleurs programmeurs (les plus productifs et les plus expérimentés) sont autorisés à archiver le code. Si tel est le cas, vous prenez le temps d'écrire du code pour réviser le code des autres afin de l'archiver. Cela est-il payant? Je veux vraiment concentrer cette question sur la meilleure utilisation du temps de votre meilleur programmeur, et non sur les meilleures pratiques de contrôle de version en général . Un corollaire pourrait être: les bons programmeurs quittent-ils si une partie importante de leur travail consiste à revoir le code des autres? Je pense que les deux questions se résument à: l'examen vaut-il le coup sur la productivité?

Comme cela ne ressort pas clairement de votre question, je tiens simplement à souligner qu'un workflow de contrôleur d'accès n'est en aucun cas requis avec git. Il est populaire auprès des projets open source en raison du grand nombre de contributeurs non fiables, mais n'a pas autant de sens au sein d'une organisation. Vous avez la possibilité de donner à tout le monde un accès push si vous le souhaitez.

Ce que les gens négligent dans cette analyse, c'est que les bons programmeurs passent beaucoup de temps à traiter le code cassé des autres programmeurs de toute façon. Si tout le monde a un accès push, alors la construction sera cassée, et les meilleurs programmeurs ont tendance à être ceux qui intègrent et traquent fréquemment les coupables lorsque les choses se cassent.

La chose à propos de tout le monde ayant un accès push est que lorsque quelque chose se casse, tout le monde qui tire obtient une construction cassée jusqu'à ce que le commit incriminé soit annulé ou corrigé. Avec un workflow de contrôleur d'accès, seul le contrôleur d'accès est affecté. En d'autres termes, vous n'affectez qu'un seul de vos meilleurs programmeurs au lieu de tous.

Il peut s'avérer que la qualité de votre code est assez élevée et que le rapport coût-bénéfice d'un contrôleur d'accès n'en vaut toujours pas la peine, mais ne négligez pas les coûts habituels. Ce n'est pas parce que vous êtes habitué à cette perte de productivité qu'elle ne se produit pas.

N'oubliez pas non plus d'explorer les options hybrides. Il est très facile avec git de mettre en place un référentiel vers lequel n'importe qui peut pousser, puis de laisser un contrôleur d'accès comme un développeur senior, un testeur ou même un serveur d'intégration continue automatisé décider si et quand un changement en fait un deuxième référentiel plus stable. De cette façon, vous pouvez tirer le meilleur parti des deux mondes.

J'ai travaillé dans un emploi où les enregistrements étaient limités aux chefs d'équipe uniquement (et les chefs d'équipe ne pouvaient pas vérifier leur propre code). Cela nous a servi de mécanisme pour appliquer les révisions de code, en grande partie à cause d'un certain nombre d'incidents où de mauvais commits sont entrés dans la base de code, même autour des enregistrements bloqués et de l'analyse statique.

D'une part, il a fait son travail. Un certain nombre de mauvais commits ont été trouvés avant qu'ils n'entrent dans la base de code (et rapidement oubliés pendant une semaine environ jusqu'à ce que quelqu'un tombe sur eux). Cela a provoqué moins de perturbations dans la base de code. De plus, je pouvais repousser certaines choses de formatage / structure avant qu'elles ne deviennent une dette technologique; attraper quelques bugs avant qu'ils ne deviennent des bugs. Et cela m'a donné une excellente idée de ce que mon équipe faisait.

D'un autre côté, cela m'a fait entrer spontanément dans des rages meurtriers lorsque mon changement de 3 lignes a pris 4 heures à s'engager parce que je devais retrouver une autre piste et les amener à faire le commit. Cela m'a poussé à faire des commits beaucoup moins fréquents que les meilleures pratiques et a parfois conduit à des problèmes pour essayer de suivre les modifications apportées au développeur qui les avait effectuées.

Je ne le recommanderais généralement pas, sauf dans les environnements les plus nécessiteux. Faire les critiques et les commits n'était pas trop mal en fait. Cependant, avoir mon propre processus dépendant des caprices des autres était exaspérant. Si vous ne pouvez pas faire confiance à vos développeurs pour archiver le code, obtenez de meilleurs développeurs.

Non. N'importe qui devrait pouvoir s'engager.

Si vous rencontrez des problèmes lors de la validation de bogues, ce n'est pas la politique de contrôle des sources qui est incorrecte. Ce sont les développeurs qui ne s'assurent pas que ce qu'ils commettent fonctionne. Donc, ce que vous avez à faire est de définir des directives claires sur ce qu'il faut engager et quand.

Une autre grande chose s'appelle les tests unitaires;)

Il existe cependant une alternative.

a) Si vous utilisez le contrôle de version distribué, vous pouvez créer un référentiel principal vers lequel seules les demandes d'extraction peuvent être effectuées. De cette façon, tous les développeurs peuvent obtenir le versioning de leur propre code pendant que vous contrôlez la branche principale.

b) En subversion et similaire, vous pouvez utiliser des branches où chaque développeur doit créer des correctifs pour le placer dans la branche principale.

Vous devriez jeter un coup d'œil à des projets tels que Gerrit qui permet à tous les développeurs de pousser leur code dans la branche `` revue '' et une fois que vos développeurs seniors / principaux sont satisfaits de ces changements, ils peuvent les pousser en master / release.

S'ils ne sont pas satisfaits, ils peuvent laisser des commentaires à côté d'une ligne de code, demander un correctif mis à jour, etc.

De cette façon, toute personne avec un changement en attente peut le sortir dès qu'il est prêt et seules les personnes qualifiées (avec les bons privilèges +2 dans Gerrit) pourront pousser ce code à tester et plus tard à la production.

Non, c'est une mauvaise utilisation de vos meilleurs talents. Imaginez une maison d'édition prenant ses auteurs les plus connus et les faisant éditer; mauvaise idée.

Il devrait y avoir des révisions de code, mais cela ne signifie pas que c'est toujours un Sr. vérifiant le code d'un jr. À terme, tous les membres de l'équipe devraient atteindre le niveau où ils peuvent contribuer au code avec un minimum de conseils. Ils passent par les trois niveaux de confiance:

1. Aucun - je veux voir chaque ligne de code avant de le vérifier.
2. Certains - Faites-moi savoir ce que vous faites et je vous ferai part de vos commentaires
3. La plupart - Allez faire votre travail et ne demandez de l'aide qu'en cas de besoin.

Avantages de libérer votre talent:

• se concentrer sur le design
• participation à la mise en place de normes de codage et de stratégies d'application (sans tout faire manuellement)
• s'attaquer aux problèmes de codage difficiles
• offrir du mentorat (sans avoir approuvé chaque ligne de code)

Il y a des développeurs intéressés par un chemin de gestion qui peuvent préférer ne pas coder toute la journée; laissez les autres tranquilles.

l'examen vaut-il le coup sur la productivité?

Cela dépend de l '«équilibre» de l'équipe et de la façon dont les évaluations sont configurées. Les deux sont des questions de gestion et de travail d'équipe, aucune quantité de magie technologique de contrôle de version (centralisée ou distribuée) ne peut avoir une influence substantielle sur cela.

S'il est mal fait, la perte de productivité tuera bien sûr tous les avantages de l'examen; la réponse est cependant de ne pas laisser tomber l'idée des avis mais de savoir comment le faire correctement .

Une approche pour savoir si vos avis sont corrects consiste à utiliser l' outil de suivi des problèmes pour suivre le temps passé sur les avis (certains outils d'examen de code le permettent également). Si vous découvrez que les avis prennent beaucoup de temps, investissez des efforts pour trouver les raisons et les moyens d'améliorer les choses. De plus, cela ne ferait pas de mal d'avoir des entretiens 1: 1 réguliers avec les membres de l'équipe pour découvrir les problèmes potentiels avec les révisions de code.

Si les "meilleurs" programmeurs de l'équipe sont obligés de passer des heures à fouiller dans les ordures incompréhensibles produites par des codeurs merdiques, la solution consiste à licencier les fabricants de conneries, sans faire appel à la technologie VCS.

• ^{Dans l'un des projets précédents, j'ai été chargé d'examiner les modifications de code effectuées par un membre de l'équipe sous-performant en permanence, dans un composant qui a pris près d'une heure pour simplement générer et exécuter des tests. J'ai commencé à lire les différences et quand j'ai remarqué un changement incompilable, j'ai simplement terminé la révision, posté les commentaires nécessaires et demandé à la direction de s'assurer que les autres demandes de révision soient accompagnées d'une confirmation écrite de la compilation de leur code. Il n'y a eu aucune "demande de révision" depuis et bientôt le gars est parti.}

D'un autre côté, lorsque l'équipe est raisonnablement équilibrée, les révisions de code sont amusantes et éducatives. Dans mon projet précédent, nous avions une exigence de révision à 100% du code et cela n'a pas pris beaucoup de temps ni distrait. Il y a eu des bogues découverts lors de l'examen, et il y a eu des débats sur le style de codage et les choix de conception, mais cela semblait juste ... normal .

Si les modifications de code sont bloquées pendant des jours ... des semaines avant d'arriver au contrôle qualité pour des tests "en raison de critiques", étudier les astuces VCS serait le moyen le moins probable de résoudre ce problème. Au lieu de cela, il serait préférable de concentrer leurs efforts sur la recherche de problèmes dans la façon dont le processus d'examen est organisé.

• <sup>- Oh l'intégration de ce changement a été beaucoup retardée car le critique est tombé soudainement malade, quel malheur.
  - Salut! Hell-lo-oo, avez-vous déjà pensé à avoir des réviseurs de sauvegarde pour traiter des cas comme ça?</sup>

Oui. Mais seulement si vous parlez de contrôle de source distribué. Avec centralisé - cela dépend.

S'il n'y a que peu de programmeurs, cela prend peu de temps. Certainement moins que les correctifs qui seront nécessaires pour supprimer les bugs et les dettes techniques ultérieurement.

S'il y a de nombreux programmeurs, vous pouvez déléguer la tâche de révision du code aux lieutenants et demander au développeur principal de retirer (presque) sans aucun doute leurs modifications. Cela fonctionne pour le noyau Linux, je ne pense pas qu'il existe de plus gros projets logiciels ...

Encore une fois, si le projet est petit, le responsable verra rapidement qui donne du bon code et qui produit du mauvais code. Il verra assez rapidement que J.Random écrit un bon code qui n'a besoin que de vérifier les décisions architecturales tandis que le stagiaire écrit un mauvais code qui doit être revu ligne par ligne avant de fusionner. Les retours générés de cette façon réduiront le fardeau de la maintenance et donneront une expérience de première main sur tout ce que le stagiaire apprend réellement et doit être conservé en entreprise. Tirer et fusionner une branche d'un autre gitréférentiel prend littéralement une ou deux secondes, la lecture des titres des messages de validation prendra généralement plus de temps, donc après que je sache à qui faire confiance pour écrire du bon code, la fusion du code d'autres personnes n'est plus un problème.

La révision du code ne nécessite pas nécessairement l'attention de vos meilleurs programmeurs. OMI, ce devrait être une chose informelle. Juste une deuxième opinion ou une deuxième paire d'yeux sur un morceau de code d'un non-débutant avant qu'il ne soit enregistré en production. Il aide à atténuer les oublis majeurs tout en aidant les gens à améliorer le codage en tant qu'artisanat en étant exposés à d'autres perspectives de développement.

Une sorte de lite de programmation de paires moins désagréable. En d'autres termes, cela ne devrait pas prendre longtemps et vous ne devriez pas avoir à attendre quelqu'un pendant des heures. Tout ce qui, dans votre processus de développement, implique que des personnes attendent des choses est un gaspillage d'argent et paralyse l'élan / le moral, OMI.

Si la révision du code était censée arrêter 99,5% des bogues avant qu'ils n'entrent dans votre base de code, il n'y aurait aucun intérêt réel à un contrôle de version sophistiqué. Cela dit, git est intimidant au début, mais l'utilisation générale de base n'est pas si compliquée et elle est hautement configurable. Vous devriez pouvoir vous arrêter pendant quelques heures pour apprendre à tout le monde à l'utiliser. Tout le monde s'engage. Toutes les recrues sauf les noobiest examinent jusqu'à ce qu'elles démontrent leur expertise dans quelque chose.

Tant que les modifications soumises ont été examinées par les «meilleurs programmeurs», n'importe qui devrait être autorisé à soumettre du code. La seule personne qui devrait avoir la possibilité d'appliquer le contrôle sur un référentiel est l'ingénieur de publication, si cette personne existe.

Personnellement, je serais bien énervé si je devais vérifier le code des autres.

Quelques commentaires sur votre montage: non, ils ne devraient pas. Les critiques sont un mal nécessaire, elles font plus de bien que de mal et les bons programmeurs l'apprécieront. Peut-être y a-t-il une réticence à participer aux revues parce qu'ils n'aiment pas l'idée que des `` programmeurs mineurs '' critiquent leur code. C'est vraiment dommage. Ils seraient beaucoup plus susceptibles d'arrêter si la ligne de code est constamment boguée et ils passent plutôt leur temps à nettoyer après les soumissions à moitié cuites d'autres personnes.

Oui, l'examen en vaut la peine. Je ne suis pas sûr qu'il y ait un impact sur la productivité si le processus d'examen est proportionnel pour les raisons suivantes:

• Il garde les programmeurs honnêtes - si vous savez qu'il sera examiné, les utilisateurs prendront moins de raccourcis
• Il aide les nouveaux programmeurs à apprendre de programmeurs plus expérimentés
• Il permet de transférer des connaissances spécifiques au domaine
• La révision est une autre porte où les bogues et les problèmes potentiels peuvent être trouvés et corrigés

En ne permettant pas à tous les programmeurs d'utiliser le contrôle de code source, ils perdent la possibilité de suivre les modifications, d'annuler les erreurs et de voir un historique raisonnable des modifications. Je ne suis pas sûr que vous souhaitiez que seuls vos "meilleurs" programmeurs puissent se connecter à git.

Cela dit, je pense qu'il est raisonnable que vous ayez quelqu'un qui est en charge de certaines branches clés, comme une branche de publication. Dans ce cas, j'imagine que tout le monde peut utiliser le référentiel git, mais seulement certaines personnes fusionnent dans la branche release. Je ne suis pas sûr qu'il existe un moyen de faire respecter cela dans git, mais il devrait être possible de le faire par processus et de simplement vérifier que personne d'autre ne s'y est inscrit.

La fusion dans la branche de publication pourrait être effectuée par les "meilleurs" programmeurs, ou plus probablement par des personnes compétentes après un examen suffisant.

les bons programmeurs quittent-ils si une partie importante de leur travail consiste à revoir le code des autres?

S'ils n'apprécient pas le travail et sont forcés de faire cette activité, alors OUI. Cela risque fort de se produire. Car trouver un prochain travail intéressant pour un bon développeur n'est pas un gros défi de nos jours.

Vos meilleurs programmeurs devraient-ils vérifier le code de tout le monde dans le contrôle de code source?

Absolument pas. C'est assurément une perte de temps, à l'exception d'une logique critique qui doit être à l'état solide .

Cependant, les développeurs juniors ou expérimentés devraient probablement être en période de probation pour une qualité de code , juste pour être sûr et s'assurer que leur code suit les directives de développement de l'équipe, au moins pendant quelques semaines avant d'obtenir le privilège de s'engager.