Comment dites-vous à quelqu'un qu'il écrit du mauvais code? [fermé]

J'ai travaillé avec un petit groupe de personnes sur un projet de codage pour le plaisir. C'est un groupe organisé et assez cohésif. Les personnes avec lesquelles je travaille ont toutes des compétences diverses liées à la programmation, mais certaines d'entre elles utilisent des méthodes anciennes ou carrément erronées, telles que des variables globales excessives, des conventions de dénomination médiocres et d'autres choses. Alors que les choses fonctionnent, la mise en œuvre est mauvaise. Quelle est une bonne façon de leur demander poliment ou de leur présenter d'utiliser une meilleure méthodologie, sans que cela ne revienne à remettre en question (ou à insulter) leur expérience et / ou leur éducation?

Introduisez des questions pour leur faire réaliser que ce qu'ils font est mal. Par exemple, posez ce genre de questions:

Pourquoi avez-vous décidé d'en faire une variable globale?

Pourquoi lui avez-vous donné ce nom?

C'est intéressant. Je fais habituellement le mien de cette façon parce que [insérer la raison pour laquelle vous êtes meilleur]

Est-ce que cela fonctionne? J'ai l'habitude [d'insérer comment vous pourriez les rendre idiotes]

Je pense que la façon idéale de procéder consiste à leur demander subtilement pourquoi ils codent d'une certaine manière. Vous constaterez peut-être qu'ils croient qu'il y a des avantages à d'autres méthodes. Sauf si je savais que la raison de leur style de codage était due à une désinformation, je ne jugerais jamais mon chemin comme meilleur sans une bonne raison. La meilleure façon de procéder est de simplement leur demander pourquoi ils ont choisi cette voie; assurez-vous d'avoir l'air intéressé par leur raisonnement, car c'est ce dont vous avez besoin pour attaquer, pas leur capacité.

Une norme de codage sera certainement utile, mais si c'était la réponse à chaque projet de logiciel, nous siroterions tous des cocktails sur nos îles privées au paradis. En réalité, nous sommes tous sujets aux problèmes et les projets logiciels ont toujours un faible taux de réussite. Je pense que le problème proviendrait principalement de la capacité individuelle plutôt que d'un problème de convention, c'est pourquoi je suggérerais de résoudre les problèmes en tant que groupe lorsqu'un problème se lève.

Plus important encore, ne présumez PAS immédiatement que votre chemin est meilleur . En réalité, c'est probablement le cas, mais nous avons affaire à l'opinion d'une autre personne et pour eux, il n'y a qu'une seule solution. Ne dites jamais que votre façon de faire est la meilleure façon de le faire, sauf si vous voulez qu'ils vous voient comme un perdant suffisant.

Commencez à faire des révisions de code ou à programmer des paires.

Si l'équipe ne les accepte pas, essayez des revues de conception hebdomadaires. Chaque semaine, rencontrez-vous pendant une heure et discutez d'un morceau de code. Si les gens semblent défensifs, choisissez l'ancien code auquel personne n'est émotionnellement attaché, du moins au début.

Comme @JesperE: l'a dit, concentrez-vous sur le code, pas sur le codeur.

Lorsque vous voyez quelque chose que vous pensez être différent, mais que les autres ne le voient pas de la même manière, commencez par poser des questions qui conduisent aux carences, au lieu de les signaler. Par exemple:

Globals : Pensez-vous que nous voudrons jamais en avoir plus d'un? Pensez-vous que nous voudrons contrôler l'accès à cela?

État mutable : pensez-vous que nous voudrons manipuler cela à partir d'un autre thread?

Je trouve également utile de me concentrer sur mes limites, ce qui peut aider les gens à se détendre. Par exemple:

fonctions longues : mon cerveau n'est pas assez gros pour contenir tout cela à la fois. Comment pouvons-nous fabriquer des pièces plus petites que je peux manipuler?

mauvais noms : je me trompe assez facilement en lisant du code clair; quand les noms sont trompeurs, il n'y a aucun espoir pour moi.

En fin de compte, l'objectif n'est pas que vous enseigniez à votre équipe comment mieux coder. Il s'agit d'établir une culture d'apprentissage dans votre équipe. Où chaque personne se tourne vers les autres pour l'aider à devenir un meilleur programmeur.

Présentez l'idée d'une norme de code. La chose la plus importante à propos d'une norme de code est qu'elle propose l'idée de cohérence dans la base de code ( idéalement , tout le code devrait ressembler à ce qu'il a été écrit par une personne en une seule séance), ce qui conduira à un code plus compréhensible et plus facile à gérer.

