Normes sur la façon dont les développeurs travaillent sur leurs propres postes de travail

Nous venons de rencontrer une de ces situations qui survient parfois lorsqu'un développeur tombe malade pendant quelques jours à mi-projet.

Il y avait quelques questions à savoir s'il avait validé la dernière version de son code ou s'il y avait quelque chose de plus récent sur sa machine locale que nous devrions examiner, et nous avions une livraison à un client en attente, donc nous ne pouvions pas attendre lui de revenir.

L'un des autres développeurs s'est connecté en tant que lui pour voir et a trouvé un gâchis d'espaces de travail, dont beaucoup ressemblaient aux mêmes projets, avec des horodatages qui ne permettaient pas de savoir lequel était "actuel" (il prototypait quelques bits sur des versions du projet autres que son «noyau»).

Évidemment, c'est une douleur dans le cou, mais l'alternative (qui semble être des normes strictes pour la façon dont chaque développeur travaille sur sa propre machine pour s'assurer que tout autre développeur peut ramasser les choses avec un minimum d'effort) est susceptible de briser de nombreuses les flux de travail personnels des développeurs et conduire à l'inefficacité au niveau individuel.

Je ne parle pas de normes pour le code archivé, ni même de normes de développement générales, je parle du fonctionnement local d'un développeur, un domaine généralement considéré (selon mon expérience) comme étant presque entièrement sous le contrôle des développeurs.

Alors, comment gérez-vous des situations comme celle-ci? Est-ce l'une de ces choses qui se produit et à laquelle vous devez faire face, le prix que vous payez pour que les développeurs soient autorisés à travailler de la manière qui leur convient le mieux?

Ou demandez-vous aux développeurs de respecter les normes dans ce domaine - utilisation de répertoires spécifiques, normes de dénomination, notes sur un wiki ou autre? Et si oui, que couvrent vos normes, sont-elles strictes, comment les contrôlez-vous, etc.?

Ou y a-t-il une autre solution qui me manque?

