Comment persuader les programmeurs de suivre les règles de base

Il y a plusieurs règles que je dois continuer à demander aux programmeurs de suivre très souvent. Ils écrivent du code et, si cela fonctionne, le travail est fait pour eux. La plupart des règles de base peuvent être:

• Valider les changements
• Ne pas écrire les problèmes de modèle dans la vue ou les contrôleurs
• Évitez le codage en dur

Pouvez-vous me parler de votre expérience? Comment gérez-vous cela?

Tous les travailleurs du savoir doivent être mis au défi de faire un travail de qualité. La qualité en souffrira s'ils sentent que des contraintes de temps arbitraires leur sont imposées. Pourquoi ne pas simplement faire des choses «assez bonnes» quand tout le monde est soucieux de respecter les spécifications et de respecter les délais?

Votre liste de plaintes est le symptôme d'une entreprise qui ne récompense que l'atteinte d'objectifs à court terme et ne souhaite pas privilégier la qualité. Vous dirigez un hôtel cinq étoiles ou un arrêt de camion?

Pour pouvoir suivre les règles de base, ils doivent connaître les règles et être d'accord avec eux.

La façon de gérer cela est de créer conjointement un document de directives de codage avec lequel tout le monde peut être d'accord. N'essayez pas de leur imposer cela, cela se retournera si vous le faites.

Alors réunissez l'équipe et commencez à travailler sur une définition commune de vos règles de base!