Vous devez expliquer pourquoi votre chemin est meilleur .

Expliquez pourquoi une fonction est meilleure que couper et coller.

Expliquez pourquoi un tableau est meilleur que $ foo1, $ foo2, $ foo3.

Expliquez pourquoi les variables globales sont dangereuses et que les variables locales vous faciliteront la vie.

Il suffit de sortir une norme de codage et de dire "faites ceci" sans valeur car cela n'explique pas au programmeur pourquoi c'est une bonne chose.

Tout d'abord, je ferais attention de ne pas juger trop vite. Il est facile de rejeter du code comme étant mauvais, alors qu'il peut y avoir de bonnes raisons (par exemple: travailler avec du code hérité avec des conventions étranges). Mais supposons pour le moment qu'ils sont vraiment mauvais.

Vous pourriez suggérer d'établir une norme de codage, basée sur les commentaires de l'équipe. Mais vous devez vraiment prendre en compte leurs opinions, et non seulement imposer votre vision de ce que devrait être un bon code.

Une autre option est d'apporter des livres techniques au bureau (Code Complete, Effective C ++, le pragmatique programmeur ...) et de proposer de le prêter à d'autres ("Hé, j'en ai fini avec ça, quelqu'un voudrait l'emprunter?" )

Si possible, assurez-vous qu'ils comprennent que vous critiquez leur code , pas eux personnellement.

Suggérer une meilleure alternative de manière non conflictuelle.

"Hé, je pense que cette méthode fonctionnera aussi. Qu'en pensez-vous?" [Geste pour visiblement un meilleur code sur votre écran]

Faites réviser le code et commencez par examiner VOTRE code.

Cela mettra les gens à l'aise avec l'ensemble du processus de révision du code, car vous commencez le processus en examinant votre propre code au lieu du leur. Commencer avec votre code leur donnera également de bons exemples de la façon de faire les choses.

Ils peuvent penser que votre style pue aussi. Réunissez l'équipe pour discuter d'un ensemble cohérent de directives de style de codage. Acceptez quelque chose. Que ce soit adapté à votre style n'est pas le problème, choisir n'importe quel style tant qu'il est cohérent est ce qui compte.

Par exemple. Montrez-leur la bonne façon.

Vas-y doucement. Ne les battez pas pour chaque petite erreur dès le départ, commencez par des choses qui comptent vraiment.

L'idée standard du code est bonne.

Mais pensez à ne rien dire, d'autant plus que c'est pour le plaisir, avec, vraisemblablement, des gens avec qui vous êtes amis. C'est juste du code ...

Il y a de très bons conseils dans le livre de Gerry Weinberg "The Psychology of Computer Programming" - toute sa notion de "programmation sans ego" consiste à aider les gens à accepter la critique de leur code comme distincte de la critique d'eux-mêmes.

Mauvaises pratiques de dénomination: toujours inexcusables.

Et oui, ne présumez pas toujours que votre chemin est meilleur ... Cela peut être difficile, mais l'objectivité doit être maintenue.

J'ai eu une expérience avec un codeur qui avait des noms de fonctions si horribles, le code était pire qu'illisible. Les fonctions mentaient sur ce qu'elles faisaient, le code était absurde. Et ils étaient protecteurs / résistants à ce que quelqu'un d'autre change leur code. confrontés très poliment, ils ont admis qu'il était mal nommé, mais ils voulaient conserver leur propriété du code et y retourneraient et le corrigeraient "à une date ultérieure". C'est dans le passé maintenant, mais comment gérez-vous une situation où l'erreur est RECONNUE, mais ensuite protégée? Cela a duré longtemps et je ne savais pas comment franchir cette barrière.