[Supposons pour les besoins de l'argument que le développeur ne peut pas être contacté pour parler de ce qu'il faisait ici - même s'il pouvait savoir et décrire quel espace de travail est lequel de mémoire ne va pas être simple et sans faille et parfois les gens peuvent vraiment 'ne pas être contacté et j'aimerais une solution qui couvre toutes les éventualités.]

Edit: Je comprends que passer par le poste de travail de quelqu'un est une mauvaise forme (bien que ce soit une question intéressante - et probablement hors sujet - pour savoir précisément pourquoi) - et je ne regarde certainement pas l'accès illimité. Réfléchissez davantage à une norme où leurs répertoires de code sont configurés avec un partage en lecture seule - rien ne peut être changé, rien d'autre ne peut être vu, etc.

" S'il n'est pas sous contrôle de source, il n'existe pas. "

C'est l'une des rares choses dans notre profession que je suis à la limite dogmatique. Pour les raisons suivantes:

1. Même si le poste de travail est la propriété de l'entreprise, avouons-le - il existe une règle non écrite selon laquelle le poste de travail d'un programmeur est son château. Je suis simplement mal à l'aise avec une culture de lieu de travail où tout le monde peut se connecter régulièrement et la parcourir.
2. Tout le monde a son propre flux (comme vous l'avez dit aussi). Essayer de forcer tous les développeurs à organiser leurs propres espaces de travail locaux d'une certaine manière peut aller à l'encontre de leur façon particulière de travailler, rompre leur flux et les rendre moins efficaces.
3. Ce qui n'est pas sous contrôle de code source est du code à moitié cuit. Si c'est du code entièrement préparé qui est prêt à être publié, il devrait être sous contrôle de code source. Ce qui revient encore à l'essentiel ...
4. "S'il n'est pas sous contrôle de source, il n'existe pas."

Une façon possible d'atténuer le problème de vouloir consulter le code sur les postes de travail des personnes est de favoriser une culture de checkins réguliers. J'ai travaillé dans une entreprise une fois où - même s'il n'y avait pas de mandat officiel pour le faire - c'était une sorte de fierté de toujours avoir tout vérifié pour le week-end. Dans les phases de maintenance et de libération des candidats, les éléments CR étaient délibérément très fins pour permettre de petits changements bien visibles et des enregistrements réguliers pour en garder la trace.

De plus, avoir tout enregistré avant de partir en vacances était obligatoire .

Version TL; DR : Rifling à travers les postes de travail des gens est une mauvaise forme. Plutôt que d'essayer de favoriser une culture permettant de parcourir facilement les postes de travail des gens pour trouver ce que nous voulons, il est préférable de favoriser une culture d'utilisation judicieuse du contrôle des sources et des enregistrements réguliers. Peut-être même des enregistrements hyper réguliers et des tâches à grain fin lors des phases critiques des projets.

Plutôt que d'appliquer une norme sur la façon dont vos développeurs organisent leurs postes de travail, appliquez une norme où tout le travail est archivé à la fin de chaque journée . Les enregistrements peuvent être effectués dans les succursales s'ils sont encore incomplets.

De cette façon, personne ne devrait jamais avoir besoin d'accéder à la station de travail d'un autre développeur.

J'imagine que cette politique rencontrerait une certaine opposition, mais rien comparé à ce à quoi je m'attendrais si vous imposiez des règles sur l'organisation de votre poste de travail.

Je vais vous dire la vérité, je suis mal à l'aise à l'idée même que quelqu'un va se connecter à ma machine et parcourir mes trucs. Certes, c'est l'équipement et les biens de l'entreprise, mais c'est tout simplement une mauvaise chose à faire.

La dernière fois que je suis parti pour un week-end, les gars ont reconfiguré les serveurs avec la base de données et le contrôle des sources et pour une raison quelconque, ils ont estimé nécessaire de se connecter à ma machine et de reconfigurer le système pour le nouveau paramètre.

Dommage qu'ils n'aient aucune idée de ce qu'ils faisaient et ils ont effacé un prototype sur lequel je travaillais depuis deux mois.

Cela ne serait pas arrivé si la bonne communication avait été en place. C'est aussi ce dont vous avez besoin. Rencontrez ce développeur et découvrez l'état des choses. Encore mieux, demandez aux gens un rapport avant de partir en congé afin de prendre une décision éclairée, que vous en ayez besoin ou non.

Mais ne plaisante pas avec les postes de travail des gens.

PS Nous avons une convention pour une structure de répertoires mais sa principale raison d'existence est un mélange d'historique / configuration - mettez-le ailleurs et il ne sera pas compilé.

Il y a quelques mois, je travaillais sur un projet assez important et j'ai dû quitter le travail brusquement en apprenant que j'étais admis à l'hôpital. Je n'ai pas eu le temps de vérifier mon dernier code pour le projet.

Heureusement, il est conventionnel ici (mais pas "nécessaire") de stocker le code dans /var/www/ourdomain.com pour imiter la production. Avec une convention aussi logique et facile à suivre, il était facile pour un collègue de se connecter à ma machine et de récupérer mes dernières modifications.

Je pense que certaines conventions sont bonnes. Bien que je sois d'accord avec Bobby quand il dit

"S'il n'est pas sous contrôle de source, il n'existe pas."

En outre, un ajout utile à tout espace de travail de programmeur pourrait être un disque SATA remplaçable à chaud sur la baie avant sur lequel stocker tous les projets source et de développement. De cette façon, si un tel problème survient, un employé peut récupérer facilement les nouvelles modifications source du projet sans avoir à se connecter au poste de travail du développeur.

La première partie de votre question identifie clairement les problèmes de communication au sein de votre équipe. Avez-vous essayé des standups quotidiens ?

Je suis d'accord avec vous lorsque vous dites que les normes conduiront probablement à l'inefficacité si elles sont trop strictes. Les normes doivent être définies par l' équipe , impliquant tout le monde.

Dans votre cas, j'attendrais quelques jours après le retour au travail du développeur concerné. Organisez ensuite une réunion pour parler de ces normes.

Afin d'éviter tout blocage psychologique et résistance, ne nommez pas les personnes ou les choses spécifiques que vous avez vues. Gardez-le général, l'objectif ici est d'obtenir l'avis de tout le monde, y compris du développeur qui, selon vous, devrait améliorer sa façon de travailler. Le gars peut aussi considérer votre organisation comme un gâchis.

Pendant la réunion, présentez le problème et demandez clairement comment l' équipe pourrait améliorer la situation.

La (toute) l' équipe décide ce qu'il faut faire.

Cet utilisateur souffrait probablement d'un manque d'outils appropriés. En particulier, l'utilisation d'un système de contrôle de version distribué aurait éliminé pour lui la nécessité d'avoir différents répertoires de code dans différents états. Il aurait pu garder tout cela dans les branches et être beaucoup plus heureux.

Pour l'essentiel, cependant, non, je ne veux pas que des normes soient imposées sur la façon dont j'organise mon propre poste de travail. Je repousse actuellement mon département en train de normaliser sur un IDE (mon patron veut vraiment que nous tous dans Eclipse parce que c'est ce qu'il utilise et sait bien, même si l'OMI n'est pas le meilleur outil pour mon travail).

Laissez les développeurs faire tout ce qui les rend confortables. Un développeur confortable est plus productif qu'un développeur inconfortable. Et si quelqu'un n'est PAS productif et que vous soupçonnez qu'il tâtonne localement avec les outils, c'est une occasion de formation, pas un bon moment pour établir de nouvelles règles.

Sur mon ancien lieu de travail, nous avions un système par lequel chaque tâche de notre suivi des bogues avait sa propre branche dans le contrôle des sources. Il était entendu que la plupart du temps, un bogue / tâche était écrasé par un développeur, de sorte que le code cassé pouvait être vérifié dans le contrôle de code source.

Une fois que le code était dans un état stable sur la branche de développement, un rebase a été fait en faisant glisser le code depuis la branche avec laquelle vous alliez vous intégrer. Une fois que vous avez testé cette fusion, il s'agirait simplement de valider le code dans la branche d'intégration - cela ne nécessiterait aucune fusion, car vous aviez déjà effectué la fusion sur votre branche.

De cette façon, vous évitez le problème des développeurs qui craignent de commettre du code qui est cassé - et vous pouvez commencer à appliquer la politique sociale de le rendre super acceptable pour archiver le code avant de quitter le bureau la nuit - agréable et sûr.

Dans cette situation particulière, appelez la personne à la maison, dites-lui très clairement que vous ne doutez pas qu'il est malade mais que vous devez demander à quelqu'un d'autre de continuer son travail et demandez où se trouvent les dernières informations et dans quel état.

Ensuite, vous devez réfléchir à ce que vous devez faire à partir d'ici. Si le problème est que les gens s'enregistrent trop rarement, envisagez d'utiliser un système de contrôle de source distribué qui permet aux gens de travailler dans les succursales sans se déranger.

Si le problème est que vous n'aimez pas que les développeurs aient plusieurs espaces de travail sur leur machine, passez-y. Le style de travail est individuel et vous devez essentiellement rester à l'écart de leurs systèmes tant qu'ils fonctionnent correctement avec les règles du référentiel source. Personnellement, je vérifie une nouvelle copie très fréquemment pour différents projets et ne nettoie que de temps en temps.

Si le problème est que vous ne savez pas ce que fait votre développeur, le problème est politique et non technique, et vous devez changer votre style de gestion. N'oubliez pas que les développeurs sont des personnes hautement qualifiées qui aiment rarement la microgestion et vous devez déléguer. Sinon, vous repousserez les individus les plus qualifiés.

Donc, je recommanderais d'encourager une meilleure façon de travailler avec le référentiel source commun - dites que c'est bien pour les gens de travailler dans des succursales et de les laisser s'engager fréquemment tant qu'ils synchronisent quotidiennement leur copie locale vers le référentiel maître (car ils fera toujours le travail de développement dans une branche, cela n'influencera pas les autres).

Alors, comment gérez-vous des situations comme celle-ci?

Vous pouvez résoudre ce problème avec un système de contrôle de source qui prend en charge les branches personnelles instables et en maintenant des validations fréquentes. Un commit n'a pas besoin de venir lorsqu'un problème entier est résolu. Cela devrait arriver chaque fois que vous bénéficiez du contrôle de code source. La fin de la journée est l'un des nombreux points où un commit doit se produire afin que vous puissiez voir où vos modifications ont été apportées, les sauvegarder et les expliquer à vous-même ou aux autres.

Ou demandez-vous aux développeurs de respecter les normes dans ce domaine - utilisation de répertoires spécifiques, normes de dénomination, notes sur un wiki ou autre?

Nous avons un immense document de configuration d'environnement qui dénote des conventions, mais pas une norme. Les normes concernent le code de production et les environnements. Cependant, bon nombre de nos outils de développement sont configurés pour prendre en charge les conventions et la plupart des développeurs ne déploient pas d'efforts pour contrecarrer la tendance.