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

28

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?

VolkerK
la source
Les problèmes qu'ils rencontrent ne sont-ils pas une incitation à vouloir améliorer leur façon de travailler?
Flosculus
1
Juste une idée, faites-les fusionner le code;) Mais une chose qui m'empêche dans SVN de commettre souvent, c'est que cela prend beaucoup de temps par rapport à git par exemple ...
Knerd
5
Qui prend la responsabilité de résoudre les conflits après que quelqu'un a effectué une fusion?
Flosculus
Une approche qui privilégie les branchements peut donner le meilleur des deux mondes; si vous effectuez un travail important sur une branche et que vous fusionnez régulièrement la branche principale dans cette branche (de sorte que toutes les fusions sont petites), lorsque vous fusionnez enfin la branche en maître, cette fusion est triviale, mais en attendant, vous ne l'avez pas fait a obtenu un état intermédiaire sur le maître qui est cassé ou autrement incomplètement déroutant. C'est plus facile avec certains SCM que d'autres (selon la façon dont la ramification lumineuse est), mais cela peut fonctionner avec n'importe lequel d'entre eux.
Jon Hanna

Réponses:

47

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.

Arseni Mourzenko
la source
"Vous cherchez une solution technique à un problème humain. Cela fonctionne rarement." - Je sais, mais je suis juste fatiguée et j'ai déjà fini avec tous vos points. Ce n'est pas mon problème pour beaucoup plus longtemps, pourtant ...
VolkerK
@VolkerK: voir ma modification (les deux premiers paragraphes de la réponse). Avez-vous un serveur CI? Lorsque vous avez parlé à vos collègues, comment expliquent-ils leur refus de s'engager plus souvent?
Arseni Mourzenko
1
@VolkerK Cette réponse explique très bien. Vous n'avez pas de problème technique. Le problème est que les gens refusent de suivre la procédure.
BЈовић
1
Vers le point 3: le client TortoiseSVN peut créer divers diagrammes qui visualisent le comportement d'enregistrement en fonction de différents paramètres (comme l'heure). Il est en fait assez intéressant de les évaluer. Je l'ai fait fréquemment à l'époque où nous utilisions SVN. stackoverflow.com/questions/412129/… :)
Aschratt
2
Merci pour la contribution mais j'ai pris l'autre route et je viens de donner un avis ;-)
VolkerK
-3

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.

Saphon
la source
4
C'est une terrible façon de traiter les gens. Que se passe-t-il lorsque vous pensez à quelque chose juste avant de partir et que vous voulez l'avoir sur la machine, mais qu'il n'est pas complet (comme ne se construit pas), donc vous ne voulez pas le valider?
user1118321
3
Et c'est un gaspillage de ressources, car normalement vous disposez d'un environnement d'installation qui correspond bien à vos besoins. J'ai eu la même situation il y a longtemps et j'ai obtenu mon propre ordinateur portable après 4 semaines. Je détestais chaque jour de m'installer tout de même, juste pour faire le travail que je devais faire.
mliebelt
1
Wow, c'est une terrible idée pour tant de raisons. Comme déjà mentionné dans les commentaires ci-dessus, (1) cela empêche toute possibilité de continuité au jour le jour et (2) prive les gens de la possibilité de mettre en place des environnements de développement personnalisés qui restent ...
Ben Lee
1
... Mais cela (3) a également le potentiel de détruire les heures de travail si quelqu'un oublie de vérifier le code, ou accidentellement pas pour une raison quelconque et (4) démontre aux développeurs que la direction ne leur fait pas confiance pour suivre les règles , au lieu d'imposer les règles de manière draconienne, ce qui pourrait en faire un environnement nous-contre-eux et (5) il pourrait les encourager à contourner les règles simplement pour être productif.
Ben Lee
S'il vous plaît, personne ne met en œuvre cette idée.
Ben Lee