Comment appliquer les bonnes / meilleures pratiques de contrôle du code source?

Je soupçonne que je me concentre sur le mauvais problème, donc je vais d'abord décrire ce que je pense que le problème est avant de présenter la solution éventuellement sous-optimale que j'envisage.

Situation actuelle:
Actuellement, mes collègues n'effectuent leurs modifications de code qu'après de longues périodes de temps en gros morceaux avec des changements qui se propagent sur tout le projet. C'est un progrès, je suppose, car il n'y a pas longtemps, ils ont simplement mis des archives .zip sur un partage réseau. Pourtant, la fusion est un cauchemar - et franchement j'en ai assez. Et je suis aussi fatigué de parler, d'expliquer et de mendier. Cela doit juste cesser - sans que je sois constamment "le méchant".

Ma solution:
Puisqu'il ne semble pas y avoir de prise de conscience et / ou aucun intérêt pour les problèmes et que je ne peux pas m'attendre à ce que les efforts durent plus de quelques jours ... harcelant.

Ma question:
suis-je loin de la base ici ou est-ce que je regarde le mauvais problème? Il semble que je manque quelque chose et je pense que je demande la mauvaise chose en regardant des outils pour résoudre mon problème.

Dois-je rechercher un outil pour résoudre ce problème ou que dois-je faire pour résoudre ce problème?

Vous recherchez une solution technique à un problème humain. Cela fonctionne rarement.

La raison en est que si les membres de l'équipe n'acceptent pas quelque chose (ni ne comprennent les implications), au lieu de suivre les règles, ils tenteront de les contourner. C'est exactement pourquoi, par exemple, les développeurs devraient accepter et comprendre les règles de style au lieu d'être simplement obligés de se conformer par un vérificateur.

Voici quelques approches que j'ai utilisées dans le passé ou que j'ai en tête sans en avoir réellement l'occasion dans la pratique. Certains peuvent ne pas s'appliquer à votre cas, selon la position que vous occupez dans une équipe (si vous êtes un chef d'équipe avec une excellente réputation, vous aurez probablement une meilleure occasion de faire valoir votre point de vue que si vous êtes un étudiant de premier cycle qui vient de rejoindre une équipe pour la durée de votre stage).

1. Discutez du problème avec vos collègues et expliquez les conséquences des grands commits. Peut-être qu'ils ne comprennent tout simplement pas que les fusions compliquées sont une conséquence directe de commits rares, et que de petites validations fréquentes rendront les fusions (relativement) faciles.

   Je connaissais beaucoup de programmeurs qui étaient tout simplement convaincus que les fusions sont toujours compliquées. Ils ont effectué au plus un commit par jour, évité d'utiliser des outils puissants tels que le diff et la fusion automatique de Visual Studio, et avaient une mauvaise pratique de fusion manuelle (à moins que "Take mine" sans autre inspection de diff soit en fait une bonne pratique). Pour eux, cela n'avait rien à voir avec eux et était la nature inhérente d'une fusion.

2. Donnez des exemples concrets de ce qui se passe dans d'autres entreprises (en particulier celles pour lesquelles vos collègues ont un profond respect). Ils peuvent simplement ignorer qu'il s'agit d'un problème et être convaincus qu'un maximum d'un engagement par jour est ce que fait chaque équipe.

   Certaines personnes ignorent qu'il existe des équipes de 5 à 10 membres qui effectuent jusqu'à 50 poussées vers la production, ce qui se traduit par une moyenne de 5 à 10 commits par jour et par personne. Ils peuvent ne pas comprendre comment c'est possible, ni pourquoi quelqu'un le ferait.

3. Mener par l'exemple. Faites suffisamment de petits engagements. Si possible, faites une courte présentation montrant leurs et vos fusions côte à côte pendant une semaine (je ne suis pas sûr que l'extraction de ce type d'informations soit facile à partir d'un contrôle de version). Insistez sur les éventuelles erreurs qu'ils ont commises lors de leur fusion et comparez-les au nombre d'erreurs que vous avez commises (qui devrait être proche de zéro).

4. Utilisez la technique «Je vous l'ai dit», le cas échéant . Lorsque vous voyez vos collègues souffrir d'une fusion douloureuse, dites haut et fort que de petits commissions fréquentes pourraient rendre les fusions (relativement) indolores.

