Відповідальність за відтворення помилок

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

1. Він прав?
2. Що я можу зробити в цій ситуації? Створення одиничного тесту неможливо, оскільки це залежить від деяких випадкових тимчасових мереж.

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

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

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

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

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

Обидві сторони повинні докласти певних зусиль.

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

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

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

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

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

Це означає, що справді ви несете відповідальність за розробку відтворюваної тестової справи, ЯКЩО ВИ ХОЧЕТЕ ФІКСУВАТИ. Вам може бути байдуже, чи виправляється це, і в цьому випадку ви зробили все, що від вас може і слід очікувати. Можливо, ви хочете, щоб це було зафіксовано, але недостатньо, щоб присвятити час, щоб зробити його відтворюваним у цей час. Це цілком прийнятно.

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

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

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

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

Ви знайшли помилку, ви повідомили про це, і він обдурює це.

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

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

Увійдіть якомога більше інформації в трекер помилок і рухайтеся далі.

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

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

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

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

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

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

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

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

Якщо це не працює, наведені нижче варіанти:

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