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

13

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.

project-management tika
la source
De quel pays s'agit-il?
C'est une entreprise internationale.
tika
2
Si c'est vraiment un gros problème et que vous êtes certain à 100% que votre collègue fait une erreur, la première chose à faire est de le signaler poliment de manière à ce qu'il ne soit pas menacé. La deuxième chose est, si votre collègue n'écoute pas, est simplement de souligner les dommages potentiels en espèces. C'est ce que tous les managers écoutent, et très attentivement. Avoir un problème de threading tel que vous l'avez décrit est potentiellement très dangereux, et à moins que vous ne soyez certain à 100% dans vos déclarations, allez-y.
NB
Appartient probablement au site Project Management SE.
Bernard
1
Le site Project Management SE ne possède pas de balise "Multithreading", ce que cette question devrait avoir.
RalphChapin

Réponses:

13

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.

Doc Brown
la source
Je crains que ce gars ne soit pas le bienvenu, car il pense qu'il est professionnel dans ce domaine (et peut enseigner à tout le monde lui-même). Mais je peux essayer.
tika
Ah oui, et un gros problème - l'anglais n'est pas ma langue maternelle, je ne parle pas très bien.
tika
Si votre collègue et votre PM ont une connaissance limitée du filetage et de la sécurité des fils, la formation est certainement la meilleure approche. Ce n'est pas l'incompétence d'un gars - c'est la compétence de l'équipe qui est le problème.
boisvert
1
Un atelier est quelque chose où vous pouvez tous mettre à contribution leurs connaissances, et vous devriez tous en tirer des leçons. Si votre collègue pense qu'il sait quelque chose sur le filetage, vous pouvez peut-être aussi apprendre certaines choses de lui.
Doc Brown
8

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


la source
1
Il connaissait déjà ce bug. Il ne peut tout simplement pas trouver la raison.
tika
Vous n'avez pas trouvé la raison de la session de débogage de trois jours? Ou ai-je mal lu votre question?
1
@scarfridge Dépend de la plate-forme. Pour Java, vous pouvez utiliser une instrumentation de code octet ou une programmation orientée Aspect pour insérer une attente exactement là où se trouve le problème (ou utiliser JVMTI pour contrôler l'exécution). C'est possible!
1
Ce n'est pas seulement une question de séquence. De nombreux autres facteurs sont impliqués - quels cœurs exécutent le code, quand GC se produit et comment il déplace les objets, comment les changements sont propagés du cache d'un cœur à un autre, etc.
tika
1
En fait, ce n'est qu'un ensemble d'appels de méthode répétés des milliards de fois. Mais cela n'a pas beaucoup d'importance. La vraie raison est l'accès à un objet dictionnaire à partir de 2 threads sans verrouillage (c'est-à-dire sans barrières mémoire). Le thread A le crée, le thread B le lit.
tika
4
  • 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.
CodeART
la source
J'ai ton idée. Obéissez à votre commande.
tika
2
Qu'importe si un test montrant un problème est appelé "test unitaire" ou "test d'intégration"? Toute la situation reste la même.
Doc Brown
1
Je crains que son collègue ne sache pas la différence entre le test unitaire et le test des composants, par conséquent, une formation supplémentaire pourrait être nécessaire pour résoudre ce problème.
CodeART
@CodeRush - Je suppose que vous ne croyez pas à l'examen par les pairs? Que faudrait-il pour que vous appréciiez réellement que quelqu'un d'autre revérifie votre code (au lieu de simplement planter en production)?
J'ai compris l'idée, mais je ne l'ai pas vue fonctionner efficacement dans mes emplois précédents. Je pense que les avis d'un développeur senior sont un meilleur mécanisme de rétroaction.
CodeART
-5

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.

RalphChapin
la source
2
Vous ne savez pas de quelle entreprise il s'agit ni de ce qu'ils font, donc le commentaire "Vous pourriez être en mesure de gérer cela, mais votre organisation ne le peut pas" est un peu infondé - pour autant que vous le sachiez, tika pourrait travailler chez Microsoft . Qui qu'ils soient, le multithreading pourrait bien être le meilleur moyen de résoudre leur problème; il y a plein de situations où ça va. Et mis à part tout cela, la question n'est pas sur le multithreading, c'est sur la gestion d'un collègue qui cause des problèmes par manque d'expertise.
anaximander
@anaximander: le multithreading produit des bogues très difficiles à reproduire et donc très difficiles à localiser. Pour produire un logiciel MT utilisable et réparable, vous aurez besoin, au minimum, d'avoir des programmeurs et une direction conscients des dangers. L'organisation de Tika ne pouvait manifestement pas gérer cela. J'ai vu des gens tester / QA forcer les programmeurs à écrire du code sonore en testant lourdement et en demandant des correctifs pour chaque bogue. Cela ne fonctionne pas avec MT. Si le collègue manque de capacité, d'intérêt et de motivation, manipulez-le en l'éloignant de MT.
RalphChapin
@anaximander: Vous devez avoir eu de meilleures expériences avec Microsoft que moi. Bien que pour être juste, je n'ai jamais rien vu de semblable à un bug de lecture mutuelle. .... Et merci pour le commentaire.
RalphChapin
1
Quoi qu'il en soit, lorsque la question est «comment gérer un collègue qui manque d'expertise?», Je ne pense pas que «votre entreprise crée un mauvais logiciel» est une réponse valable. Dans toute organisation, quelle que soit sa taille et ses connaissances, il y aura toujours des lacunes dans ses connaissances. Sans savoir qui est l'organisation ni ce que fait le logiciel, je ne pense pas que vous puissiez juger de manière fiable que l'entreprise ne sait pas ce qu'elle fait ou que son problème peut être résolu sans multithreading.
anaximander