Comment dites-vous à quelqu'un qu'il écrit du mauvais code?
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 gens avec qui je travaille ont tous des compétences diverses liées à la programmation, mais certains d'entre eux 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 médiocre. Quelle est la bonne façon de leur demander poliment ou de leur présenter d'utiliser une meilleure méthodologie, sans que cela ne se présente comme une remise en question (ou une insulte) de leur expérience et/ou de 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 ça marche? 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 que d'autres méthodes présentent des avantages. À moins que je sache 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 supposez 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 voie 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 parlez 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 voulons manipuler cela à partir d'un autre thread?
Je trouve également utile de se concentrer sur mes limitations, 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 m'embrouille 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 obtenir de l'aide pour 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 maintenable.
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" est 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-il l'emprunter?" )
Si possible, assurez-vous qu'ils comprennent que vous critiquez leur code, pas eux personnellement.
Examinez le code et commencez par consulter le code VOTRE .
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.
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]
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 à pas dire quoi que ce soit, 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 tellement 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 une clarté et une facilité de débogage. (S'il vous plaît, ne me flammez pas/ne me dévaluez pas :)) En fin de compte, j'ai vu beaucoup de très bon, efficace, code sans bogue qui utilisait des variables globales (pas mises par moi!) et beaucoup de bogué, impossible de lire/maintenir/corriger le code qui utilise méticuleusement les modèles appropriés. Peut-être qu'il y a EST une place (bien que rétrécie 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.
J'ai fait cela 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 lâche, être capable 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: https://stackoverflow.com/questions/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 donne simplement 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&R 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 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. n bon nombre d'environnements ont besoin des avantages de l'évolution, pas 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. Vous découvrirez 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 l'Edge, 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 ... vous devrez peut-être gérer cela en vous-même (en particulier dans le cadre d'un projet "amusant").
La patience. Évolution, pas révolution.
Bonne chance.
Je mets une toge et ouvre une boîte de méthode socratique.
Le méthode socratique du nom du 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 d'opposition 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 l'argument du demandeur.
J'adore le code et je n'ai jamais suivi de cours dans ma vie sur tout ce qui touche à l'informatique. J'ai commencé très mal et j'ai commencé à apprendre à partir d'exemples, mais ce dont je me souviens toujours et que je garde en tête depuis que j'ai lu le "Gang De quatre " 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 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 en binôme pour le supprimer.
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 concentrer 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 incitez les autres à penser et à agir comme des programmeurs de merde. Dans le dernier cas, vous vous apprêtez à penser comme un professionnel qualifié.
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 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.
Au lieu de leur faire écrire du code, demandez-leur de maintenir leur code.
Tant qu'ils n'auront pas à conserver leur tas de spaghettis fumants, ils ne comprendront jamais à quel point ils sont mauvais au codage.
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.
- Discuter.
- Montrez-leur pourquoi
- 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
Cela dépend totalement de la culture dans laquelle vous écrivez. Dans un projet de logiciel libre, vous leur dites qu'ils écrivent du mauvais code avec des suggestions positives, des façons de l'améliorer et des commentaires. Vous pouvez également leur envoyer un patch sur leur code.
Un e-mail amical ne fait jamais de mal non plus.
Dépend du programmeur. Certains gars aiment entendre "ça craint" parce qu'ils savaient que le code sentait mais ne savaient pas pourquoi.
D'autres programmeurs doivent être un peu plus bébés. Je trouve que leur dire que quelque chose est mauvais est bon; "ce n'est pas un bon moyen d'écrire du code" suivi d'un peu de coaching "ici, voyez si on fait ça c'est plus lisible/moins d'avertissements/peu importe". C'est la critique constructive qui aide; si vous ne pouvez pas mettre votre argent là où se trouve votre bouche et que vous le faites mieux, il vaut mieux ne pas commenter, même si vous savez que c'est mauvais.
La seule personne sur laquelle les deux approches ont échoué était un assistant d'administration stubbon qui écrivait d'énormes macros dans VBscript et faisait tout en arrière. En fait, elle a eu le culot de me dire que je ne savais rien de la programmation informatique et que je pouvais apprendre de son 1337 sk1l50rz.
Vous voulez probablement vous concentrer sur le 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 vue de la possibilité qu'il soit réellement raisonnable code, (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 n'entraîne pas 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 les 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.
Non pas que j'ajoute vraiment beaucoup à cela, mais je dois convenir que les deux choses les plus importantes à considérer dans votre approche sont d'expliquer votre raisonnement et de permettre au codeur en question d'expliquer leur raisonnement. Le mauvais code ne vient pas de nulle part (et, oui, le "mauvais code" est certainement un terme à discuter - je suppose quelque peu dans cette situation que vous êtes en mesure de définir ce qui constitue un bon contre un mauvais code).
J'ai trouvé qu'une approche interrogative et pédagogique fonctionnait bien avec mon équipe. J'essaie de ne jamais dire "fais comme ça" sans aucune discussion ni explication sur pourquoi.
Et bien que vous deviez être quelque peu sensible à ce sujet, vous ne pouvez pas enrober le problème. L'idéal est que votre équipe réfléchisse au code qu'elle écrit, non seulement en termes de ce que fait le code, mais aussi de la façon dont il est écrit.
Enfin, j'ajouterais qu'il existe de nombreux livres à explorer sur le sujet - mon préféré à ce stade est "Framework Design Guidelines" par Brad Abrams et Krystof Kwalina (et al), de l'équipe .NET BCL chez Microsoft. Il fait un travail étonnant de discuter et d'expliquer les décisions qui ont été prises, et présente des endroits où les directives n'ont pas été suivies en interne et les retombées qui en ont résulté.
D'après mon expérience, il fut un temps où nous voulions changer une application Windows en une application Web et l'optimiser, car il est plus facile de la mettre à jour et de la maintenir. Mais comme mon ami était un contributeur majeur à l'application Windows, il a refusé le changement et le reste appartient à l'histoire.
Moral: Donner plus d'importance à l'objectif des organisations qu'au sien au profit de l'optimisation du code et d'une meilleure maintenance jouera un rôle important dans tout environnement de programmation.
Devant lui juste refactoriser son code et montrer la différence entre les deux versions. Certainement, il aimera ça.
Je suggère d'adopter une approche positive de la question. Au lieu d'accuser votre (vos) collègue (s) d'utiliser un mauvais style, faites des suggestions sur le style et des directives de commentaires que toute votre équipe pourrait suivre.
Par exemple, si vous êtes principalement une boutique .NET, suggérez de respecter le style C # de Microsoft et les directives de commentaires, car cela vous mettrait davantage en conformité avec les pratiques standard de cette communauté.
Vous pouvez également indiquer certains des exemples d'adhésion à un style de code unifié - par exemple, si quelqu'un qui n'est pas familier avec la base de code le regarde, il n'a pas à déchiffrer plusieurs styles. Pensez-y comme ceci: si vous lisiez un livre et qu'il était facile de dire que chaque chapitre avait été écrit par une personne différente, pourriez-vous être confus après quelques chapitres?
Je pense que l'important n'est pas de critiquer vos collègues de manière négative. Il est préférable de vendre à quelqu'un les avantages du changement et beaucoup plus facile que de le convaincre qu'il écrit du code merdique.
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 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.
J'ai vraiment aimé réponse d'EnderMB , mais je voulais ajouter à cela:
Cultivez un environnement dans lequel la discussion sur la qualité du code est encouragée plutôt que perçue comme sensible ou taboue. Par exemple, j'ai travaillé sur un projet open source (une Python) où le nouveau code et les corrections de bugs sont fréquemment discutés avec le groupe. Non seulement il est OK de dire "hé, je pense il vaut mieux le faire de cette façon "mais c'est en fait encouragé et une partie du processus que nous utilisons pour maintenir un code de haute qualité.
Je me rends compte que tous les environnements ne sont pas propices à ce type de processus, mais cela a vraiment bien fonctionné pour nous. Chaque engagement de code ne doit pas nécessairement être une réunion de comité, mais il devrait être parfaitement acceptable pour vous de discuter de code discutable ou non optimal et de rechercher des améliorations. Après tout, un meilleur code vaut mieux pour tout le monde dans l'équipe, et un concept majeur de travail d'équipe fonctionne ensemble plutôt que comme un groupe lâche d'individus.
Probablement un peu tard après l'effet, mais c'est là qu'une norme de codage convenue est une bonne chose.
Il est important de motiver et de coacher les gens et d'être respectueux même si quelqu'un fait manifestement des erreurs. Mais il devrait y avoir un moyen non seulement d'entraîner mais aussi de déclarer que l'erreur est une erreur. Un mauvais code devrait être mieux fait. Ce n'est pas facultatif. Et l'employé doit savoir quel code est correct et lequel ne l'est pas du point de vue de son superviseur. Il est toujours censé être fait avec respect et motiver ceux qui sont tenus de s'améliorer.