Comment mettre tout le monde sur la même page en termes de préférences de codage dans une petite équipe?
Supposons que 10 à 50 ingénieurs travaillent sur une base de code. Tout le monde a différent préférences pour ces types de choses:
- Structure des dossiers
- Conventions de dénomination (noms de classes CSS, noms de fonctions, noms de variables, etc.)
- Conventions de test
- Emplacement de l'expression (où les variables sont définies dans un fichier, etc.)
- Encapsulation (si cela va dans un utilitaire, une classe, etc.)
- Comment écrire des types d'expressions spécifiques
- etc.
Si vous laissez tout le monde faire ce qu'il veut, beaucoup de conflits et les gens se mettent en colère. Si vous appliquez un guide de style spécifique, vous ne pouvez pas prévoir de cas d'utilisation spécifiques et vous avez beaucoup de passe-partout. Si le "leadership" choisit la direction, les gens se sentent exclus.
Comment décidez-vous d'un ensemble de préférences spécifiques, d'une manière générale (c'est-à-dire sans se soucier de savoir s'il s'agit d'une discussion sur la structure des dossiers ou des conventions de dénomination CSS)?
la réponse de Matt donne de bons conseils (ainsi que les commentaires de Robert Harvey à la question), mais les deux sont à mon humble avis incomplets en ce qui concerne la question de savoir comment obtenir jusqu'à 50 personnes à bord. Les problèmes d'organisation pour essayer de faire travailler 5 personnes sur la même norme sont très différents de ceux auxquels vous êtes confronté lorsque vous avez 50 personnes à gérer.
Il y a environ 20 ans, j'étais dans une telle situation, où nous avions des équipes d'environ cette taille au total pour un nouveau projet, et nous avons essayé d'établir des normes à l'avance entre elles sur une période d'environ 6 mois (! ). Ce n'était pas un désastre complet, mais certainement pas rentable, et de nouvelles améliorations de ces normes étaient en fait difficiles à apporter par la suite. Avec le recul d'aujourd'hui, je vois certaines choses que nous aurions pu faire mieux là-bas:
Commencez avec une équipe plus petite de 5-6 développeurs expérimentés maximum et laissez-leur le temps de faire quelques itérations pour prototyper l'écosystème, l'architecture et les normes de codage du système. Puis évoluez - les personnes qui viendront plus tard dans l'équipe devront adopter les normes déjà données. Ils peuvent apporter de nouvelles suggestions d'améliorations, mais pas de changement complet "sur le terrain" - du moins, non sans obtenir l'adhésion de la direction.
Une équipe de 50 personnes est trop grande pour travailler toutes "sur la même base de code" dans son intégralité, il existe généralement des sous-équipes pour différentes parties/composants du produit. N'insistez pas pour que chaque sous-équipe obéisse précisément au même standard. Donnez-leur de la place pour des améliorations par eux-mêmes. Les frais généraux de communication n'en valent généralement pas la peine, et si vous devez déplacer un développeur d'une sous-équipe à un autre, le développeur peut généralement et rapidement adopter la "variante de la norme" de la sous-équipe individuelle. Dans une telle situation, il est plus important d'avoir des interfaces rigides entre les composants que d'avoir tous les composants structurés à 100% de manière similaire à l'intérieur.
Assurez-vous de ne pas standardiser pour des raisons de standardisation. Gardez les "normes mondiales" valables pour tous au minimum nécessaire. Si c'est vraiment un système cohérent qui doit être construit, les choses que vous devez habituellement normaliser sont "l'écosystème" des frameworks/langages de programmation/systèmes d'exploitation impliqués, la structure globale des dossiers, les technologies de serveur impliquées (base de données, web, SCCS ). Mais laissez les petits détails comme "où les variables sont définies dans un fichier" , ou des niveaux inférieurs de la structure des sous-dossiers aux sous-équipes plus petites. Essayer de standardiser de telles choses pour une grande équipe ne vaut généralement pas la peine.
Utilisez un ou plusieurs documents de normes de codage publiés comme point de départ pour la discussion. De nombreuses grandes organisations ont rendu leurs documents de normes disponibles gratuitement sur le Web pour à peu près tous les langages et cadres imaginables. Téléchargez certains de ces documents et distribuez-les pour que l'équipe les examine et les examine, en précisant que les documents sont uniquement destinés à faciliter la discussion et que les opinions de votre équipe sont sollicitées. Ensuite, organisez des réunions en face à face en équipe pour passer en revue ces documents de normes et donner aux gens la possibilité de faire valoir leurs arguments pour ou contre des règles particulières et de décider quelles normes méritent d'être adoptées. En cours de route, les développeurs proposeront inévitablement des règles qui ne figurent dans aucun des documents de normes publiés avec lesquels vous avez commencé et c'est correct aussi.
Tenir des discussions, viser à dégager un consensus, tenir des votes si des règles particulières sont litigieuses (votes sur l'opportunité ou non d'adopter une règle ou laisser cette question à la discrétion individuelle et, si une règle doit être adoptée, ce que cette règle devrait être), etc. Si le processus de discussion et de prise de décision est conduit de manière juste et équitable, alors le consensus et l'adhésion doivent être atteints même si tout le monde n'est pas satisfait de chaque règle de la norme parce qu'il a de bonnes raisons de respecter le processus qui a produit la norme.
Les conflits surviennent lorsque les abmitions des gens s'affrontent. Vous pouvez éviter cela en utilisant un système automatisé qui applique les conventions. Les documents de politique et les guides de codage ne sont d'aucune utilité car ils sont sujets à interprétation. Valider le crochet en vérifiant les règles de formatage, les conventions de dénomination, etc. est une solution beaucoup plus propre qui garantit à tout le monde un traitement similaire.