TracEffectiveWork – Диспетчерський зв’язок

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

Рекомендації щодо роботи з тикетами

Відкриваючи тикет, надавайте йому відповідний тип

Існує кілька типів тикетів: "баг", "покращення" і "завдання". Створюючи тикет, вибрати відповідний тип:

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

Створюючи тикет із типом "баг", опишіть подробиці

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

Додайте ключові слова

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

Закриваючи тикет, вказуйте відповідну резолюцію

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

Не закривайте тикет із резолюцією fixed, якщо виправлення ще не внесено до репозиторію

Краще виправити баг і забути закрити тикет, ніж закрити тикет авансом і потім забути виправити баг.

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

Закриваючи тикет із резолюцією fixed, вказуйте номер ревізії, в якій виправлено виправлення

Зручно робити посилання на тикети прямо у процесі комміту, як описано нижче.

Закриваючи тикет із резолюцією duplicate, вказуйте номер тикета, який був дубльований

Це дозволить одразу перейти до опису спочатку відкритого тікету.

Якщо не вдалося відтворити описаний у тикеті баг, не закривайте тикет відразу

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