Чи розумно наполягати на відтворенні кожного дефекту, перш ніж поставити діагноз та виправити його?

Я працюю в компанії програмного продукту. У нас є великі клієнтські підприємства, які реалізують наш продукт, і ми надаємо їм підтримку. Наприклад, якщо є дефект, ми надаємо виправлення тощо. Іншими словами, це досить типова настройка.

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

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

Мені розробка абстрактного плану (програмного коду), а не відчутного, видимого прояву (відтворення часу виконання) здається важким, тому я хотів задати загальне запитання:

Чи розумно наполягати на тому, щоб відтворити кожен дефект і налагодити його, перш ніж поставити діагноз та виправити його?

Або:

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

Налагодження для Sissies?

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

Не в останню чергу, якщо ви згодні зі мною:

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

Чи розумно наполягати на тому, щоб відтворити кожен дефект і налагодити його, перш ніж поставити діагноз та виправити його?

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

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

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

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

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

Тому що якщо вони ніколи не відтворювали помилку, вони не можуть точно знати, що вона виправлена. І якщо клієнт повертається і скаржиться, що помилка все ще є, це не є гарною справою. Зрештою, вони платять вам великі $$$ (я припускаю), щоб вирішити цю проблему.

Якщо ви не зможете усунути проблему належним чином, ви порушили віру з клієнтом (певною мірою), і якщо на вашому ринку є конкуренти, вони можуть не залишатися вашими клієнтами.

Як вони мають намір перевірити, чи була виправлена ​​помилка? Чи хочуть вони відправити користувачеві неперевірений код і дати їм зрозуміти? Будь-яка установка тесту, на якій ніколи не було показано помилку, не може покладатися на те, щоб виявити відсутність помилки. Вам, звичайно, не потрібно відтворювати все клієнтське середовище, але вам потрібно достатньо, щоб відтворити помилку.

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

В ідеалі ви хочете мати можливість відтворити кожну помилку, щоб, принаймні, ви могли перевірити її виправлення.

Але ... Це не завжди може бути здійснено або навіть фізично можливо. Особливо з програмним забезпеченням типу "підприємство", де кожна установка унікальна. Існує також оцінка вартості / вигоди. Декілька годин перегляду коду та створення декількох здогадок про некритичну проблему може коштувати набагато дешевше, ніж те, що група технічної підтримки проводить тижні, намагаючись створити та дублювати середовище клієнта саме в надії на можливість дублювання проблема. Ще тоді, коли я працював у світі "Підприємства", ми часто просто виводили кодери та давали їм можливість виправляти помилки на сайті, оскільки не було можливості дублювати налаштування клієнта.

Отже, дублюйте, коли можете, але якщо не можете, то використайте свої знання про систему та спробуйте визначити винуватця в коді.

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

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

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

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

Працюючи в підтримці, я завжди обґрунтовано очікував, що клієнт зможе дати певний "сценарій" дій, які вони виконували, щоб послідовно відтворити помилку, а якщо не послідовно, то приклади кандидатів, які викликали помилку.

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

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

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

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

Чи розумно наполягати на тому, щоб відтворити кожен дефект і налагодити його, перш ніж поставити діагноз та виправити його?

Я кажу так, з деякими застереженнями.

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

Я був у сторони клієнтів за цим сценарієм. Я працював в урядовому офісі США, який використовував неймовірно великий кластер бази даних Oracle (кілька терабайт даних та обробка мільйонів записів на день).

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

Зрештою, вони вилетіли пару розробників до нашого місця, щоб налагодити проблему на сайті. І тоді було виявлено першопричину помилки, і пізніший патч правильно вирішив проблему.

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

Однак, умови перегонів, проблеми з одночасним корінням та інші «недетерміновані» помилки є одними з найскладніших для розробника, оскільки вони трапляються нечасто в системі з більш високим навантаженням та більш складною, ніж будь-яка копія одного розробника програму, і вони зникають, коли завдання буде повторно запущено в тій же системі в більш пізній час.

