Мой коллега не понимает, с чем работает. Что делать? [закрыто]

13

Я потратил 3 дня на отладку одной очень неясной ошибки в библиотеке, сделанной моим коллегой, эта ошибка случается очень редко. В конце концов я обнаружил, что эта ошибка возникает из-за многопоточного доступа к объекту без какой-либо блокировки. На самом деле это не первая ошибка такого рода, ранее были подобные ошибки. Он просто запускает свои юнит-тесты и, если что-то не получается, ставит где-то блокировку. И если ничего не получится, тьфу, тогда его код идеален. Кажется, он понятия не имеет о безопасности потоков. Я на 100% уверен, что есть много подобных ошибок, которые просто еще не появились. Кажется, PM тоже не разбирается в многопоточности.
Проблема в том, что он работает в компании гораздо больше времени, чем я. В любом случае, я не могу просто сказать «этот парень некомпетентен в этой области», потому что это всегда показывает тебя как «плохого командного игрока» и т. Д.

project-management ТИКА
источник
Что это за страна?
Это международная компания.
Тика
2
Если это действительно большая проблема, и вы на 100% уверены, что ваш коллега совершает ошибку, первым делом нужно вежливо указать на это так, чтобы ему не угрожали. Во-вторых, если ваш коллега не слушает, просто укажите на потенциальный ущерб наличными. Это то, что все менеджеры слушают, и очень внимательно при этом. Наличие проблемы с потоками, такой как вы описали, потенциально очень вредно, и если вы не уверены на 100% в своих утверждениях, продолжайте их.
NB
Вероятно, принадлежит на сайте управления проектами SE.
Бернард
1
На сайте Project Management SE отсутствует тег «Многопоточность», который должен иметь этот вопрос.
RalphChapin

Ответы:

13

Убедите PM, что для того, чтобы избежать таких ошибок, необходимо улучшить ноу-хау команды о многопоточности, и скажите им, что вы готовы организовать что-то вроде семинара или презентации по этому поводу. Не делайте это личным делом между вами и вашим коллегой.

Док Браун
источник
Я боюсь , что это не будет приветствоваться этим парнем, потому что он думает , что он является профессионалом в этой области (и сам может научить каждый). Но я могу попробовать.
Тика
Ах да, и одна большая проблема - английский не мой родной язык, я говорю не очень хорошо.
Тика
Если и ваш коллега, и премьер-министр имеют ограниченное знание потоков и безопасности потоков, то обучение, безусловно, является лучшим подходом. Дело не в некомпетентности одного парня, а в компетенции команды.
Boisvert
1
Мастерская - это то, что вы все можете использовать в своих знаниях, и все вы должны чему-то научиться. Если ваш коллега думает, что он знает что-то о потоках, возможно, вы тоже сможете кое-что узнать у него.
Док Браун
8

Напишите юнит-тест, который показывает ошибку и попросите его исправить ее.


источник
1
Он уже знает об этой ошибке. Он просто не может найти причину.
Тика
Разве вы не нашли причину в трехдневной отладочной сессии? Или я неправильно прочитал ваш вопрос?
1
@scarfridge Зависит от платформы. Для Java вы можете использовать инструментарий байтового кода или Аспектно-ориентированное программирование, чтобы вставить ожидание именно там, где проблема, (или использовать JVMTI для управления выполнением). Это можно сделать!
1
Это не только вопрос последовательности. Вовлечены многие другие факторы - какие ядра выполняют код, когда происходит GC и как он перемещает объекты, как изменения передаются из кэша одного ядра в другое и т. Д.
tika,
1
На самом деле это просто набор вызовов методов, повторяющихся миллиарды раз. Но это не имеет большого значения. Настоящая причина - доступ к объекту словаря из 2 потоков без блокировки (т.е. без барьеров памяти). Поток A создает его, поток B читает его.
Тика
4
  • Работа старшего разработчика - анализировать его код и предлагать улучшения.
  • Вы не будете там, чтобы проверить после его работы, я лично ненавижу, если кто-то перепроверяет все мои изменения, чтобы увидеть, если что-то сломалось
  • Если он не примет ваш совет, то задача PM - решить проблему со связью.
  • Проблема многопоточности в модульном тесте заставляет меня задуматься, является ли этот тест модульным, а не интеграционным или компонентным тестом.
CodeART
источник
Я понял вашу идею. Соблюдайте вашу команду.
Тика
2
Какое имеет значение, если тест, показывающий проблему, называется «модульным тестом» или «интеграционным тестом»? Вся ситуация остается прежней.
Док Браун
1
Я обеспокоен тем, что его коллега может не знать о разнице между модульным тестированием и тестированием компонентов, поэтому для решения этой проблемы может потребоваться дополнительное обучение.
CodeART
@CodeRush - я так понимаю, вы не верите в рецензирование? Что бы вам понадобилось, чтобы на самом деле оценить, что кто-то еще перепроверил ваш код (в отличие от просто сбоя в работе)?
Я понял идею, но я не видел, чтобы она работала эффективно на моих предыдущих работах. Я думаю, что отзывы от старшего разработчика - лучший механизм обратной связи.
CodeART
-5

