Mon collègue ne comprend pas les choses avec lesquelles il travaille. Que faire? [fermé]

J'ai passé 3 jours à déboguer un bogue très obscur dans une bibliothèque faite par mon collègue, ce bogue arrive très rarement. Après tout, j'ai trouvé que ce bug se produit en raison de l'accès inter-thread à un objet sans aucun verrouillage. En fait ce n'est pas un premier bogue de ce genre, il y en avait auparavant. Il exécute simplement ses tests unitaires, et si quelque chose échoue, il met un verrou. Et si rien n'échoue, ughm, alors son code est parfait. Il semble qu'il n'ait aucune idée de la sécurité du filetage. Je suis sûr à 100% qu'il existe de nombreux bogues similaires qui n'ont pas encore fait surface. Il semble que PM ne comprenne pas trop le filetage.
Le problème est qu'il travaille beaucoup plus de temps dans l'entreprise que moi. Quoi qu'il en soit, je ne peux pas simplement dire "ce gars est incompétent dans ce domaine", car cela vous montre toujours comme un "mauvais joueur d'équipe", etc.

Convaincre PM que pour éviter de tels bugs, le savoir-faire de l'équipe sur le filetage doit être amélioré, et dites-leur que vous êtes prêt à organiser quelque chose comme un atelier ou une présentation à ce sujet. Ne faites pas une affaire personnelle entre vous et votre collègue.

Écrivez un test unitaire qui montre le bug et demandez-lui de le corriger.

• C'est le travail d'un développeur senior d'examiner son code et de suggérer des améliorations.
• Vous n'êtes pas là pour vérifier son travail, je détesterais personnellement que quelqu'un revérifie toutes mes modifications pour voir si quelque chose s'est cassé
• S'il n'accepte pas votre conseil, c'est le travail du PM de résoudre le problème de communication.
• Le problème de thread dans un test unitaire me fait me demander si ce test est en fait un test unitaire plutôt qu'un test d'intégration ou de composant.

Je pense que votre entreprise ne devrait pas utiliser le multithreading.

Après avoir réalisé un projet massivement multithread, j'ai trouvé que deux techniques étaient essentielles pour faire fonctionner les choses. Premièrement , le code devait être écrit correctement. Chaque champ a dû être vérifié manuellement pour s'assurer qu'il a été déclaré correctement et correctement synchronisé où qu'il soit référencé. (Avertissement: je simplifie un peu les choses ici pour garder ma réponse courte - ou en tout cas, plus courte.) Deuxièmement , le code a dû être testé en l'exécutant à plat sur les machines mono et multicœurs - plusieurs minutes en utilisant 100% de chaque noyau. (Et s'il n'utilise que 2% de chaque cœur, comme c'est souvent le cas pour moi, c'est aussi un bug.)

Vous pourrez peut-être gérer cela, mais votre organisation ne le peut pas. Même s'ils ont compris le problème, ce qu'ils ne comprennent pas, ils n'ont pas l'expertise.

La plupart des langues permettent d'éviter cela. Si vous avez un lecteur de socket, qui a généralement son propre thread, demandez-lui d'obtenir les informations sur le thread principal aussi rapidement et simplement que possible. Mieux encore, recherchez les classes / fonctions système qui géreront pour vous la partie thread de la lecture. Utilisez une file d'attente qui exécute les «événements» les uns après les autres, comme le font la plupart des API GUI. (Utilisez la file d'attente d'événements de l'API GUI elle-même, d'ailleurs.) Si vous avez besoin d'un traitement parallèle, vous pouvez probablement trouver une sorte de "thread de travail" qui vous permettra de conserver les données / champs dans un seul thread, gérant tous les transferts pour vous.

Soulignez tous les dangers du multithreading. (Histoires effrayantes: mon bug préféré impliquait quelques lignes comme int i = 5; i = i * i;:, ce qui donnait iune valeur de 35. L'une que j'ai beaucoup vue était: if (thing != null) thing.reset();lancer une exception de pointeur nul.) Je pense que votre seul espoir est de leur faire comprendre qu'ils sont entrer dans un monde entier, nouveau et étrange, et qu'ils devraient peut-être faire un grand pas en arrière.

Je ne suis pas sûr de savoir comment réel multithreading devrait être manipulé. Si le travail peut être confié à une seule personne, et tout ce qu’ils font en cas d’échec, tant mieux. Mais une équipe ne sera aussi forte que son membre le plus faible, et même un bon programmeur aura du mal avec le multithreading complet. J'espère que les gens de la langue trouveront un moyen de le rendre sûr. J'ai vu des logiciels utiles. Mais je pense qu'il vaut mieux éviter le multithreading à moins que le temps d'exécution ne soit critique et qu'un bon programmeur ou une équipe éprouvée ne soit disponible.