Variables globales: Moi-même, je n'aime pas tellement les variables globales, mais je connais quelques programmeurs par ailleurs excellents qui les aiment BEAUCOUP. À tel point que j'en suis venu à croire qu'ils ne sont en fait pas si mauvais dans de nombreuses situations, car ils permettent la clarté et la facilité de débogage. (S'il vous plaît, ne me flammez pas / ne me dévaluez pas :)) Cela revient à dire que j'ai vu beaucoup de très bon code, efficace et sans bogue qui utilisait des variables globales (pas mises par moi!) et beaucoup de boguet, impossible de lire / maintenir / corriger le code qui utilise méticuleusement les modèles appropriés. Peut - être qu'il EST un lieu (bien que le rétrécissement peut - être) pour les variables globales? J'envisage de repenser ma position sur la base de preuves.

Démarrez un wiki sur votre réseau en utilisant un logiciel wiki.

Commencez une catégorie sur votre site appelée "meilleures pratiques" ou "normes de codage" ou quelque chose.

Dirigez tout le monde vers elle. Autoriser les commentaires.

Lorsque vous effectuez des versions du logiciel, demandez à la personne dont le travail consiste à mettre du code dans la génération de repousser les développeurs, en les pointant vers les pages Wiki.

Je l'ai fait dans mon organisation et il a fallu plusieurs mois pour que les gens se familiarisent vraiment avec le Wiki, mais maintenant c'est cette ressource indispensable.

Si vous avez même une norme de codage souple, être en mesure de pointer vers cela ou indiquer que vous ne pouvez pas suivre le code car ce n'est pas le bon format peut valoir la peine.

Si vous n'avez pas de format de codage, ce serait le bon moment pour en mettre un en place. Quelque chose comme les réponses à cette question peut être utile: /programming/4121/team-coding-styles

Je vais toujours avec la ligne «C'est ce que je ferais». Je n'essaie pas de leur faire la leçon et de leur dire que leur code est des ordures, mais juste de donner un point de vue alternatif qui peut, espérons-le, leur montrer quelque chose qui est évidemment un peu plus net.

Demandez à la ou aux personnes en question de préparer une présentation au reste du groupe sur le code d'un module représentatif qu'elles ont écrit, et laissez le Q&A s'en occuper (croyez-moi, ce sera le cas, et si c'est un bon groupe, ça ne devrait même pas devenir moche).

Je ne le code d'amour, et n'a jamais eu de cours de ma vie au sujet de tout ce qui touche à l' informatique , j'ai commencé très mal et a commencé à apprendre des exemples, mais ce que je me souviens toujours et gardé dans mon esprit depuis que je lis le « Gang Of Four » livre était :

"Tout le monde peut écrire du code compris par une machine, mais tous ne peuvent pas écrire du code compris par un être humain"

dans cet esprit, il y a beaucoup à faire dans le code;)

Je ne saurais trop insister sur la patience. J'ai vu ce genre de chose exactement se retourner contre moi, principalement parce que quelqu'un voulait que les changements se produisent MAINTENANT. Un certain nombre d'environnements ont besoin des avantages de l'évolution et non de la révolution. Et en forçant le changement aujourd'hui, cela peut créer un environnement très malheureux pour tous.

L'adhésion est la clé. Et votre approche doit prendre en compte l'environnement dans lequel vous vous trouvez.

On dirait que vous êtes dans un environnement qui a beaucoup «d'individualité». Donc ... je ne suggérerais pas un ensemble de normes de codage. Il apparaîtra que vous voulez prendre ce projet "amusant" et le transformer en un projet de travail hautement structuré (oh super, quelle est la prochaine ... documents fonctionnels?). Au lieu de cela, comme quelqu'un l'a dit, vous devrez y faire face dans une certaine mesure.

