Comment dire à votre patron que son style de programmation est vraiment mauvais?
Je suis étudiant et pendant mon temps libre, je travaille pour une grande entreprise en tant que Java. Le travail est bon, mais le problème est que mon patron écrit du code très étrange. Je ne veux pas me plaindre, mais certains problèmes sont à mon avis vraiment étranges. Par exemple:
il ne connaît aucun booléen. Toutes les conditions booléennes sont des chaînes appelées "YesOrNo" puis dans la condition qu'il utilise si (YesOrNo == "Yes")
il y a beaucoup de caractères très étranges dans les noms de méthodes et les variables comme é õ ô ou è
toutes les boucles sont des boucles infinies dans le style de for (;;). Ensuite, à la fin de la boucle, la condition est testée et si les conditions sont remplies, rompez; est appelé.
Je ne sais pas si je dois lui dire que je pense que ce n'est pas une bonne pratique, car il est mon patron et décide comment et quoi faire. D'un autre côté, certains de ses exemples sont vraiment très étranges.
Des conseils sur la façon de faire face? Et est-ce seulement moi qui pense que c'est un mauvais style?
Demandez-lui de vous expliquer son code
Dites-lui que vous n'avez jamais vu X programmé de cette façon auparavant et demandez-lui pourquoi il le code de cette façon. Montrez-lui la façon dont vous le codez et dites pourquoi vous le faites de cette façon (meilleures pratiques, meilleures performances, moins de risques d'erreurs, plus facile à lire/à gérer pour les autres programmeurs, etc.).
Assurez-vous de préparer tous vos arguments à l'avance et de vous concentrer sur les raisons pour lesquelles votre méthode est la meilleure plutôt que sur les raisons pour lesquelles sa méthode est la pire. Ensuite, voyez s'il soutient toujours sa méthode par rapport à la vôtre.
S'il est ouvert à l'amélioration, il changera probablement sa façon de coder. S'il préfère toujours utiliser son style de codage par rapport au vôtre, il est peu probable que vous changiez son opinion.
Promouvoir l'utilisation d'outils automatisés d'analyse statique et de vérification de style tels que les linters et les recherche de bogues (dans la langue que vous utilisez). Si tout le monde dans l'entreprise commence à les utiliser (par exemple, ils sont mandatés avant les enregistrements), il n'est pas isolé.
La raison pour laquelle je suggère ceci est que:
1) Les gens préfèrent généralement censurer les outils automatisés que leurs collègues ou leurs subordonnés.
2) Ces outils couvrent de nombreuses questions qui peuvent être considérées comme un style médiocre.
3) Vous pouvez éventuellement modifier les règles en coulisses pour son mauvais style au-delà de ce qui est intégré dans l'outil. Par exemple, appliquez un certain style de variable.
4) Certaines personnes se rendent compte que leur code n'est pas si bon et commencent à prêter plus d'attention, même sur des choses non couvertes par les linters.
Un bon nombre d'entreprises très respectées (comme mon propre employeur) imposent un contrôle des peluches avant l'enregistrement. Le point de vue est que le mauvais style est une dette technique. Vous pouvez toujours utiliser le "Eh bien, si X et Y et Z le font, c'est probablement une bonne idée".
Je pense que vous ne devriez certainement pas lui dire quelque chose comme ça . De telles déclarations peuvent facilement provoquer une réaction défensive en lui, ce qui lui fermera presque sûrement toute possibilité d'apprentissage et peut même vous causer des problèmes.
Au lieu de cela, recherchez (et essayez même de créer) des occasions de discuter de manière désinvolte des problèmes de style de codage et d'idiome et mentionnez-lui les "meilleures pratiques" que vous connaissez. Bien sûr, vous devez d'abord vous assurer que ce que vous proposez est vraiment une bonne pratique largement connue et acceptée.
Essayez également de discuter des mêmes problèmes avec les autres membres de l'équipe. Il est important de comprendre le "consensus" (parlé ou non) au sein de l'équipe concernant le style et la qualité du codage . (Si tout le monde écrit du code propre et de haute qualité, votre cas est très différent de celui si le reste du groupe est composé de vrais programmeurs qui écrivent fièrement des programmes FORTRAN dans n'importe quelle langue.) Ils peuvent également en dire plus sur le contexte historique du projet et le style de codage de votre patron, qui vous aide à mieux orienter vos efforts.
Une autre façon est de lui demander de commander Java efficace pour vous, car vous sentez que vous en avez besoin pour devenir un meilleur programmeur. (Si vous ne l'avez pas encore lu, vous en avez réellement besoin.) Ensuite, vous pouvez lui parler des merveilleuses solutions et pratiques de ce livre.
S'il est disposé à s'améliorer, il prendra vos suggestions (et le livre). Sinon, vous pouvez vous retirer sans perdre la face et sans forcer votre relation.
Si votre patron est un mec cool, demandez-lui simplement: "Mec, WTF?"
Dans tous les cas où vous pensez que "le mien est meilleur", ne dites jamais à quelqu'un que vous pensez cela, montrez-le-lui.
Je le répète, MONTREZ, ne dites pas.
Tu sais que dire des actions, plus fort, des mots ... c'est vrai.
Quelle est la position exacte de votre patron? Est-il développeur, responsable technique? Combien d'autres développeurs y a-t-il dans l'entreprise? L'entreprise a-t-elle des normes de codage et des revues de code?
Il est peu probable que votre patron change ses mauvaises habitudes (à mon humble avis), mais vous pourrez peut-être utiliser un groupe de pairs ou les normes de l'entreprise pour l'influencer. Si son code fait suit les normes et que les pairs sont tous les mêmes, alors vos options sont limitées.
Voici ma recommandation:
- Exposez bien votre cas.
- Si votre manager n'est pas réceptif * à votre point de vue et que vous sentez que vous avez raison, cherchez des pâturages plus verts et ne faites aucune excuse.
Je vous recommande de chercher des pâturages plus verts pour trois raisons:
- À long terme, il est nuisible à la carrière d'un programmeur de perpétuer de mauvaises pratiques. La perpétuation des mauvaises pratiques engendre de mauvaises habitudes.
- Une boutique de programmation qui n'est pas réceptive à d'autres points de vue étouffe l'imagination.
- Lorsque vous savez que vous perpétuez de mauvaises pratiques et que votre équipe n'est pas réceptive à des points de vue alternatifs, votre moral ne peut que couler, ce qui rendra votre vie misérable. Alors, quittez dès que possible.
* Distinction importante: Attendre que quelqu'un soit réceptif à votre point de vue n'est pas la même chose que s'attendre à ce que quelqu'un donne à votre point de vue. J'apprécie toujours les gens qui considèrent mon point de vue, alors que j'ai peu de respect pour les gens qui sont doux et cèdent à mon point de vue sans raison suffisante ou preuves à cet effet.
Les actions parlent plus fort que les mots:
Une approche différente:
- Vous devez conduire par exemple.
- Assurez-vous que les projets que vous faites sont les meilleurs que vous pouvez faire.
- Vous devez Excel en termes de performances, moins de bugs, etc.
- Une fois que vous pouvez démontrer que votre approche et votre style sont meilleurs que votre patron, à moins qu'il ne soit très arrogant, je pense que naturellement cette personne suivra ce qui fonctionne le mieux.
Je lui donnerais juste des pointeurs à petites doses, quand vous le voyez faire quelque chose de "mauvais"
"Hmm, découvrez cette approche pour cela {montrant son écran}, j'aime le faire de cette façon à cause de bla bla bla."
Faites ceci Pas plus d'une fois tous les deux jours. S'il n'accepte pas votre suggestion, ne la mentionnez plus jamais (pendant quelques semaines). Quelques-uns resteront. Et il s'améliorera lentement.
Demandez à votre patron de comparer avec une autre façon dont vous avez appris. Il peut avoir une raison légitime. Tu ne le sauras pas avant d'avoir demandé. Il peut y avoir une ancienne norme de codage qu'elle essaie de maintenir ou elle ne s'en soucie pas. Ne donnez aucune indication que vous pensez que le patron se trompe automatiquement. Oh, et faites-le en privé. Ceci est à des fins éducatives.
Ça dépend. Si le code que vous examinez est un nouveau code, demandez à avoir des révisions de code car cela vous aidera à "vous mettre à jour" et cela montrera que vous êtes intéressé à apprendre. Le patron peut trouver cela utile car cela lui montrera que vous cherchez à faire la bonne chose. Si c'est un ancien code que vous avez rencontré et que vous êtes obligé de le maintenir, assurez-vous de faire une refactorisation lente. Une déclaration de type ici et là tout en poursuivant la tâche à accomplir. Maintenant, le problème ici est que la chaîne YesOrNo peut prendre d'autres valeurs telles que Maybe, ce qui peut entraîner un code cassé si vous ne faites pas attention.
La première chose que je ferais serait de découvrir comment il réagit aux critiques. Si j'étais le patron - eh bien, je ne ferais rien de mal, n'est-ce pas? - Je préférerais qu'on me le dise en face, tout d'un coup mais avec respect. Selon le tempérament et la culture, votre patron peut être différent.
Mais la plupart d'entre eux ont besoin de respect. Une bonne façon de montrer que vous le respectez est ce qui a été suggéré auparavant: vous expliquez ce que vous voulez dire, mais laissez-lui la décision: "C'est ma raison, mais j'ai peut-être supervisé quelque chose. Après mon explication:"
if (YesOrNo == "Yes")
if (YesOrNo == "yes")
if (YesOrNo == "YES")
if (YesOrNo == "oui")
if (YesOrNo.equals ("Yes"))
if ("Yes".equals (YesOrNo)) // might be null
"qu'est-ce que vous suggérez?"
Et vous pouvez demander une métaquestion avant: "M. X, si j'ai trouvé quelque chose dans votre code, qui est communément rapporté comme une pratique améliorable - comment dois-je vous le signaler? Tout à la fois, ou étape par étape? Ou devrais-je éviter de le mentionner à tout prix? Améliorer silencieusement le code? "
Cela dépendrait de ma relation quelle formulation je choisirais et quelle approche.
Votre patron ne sait pas programmer et il ne devrait pas le faire. Mon expérience m'a dit que supposer que quelqu'un appelé patron est également plus expérimenté ou meilleur que vous est une erreur. Il peut être meilleur dans d'autres choses, mais le point de gestion et de hiérarchie est de déléguer les choses à la personne la plus appropriée. Un patron est quelqu'un qui a eu la chance de démarrer une entreprise, ou qui a fini par occuper un poste de gestion pour ses compétences en gestion, pas nécessairement pour ses compétences en programmation.
J'ai eu un patron qui a prétendu avoir installé un ordinateur alors qu'il était connecté à un générateur électrique à essence, car il a affirmé que des pirates pouvaient entrer via le réseau électrique alors que la machine n'était toujours pas protégée. J'ai arrêté immédiatement. À l'époque, j'ai appris une leçon précieuse: le patron n'a pas toujours raison, et parfois, arrêter est la seule réponse valable.
Donc, pour revenir à votre cas, vous pouvez avoir un cas où seule la recherche d'un autre emploi (oui, crise, yadda yadda ... je sais) peut être le meilleur remède. Ne perdez pas votre temps précieux.
Essayez de lui montrer de courts exemples de code provenant de sites/lieux/livres de bonne réputation, etc.
Je vis dans l'industrie où je ne trouve pas les erreurs de mon patron. Donc, mieux, je générerais les cas dans lesquels des erreurs apparaissent dans le code et lui laisserais voir l'erreur, que je lui suggérerais les modifications requises et la raison possible [dans votre cas, vous êtes sûr de la raison ..: - D] de l'erreur. Tout développeur, bon ou mauvais, n'acceptera pas l'erreur tant qu'il n'aura pas vu le bogue.
J'ai déjà eu un gros problème avec un style de boss.
Il y a deux problèmes avec cela. Tout d'abord, je ne pense pas l'avoir jamais dit à son visage, mais j'imagine qu'il savait. Il est resté professionnel, je ne l'ai pas fait, IOW.
Deuxièmement, il y avait des raisons pour ce qu'il a fait, et il m'a juste fallu du temps pour comprendre à quel point mes "solutions" étaient trop complexes et désagréables.
Sur les trois points de la question, les signes diacritiques ne sont pas étranges pour tout le monde, et même si je n'utiliserais pas cela pour la boucle, je suis irrité par la famille C ... tandis que la syntaxe et la façon dont cela ne correspond pas mon style d'indentation, donc je peux peut-être voir d'où il vient.
Même le booléen pourrait avoir une explication en termes d'habitudes apportées par une autre langue (ce qui n'est pas une justification, bien sûr).
Je suppose que cela pourrait fonctionner -
- Demandez à votre responsable de revoir votre code qui ne contient aucune des erreurs qu'il commet.
- Ensuite, voyez si votre manager vous demande pourquoi ne pas le faire "à sa façon"
- S'il pose cette question, vous pourriez lui demander pourquoi ce serait une meilleure façon.
De cette façon, vous apprenez pourquoi il pense que son chemin est correct.
Je suis passé par là avant. J'étais tout droit sorti d'Uni et après environ un an de travail pour un gars, j'ai réalisé que j'en savais beaucoup plus que lui sur la programmation, mais c'était son affaire, et il a appelé les coups de feu - et je ne voulais juste pas l'offenser en tous cas! J'ai décidé que la meilleure façon de le contourner était de discuter des avantages d'avoir des conventions de codage communes à toute l'entreprise que nous devrions tous respecter également et de voir comment il a réagi. Étonnamment, il a pensé que c'était une excellente idée et m'a demandé de dresser une liste de normes que nous avons ensuite examinées ensemble et finalisées, etc.
L'important ici est que vous n'êtes qu'un faillible comme lui, et que simplement parce que certaines de ses voies sont bizarres/fausses, certaines seront meilleures que les vôtres.
D'après mon expérience personnelle, cela n'a pas fonctionné. Bien qu'il ait passé 2 jours à rechercher et à compiler un excellent doc de normes et de conventions de codage - il était déjà défini à sa manière, ne voyait pas vraiment l'avantage des conventions de codage ou de l'écriture de code qui mettait moins de pression sur le serveur, ce qui rendait nos travaux plus rapide et plus facile, et réduire les coûts.
Finalement, je suis parti pour trouver un endroit qui prenait le développement un peu plus au sérieux. Ce n'était pas si mal, car les recherches que j'ai faites sur les conventions de codage aident vraiment à ce jour.