Comment gérer différents styles de programmation en équipe?

Nous avons une petite équipe de développement (seulement 3 développeurs) et nous avons récemment eu un nouveau membre d'équipe. Bien qu'il soit un codeur intelligent, son style de codage est complètement différent du nôtre. Notre base de code existante contient principalement du code lisible, propre et maintenable, mais le nouveau membre de l'équipe modifie rapidement de nombreux fichiers, introduisant des hacks et des raccourcis laids, utilisant des définitions partout, ajoutant des fonctions aux mauvais endroits, etc.

Ma question est de savoir si d'autres ont déjà vécu une telle situation auparavant et si quelqu'un a des conseils sur la façon de lui parler.

Je travaille avec une équipe qui est passée de 2 développeurs à 10 en moins d'un an. J'étais numéro 3 et le premier à soulever un problème de normes de codage. Les deux développeurs originaux travaillaient côte à côte depuis quelques années et ils avaient adopté une norme commune qui me semblait étrangère. Nous avons eu exactement les mêmes problèmes que vous décrivez.

Ce que nous avons fait était:

Normes de codage de recherche

Nous avons passé quelques jours à vérifier les projets open source établis. Nous savions que l'équipe se développerait rapidement et nous recherchions de vraies solutions basées sur de vrais projets et non sur des directives génériques. Nous ne nous soucions pas non plus des normes de codage optimales, mais d'un ensemble de règles et de directives qui auraient du sens et ne nécessiteraient pas la refactorisation de l'ensemble de notre base de code. Nous recherchions un hack de normes de codage si vous voulez.

Nous avons décidé tous les trois que les meilleures normes de codage pour un projet PHP établi étaient celles suivies par Zend Framework. Heureusement, les gens de Zend Framework fournissent un document de normes de codage très complet .

Création de nos propres normes de codage

Bien sûr, appliquer les normes de codage d'un autre projet sur notre projet tel quel n'était pas logique. Nous utilisons le document Zend Framework comme modèle:

• Nous avons d'abord supprimé tout ce qui ne s'appliquait pas à notre projet
• Ensuite, nous avons changé tout ce que nous percevions comme une question de style pour notre style
• Et finalement nous avons tout écrit

Nous avions donc un document assez volumineux à portée de main, stocké dans notre wiki de fantaisie , c'était une bonne lecture, convenue par nous tous. Et complètement inutile en soi.

Rester fidèle à notre promesse

Notre base de code à l'époque était d'environ 1 * 10 ^ 6 sloc. Nous savions que depuis que nous avons adopté des normes de codage formelles, nous avons dû commencer à refactoriser notre code, mais à l'époque, nous étions confrontés à d'autres problèmes. Nous avons donc décidé de refactoriser simplement nos bibliothèques de base, un simple sloc 5 * 10 ^ 3.

Nous avons confié à l'un d'entre nous le rôle de maître des normes de codage (nous avons utilisé des jurons locaux à la place du maître ) avec la responsabilité de vérifier et d'appliquer les normes. Nous recyclons le rôle tous les quelques sprints. J'étais le premier, et c'était beaucoup de travail, car je devais surveiller presque chaque commit.

Nous avons eu plusieurs nouvelles discussions et petits addenda au document original pendant mon mandat, et finalement nous avons eu un document quelque peu stable. Nous le changeons de temps en temps, mais la plupart de ces changements concernent les nouvelles fonctionnalités du langage, car PHP 5.3 était une version majeure à part nom.

Traiter avec le nouveau mec

Lorsque le prochain nouveau venu est arrivé, il était temps de mettre nos normes de codage à l'épreuve. Après une petite introduction à notre base de code, nous lui avons demandé d'évaluer notre document sur les normes de codage. Il a presque pleuré. Il est apparu qu'il avait tout fait différemment.

Comme j'étais le maître des normes de codage à l'époque, c'était à moi d'évaluer sa contribution et de réviser le document en conséquence. Ses propositions étaient les suivantes:

• Questions de style personnel (rejetées sommairement)
• Des normes qui avaient du sens pour son expérience Java mais pas tellement avec PHP (rejeté)
• Conventions qu'il portait de sa brève exposition avec PHP (certaines ont été rejetées, mais beaucoup se sont avérées être des conventions populaires auxquelles nous n'avons jamais pensé ou découvert dans nos recherches initiales)

Au cours des deux semaines suivantes, on lui a confié une tâche simple: mettre à jour plusieurs parties de notre base de code avec les normes. J'ai dû choisir soigneusement ces pièces en fonction de quelques règles:

• Le code devrait être relativement facile pour quelqu'un qui ne connaît pas notre base de code (et PHP en général)
• Le code devrait être sur ce qu'il a été embauché pour faire

