Мій колега не розуміє речей, з якими працює. Що робити? [зачинено]

Я провів 3 дні налагоджуючи одну дуже незрозумілу помилку в бібліотеці, зроблену моїм колегою, ця помилка трапляється дуже рідко. Зрештою я виявив, що ця помилка трапляється через перехресний доступ до об’єкта без будь-якого блокування. Насправді це не перша помилка такого роду, раніше були подібні помилки. Він просто виконує свої тести на одиницю, і якщо щось не вдається, ставить десь замок. І якщо нічого не виходить, угм, то його код ідеальний. Здається, він не має уявлення про безпеку різьби. Я на 100% впевнений, що існує багато подібних помилок, які просто ще не з'явилися. Здається, Прем'єр-міністр теж не розуміє різьблення матеріалів.
Проблема в тому, що він працює в компанії набагато більше часу, ніж я. У всякому разі, я не можу просто сказати, "цей хлопець некомпетентний у цій галузі", тому що це завжди показує вас як "поганого гравця команди" тощо.

Переконайте прем’єр-міністра, що щоб уникнути подібних помилок, слід покращити ноу-хау команди щодо нитки різання, і скажіть їм, що ви готові організувати щось на зразок семінару чи презентації з цього приводу. Не робіть це особистою справою між вами та колегою.

Напишіть одиничний тест, який показує помилку, і попросіть його виправити.

• Завдання старшого розробника - переглянути його код та запропонувати вдосконалення.
• Ви там не для того, щоб перевірити його роботу, я особисто ненавиджу, якщо хтось повторно перевіряв усі мої зміни, щоб побачити, чи щось зламалося
• Якщо він не приймає ваші поради, то завдання прем'єр-міністра вирішити питання зв'язку.
• Питання теми в одиничному тесті змушує мене замислитись, чи справді цей тест є одиничним тестом, а не тестом інтеграції чи компонентів.

Я думаю, що ваша компанія не повинна використовувати багатопотокові.

Зробивши широкомасштабний багатопрофільний проект, я виявив, що дві техніки були вирішальними для того, щоб справи працювали. По-перше , код потрібно було написати правильно. Кожне поле повинно бути перевірено вручну, щоб переконатися, що воно було оголошено належним чином і належним чином синхронізовано, де б не було посилання. (Попередження: я трохи спрощую тут речі, щоб відповідь була короткою - або, в будь-якому разі, коротшою.) По-друге , код потрібно було перевірити, виправляючи його на одно- і багатоядерних машинах - багато хвилин, використовуючи 100% кожного ядра. (І якщо він використовує лише 2% кожного ядра, як це часто робив для мене, це теж помилка.)

Ви можете цим керувати, але ваша організація не може. Навіть якщо вони зрозуміли проблему, якої вони не мають, вони не мають досвіду.

Більшість мов надають способи цього уникнути. Якщо у вас є зчитувач сокетів, у якого зазвичай є своя нитка, попросіть його отримати інформацію до основного потоку якомога швидше та простіше. Ще краще, шукайте системні класи / функції, які будуть обробляти поточну частину читання для вас. Використовуйте чергу, яка виконує "події" одна за одною, як і більшість інтерфейсів API інтерфейсу. (Для цього використовуйте саму чергу подій API GUI.) Якщо вам потрібна паралельна обробка, ви, ймовірно, можете знайти якийсь "робочий потік", який дозволить вам зберігати дані / поля в одному потоці, обробляючи всі передачі для вас.

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

Я не впевнений, як слід обробляти багатопотоковість . Якщо роботу можна дати одній людині, а все, що вони роблять, викинуто, якщо вони не зможуть, добре. Але команда буде тільки такою сильною, як і її найслабший член, і навіть хороший програміст матиме проблеми з повномасштабною багатопотоковою програмою. Я сподіваюся, що люди знайдуть спосіб зробити це безпечним. Я бачив якесь корисне програмне забезпечення там. Але я вважаю, що найкраще уникати багатопотокових записів, якщо час виконання не є критичним і не буде в наявності хорошого програміста або перевіреної команди.