Я думаю, что ваша компания не должна использовать многопоточность.

После выполнения многопоточного проекта я обнаружил, что два метода имеют решающее значение для того, чтобы все заработало. Во-первых , код должен быть написан правильно. Каждое поле нужно было проверять вручную, чтобы убедиться, что оно было объявлено правильно и правильно синхронизировано там, где на него ссылаются. (Предупреждение: я немного упрощаю здесь, чтобы мой ответ был коротким - или, во всяком случае, короче.) Во-вторых , код должен был быть проверен путем запуска его на одно- и многоядерных компьютерах - много минут, используя 100% каждого ядра. (И если он использует только 2% каждого ядра, как это часто делали для меня, это тоже ошибка.)

Вы могли бы справиться с этим, но ваша организация не может. Даже если они поняли проблему, которую они не понимают, у них нет опыта.

Большинство языков предоставляют способы избежать этого. Если у вас есть устройство чтения сокетов, которое обычно имеет свой собственный поток, пусть он передает информацию в основной поток как можно быстрее и проще. А еще лучше, ищите системные классы / функции, которые будут обрабатывать поточную часть чтения для вас. Используйте очередь, которая запускает «события» одно за другим, как это делают большинство GUI API. (Используйте в этом случае саму очередь событий GUI API.) Если вам нужна параллельная обработка, вы, вероятно, можете найти какой-то «рабочий поток», который позволит вам хранить данные / поля в одном потоке, обрабатывая все переносы за вас.

Подчеркните все опасности многопоточности. (Страшные истории: моя любимая ошибка включала в себя пару строк, таких как:, int i = 5; i = i * i;что привело iк значению 35. Одна из многих, что я видел, была: if (thing != null) thing.reset();создание исключения нулевого указателя.) Я думаю, ваша единственная надежда - заставить их понять, что войти в новый, странный мир, и, может быть, они должны сделать один большой шаг назад.

Я не совсем уверен, как многопоточность должна быть обработана. Если работа может быть дана одному человеку, и все, что он делает, выбрасывается, если он терпит неудачу, хорошо. Но команда будет такой же сильной, как и ее самый слабый член, и даже у хорошего программиста возникнут проблемы с полноценной многопоточностью. Я надеюсь, что люди найдут способ сделать это безопасным. Я видел некоторое полезное программное обеспечение там. Но я думаю, что лучше всего избегать многопоточности, если время выполнения не является критическим и если у вас есть хороший программист или проверенная команда.

RalphChapin
источник
2
Вы понятия не имеете, что это за компания или чем они занимаются, поэтому комментарий «Возможно, вы сможете управлять этим, но ваша организация не может» - это несколько необоснованно. Тика может работать в Microsoft. , Кто бы они ни были, многопоточность вполне может быть лучшим способом решения их проблемы; Есть много ситуаций, когда это подходит. И, кроме всего прочего, вопрос не в многопоточности, а в том, чтобы справиться с коллегой, который вызывает проблемы из-за недостатка опыта.
Анаксимандр
@anaximander: Многопоточность приводит к ошибкам, которые очень трудно воспроизвести и так сложно отследить. Чтобы создать пригодное для исправления программное обеспечение MT, вам нужно, как минимум, иметь программистов и менеджеров, которые знают об опасностях. Организация Тики явно не могла справиться с этим. Я видел, как люди, занимающиеся тестированием / QA, заставляли программистов писать звуковой код, тщательно тестируя и требуя исправлений для каждой ошибки. Это не работает с МТ. Если коллеге не хватает способностей, интереса и мотивации, держите его подальше от МТ.
Ральф Чапин
@anaximander: Наверное, у вас был лучший опыт работы с Microsoft, чем у меня. Хотя, чтобы быть справедливым, я никогда не видел ничего похожего на многопоточную ошибку от них. .... и спасибо за комментарий.
Ральф Чапин
1
Несмотря на это, когда вопрос «как мне справиться с коллегой, у которого нет опыта?», Я не думаю, что «ваша компания неправильно разрабатывает программное обеспечение» - это правильный ответ. В любой организации, какой бы обширной и знающей она ни была, всегда найдутся люди с пробелами в знаниях. Не зная, кто является организацией или что делает программное обеспечение, я не думаю, что вы можете с уверенностью сказать, что компания не знает, что они делают, или что их проблема может быть решена без многопоточности.
Анаксимандр