Cacher les bugs ne vous rendra pas service à long terme et vous a en partie mis dans cette situation.

Il y a quelques pistes à emprunter potentiellement:

1. Dites-lui simplement qu'il y a un bug - L'approche amicale peut ne pas fonctionner comme il a noté que vous vous «mêlez de ses affaires». Donc, si vous dites que j'ai trouvé un bogue à cause de X, alors il peut le résoudre.
2. Tenter d'introduire des révisions de code - Si vous êtes libre de mettre en œuvre des pratiques de travail, suggérez à votre équipe de procéder à des révisions de code pour chaque archivage. De cette façon, vous pouvez réviser cet enregistrement et signaler l'erreur dans la révision.

Ne corrigez pas les bogues vous-même. S'il existe un moyen de consigner les bogues (avez-vous un outil de suivi des bogues), enregistrez-les. Il faut vraiment essayer de faire participer un manager pour s'intéresser à la qualité du code. Comme vous devez repérer / corriger le code de vos collègues, vous vous éloignez de vos tâches.

Tout le monde fait des bogues, signaler les bogues dans le code de quelqu'un, c'est comme signaler que vous avez toussé. C'est tout naturel, peu importe la façon dont nous nous préparons, vous ne pouvez pas l'éviter à 100%, donc cela ne devrait pas être un tabou.

De même, puisque tout le monde fait des bugs, il ne sert à rien de les cacher ou de ne pas en parler avec des personnes impliquées et si la direction doit connaître les bogues existants, dites-leur simplement, ne jouez pas à un jeu de blâme.

Parlez du bogue à votre collègue. Si vous vous souciez du projet et de votre intégrité en tant qu'employé, vous indiquez que vous pensez que le bogue aurait pu être évité en suivant les pratiques X, Y, vous pouvez lui demander s'il est d'accord avec vous ou non pour vous assurer que vous connaissez ses opinions. à ce sujet.

Nous avons trouvé un bogue dans A après le dernier patch, nous devons corriger C, D. Pour éviter de futurs bogues du même genre, je pense que ce serait une bonne pratique de faire X, Y, êtes-vous d'accord? Sinon, que pensez-vous que nous pouvons faire différemment pour éviter cela?

S'il n'y a pas de directives officielles, vous ne pouvez pas faire grand-chose à part essayer de suggérer de meilleures pratiques, mais s'il est absolument refuse d'écouter et vous croyez vraiment qu'il ne convient pas au projet parce qu'il ne se soucie pas en général de la façon dont il fait son travail, vous devez en parler avec votre directeur le plus proche et ensuite accepter simplement le résultat de ce que vous manager veut faire ou ne veut pas faire.

Si vous voulez que la direction se soucie davantage de la qualité du code, donnez-leur simplement des exemples sur la façon dont le non-respect de certaines pratiques pourrait et a conduit à certains bogues dans le passé, non seulement dans votre projet mais dans les autres et expliquez l'impact. Les gens ne se soucient pas des choses qu'ils ne comprennent pas, s'ils comprennent pourquoi certaines pratiques doivent être suivies, ils seront plus susceptibles de les appliquer.

Si vous ne voulez pas de discussion ouverte avec le collègue, vous pouvez utiliser ses affaires d'une manière qui déclenchera le bogue. Ce que vous faites ensuite, c'est

1. Consigner le bogue
2. Créer un cas de test
3. Corriger le bogue. Conservez le cas de test comme preuve
4. Résoudre les problèmes associés

Cela ne nous intéresse pas pour le moment, vous devriez vous concentrer sur X

C'est une critique juste que vous pourriez rencontrer pour avoir consacré des ressources à un problème qui n'est pas encore un problème, auquel cas vous voudrez peut-être abandonner les étapes 3 et 4 ci-dessus.

Parler au collègue est bien sûr la meilleure chose à faire, ma réponse offre une alternative à l'idéal.

Je pense que vous avez du mal à savoir comment dire quelque chose parce que vous vous sentez investi dans le résultat. Et à juste titre, puisque vous êtes tous les deux amis et collègues.

Mais j’ai aussi le sentiment que c’est l’un des moments où vous devez simplement lâcher prise.

Si vous appréciez votre amitié et ambiance de travail, il vous suffit alors d'accepter cet aspect de votre ami et de passer à autre chose.

Ensuite, armé de cette attitude, vous pouvez procéder à la résolution de votre problème.

Dites-le-lui clairement.

C'est parfois comme ça que je me souviens de quelque chose que j'avais appris au collège: les messages-I.

"I vous sentez ennuyé lorsque vous travaillez avec des bogues parce qu'alors je dois les corriger. J'aimerais vraiment que vous ne fassiez plus ça. "

Je me sens ... quand vous ... je veux .

