Чи повинні розробники вводити помилки в систему відстеження помилок?

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

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

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

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

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

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

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

Ви повинні ввести помилки в системі відстеження помилок в обох випадках:

• коли помилка стосується безпосередньо коду, над яким ви працюєте,

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

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

Це також пояснює, чому фрілансери повинні використовувати як систему контролю версій, так і систему відстеження помилок: ці два інструменти не тільки для команд.

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

Причини не вступу:

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

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

Рішення не має чіткого вирішення і передбачає компроміси.

(деякі) ПРОС

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

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

Взагалі, помилки, коли ви їх знайдете, - це взагалі хороша звичка.

(деякі) CONS

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

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

Іноді відстеження помилок - це просто не найефективніше використання вашого часу.

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

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

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

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

З часом я виявив всілякі налаштування як корисні. Наприклад:

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

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

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

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

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

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

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

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

Що з іншими розробниками? Що робити, якщо вони одночасно виправлять це по-іншому? Що робити, якщо вони виявляють подібну помилку пізніше, і все, що ти можеш зробити, - сказати "о, чорт, я знаю, у нас було щось подібне раніше - тепер що це було?"

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

Програмування принципово складна робота. Клопи складні. тому я оцінював помилку за двома факторами:

1. Як часто такі помилки можуть з’являтися знову в майбутньому? Точна чи ні ця оцінка, продовжуйте оцінювати.
2. Коли такі помилки з’являються знову, чи легко це зрозуміти? Це точно, коли ви аналізуєте цю помилку та виправляєте її.

Я б класифікував помилку на один із таких типів:

1. Ймовірно, з’явиться знову в майбутньому, і це легко зрозуміти
2. Ймовірно, з’явиться знову в майбутньому, але важко зрозуміти
3. Рідко з'являються знову в майбутньому, і їх легко зрозуміти
4. Рідко з'являються знову в майбутньому, але важко зрозуміти

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

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

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

У випадку 4 такі помилки створюють дилему. Для опису таких помилок потрібен певний час, щоб написати розроблений і зрозумілий запис. Але цей запис в майбутньому рідко використовується. Однак без записів поява таких помилок буде знову боротьбою. Наприклад, такі помилки з’являються через комп'ютерний вірус у чийсь комп’ютері.

Звичайно, ви повинні ввести це. Або, принаймні, повідомте про це своїм QA людям, якщо це ваш звичайний процес.

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

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

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

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

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

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

Для цього є ряд причин:

Пам'ять - Система дійсно навряд чи забуде помилку, будь-який даний розробник може.

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

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

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

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

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

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

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

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

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

Пункт 2 повинен бути корисним попереджувальним знаком для розробки щодо поточних завдань.

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

• Повідомлення про помилки.
• Виправлення помилок.

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

З ними можна впоратися з: Повідомлення про помилки: - помістіть його в систему, як всі кажуть.

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

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

Якщо ви щось бачите, то скажіть щось!

Я навіть вводжу звіти про помилки щодо власних модулів, тому що не хочу переривати своє поточне завдання. І я можу переконатися, що всі кроки для відтворення включені :-)

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

Я думаю, що це скоріше політичне питання, ніж питання про найкращу практику.

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

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

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

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