Comment puis-je convaincre les programmeurs Cowboy d'utiliser le contrôle de code source?
[~ # ~] mise à jour [~ # ~]
Je travaille sur une petite équipe de développeurs, 4 gars. Ils ont tous utilisé le contrôle de source. La plupart d'entre eux ne supportent pas le contrôle de code source et choisissent plutôt de ne pas l'utiliser. Je crois fermement que le contrôle des sources est une partie nécessaire du développement professionnel. Plusieurs problèmes rendent très difficile de les convaincre d'utiliser le contrôle de code source:
- L'équipe n'est pas habituée à utiliser TFS . J'ai eu 2 séances d'entraînement, mais je n'ai eu droit qu'à 1 heure, ce qui est insuffisant.
- Les membres de l'équipe modifient directement le code sur le serveur. Cela empêche le code d'être synchronisé. Exiger une comparaison juste pour être sûr de travailler avec le dernier code. Et des problèmes de fusion complexes se posent
- Les estimations de temps proposées par les développeurs excluent le temps nécessaire pour résoudre l'un de ces problèmes. Donc, si je dis non, cela prendra 10 fois plus longtemps ... Je dois constamment expliquer ces problèmes et me risquer car maintenant la direction peut me percevoir comme "lente".
- Les fichiers physiques sur le serveur diffèrent de manière inconnue sur ~ 100 fichiers. La fusion nécessite une connaissance du projet en question et donc une coopération des développeurs que je ne suis pas en mesure d'obtenir.
- D'autres projets ne sont plus synchronisés. Les développeurs continuent de se méfier du contrôle de code source et aggravent donc le problème en n'utilisant pas le contrôle de code source.
- Les développeurs soutiennent que l'utilisation du contrôle de code source est un gaspillage car la fusion est source d'erreurs et difficile. C'est un point difficile à argumenter, car lorsque le contrôle de source est tellement mal utilisé et que le contrôle de source est continuellement contourné, il est en effet sujet aux erreurs. Par conséquent, les éléments de preuve "parlent d'eux-mêmes" selon eux.
- Les développeurs soutiennent que la modification directe du code serveur, en contournant TFS permet de gagner du temps. C'est également difficile à discuter. Parce que la fusion requise pour synchroniser le code pour commencer prend du temps. Multipliez cela par les 10+ projets que nous gérons.
- Les fichiers permanents sont souvent stockés dans le même répertoire que le projet Web. La publication (publication complète) efface donc ces fichiers qui ne sont pas sous contrôle de source. Cela entraîne également une méfiance à l'égard du contrôle des sources. Parce que "la publication rompt le projet". La résolution de ce problème (déplacement des fichiers stockés hors des sous-dossiers de la solution) prend beaucoup de temps et de débogage, car ces emplacements ne sont pas définis dans web.config et existent souvent sur plusieurs points de code.
Ainsi, la culture persiste. Une mauvaise pratique engendre plus de mauvaise pratique. Les mauvaises solutions poussent les nouveaux hacks à "résoudre" des problèmes beaucoup plus profonds et plus longs. Les serveurs, l'espace disque dur sont extrêmement difficiles à trouver. Pourtant, les attentes des utilisateurs augmentent.
Que peut-on faire dans cette situation?
Ce n'est pas un problème de formation, c'est un problème de facteurs humains. Ils ne le veulent pas et créent des barrages routiers. Traitez la dynamique de groupe brisée, quelle est la cause profonde de leur objection - généralement la peur, est-ce simplement la peur du changement, ou est-ce plus sinistre.
Aucun développeur professionnel, ni depuis 20 ans, n'a résisté au contrôle des sources. Il y a 30 ou 40 ans, lorsque les ordinateurs étaient lents, le contrôle des sources encore plus lent et les programmes constitués d'un fichier de 500 lignes, c'était pénible et il y avait de bonnes raisons de ne pas l'utiliser. Ces objections ne peuvent venir que du pire type de cow-boy auquel je puisse penser.
Le système leur est-il imposé, leur rendant la vie difficile d'une manière ou d'une autre? Découvrez ce que c'est et changez le système pour invalider l'objection. Répétez jusqu'à ce que vous ayez terminé.
Je suggère de regarder GIT ou Mercurial. Vous pouvez créer un référentiel dans chaque arborescence de code source, ils ne le remarqueront même pas et peuvent continuer à pirater comme ils le font maintenant. Vous pouvez suivre les modifications qu'ils ont piratées dans la base de code, effectuer des validations, les fusionner dans d'autres arborescences sources, etc. Quand ils vous voient faire une fusion d'une semaine d'efforts dans un autre produit en quelques secondes, ils peuvent changer leurs idées. Lorsque vous annulez l'une de leurs erreurs avec une seule commande et enregistrez leur cul, ils peuvent même vous remercier (ne comptez pas dessus). Au pire, vous avez fière allure devant le boss et, en prime, faites-les ressembler aux cow-boys qu'ils sont.
La fusion nécessiterait non seulement une grande connaissance du projet
Dans ce cas, je crains que vous ne remontiez le ruisseau proverbial sans pagaie. Si la fusion n'est pas une option, ni l'implémenter, vous dites donc que vous ne pouvez plus ajouter des fonctionnalités que vous avez déjà dans une branche (terme utilisé de manière lâche) à une autre.
Si j'étais vous, je reconsidérerais mes perspectives de carrière ...
Parfois, les problèmes du monde réel rendent son utilisation peu pratique.
Faux.
Si l'équipe n'est pas habituée à utiliser le contrôle de code source, des problèmes de formation peuvent survenir
Cela n'a rien à voir avec le contrôle du code source et tout à voir avec la formation. La formation est facile, bon marché, efficace et se fait en quelques heures. Ne pas utiliser le contrôle du code source est coûteux, risqué, inefficace et les problèmes persistent pour toujours.
Si un membre de l'équipe modifie directement le code sur le serveur, divers problèmes peuvent survenir.
Voilà le problème de la formation. Encore. Rien à voir avec le contrôle du code source et tout à voir avec la formation.
Les développeurs continuent de se méfier du contrôle de code source et aggravent donc le problème en n'utilisant pas le contrôle de code source
Ils doivent être formés à l'utilisation du contrôle du code source. Il réduit les coûts, les risques, simplifie les choses et est plus efficace. Il s'agit d'un investissement unique qui rapporte des dividendes à chaque instant.
Que peut-on faire dans ce type de situation?
Commencez à former tout le monde à l'utilisation du contrôle du code source.
Mise à jour
Les développeurs soutiennent que la modification directe du contrôle de source permet de gagner du temps.
Puisqu'ils se trompent, il est important de recueillir des données pour démontrer précisément à quel point cela est faux.
Malheureusement, cependant, la direction semble récompenser une réponse immédiate qui est coûteuse à long terme.
La seule façon de surmonter ce système de récompense est de
A) Identifiez que le coût à long terme est supérieur à la valeur apparente à court terme.
B) Identifiez les récompenses réellement en place qui font que la corruption à court terme (c'est-à-dire les changements directs) semble plus valable que le contrôle correct du code source à long terme. Qui se tape la tête pour avoir mal agi? Quel genre de tape sur la tête obtiennent-ils? Qui le donne? Afin de réparer les choses, vous devez nommer les choses qui ne vont pas et le ou les gestionnaires spécifiques qui encouragent réellement les gens.
C) Recommander un système de récompense révisé qui valorise la valeur à long terme au lieu d'une réponse rapide à court terme. Différents tapotements sur la tête pour différentes raisons.
D) Former les gens aux récompenses que vous avez trouvées pour une valeur à long terme; valeur nettement supérieure à la réponse rapide à court terme.
Les développeurs qui refusent d'utiliser le contrôle de source/version devraient être renvoyés, aussi simple que cela. Comme vous l'avez déjà souligné, les risques et les coûts inhérents de NE PAS l'utiliser l'emportent sur les frais généraux qu'il engendre par de très nombreux ordres de grandeur. Quiconque essaie de contester cela ne devrait tout simplement pas être impliqué dans le développement de logiciels et je refuserais catégoriquement de travailler avec de telles personnes.
Nous avons d'abord résolu le problème en installant un serveur d'intégration continue pour intégrer notre contrôle de code source dans le développement. Deuxièmement, verrouillez l'accès aux dossiers en lecture seule, pour empêcher les gens de contourner le contrôle des sources et de modifier directement les fichiers.
C'est un PITA les jours où vous ne pouvez pas reproduire le bogue localement, mais à part cela, il est plus agréable de pouvoir travailler, archiver et passer à autre chose, sachant qu'il sera poussé à se développer automatiquement par le serveur CI.
J'entends ta douleur. Je suis entré dans quelques lieux de travail pour découvrir que le "contrôle des sources" était un dossier partagé sur un lecteur réseau. Le problème n'est généralement pas parce qu'ils croient que cette approche est supérieure à toute autre chose, cela fonctionne simplement et ils n'ont jamais été introduits dans un flux de travail qui intègre avec succès le contrôle de source.
Avec la structure de l'équipe Flat Earth, vous avez expliqué que le changement poussé de haut en bas n'était peut-être pas la meilleure façon d'aborder la situation. Une méthode qui mérite d'être essayée est d'obtenir l'adhésion directe d'un ou deux des autres développeurs pour permettre au concept de prendre de l'ampleur. Une fois que vous avez même un autre développeur à bord, il sera beaucoup plus facile de le diffuser au reste de l'équipe. Présentez-leur lentement le concept, par exemple commencez à travailler sur un petit projet parallèle, montez-le et allez dans Git , ou même branchez quelque chose hébergé sur GitHub .
Commencez simplement, introduisez les concepts lentement et séparément de leur flux de travail quotidien. Les humains sont grands pour apprendre des choses et s'adapter au changement, surtout lorsque ce changement leur apporte un avantage direct (pensez à l'évolution). Cependant, lorsqu'il est présenté avec tout un tas de petits changements à la fois, il devient aliénant. Une fois qu'ils ont compris le fonctionnement du contrôle de code source et les avantages qu'il offre, essayez de l'intégrer dans l'un de vos projets internes (si vous démarrez un nouveau projet, c'est le moment de le présenter). Laissez les autres projets fonctionner de la manière existante si vous le souhaitez également, cela sera particulièrement efficace pour mettre en évidence les avantages d'un contrôle de code décent.
Si cela échoue, exécutez.
Vous avez évidemment les compétences techniques pour identifier et corriger votre situation, vos problèmes sont humains et liés aux processus.
Les gens ont tendance à mieux répondre à l'exemple qu'à la vision, donc je suggérerais de "le réparer" vous-même:
Prenez une copie de la dernière source, restructurez-la pour qu'elle soit compatible avec le contrôle de version, créez un nouveau projet avec une structure utile et prospective (déterminez comment vous allez gérer les branches, où vous mettez les dépendances tierces, etc.). Vous devrez probablement le faire à votre rythme.
Faites ensuite glisser vos collègues et votre direction dans une pièce et montrez à eux à quoi ressemble le développement de logiciels au 21e siècle. Illustrez les échecs de votre système actuel et montrez comment ils sont éliminés avec votre nouvelle structure.
Vous devrez également vous définir comme le gardien de la source - puisque vous semblez être le seul à vous en soucier, c'est à vous de forcer les gens (avec tous les moyens techniques ou psychologiques à votre disposition) à rester fidèles à le plan. Assurez-vous que la chose seulement qui va à un client provient d'une machine de construction hors contrôle de source. Humiliez rituellement les gens qui enfreignent les règles et causent des ravages. Les soudoyer avec des beignets ... tout ce qui fonctionne.
Si tout cela vous demande trop d'efforts (comme cela a été dit dans presque toutes les autres réponses) - trouvez un autre emploi. Ils ne valent pas votre temps.
Comment quelqu'un peut-il ne pas vouloir différentes versions de ses fichiers et la possibilité de voir les différences? Oubliez les branchements et tout ce qui est complexe. Ils n'ont même pas les bases. Modifier directement un fichier de production sans effectuer le changement le plus rudimentaire dans un environnement de test est insensé. J'ai travaillé avec certaines personnes et heureusement, nous n'avons jamais travaillé sur les mêmes projets.
Vos collègues sont trop stupides pour être paresseux. C'est une perte de temps. Tout ce que vous pouvez espérer faire, c'est former votre manager. La direction devrait aimer le contrôle des sources car elle aime toutes les formes de contrôle. Les fait se sentir importants. Vissez les autres; fixer le leader est votre seul espoir car vous ne pouvez pas le remplacer. Commencez à travailler en réseau avec d'autres développeurs compétents et essayez de les amener à rejoindre votre équipe lorsque vous avez une ouverture ou demandez-leur de vous embaucher dans leur boutique.
Étape 1 - licenciez un gestionnaire incompétent!
Si vous ne pouvez pas faire l'étape 1, essayez de faire en sorte que le gestionnaire limite le déploiement à la production uniquement aux scripts extraits du contrôle de code source. Si les développeurs (qui ne devraient pas avoir de droits de production sur prod, voir l'étape 1 s'ils le font) veulent que leur contenu soit déployé, cela doit provenir du contrôle des sources. Cela a résolu notre problème de ne pas utiliser le contrôle de source assez bien lorsque nous avons commencé à l'utiliser pour des trucs de base de données ainsi que du code C #.
Il semble d'après votre description qu'il y a un ou plusieurs problèmes avec la situation - l'équipe de développement est hors de contrôle ou une mauvaise solution de contrôle de source a été implémentée. Quoi qu'il en soit, il incombe à l'équipe de développement d'utiliser une solution de contrôle de source - la modification directe du code source sur le service de production ne fait que supplier que des problèmes se produisent.
D'après mon expérience, la première étape qui doit avoir lieu immédiatement est de synchroniser le contrôle des sources avec le serveur de production. Cette étape peut être aussi simple que de prendre une copie du code de production et de l'archiver - le code prod est probablement la base que votre équipe développe. Cette étape devra peut-être être augmentée par une fusion avec du code flottant dans le système de contrôle de source existant. Le code doit passer du développement à l'intégration/AQ (ou les deux), puis à l'étape ou à l'étape/production.
Ensuite, la direction doit rendre obligatoire le contrôle des sources. Tout simplement, si la construction ne venait pas du système de contrôle de code source, le code ne devrait pas être déployé en production. L'accès à la production doit être limité à l'équipe d'assistance uniquement, avec un accès limité au développeur pour résoudre les problèmes de production. Les développeurs ne devraient généralement jamais effectuer de déploiements à chaud de code en production - des problèmes de production pourraient certainement se produire, en particulier si les développeurs sont sous pression.
La direction doit certainement mieux gérer les problèmes ici - il sera presque impossible de soutenir le développement si le code est appliqué directement à prod (et ne passe pas au contrôle de code source).
Ceci est un bon exemple de projet où les mauvaises pratiques ont été utilisées de manière si répandue qu'il devient pratiquement impossible de le réparer. Le réparer nécessiterait un gel, donc tout peut être nettoyé sans interruption. Malheureusement, ces projets sont généralement (pour des raisons évidentes) trop bogués pour être gelés pendant plusieurs mois, les bogues critiques doivent être corrigés tous les deux jours.
Vous pourriez être tenté de bifurquer le projet pour créer une version propre tandis que la version sale est traitée avec ces corrections de bugs quotidiennes; mais le résultat le plus probable est qu'après plusieurs mois, lorsque la version "propre" est terminée, personne ne peut vous dire quelles corrections de bugs et changements ont été incorporés depuis le fork (car le même état d'esprit qui permet aux gens de se glisser dans de telles pratiques rend peu probable que ils tiennent des registres sur les changements qu'ils apportent). La version propre est obsolète, la version sale fonctionne toujours un peu, alors que se passe-t-il? La version propre est abandonnée, les oppositions se sont avérées exactes.
Autre que l'évidence Trouver un nouvel emploi, je pense que la réponse est plus tout ce qui précède.
Rendez-vous d'abord à la direction pour les inciter à passer au contrôle des sources et à le renforcer. Ensuite, découvrez ce qui doit être fait pour que les choses fonctionnent, même si cela signifie travailler directement sur le serveur. Démarrez le processus de tout contrôler en source.
Une autre option consiste à vous assurer que la dernière est sur le serveur (ce que vous devez faire malgré tout) et à démarrer un nouveau référentiel complètement à partir de la dernière. Vous perdrez l'histoire, mais à ce stade, ce sont les petites pommes de terre.
Pour votre propre raison, je vous suggère de configurer Git ou un autre DVCS sur votre propre machine afin de pouvoir suivre les changements. Importez souvent les modifications de vos collègues dans votre référentiel. Résolvez les conflits du mieux que vous le pouvez. Cela vous protégera partiellement de la folie de vos collègues.
Vous avez mentionné que la direction a déclaré que les développeurs devraient utiliser le contrôle de code source. Si vous voulez être mauvais, vous pouvez appliquer cela en vérifiant les modifications dans TFS et en publiant périodiquement le référentiel, encombrant ainsi toutes les modifications qui ne sont pas dans TFS. (Si vous gérez également votre propre DVCS, vous devez garder les deux synchronisés.) Votre justification est que vous suivez les ordres de la direction. Si vos collègues en ont assez de voir leurs modifications écrasées, invitez-les à utiliser TFS. Et continuez à assommer les modifications qui n'ont pas été enregistrées. Continuez jusqu'à ce que vos collègues cèdent ou que vous soyez viré.
Le vrai problème n'est pas que les codeurs cowboy n'utilisent pas le contrôle de version. Le vrai problème est qu'ils ont déjà choisi une façon de faire et que vous essayez de changer leur processus. Le processus choisi n'inclut pas le contrôle de version. Tous les changements de processus sont difficiles, sauf si les programmeurs eux-mêmes remarquent un problème. S'il y a un sentiment que le système existant est assez bon, essayer d'imposer un système différent est tout simplement inutile. Nous sommes les borgs, vous serez assimilés. Bien sûr, ils essaient de se battre pour devenir borg.
Verrouillez tout serveur autre que leur développement. Utilisez un gestionnaire de configuration. Faites des builds identifiables réguliers (contre des balises). Étiquetez chaque ensemble de modifications (c'est-à-dire 1 ensemble de modifications par bogue). Nous avons également mis une balise sur chaque build. Avoir un système de type AQ entre le développement et la production (au minimum). Faites des builds vers le système QA en utilisant la bonne balise de build. Donnez-leur du chagrin pour avoir "brisé la construction".
Je n'ai jamais rencontré de situation où je ne pouvais pas recréer/résoudre un problème (qui n'apparaissait qu'en production). Oui, j'ai passé des heures à recréer le problème sur un système de développement (en plus, lorsque vous le comprenez, vous pouvez l'ajouter à votre test de régression).
Nous avons réalisé un projet avec un tas de sous-traitants qui ont fait toutes ces mauvaises choses. Je passe ensuite 4 semaines à nettoyer puis à mettre en place les pratiques ci-dessus. Le projet n'a eu aucun problème avec aucune de ces choses depuis lors.