Si cela ne fonctionne pas, je changerais mon approche du problème, c'est-à-dire que je correspondrais à son attitude et laisserais le passé être révolu car, après tout, on ne sait jamais vraiment qui est le meilleur ingénieur.

Avez-vous des révisions de code obligatoires ? Mon sentiment est que la réponse à cette question est non. Si c'est le cas, c'est là que de telles exceptions doivent être détectées, documentées et la modification rejetée.

Disposez-vous d'un système de suivi des problèmes tel que Jira? Vous devez documenter vos constatations, inclure les différences de fichiers et décrire comment elles introduisent un défaut. Décrivez également une série d'étapes pour reproduire le défaut causé par le changement de code mal implémenté.

Vous devez rendre votre objection aussi formelle que possible et utiliser des faits concrets et démontrables, pas des opinions. Ce n'est pas une question de "soft skills", de personnalité ou d'opinions. C'est une question d'incompétence facilement démontrable et vous devez le documenter comme tel, visible par vos supérieurs. Ils devraient choisir un plan d'action. Au cours de mes 20 années d'expérience en programmation, réprimander un collègue sur le type d'objections que vous avez et que j'ai eu à plusieurs reprises, est en grande partie inutile. Mais si vous ne pouvez pas démontrer lucidement votre cas d'une manière qui soit compréhensible pour quelqu'un qui a un pouvoir décisionnel, cela tombera probablement dans l'oreille d'un sourd.

Si vos supérieurs reconnaissent vos griefs, j'espère que vous devriez être en mesure pour présenter un cas d'implémentation de révisions de code obligatoires dans le cadre du SDLC, ce que je soupçonne qu'un de vos penchants devrait accueillir.

Cela se produit généralement dans les produits que votre entreprise n'a pas à maintenir, ou dans les projets où le chef de projet n'a pas suffisamment de compétences en programmation.La seule chose que vous pouvez faire est de signaler à votre chef de projet et à vos collègues les problèmes que vous rencontrez en maintenant ce projet sans respecter les normes de qualité, et afficher les chiffres. Si le client accepte cette perte d'argent, le plus probable est que personne ne s'en soucie, juste la personne qui fait face à l'enfer. S'il s'agit d'un projet à budget fermé ou d'un projet que vous maintenez habituellement, votre entreprise vous entendra. Le plus simple est de détecter le bogue et de l'aider jusqu'à ce qu'il en apprenne suffisamment pour résoudre les problèmes lui-même.

J'ai essayé des révisions de code sur quelques équipes, mais elles représentent un fardeau qui nécessite un soutien continu de la direction. Difficile d'obtenir l'adhésion. Et pas infaillible.

Ce qui a fonctionné pour nous, c'est que chaque développeur devait produire des tests unitaires documentés. De cette façon, ils détectent généralement leurs erreurs avant le déploiement vers les tests d'acceptation des utilisateurs.

Pour les projets complexes plus importants, nous avons eu des équipes de 2 analystes ou plus qui créent les tests unitaires pour les équipes de codage à partir de la conception / des exigences. Ils exécuteraient ces tests pour l'équipe dans son ensemble. Cela n'a pas éliminé l'exigence de test unitaire, mais a ajouté la couche nécessaire pour garantir que toutes les activités de l'équipe de développement soient maintenues ensemble.

Faire des tests unitaires documentés une partie du processus de validation du code pour chaque personne de l'équipe garantissait que le siège des développeurs de pantalons appliquait une discipline appropriée sans distinguer personne.

Les défauts de l'équipe ont chuté de 80% ou plus avec cette discipline en place. Les efforts de support sur appel ont chuté au point que nous n'avons presque jamais été appelés après un nouveau déploiement.

La complexité / formalité du plan de test a été ajustée en fonction du niveau d'impact ... souvent juste un paragraphe pour les petits changements ... mais les résultats attendus et les résultats réels devaient être documentés (captures d'écran, etc.) .

Après avoir réussi à faire appliquer cela au sein de notre équipe pendant plusieurs années, l'équipe QA a introduit cette exigence à l'ensemble du service informatique (ils l'ont fait de manière indépendante au fur et à mesure que l'AQ évoluait dans notre entreprise).

Parfois, nous effectuions des révisions de code sur de nouveaux coéquipiers ou lorsque nous travaillions avec de nouvelles technologies. Mais cela ne ressemble pas à votre problème.

Avec une nouvelle application que nous étions en train de créer, nous avons commencé à documenter et à enregistrer les plans de test unitaire afin qu'ils puissent être réutilisés. Nous utilisions Team Track pour ce faire. Ce n'était pas tout à fait le meilleur outil, mais c'était mieux qu'une bibliothèque de documents Word. Cela nous a permis de sélectionner les fonctionnalités à tester et de modifier les plans pour documenter nos modifications. Ensuite, nous pourrions parcourir tous les scénarios de test associés et documenter la réussite ou l'échec.