J'ai surveillé son processus et il a fait du bon travail. Nous avons identifié plusieurs parties de code qui étaient impossibles à adapter à notre document et révisées en conséquence (code et / ou normes, selon ce qui était le plus logique)

Et puis un autre nouveau type est arrivé. Nous avons répété le processus (maître différent cette fois), et cela a de nouveau fonctionné. Et encore.

En conclusion

1. Créez un document de normes de codage, mais assurez-vous que vos normes ne sont pas exclusivement les vôtres, mais qu'elles reflètent des normes communes dans la communauté plus large de votre plate-forme.
2. Attribuez un rôle similaire à notre maître des normes de codage. Quelqu'un pour surveiller au moins le nouveau code, et surtout le nouveau code des nouveaux membres. Recyclez le rôle, car il est extrêmement ennuyeux.
3. Évaluez toujours les commentaires d'un nouveau membre. Révisez toujours vos normes si cela a du sens. Votre document sur les normes de codage devrait évoluer, mais lentement. Vous ne voulez pas refaçonner votre base de code à chaque itération.
4. Prévoyez un certain temps pour que chaque nouveau membre apprenne et s'adapte à vos normes et conventions. Apprendre en faisant des travaux dans ces situations
5. Le wiki fait des merveilles pour de tels documents.
6. Les révisions de code font des merveilles dans toutes les situations!

À un moment donné du processus, il a été suggéré d'utiliser un hook de pré-validation pour automatiser la vérification des normes. Nous l'avons décidé pour diverses raisons, il y a des discussions intéressantes sur StackOverflow sur la question:

• Formatage automatique du code SVN lors de l'enregistrement?
• Contrôle de version et formatage du codage
• PHP codesniffer (phpcs) - comment autoriser le remplacement lors de l'utilisation dans le cadre d'un hook de pré-validation svn?
• SVN Pre-commit hook à déclencher pour un dossier particulier
• Implémentation des normes de codage PHP

Certains sont spécifiques à PHP, mais les réponses s'appliquent à toutes les plateformes.

Oui, je l'ai déjà vécu. Lorsque vous travaillez en équipe, les membres de l'équipe doivent s'entendre sur certaines règles et conventions, y compris le style.

Vous devriez demander à votre équipe de s'asseoir ensemble et de rédiger un ensemble de règles, de normes de codage , auxquelles vous auriez besoin que chaque morceau du code enregistré adhère.

Très probablement, la base de votre ensemble de règles, concernant le style au moins, serait le code existant. Une fois que c'est fait, tout le monde doit se conformer et il doit être inspecté dans le cadre de la révision du code . Le code non conforme aux normes ne doit pas être autorisé à être enregistré.

Il n'est pas nécessaire que ce soit un vote démocratique, c'est l'une des choses où le chef d'équipe peut effectivement exercer une certaine autorité. Mais cela dit, je ne pense pas que vous puissiez imposer des normes que la majorité de l'équipe rejette. Vous pouvez imposer des normes qu'une seule personne, en particulier une nouvelle, rejette.

Quant à savoir comment lui parler ... Chaque programmeur expérimenté sait que chaque lieu et équipe a ses propres conventions et style, qui doivent être suivis. Vous pouvez lui dire qu'il est plus que bienvenu pour suggérer des améliorations, mais il doit se conformer aux règles de l'équipe, et il ne devrait pas changer le style du code existant mais plutôt utiliser le même style lors de l'ajout de nouveau code.

