Rappel général: il vaut toujours mieux éviter un ton critique ou de conférence. Faites-en une simple observation ("vous semblez avoir oublié d'implémenter le hashcode ici") ou faites-en une question ("y a-t-il une raison pour laquelle vous n'avez pas implémenté le hashcode?"). Laissez leur réponse conduire la discussion sur les raisons pour lesquelles cela compte, si nécessaire, mais partez de l'hypothèse qu'ils connaissent les principes et que la bizarrerie était soit une simple erreur / faute de frappe, soit une raison rationnelle derrière elle qui peut être discutée plutôt que

Les gens écoutent mieux si vous les traitez avec respect.

Et rappelez-vous, parfois, le malentendu sera le vôtre. Vous vous embarrasserez beaucoup moins de cette façon que si vous faites une déclaration plus absolue ou didactique.

Peut-être que regarder cela d'un autre point de vue pourrait vous donner une meilleure vue.

Je suis chef d'équipe et aussi directeur dans une petite entreprise de huit développeurs. J'ai 15 ans d'expérience en programmation en Java. J'ai une nouvelle personne dans mon équipe qui est beaucoup plus jeune que moi avec seulement quelques années d'expérience.

Le mois dernier, alors que nous discutions de certains modules de code source que j'ai écrits, il a commencé à rabaisser mon code. Même s'il a beaucoup moins d'expérience que moi, il a prétendu voir des bogues dans le code qui fonctionnait parfaitement. Après une courte discussion, il me semblait que j'étais capable de lui expliquer cela.

Mais malheureusement, il ne peut tout simplement pas se reposer sur cette question. Il continue de saper mon autorité en exigeant que nous fassions tout par des manuels (comme le livre de Joshua Bloch `` Effective Java ''), même dans les cas où ce serait juste une perte de temps et n'entraînerait pas un avantage tangible pour notre produit. Comment puis-je amener ce développeur junior à faire confiance à mon expérience?

Il est difficile en tant que junior de convaincre un senior de changer ses pratiques. De plus, en tant que manager, il doit maintenir une aura de supériorité pour être capable de diriger efficacement.

Ainsi, lorsque vous souhaitez améliorer les normes de qualité dans votre lieu de travail sans l'autorisation de le faire, donnez l'exemple. Faites ce que les autres font de mal et montrez que votre chemin est meilleur car il en résulte un meilleur produit en moins de temps. Lorsque vous signalez des erreurs dans le code d'autres personnes, ne le faites pas en pinçant les fichiers de code source. Faites-le en présentant un défaut reproductible dans le produit lui-même et un moyen de le réparer en suivant les meilleures pratiques.

En passant, l'une des maladies professionnelles les plus courantes chez les programmeurs est un ego gonflé. Il en a peut-être déjà un, mais vous commencez également à montrer des symptômes des premiers stades.

Un moyen d'atténuer ce genre de problème est de «donner et recevoir». J'ai réussi à plusieurs reprises avec cette stratégie. Les gens sont plus réceptifs à vos suggestions et critiques lorsque c'est dans les deux sens. Je posais donc des questions et des conseils lorsque j'en avais l'occasion et je prenais leurs réponses au sérieux. (Pour être honnête, parfois, je connaissais déjà la réponse, mais on ne sait jamais, j'ai aussi appris des choses intéressantes de cette façon.)

Finalement, vous établissez un rapport où vous vous soutenez et les choses se passent beaucoup mieux à bien des égards. Et s'il a 15 ans d'expérience, je parie qu'il pourrait vous dire beaucoup de choses qui valent la peine d'être connues.

Je ne m'inquiéterais pas pour lui et son épaule froide, c'est assez normal après ce qui s'est passé. Selon toute vraisemblance, il aura pris en compte votre contribution et sera prudent avec vous, et vous l'avez probablement un peu contrarié. Mais ce n'est pas un concours de popularité, alors à moins qu'il ne devienne incontrôlable, donnez-lui un peu d'espace. Restez amical et solidaire et il reviendra.

Au lieu d'en faire une discussion "Je pense que vous devriez" qui est désormais claire et qui ne vous mènera nulle part, transformez-la en discussion technique.

Après avoir examiné le code J'ai trouvé un problème et j'ai écrit le test X qui le démontre.

(Vous pouvez en écrire plusieurs si nécessaire). Il appartient ensuite à l'équipe de discuter de la manière de résoudre le problème afin que votre test réussisse.

Avez-vous des rencontres matinales? ou d'autres réunions d'équipe où vous pouvez le mentionner de manière informelle.

En les adressant à tout le monde de manière totalement impersonnelle "Oh dérange, j'ai trouvé que ce problème que cette classe a implémenté équivaut à pas de hashcode, cela peut vraiment causer des problèmes si la classe est jamais utilisé dans un hashmap car seule l'identité de l'objet est utilisée comme clé "et ensuite discuter du moment où cela peut être corrigé.