Частіше за все те, що спочатку виглядає як випадкова помилка, виявляється детермінованою причиною, що призводить до того, що помилка може бути детерміновано відтвореною, як тільки ви знаєте, як. Ті, хто спростовує це, справжні Heisenbugs (начебто випадкові помилки, які зникають при спробі тестування на них у стерильному, моніторинговому середовищі), пов'язані з термінами на 99,9%, і як тільки ви це зрозумієте, ваш шлях вперед стає більш зрозумілим; скануйте речі, які можуть вийти з ладу, якщо б щось інше було отримати слово вкрай під час виконання коду, і коли ви виявите таку вразливість, спробуйте використати його в тесті, щоб побачити, чи виявляє він поведінку, яку ви намагаєтесь відтворити.

Зазвичай у цих ситуаціях вимагається значна кількість глибокої перевірки коду; Ви повинні подивитися на код, відмовившись від будь-яких заздалегідь задуманих уявлень про те, як повинен поводитись код , і уявити сценарії, в яких він може вийти з ладу у тому, як спостерігав ваш клієнт. Для кожного сценарію спробуйте розробити тест, який можна було б ефективно запустити у вашому поточному середовищі автоматизованого тестування (тобто без необхідності нового стека VM саме для цього одного тесту), який би підтвердив або спростував, що код поводиться так, як ви очікували ( що, залежно від того, що ви очікували, підтвердить або спростує, що цей код є можливою причиною проблем клієнтів). Це науковий метод для інженерів програмного забезпечення; спостерігати, гіпотезувати, перевіряти, розмірковувати, повторювати.

Чи розумно наполягати на тому, щоб відтворити кожен дефект і налагодити його, перш ніж поставити діагноз та виправити його?

Ні, це точно не так. Це була б дурна політика.

Проблема, яку я бачу з вашим запитанням і вашою пропозицією, полягає в тому, що вони не можуть розрізнити між собою

• звіти про помилки
• збої ( помилки )
• помилки (також іноді називаються помилками )

Звіт про помилку - це повідомлення про помилку. Це говорить вам, що хтось вважає, що щось не так. Це може бути, а може і не бути конкретним щодо того, що має бути неправильним.

Звіт про помилку є свідченням невдачі.

Недостатність є випадок що - щось піде не так. Конкретна несправність, але не обов'язково з будь-якими підказками щодо того, що це могло спричинити.

Помилка може бути викликана помилкою.

Помилка є причиною невдач; щось, що можна (в принципі) змінити, щоб запобігти виникненню невдач, які він спричиняє в майбутньому.

Іноді, коли повідомляється про помилку, причина одразу з’ясовується. У такому випадку відтворення помилки було б безглуздо. В іншому випадку причина зовсім не зрозуміла: звіт про помилку не описує якогось конкретного відмови, або він є, але відмова такий, що не дає поняття, що може бути причиною. У таких випадках я вважаю, що ваша порада є виправданою - але не завжди: ніхто не наполягає на тому, щоб розбити другу космічну ракету на суму 370 мільйонів доларів, перш ніж прийняти дослідити, що спричинило збій першого (конкретна помилка в програмному забезпеченні управління).

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

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

Як і у всьому, що стосується розробки програмного забезпечення, правильна відповідь - це компроміс.

Теоретично ніколи не слід намагатися виправити помилку, якщо ви не можете довести, що вона існує. Це може призвести до того, що ви внесете непотрібні зміни у свій код, які в кінцевому рахунку нічого не вирішать. І довести це означає спершу відтворити його, потім створити та застосувати виправлення, а потім продемонструвати, що цього більше не відбувається. Твоя кишка тут спрямовує тебе в правильному напрямку - якщо ти хочеш бути впевненим, що ти вирішив проблему свого клієнта, потрібно в першу чергу знати, що це викликало.

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

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

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

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

Крім того, як би ви довели їм, що помилка виправлена, якщо ви не можете повторити дії?

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

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

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

Проблема буде в тому випадку, коли хтось із ваших колег виявить помилку з чистої долі та виправить її.

Давайте розглянемо це до крайності та припустимо, що ви знайшли помилку набагато раніше: у своєму коді, як ви писали його. Тоді у вас не виникне жодних труднощів щодо його виправлення саме там - ви бачите логічний недолік у написаному вами коді, він не робить те, що ви хотіли. Ви не відчували б потреби налаштувати ціле середовище, щоб показати, що це насправді помилка.

