Чи слід записувати помилку, яку я виявив і виправляв?

Я припускаю, що це звичайна ситуація: я перевіряю якийсь код, виявляю помилку, виправляю її та здійснюю виправлення помилок у сховищі. Якщо припустити, що багато людей працюють над цим проектом, я повинен спершу створити звіт про помилку, призначити його собі та посилатися на нього у повідомленні про виконання (наприклад, "Виправити помилку #XYZ. Помилка через X та Y. Виправлено Q і R ")? Крім того, я можу пропустити звіт про помилку та здійснити повідомлення з таким повідомленням, як "Виправлена ​​помилка, яка викликала A, коли B. Помилка була зумовлена ​​X та Y. Виправлено її Q і R".

Що вважається кращою практикою?

Це залежить від того, хто аудиторія звіту про помилку.

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

Невичерпний перелік причин все-таки ввійти:

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

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

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

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

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

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

Це залежить від кількох факторів.

І Пітер Б, і Калет перераховують деякі свої відповіді:

• Чи була помилка частиною офіційного випуску?
• Чи відслідковується кількість помилок / час, витрачений на них?

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

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

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

Але дозвольте запитати інше: чому б ви не записували помилку, яку ви латали?

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

У цьому випадку проблема полягає не в тому, що помилку настільки легко виправити, а в тому, що оформлення паперу займає занадто багато часу. Це справді не повинно. Для мене накладні витрати, щоб створити квиток на Джиру, натискають c, потім вводять короткий підсумок 1 рядка та натискають Enter. Опис навіть не є накладними, оскільки я можу вирізати та вставити це повідомлення у фіксацію разом із номером проблеми. Наприкінці . c <Enter>і питання закрите. Це зводиться до 5 натискань клавіш над головою.

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

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

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

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

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

Так .

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

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

Отже, коли ви зіткнулися з помилкою, у вас є два рішення:

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

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

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

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

Просто запитайте свого менеджера . Добре, що ваш менеджер або альтернативно веде проект або майстер розробки тощо, залежно від структури вашої групи.

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

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