Faites-le comme un atelier où toutes les voix sont entendues. Timebox it pour éviter les discussions sans fin. Vous essayez de rassembler plusieurs esprits, vous pouvez donc vouloir préparer le terrain avec une note positive que vous devez tous être respectueux et garder un esprit ouvert (l'écriture de code est personnelle ...).

Ces directives doivent être modifiées à chaque fois que l'équipe estime qu'il y a quelque chose à ajouter ou à clarifier.

Quel est ton rôle? Si vous êtes juste un autre développeur avec un intérêt particulièrement fort pour la qualité du code, vous n'avez probablement pas le pouvoir de les amener à vous écouter, et peut-être devriez-vous propager ces idées à la direction pour établir des normes de code qui devraient / doivent être suivi. Si vous êtes un gestionnaire / chef d'équipe / architecte et que vous avez une certaine autorité, vous pouvez établir ces pratiques vous-même. Instituer un document de normes et un processus de révision du code pour éliminer ces éléments.

Ce ne sera pas un interrupteur magique que vous pouvez activer; ce sera un processus lent et ne sera jamais à 100%. C'est mon expérience de toute façon.

Il doit s'agir d'une combinaison judicieuse de toutes les réponses jusqu'à présent. En fin de compte, lorsque vous parlez d'un groupe de personnes intelligentes (développeurs), vous devez leur donner les raisons pour lesquelles le comportement est important et leur donner suffisamment de contrôle sur la façon dont ce comportement est mis en œuvre pour qu'ils soient investis à bien le faire. Les mandats ci-dessus sont généralement lâches avec les gens intelligents, car s'ils n'ont pas convenu que le problème est un problème, ils passeront probablement plus de temps à contourner le mandat qu'à suivre la règle.

Voici quelques-unes de mes tactiques:

Validation des modifications:

Tout d'abord, l'équipe doit se mettre d'accord sur le moment de s'engager et sur quoi s'engager. Une configuration de construction qui a du sens est absolument essentielle, de sorte que les gens ne se retiennent pas simplement parce qu'ils ne savent pas où mettre quelque chose. Et un consensus sur le moment / la fréquence d'enregistrement. "Ne pas casser la version" est une bonne règle évidente, mais comment est-ce vérifié et qui en est informé? Une autre référence est "ce n'est pas fait s'il n'est pas enregistré".

La plupart des développeurs que je connais sont plus qu'heureux de vérifier le code IF:

• Le processus d'enregistrement est facile
• Le processus de synchronisation est facile (prise en compte des modifications d'autres développeurs)
• Voir les changements et passer d'une version à l'autre est facile

Une chose que j'ai remarquée récemment est que les enregistrements sont devenus plus fréquents et moins douloureux lorsque nous nous sommes dirigés vers un nouvel outil CM. Notre équipe est un pionnier de Rational Team Concert ayant auparavant utilisé Clearcase. Je ne veux pas annoncer d'outils, mais la nouvelle vague (pour moi) de connexions en streaming avec beaucoup de petites fusions rapides rend beaucoup plus attrayant l'enregistrement tôt et souvent.

Laisser les développeurs être en charge d'éliminer la douleur CM augmente généralement la quantité de checkin qui se produit.

Adhésion à l'architecture - pas d'écriture des problèmes de modèle dans les vues et les contrôleurs

Je mets cela dans le bloc général de "faire l'architecture correctement". Je suis d'accord avec celui qui a dit les évaluations par les pairs - la pression des pairs est excellente pour cela. L'une des façons dont je vois généralement les gens entrer dans le giron des meilleures pratiques dans ce domaine est lorsque leurs pairs leur demandent pourquoi ils l'ont fait dans l'autre sens (la manière pas si correcte). Généralement, la question du «pourquoi» amènera les gens à comprendre par eux-mêmes pourquoi ils auraient dû procéder différemment. Lorsque les gens ont une raison bien comprise de la meilleure pratique, il est beaucoup plus facile de s'y conformer.

De plus, s'il existe une formalité reliant une personne à une décision, il peut être plus facile d'attribuer des bogues dans ce domaine ... donc si une personne est responsable de la correction des bogues dans une zone de conception défectueuse, la nécessité de corriger quelque chose avant ils peuvent passer à quelque chose de nouveau et d'excitant peut être une grande motivation.

Évitez le codage en dur

Je commencerais par des normes de codage claires et en intégrant un examen des normes de codage dans les examens par les pairs. Le codage en dur est l'une de ces choses qui peut facilement être une case à cocher dans un programme d'examen par les pairs.

J'ai peur que ce genre de chose soit la seule chose où je l'ai vu devenir le rôle du chef d'équipe pour faire respecter la règle. Dans les équipes que j'ai dirigées, nous ne laissons généralement pas quelqu'un avancer tant qu'il n'a pas corrigé les commentaires d'un examen par les pairs de son code. Et "pas de codage en dur" est un commentaire fréquemment revu par les pairs.

En général

Avec presque toutes les meilleures pratiques, je pense que vous devez choisir vos batailles. Aucune équipe ne deviendra absolument parfaite. Mais vous pouvez garder un œil sur vos principaux points douloureux et commencer à les résoudre en grappes. Je pense que cela devient le rôle du leader de vraiment savoir ce qui est un point douloureux pour l'équipe contre une bizarrerie ennuyeuse d'un individu particulier.

Si votre équipe manque de faire une meilleure pratique particulière, je pense que la première question doit être "combien de dégâts cela cause-t-il?" si la réponse est "minimale", cela ne vaut probablement pas le temps. Certaines meilleures pratiques sont plus pertinentes pour des types spécifiques de systèmes - bien qu'elles soient globalement bonnes, elles ne valent peut-être pas la bataille pour des systèmes où la pratique n'est pas fréquente ou une partie importante du système.

Si la réponse à "combien de damange?" est "BEAUCOUP !!!", alors vous pouvez commencer à construire un dossier pour montrer à l'équipe que toutes ces douleurs et souffrances pourraient être éliminées en corrigeant ce point de relâchement dans les meilleures pratiques. La plupart des gens sont heureux d'éviter la douleur et la souffrance et cela change le dialogue de "fais ça parce que je te l'ai dit", à "on a décidé de faire ça parce que c'est mieux".

Révision du code. N'acceptez que du code bien écrit et sans erreur.

Au moins :

• Aidez-les à suivre les codes (outils comme resharper, StyleCop). Si c'est facile, ils sont plus susceptibles d'adopter.

En plus de cela, choisissez ce qui fonctionne en fonction de votre organisation, des développeurs et de votre rôle au sein de l'équipe.

• Laissez-les faire des corrections de bugs et changer régulièrement les demandes
• Programme de jumelage avec un développeur expérimenté
• Revues de code de manière constructive
• Procédures pas à pas de code
• Commencez la formation, utilisez des livres comme Code Complete et The pragmatic programmer.

Mon rôle est Manager, mais en tant que petite équipe, je me développe et je préfère plutôt gérer en tant que coach.

Des électrodes dans le fauteuil connectées à un analyseur de code ont déjà été signalées, mais les programmeurs ne semblent pas avoir peur. Le tir ne semble pas être une bonne approche, car cela signifie perdre des actifs dignes.

Je vais jeter un œil à tous ces outils et je reste ouvert à tout autre que vous me direz.

Nous pouvons résoudre ce problème de trois manières:

1. Analyse statique du code source pour vérifier les problèmes de convention de codage. Utilisez des outils comme cppcheck et ceux de grammatech . Wikipedia a une bonne liste: http://en.wikipedia.org/wiki/List_of_tools_for_static_code_analysis . En règle générale, la plupart des systèmes de contrôle de source ont des crochets par lesquels vous pouvez vérifier ces problèmes directement lors de l'enregistrement. Pour les crochets CVS, consultez ce lien: http://goo.gl/F1gd2 . Le non-respect signifie un échec d'enregistrement, et plus de 3 échecs signifient que le développeur doit s'expliquer à l'équipe.

2. Au cours du processus de codage, signalez les problèmes au développeur. Avoir des scripts personnalisés qui sont intégrés à l'EDI de votre choix est une bonne façon de le faire. Consultez ce lien: http://goo.gl/MM6c4

3. Suivez les processus agiles et assurez-vous que la révision du code fait partie du sprint

Voici mon plan en 3 étapes:

1. Tire les programmeurs
2. Embaucher des ingénieurs logiciels
3. ...
4. Profit!

:RÉ

Sérieusement, s'ils ne croient à rien d'autre qu'à écrire du code, vous avez besoin d'une équipe plus complète. Un programmeur où je travaillais utilisait différents répertoires sur l'ordinateur comme son CM. Nous nous sommes battus avec leur programmeur pendant près d'un an (car les changements introduiraient des bogues alors qu'ils copiaient et collaient l'ancien code). Nous les avons finalement licenciés.

1. Faites-leur remarquer quand ils violent les règles de base.
2. Attendez qu'ils produisent des bogues qu'ils ne peuvent tout simplement pas localiser ou qu'ils soient confrontés à une demande de fonctionnalité qu'ils ne peuvent tout simplement pas implémenter en raison de leur code inflexible.
3. Rappelez-leur ce que vous avez dit plus tôt.
4. Laissez-les se noyer dans leur propre merde pendant un moment.
5. Prenez le temps de refactoriser le code en question, d'isoler les bugs / fournir des infrasturcutre pour brancher de nouvelles fonctionnalités. Prenez le temps d'expliquer ce que vous avez fait.

Alternativement, la chose la plus cruelle mais très persuasive à faire est de les laisser maintenir une base de code extrêmement mal écrite, étant donné un calendrier serré. : D
Et puis, pour un changement, laissez-les maintenir une base de code bien écrite, étant donné un calendrier serré.

Généralement, la réticence à adapter certaines normes signifie un manque d'expérience dans le travail d'équipe.

En fin de compte, les gens apprennent seulement des erreurs. Ne réglez JAMAIS des problèmes qui sont basés sur l'entêtement de quelqu'un d'autre. Si c'est vraiment vital pour le projet (c'est-à-dire que votre entreprise sera poursuivie si vous ne livrez pas dans les N jours), mettez-les d'abord hors du projet.

Je pense que votre programmeur ne changera pas d'attitude vis-à-vis de ces problèmes que vous avez mentionnés jusqu'à ce qu'il se rende compte que ces choses leur apporteront un avantage ou un avantage. Essayez de leur expliquer pourquoi vous voulez qu'ils fassent ces choses. Encore mieux, laissez-les découvrir les avantages.

Embaucher un ingénieur logiciel professionnel. Et puis tirez le plus faible. Remplacez ensuite lentement ceux qui ne peuvent pas adopter. Avoir de telles personnes fait parfois plus de mal que de profit à long terme.

L'idée principale ici, que le professionnel commencera à faire la plupart des tâches, et licencier d'autres ne réduira pas les précieuses ressources humaines.

C'est un peu dégoûtant, mais j'ai laissé Code Complete dans la salle de bain pendant quelques mois. Pas sûr que ce soit efficace, mais cela semblait être une bonne idée à l'époque.

Alors, quelles sont les conséquences pour ne pas suivre les règles et les récompenses pour suivre les règles? Si la réponse est la même - rien - bonne chance pour obtenir une traction. Je suggère une approche à plusieurs niveaux. Rassemblez-les d'abord et discutez s'ils adhèrent aux règles. L'étape suivante consiste à les inclure dans les revues de code. Vous pouvez également essayer des carottes et des bâtons. Quelque chose comme quiconque laisse un fichier extrait du jour au lendemain doit apporter des beignets à la prochaine réunion hebdomadaire. Une carotte pourrait être toute personne qui suit les règles pendant un mois entier obtient un week-end à Vegas. Pour deux.

Ou renvoyez le pire des délinquants et laissez le reste transpirer.

Faites-leur subir les conséquences que vous voulez éviter en utilisant ces règles, c'est la seule façon qu'ils vont vraiment comprendre pourquoi vous demandez, par exemple: faire un petit gâchis contrôlé qu'ils doivent corriger.

Si cette équipe a vraiment du mal à vérifier les changements, à respecter la séparation des préoccupations et non les constantes magiques à coder en dur, je licencierais toute l'équipe et les remplacerais par de vrais programmeurs ¹ qui se soucient réellement de leur métier dès que possible. Que ce soit à la fois ou en masse, je ne pourrais pas le dire, mais ces jokers doivent partir.

Le type de codage que vous décrivez convient aux scripts jetables à usage unique. Ce n'est pas comme ça qu'on construit une vraie application. S'ils sont payés en tant que programmeurs professionnels, alors c'est leur travail de savoir ce genre de chose.

¹ Ceci est souvent utilisé comme un terme de plaisanterie pour les personnes imaginaires qui écrivent leur code directement en binaire ou quelque chose de tout aussi ridicule. Ici, je ne plaisante pas. Je suis un programmeur assez novice et je n'aurais pas besoin qu'on me dise ces choses parce que je me soucie de mon métier. Ce ne sont pas de vrais programmeurs avec qui vous avez affaire.

Le travail d'un manager n'est pas d'être l'ami de l'employé, il faut parfois être le méchant. L'application des normes de codage et des commits, le refus de suivre l'architecture prédéfinie, le non-recours aux outils prescrits, etc. sont les moments où vous devez être impopulaire.

Exprimez clairement les politiques. Faites des révisions de code formelles et vérifiez si les politiques sont suivies. Ne leur permettez pas de passer à une autre tâche tant que tous les problèmes de la révision du code n'ont pas été résolus.

Si la politique concerne la non-validation du code, cela appelle un avertissement écrit s'ils ne peuvent pas le faire quand on leur demande de le faire. S'ils ne commettent pas de code, en ce qui vous concerne, ils n'en ont pas écrit.

S'ils ne s'améliorent pas après avoir eu une chance raisonnable de s'améliorer, tirez-les. Les développeurs non professionnels sont un frein à votre équipe, quel que soit le type de code qu'ils écrivent. Ils affectent les autres par leur manque de professionnalisme et cela ne doit pas être toléré. Ce ne sont pas de bonnes personnes à retenir de toute façon. Les bons développeurs engagent leur code, les bons développeurs suivent les décisions architecturales même s'ils ne sont pas d'accord avec eux et les bons développeurs ne codent pas en dur. Vous ne manquerez de rien sauf des maux de tête en vous débarrassant des codeurs de cow-boy.