Зараз надходить звіт про помилку. Ви можете зробити кілька речей. Один з них - повернутися до коду і перечитати його. Тепер припустимо, що в цьому другому читанні ви відразу знайдете помилку в коді - вона просто не робить те, що ви мали намір це зробити, і ви не помітили, коли це написали. І , це прекрасно пояснює помилку, яка щойно потрапила! Ви робите виправлення. Це зайняло у вас двадцять хвилин.

Чи виправили це помилку, яка спричинила звіт про помилку? Ви не можете бути впевнені на 100% (можливо, дві помилки спричиняли це одне і те ж), але, мабуть, так і було.

Інша річ, яку ви можете зробити, - це відтворити конфігурацію клієнта, а також ви можете (кілька днів роботи), і врешті відтворити помилку. У багатьох випадках виникають проблеми із термінами та паралельністю, які означають, що ви не можете відтворити помилку, але ви можете спробувати багато часу та інколи побачити те саме. Тепер ви починаєте налагодження, знаходите помилку в коді, вкладаєте її в оточення і ви багато разів намагаєтеся повторити. Ви більше не бачите помилку.

Чи виправили це помилку, яка спричинила звіт про помилку? Ви все ще не можете бути на 100% впевнені - один, можливо, ви насправді бачили зовсім іншу помилку, яку робив клієнт, дві, можливо, ви не пробували досить часто, і три, можливо, конфігурація все-таки трохи інша, і це зафіксовано на цій системі, але не у клієнта.

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

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

Читаючи питання, я не бачу принципового протистояння між вашою позицією та вашою командою.

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

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

• Так, старший розробник повинен вміти читати код і, ймовірно, знайде причину проблеми після вмісту журналу. Дійсно, часто можливо написати тест на одиницю, який виявляє проблему після уважного ознайомлення з кодом.

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

Підсумовуючи, я б спробував обидва підходи одночасно і попросив або живу систему, яка демонструє проблему (і показує, що вона виправлена ​​після цього), або для якогось тесту на розрив блоку на проблему (а також показує, що вона виправлена ​​після виправлення).

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

Мені здається, що вам потрібна більш детальна реєстрація.

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

Особливо у складних ситуаціях / врізанні ниток або в будь-якому випадку, коли ви не можете використовувати налагоджувач, повернення на "налагодження від printf ()" може бути вашим єдиним зверненням. У такому випадку запишіть стільки, скільки зможете (більше, ніж очікуєте, що потрібно) та матимете гарні інструменти для фільтрації пшениці із пшениці.

Чи розумно наполягати на тому, щоб відтворити кожен дефект і налагодити його, перш ніж поставити діагноз та виправити його?

Оскільки ніхто ще не сказав це чітко: абсолютно немає!

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

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

І звичайно, є помилки, де, якщо ви помилитесь, клієнт втратить $ 100 000 +. А помилки, у яких клієнт втрачає $ 100 000 + за кожну годину, помилка не виправлена. Потрібно подивитися на помилку і прийняти рішення. Бланкетні твердження для лікування всіх помилок не працюють.

Дуже гарне запитання! На мою думку, якщо ви не зможете відтворити проблему, то ви не можете на 100% точно сказати, що зроблене вами виправлення не буде:

а) фактично виправити проблему. б) створити ще одну помилку

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

Якщо ви не можете відтворити помилку, а потім встановіть нову версію і підтвердите, що вона виправлена, ви не можете зі 100% впевненістю сказати, що помилка зникла.

Я кілька хвилин намагався придумати аналогію, щоб допомогти вам пояснити іншим, але нічого насправді не прийшло в голову. Вазектомія - смішний приклад, але це не та сама ситуація :-)

[помилка, пов'язана з] одночасним доступом до бази даних, кластерна реалізація, багатопотокова

Чи розумно наполягати на тому, щоб відтворити кожен дефект і налагодити його, перш ніж поставити діагноз та виправити його?

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

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

Обидві дії (перегляд та тестування коду) необхідні, і жодна не є достатньою.

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

Деякі розробники відносно кращі в одній діяльності (огляд коду та побудова тестів), ніж у інших. Ідеальний менеджер зважує ці сильні сторони при призначенні помилок. Командний підхід може бути ще більш плідним.

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