5. Expliquez qu'il n'y a pas de durée minimale pour effectuer une validation. Un commit peut même correspondre à une modification mineure effectuée en quelques secondes. Renommer un fichier, supprimer un commentaire obsolète, corriger une faute de frappe sont autant de tâches qui peuvent être validées immédiatement.

   Les programmeurs ne devraient pas craindre de faire un petit commit, mais plutôt d'agréger de nombreux changements en un seul gros commit.

6. Travaillez avec des individus plutôt qu'avec une équipe, le cas échéant. S'il y a une personne qui refuse particulièrement de faire des petits commissions fréquentes, parlez avec cette personne individuellement pour voir pourquoi il la refuse.

   Ils peuvent donner des raisons parfaitement valables qui peuvent vous donner une idée de ce qui se passe avec une équipe. Quelques raisons pour lesquelles je me suis entendu:

   • «Mon professeur / mentor m'a dit que la meilleure pratique est de faire un engagement par jour.» Cela ne me surprend pas, compte tenu de ce que j'ai dû entendre de mes professeurs au collège .

   • «Mes collègues m'ont dit que je devrais faire moins de commits.» On m'a dit cela aussi dans certaines équipes, et je comprends leur point. Nous avions un journal qui était pratiquement rempli de mes commits (pas difficile à faire lorsque quatre coéquipiers ne font même pas un commit par jour), ce qui a frustré mes collègues.

   • «Je pensais que les petits commits rendaient difficile la recherche d'une révision.» Point en quelque sorte valable, même lorsque l'équipe s'efforce d'écrire des messages de journal descriptifs.

   • «Je ne veux pas perdre trop d'espace sur notre serveur de contrôle de version.» La personne ne comprend évidemment pas comment les commits sont stockés (ni à quel point l'espace de stockage est bon marché).

   • «Je pense qu'un commit doit correspondre à une tâche spécifique.» Étant donné que souvent, une tâche correspond à un travail à effectuer en une journée (comme dans les tableaux de bord de la gestion visuelle), ce n'est pas un hasard. La personne doit alors apprendre à faire la différence entre une tâche dans un carnet de commandes (2 à 8 heures de travail) et un changement logiquement isolé qui doit être validé (quelques secondes à quelques heures de travail). Ceci est également lié au point 5.

7. Recherchez la raison pour laquelle l'équipe n'effectue pas les validations plus fréquemment. Vous pourriez être surpris par les résultats.

   Récemment, j'ai mentionné dans une réponse différente que la vitesse d'un commit est importante, et même des centaines de millisecondes peuvent pousser les développeurs à s'engager sur une base moins fréquente.

   D'autres raisons peuvent inclure:

   • Règles trop compliquées pour écrire un message de validation.

   • Règle qui oblige le développeur à lier la validation à une tâche à partir d'un système de suivi des bogues.

   • La peur de casser la construction.

   • La réticence à faire face à un risque de rupture de build en ce moment: si vous effectuez un commit vendredi soir juste avant de partir, vous pouvez reporter le traitement de build cassé à lundi.

   • La peur de faire une fusion.

8. Déterminez si les développeurs comprennent qu'il existe d' autres avantages à engager souvent . Par exemple, une plate-forme d'intégration continue est une incitation énorme à avoir des validations fréquentes , car elle permet de localiser avec précision où la régression a été introduite .

   Je préférerais plutôt que la plate-forme CI me dise que j'ai cassé la construction dans la révision 5023 qui consiste en un changement de deux méthodes dans un fichier que j'ai fait il y a quinze minutes, plutôt que dans la révision 5023 consistant en des changements qui s'étendent sur quatre douzaines de fichiers et représentent 13 heures de travail.

Une organisation pour laquelle j'ai passé un contrat dans le passé voulait résoudre ce même problème et a trouvé une assez bonne solution sociale: les développeurs n'ont pas leurs propres ordinateurs. L'ÉQUIPE de développement dispose d'ordinateurs, mais il peut être demandé à tout individu de travailler sur n'importe quel ordinateur de développement chaque jour. L'enregistrement est donc le seul moyen de s'assurer que vous pouvez continuer à travailler sur ce que vous faisiez hier!

La direction a ensuite fait le tour et annulé subrepticement les modifications sur les ordinateurs après les heures de travail afin que tout ce qui n'était pas enregistré soit perdu. Ces «pannes informatiques simulées» n'ont dû se produire que quelques fois avant que les développeurs ne soient embarqués.

Bien sûr, il est important d'expliquer le "pourquoi" des règles ainsi que le "quoi". À moins que le «pourquoi» ne soit précisé, ils pourraient simplement stocker leur source sur des clés USB ou quelque chose.