En outre, vous pouvez dire (si vous êtes le responsable ou en parler à votre responsable) à cette personne de ne pas faire certaines choses que vous jugez inappropriées (vous avez mentionné les définitions, l'ordre, les hacks et les raccourcis, etc.).

1. Quelqu'un est en charge - ils doivent agir comme ça.
2. Si le style de codage est si important, pourquoi cela n'a-t-il pas été expliqué à cette personne et dites-lui qu'elle n'aura accès à aucun code tant qu'elle n'aura pas appris les règles.
3. Examen du code - apparemment, vous n'en avez pas ou il est très faible. Voir # 1.

Notez dans votre processus d'embauche que le respect des styles de codage acceptés est une exigence pour l'emploi. Maintenant, que faites-vous à ceux qui ne respectent pas les règles? Commencez par supprimer leur accès au code en direct jusqu'à ce qu'ils obtiennent le programme.

.

Voici ce qui peut être fait:

1. Écrivez un document expliquant le style de codage requis et faites-le apprendre à tout le monde dans l'équipe. Collectez des informations auprès de chaque membre de l'équipe.
2. divisez les tâches de manière à ce que chaque membre de l'équipe soit responsable de sa propre pièce et puisse décider des conventions de cette partie du code. Si des problèmes sont détectés, celui qui l'a écrit les corrigera.
3. ajouter un outil automatique au contrôle de version qui corrige l'indentation et d'autres éléments à chaque fois que le code est validé pour le contrôle de version
4. Différents programmeurs ont toujours un style de programmation différent, et plus tard, il peut être difficile de changer. La meilleure façon de le gérer est de partager des informations entre les membres de l'équipe afin que chacun apprenne quels styles les gens ont utilisés. Si vous avez un membre de l'équipe qui écrit un code différent, c'est une chance pour les membres de votre équipe existante d'apprendre le nouveau style.
5. Une bonne astuce consiste à ne jamais modifier le code existant. Au lieu de modifier le code, écrivez un nouveau code en remplaçant les lignes vides par un nouveau code. Et une fois le code prêt, n'effectuez que des modifications minimes sur le système existant pour utiliser le nouveau code. Cela évite de modifier le code existant, voire de casser ce qui fonctionnait déjà bien.

Voici ce qu'il faut éviter:

1. décider que le code d'une personne est meilleur ou pire que les autres membres de l'équipe. Cela ne fonctionne tout simplement pas comme ça - tout le monde connaît certains sous-ensembles du langage assez bien pour l'utiliser dans du code. Chaque programmeur a choisi un sous-ensemble différent pour apprendre, et à moins qu'ils ne l'apprennent ensemble, ça va avoir l'air différent.
2. Changer la façon dont quelqu'un écrit du code. Tout ce que vous obtenez en forçant les gens à écrire un style inconnu, c'est que vous obtenez une grande quantité de bogues dans le code. Les gens ne savent tout simplement pas assez de détails sur quelque chose qu'ils utilisent la première fois. Les programmeurs choisissent toujours un sous-ensemble de langage et l'utilisent seuls. Si vos programmeurs ont écrit des milliers de lignes de code remplies de gotos, alors les gotos vont vous donner du code qui a le moins de bugs.
3. Vous ne devriez pas non plus penser que votre base de code existante est une chose agréable, propre et maintenable. Il y a toujours des choses à améliorer. Mais chaque changement brouille également l'idée de conception originale qui lui a été écrite. Essayez d'écrire du code parfait la première fois, afin que les modifications ne soient pas nécessaires plus tard. (le nouveau type n'aurait pas besoin de "casser" votre code parfait, s'il était fait correctement la première fois)

Notre base de code existante contient principalement du code lisible, propre et maintenable

Une chose que j'ai apprise au fil des ans, c'est que la lisibilité est dans l'œil du spectateur. J'ai vu de nombreux cas où le style de codage chickenscratch de quelqu'un est justifié comme étant "lisible", et j'ai vu des gens parfaitement raisonnables se disputer sur les styles de codage les plus "lisibles". Peut-être que ce gars ne voit pas votre style comme lisible?

Cela dit, le nouveau gars doit se conformer à vos normes, et non l'inverse.

Pensez à utiliser les demandes d'extraction de nouveau code dans le référentiel. Cela donne un endroit pratique pour passer en revue le code. Le code qui échoue à la révision du code n'est pas fusionné dans le référentiel tant qu'il n'est pas en forme.

Faites juste attention à ne pas faire trop de demandes de tirage. D'après mon expérience, ils ne doivent pas dépasser une demi-journée à deux jours maximum, sinon vous aurez trop de conflits de fusion.

Les systèmes vcs en ligne comme bitbucket ou github prennent en charge cette fonctionnalité. Si vous préférez une cachette d'approche sur site semble être le meilleur pari actuellement.

Il existe une règle simple que vous pouvez suivre: si vous modifiez un fichier avec du code, vous utilisez la norme de codage utilisée dans ce fichier. Si vous créez un nouveau fichier, vous utilisez n'importe quelle bonne norme de codage. (Plus: si votre compilateur peut donner des avertissements, vous activez tous les avertissements raisonnables, activez warnings = error si possible et n'autorisez aucun code avec des avertissements. tabulations vers des espaces ou similaires, NE PAS les utiliser).

La raison pour laquelle il existe d'énormes arguments au sujet des normes de codage est qu'une norme n'est pas meilleure ou pire qu'une autre (généralement) mais juste différente. La seule chose vraiment mauvaise est de mélanger les styles de codage.

Évidemment, je m'attends à ce que tout programmeur décent puisse écrire du code suivant n'importe quelle norme de codage, qu'il préfère cette norme particulière ou non.

Et d'autre part, il existe des normes de qualité. N'acceptez jamais de code qui ne répond pas à vos normes de qualité.