Vous n'avez accusé personne d'avoir écrit du mauvais code, tout le monde sait maintenant pourquoi c'est un problème , le code est corrigé.

Soyez poli et professionnel. Soumettez un ticket pour le bogue, dans votre ticket, détaillez le problème et une solution potentielle, et laissez une ouverture pour que vous soyez contacté pour plus d'informations ou une explication du problème. En rester là. Lorsque vos tickets sont examinés, ils seront attribués soit à vous-même pour corriger le bogue que vous avez trouvé, soit au développeur d'origine. Espérons que l'autre développeur comprendra et résoudra le problème, ou reviendra vers vous pour plus d'informations. Si ni l'un ni l'autre ne se produit, alors c'est un problème de gestion maintenant.

Cette méthode n'appelle aucun développeur spécifique pour les erreurs, et permet de tenir compte du temps de réparation et peut-être même d'inclure dans une mêlée (si vous le faites cela).

Trouver des bogues dans le code d'autres personnes est une pratique courante. Chaque fois qu'un nouveau développeur entre dans un projet, il trouve des problèmes. Attribuer le blâme n'est pas important. Créez simplement un ticket et laissez les processus de l'entreprise le gérer. Les développeurs expérimentés ne devraient pas être offensés par les autres qui découvrent des problèmes dans leur code. Et s'ils le font, ils ne devraient probablement pas être des développeurs.

Je pense que Keshlam fait valoir un bon point. Il est également important de garder à l’esprit que l’équipe est propriétaire du code, et non un individu. J’éviterais donc d’utiliser le mot «Vous» lorsque vous posez des questions sur des problèmes potentiels avec le code. Vous pouvez plutôt demander

"Bonjour, j'ai remarqué que nous n'avons pas implémenté le hashcode ici, y a-t-il une raison à cela?"

Vous êtes résoudre le problème potentiel avec le code, mais aussi demander une raison possible du problème et donner au chef d'équipe l'occasion d'en faire une expérience d'apprentissage pour vous.

Quelques indications générales, mais à partir de ces informations, je pense que les points 4 et 5 pourraient être les plus appropriés:

1. Séparez le code de son auteur. Vous êtes ici pour évaluer le premier, pas le second. "Ce code est [X]" est meilleur que "Vous avez créé ce code [X]".
2. Soyez précis. Ne donnez pas de descriptions vagues pour l'ensemble de la base de code. «Des commentaires descriptifs seraient appréciés en X, Y et Z concernant le libellé de cette fonction» est infiniment plus apprécié que «Tout est grec pour moi».
3. Soyez positif aussi! le terme pour ce processus est «révision du code», et non «dépeçage verbal du code» pour une raison. Dans la plupart des revues publiées, un critique parlera des bons et des mauvais aspects d'un produit. Vous devriez faire de même.
4. Choisissez vos batailles. Ne traitez pas tout comme un facteur décisif. Si c'est un peu bizarre mais que cela fonctionne parfaitement bien, donnez-lui au mieux une note de bas de page et résolvez-le comme un `` problème mineur '' ou une `` question rapide ''. En général, si vous devez ouvrir un débogueur / décompilateur pour créer un scénario de casse, cela ne compte pas comme quelque chose de grave.
5. Assurez-vous que les choses dont vous parlez ne sont pas seulement «théoriques». Testez l'application vous-même ou parlez à l'équipe de test de quelque chose qui, selon vous, pourrait poser problème.

Écrivez un cas de test, décrivez le comportement auquel vous vous attendez et montrez que le problème rompt le test.

(O garçon, quelles choses insensées nous avons découvertes lorsque nous avons commencé à tester hashCode et est systématiquement égal dans notre projet .....)

Super bonne question. J'adore apprendre, mais quand quelqu'un me calme, je sens que je devrais arrêter. Je recommande de revoir le «style de codage» de vos collègues et d'identifier ses forces pour qu'il ne se sente pas comme si tout ce temps qu'il a passé à apprendre était inutile. PUIS identifier les OPPORTUNITÉS. De cette façon, vous affichez les forces pour l'avenir qui aident l'entreprise et travaillent également sur les «opportunités» que vous avez déjà identifiées. Je dirige des équipes en donnant un calendrier de 30-60-90 jours, puis je loue les ajustements où nous avons capitalisé sur les «opportunités». Cela fonctionne très bien et constitue un moyen équitable d'identifier les leaders par rapport aux personnes qui ne sont pas et ne devraient pas être des leaders.

Réparez-le vous-même. Créez une branche, corrigez-la, testez-la par les développeurs et si vous avez besoin d'une approbation, effectuez simplement une révision du code. Cela change le fardeau pour vous, mais vous êtes celui qui pense que c'est important, donc le fardeau retombe vraiment sur vous, même si c'est le code de quelqu'un d'autre.