Restez patient et travaillez à éduquer les autres dans votre direction. Commencez par les bords (points où votre code interagit avec les autres) et lorsque vous interagissez avec leur code, essayez de le saisir comme une occasion de discuter de l'interface qu'ils ont créée et de leur demander si cela leur conviendrait si elle était modifiée (par vous ou eux). Et expliquez en détail pourquoi vous voulez le changement ("cela aidera à mieux gérer les changements d'attributs de sous-système" ou autre). Ne vous contentez pas d'essayer de changer tout ce que vous voyez comme étant faux. Une fois que vous interagissez avec d'autres sur le bord, ils devraient commencer à voir comment cela leur serait bénéfique au cœur de leur code (et si vous obtenez suffisamment d'élan, allez plus loin et commencez vraiment à discuter des techniques modernes et des avantages des normes de codage). S'ils ne le voient toujours pas ... peut-être vous '

La patience. L'évolution, pas la révolution.

Bonne chance.

Je mets une toge et ouvre une boîte de méthode socratique.

La méthode socratique nommée d'après le philosophe grec classique Socrate, est une forme d'enquête philosophique dans laquelle le questionneur explore les implications des positions des autres, pour stimuler la pensée rationnelle et éclairer les idées. Cette méthode dialectique implique souvent une discussion oppositionnelle dans laquelle la défense d'un point de vue s'oppose à un autre; un participant peut en amener un autre à se contredire d'une manière ou d'une autre, renforçant le point de vue du demandeur.

Beaucoup de réponses ici concernent la mise en forme de code qui, de nos jours, n'est pas particulièrement pertinente, car la plupart des IDE reformateront votre code dans le style que vous choisissez. Ce qui compte vraiment, c'est le fonctionnement du code, et l'affiche a raison de regarder les variables globales, le copier-coller du code, et ma bête noire, les conventions de dénomination. Le mauvais code existe et il n'a pas grand-chose à voir avec le format.

La bonne partie est que la plupart d'entre eux sont mauvais pour une très bonne raison, et ces raisons sont généralement quantifiables et explicables. Donc, de manière non conflictuelle, expliquez les raisons. Dans de nombreux cas, vous pouvez même donner à l'auteur des scénarios où les problèmes deviennent évidents.

Je ne suis pas le développeur principal de mon projet et ne peux donc pas imposer de normes de codage, mais j'ai constaté qu'un mauvais code provoque généralement un problème plus tôt que tard, et quand il le fait, je suis là avec une idée ou une solution plus propre.

En n'intervenant pas à l'époque et en adoptant une approche plus naturelle, j'ai gagné plus de confiance avec le responsable et il se tourne souvent vers moi pour des idées et m'inclut dans la conception architecturale et la stratégie de déploiement utilisées pour le projet.

Les gens qui écrivent du mauvais code ne sont qu'un symptôme d'ignorance (ce qui est différent d'être stupide). Voici quelques conseils pour traiter avec ces personnes.

• L'expérience des gens laisse une impression plus forte que ce que vous direz.
• Certaines personnes ne sont pas passionnées par le code qu'elles produisent et n'écouteront rien de ce que vous dites
• La programmation en binôme peut aider à partager des idées mais à changer qui conduit ou ils vérifieront simplement les e-mails sur leur téléphone
• Ne les noyez pas trop, j'ai trouvé que même l'intégration continue devait être expliquée plusieurs fois à certains développeurs plus âgés
• Redonnez-leur de l'excitation et ils voudront apprendre. Cela pourrait être quelque chose d'aussi simple que de programmer des robots pour une journée
• FAITES CONFIANCE À VOTRE ÉQUIPE, les normes de codage et les outils qui les vérifient au moment de la construction ne sont souvent jamais lus ou ennuyeux.
• Supprimez la propriété du code, sur certains projets, vous verrez des silos de code ou des collines de fourmis où les gens disent que c'est mon code et que vous ne pouvez pas le changer, c'est très mauvais et vous pouvez utiliser une programmation par paire pour le supprimer.

Au lieu de leur faire écrire du code, demandez-leur de maintenir leur code.

Jusqu'à ce qu'ils doivent maintenir leur tas de spaghettis fumants, ils ne comprendront jamais à quel point ils sont mauvais au codage.

Personne n'aime écouter quelqu'un dire que son travail est nul, mais toute personne sensée apprécierait le mentorat et les moyens d'éviter un travail inutile.

Une école d'enseignement dit même qu'il ne faut pas signaler les erreurs, mais se concentrer sur ce qui est bien fait. Par exemple, au lieu de signaler que le code incompréhensible est mauvais, vous devez indiquer où leur code est particulièrement facile à lire. Dans le premier cas, vous amenez les autres à penser et à agir comme des programmeurs de merde. Dans le dernier cas, vous vous apprêtez à penser comme un professionnel qualifié.

J'ai un senario similaire avec les gars avec qui je travaille .. Ils n'ont pas autant d'exposition au codage que moi, mais ils sont toujours utiles au codage.

Plutôt que de laisser les faire ce qu'ils veulent et de revenir en arrière et d'éditer le tout. Je les assieds habituellement et leur montre deux façons de faire les choses. De cette façon et de ma façon, nous discutons des avantages et des inconvénients de chaque méthode et arrivons ainsi à une meilleure compréhension et à une meilleure conclusion sur la manière de procéder.

Voici la partie vraiment excitante. Parfois, ils poseront des questions auxquelles même je n'ai pas de réponses, et après la recherche, nous obtenons tous un meilleur concept de méthodologie et de structure.

1. Discuter.
2. Montrez-leur pourquoi
3. Ne pensez même pas que vous avez toujours raison .. Parfois même, ils vous apprendront quelque chose de nouveau.

C'est ce que je ferais si j'étais toi: D

Probablement un peu tard après l'effet, mais c'est là qu'une norme de codage convenue est une bonne chose.

Je crois franchement que le code de quelqu'un est meilleur quand il est plus facile de changer, déboguer, naviguer, comprendre, configurer, tester et publier (ouf).

Cela dit, je pense qu'il est impossible de dire à quelqu'un que son code est mauvais sans avoir d'abord à lui expliquer ce qu'il fait ou comment quelqu'un est-il censé l'améliorer par la suite (comme créer une nouvelle fonctionnalité ou le déboguer).

Ce n'est qu'alors que leur esprit se brise et que n'importe qui pourra voir que:

• Les changements de valeur des variables globales sont presque toujours introuvables
• Les énormes fonctions sont difficiles à lire et à comprendre
• Les modèles facilitent l'amélioration de votre code (tant que vous respectez leurs règles)
• ( etc...)

Peut-être qu'une session de programmation par paire devrait faire l'affaire. Quant à l'application des normes de codage - cela aide, mais elles sont trop loin de définir vraiment ce qu'est un bon code.

Vous voulez probablement vous concentrer sur l' impact du mauvais code, plutôt que sur ce qui pourrait être rejeté comme étant simplement votre opinion subjective de savoir si c'est un bon ou un mauvais style.

Renseignez-vous en privé sur certains des «mauvais» segments de code en pensant qu'il s'agit en fait d' un code raisonnable (peu importe votre prédisposition) ou qu'il existe peut-être des circonstances atténuantes. Si vous êtes toujours convaincu que le code est tout simplement mauvais - et que la source est en fait cette personne - allez-vous-en. Plusieurs choses peuvent se produire: 1) la personne remarque et prend des mesures correctives, 2) la personne ne fait rien (est inconsciente ou s'en fiche autant que vous).

Si # 2 se produit, ou # 1 ne se traduit pas par une amélioration suffisante de votre point de vue ET qu'il blesse le projet et / ou vous affecte suffisamment, alors il peut être temps de lancer une campagne pour établir / appliquer des normes dans l'équipe. Cela nécessite l'adhésion de la direction, mais est plus efficace lorsqu'il est provoqué par la base.

Bonne chance avec ça. Je sens ton frère de douleur.