Як ви відстежуєте помилок у своїх особистих проектах? [зачинено]


45

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

На жаль, я починаю цікавитись, чи не є ця система нестійкою. Знайдені вами, як правило, пов'язані з фрагментом коду, над яким я працюю; помилки, які не відразу зрозуміли, як правило, забуваються або ігноруються. Я написав заяву для своєї дружини, яка мала серйозний дефект майже 9 місяців, і я забуваю виправити це.

Який механізм ви використовуєте для відстеження дефектів у своїх особистих проектах? Чи є у вас конкретна система чи процес їх визначення пріоритетів та управління ними?


Ознайомтеся з todo.ly
робота

1
Це може бути над рядком, як питання, яке faq вважає поза темою. "Яка технологія краща?"
jzd

Trello - чудовий інструмент для подібних речей, і це безкоштовно.
gahooa

Відповіді:


25

Fogbugz (безкоштовна індивідуальна ліцензія), якщо це тривалий проект чи простий у виконанні список (використовуючи завдання Google)


7
Приємно. Я не розумів, що у FogBugz є безкоштовна версія (для тих, хто її шукає).
Ерік Кінг

Простим поглядом виглядає дуже цікаво
bedwyr

Після використання FogBugz я не бачу, як хтось віддає перевагу чомусь іншому. Щоб не потрібно відслідковувати кілька облікових записів fogbugz, я просто створив для себе єдиний fogbugz: earlz.fogbugz.com
Earlz

17

Зазвичай я використовую веб-систему контролю версій (Github, Bitbucket, Redmine, Google Code, ...) для зберігання свого вихідного коду та відстеження помилок. Якщо ви думаєте, що в певному коді є помилка, ви можете створити проблему з номером редакції / списком змін / набором змін і вказати, який файл та діапазон рядків ви підозрюєте.


8

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

Нещодавно я створив сервер Redmine у своїй домашній мережі. Це "важка вага" для "команди" з одного, але я працюю над досить багатьма проектами свого часу, і, як правило, просто використовую параметри Issue Tracker + Repository, можливо, дивна сторінка вікі в складніших місцях.

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

Для проектів з відкритим кодом я просто відстежую проблеми GitHub.


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

7

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

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

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

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


Я використав MANTIS, і це приголомшливо!
робота


5

Ми використовуємо JIRA на своєму робочому місці, і я великий фанат. Багато продуктів і людей, які беруть участь, і це все добре справляється.


+1 Jira - це найкраща система відстеження проблем, з якою я зіткнувся. Легко розпочати використання, поступово використовувати більш вдосконалені функції, коли це необхідно. Досить дружній навіть для нетехнічних користувачів, щоб повідомляти про проблеми та слідкувати за ними.
Маглоб

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

4

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

Цілі за важливістю:

  1. Дозвольте ввести нове завдання / помилку якомога більше зусиль, так що я можу записати його, як тільки я помічу це чи приснився, і повернутися до кодування, перш ніж я втрачу своє місце.
  2. Спростіть переглядати проблеми та керувати ними без великого пошуку, натискання, свердління.
  3. Полегшіть зв'язок із контролем версій, щоб я згодом дізнався, які зміни були внесені для вирішення проблеми, або яке завдання чи помилка спричинили певну зміну коду.
  4. Зробити його досить просто: мінімальна установка та конфігурація та мінімальна ціна.

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

Крок 1: Отримайте проект у Bitbucket

Я використовую бітбукет для відстеження випусків і для контролю версій git (наприклад, для iOS-проекту в XCode). Я подивився на FogBUGz (про який я багато років читав на JoelOnSoftware) та GitHub та інших, але, схоже, у бітбукета є найкращі безкоштовні функції для невеликих команд.

Крок 2: Використовуйте відстеження випуску Bitbucket у проекті

Далі я налаштував відстеження проблем у тому ж проекті бітбукета. Тож мій проект тепер має сховище git та відстеження випусків.

Крок 3. Спростіть відстеження проблем!

Для цього я використовую Карти Bitbucket, які є приємним, простим переднім кінцем до питань Bitbucket. Вам просто потрібно увійти у свій обліковий запис Bitbucket і налаштувати потрібні стовпці. У мене є чотири стовпці: "Блокування", "Далі", "Помилки" та "Вирішено". (Я думаю про об'єднання помилок із "Блоком", але це не майте на увазі поки що)

Приклад карт Bitbucket (Це зображення з блогу Bitbucket Cards, а не з мого проекту, тому колонки відрізняються від тих, які я використовую)

Карти Bitbucket дозволяють вам налаштувати дуже простий фільтр для кожного списку, де ви вибираєте статус (и) та види питань, які надходять у стовпчик карт. Отже, openподібні питання про статус bugпереходять у стовпчик помилок .

Визначення стовпця (Цей з мого проекту: саме так я вибираю те, що йде у стовпці помилок)

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

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

Це піклується про мою другу мету.

Крок 4: Зв’яжіть його за допомогою контролю версій.

Проблеми з Bitbucket чітко поєднуються з контролем версій (як і для більшості конкурентів), тому коли я закінчую роботу над проблемою, я виконую це git із повідомленням на кшталт "Додано речі до Whatsit. Виправлення №245". Якщо я зроблю це, потім натискаю його, а потім перезавантажую сторінку Bitbucket Cards, я побачу, що проблема перемістилася у стовпчик «Розв’язано». Класно.

Там моя третя мета виконана.

Крок 5. Спростіть СТВОРИТИ проблеми.

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

Тепер, Bitbucket Cards дозволяє мені створювати завдання досить легко, але це лише трохи натиснути / прокрутити, щоб повністю досягти мети №1. Ви повинні натиснути Створити проблему; потім спливає модальний редактор; після введення назви випуску вам потрібно прокрутити вниз, щоб вказати вид (помилка / завдання) та пріоритет; потім натисніть кнопку створити.

Натомість я вирішив використовувати другий додаток Bitbucket під назвою taskrd .

Ви можете налаштувати taskrd, давши йому свій логін для Bitbucket, встановити його на закладку та вкладку та тримати його відкритим протягом усього дня, як і карти Bitbucket. Taskrd має набагато простіший робочий процес для додавання нового завдання, просто введіть його, додатково встановіть тип та пріоритет та натисніть кнопку Додати.

інтерфейс tasrkd (це зображення із блогу Taskrd)

Тепер можна сперечатися, що не варто докладати зусиль, щоб налаштувати Taskrd над використанням Bitbucket Cards або навіть власною системою введення питань Bitbuckets. Зрештою, із Taskrd я повинен натиснути вкладку на своєму браузері та натиснути Перезавантажити на своїй сторінці за допомогою Bitbucket Cards, щоб оновити та отримати новий випуск, який я додав у програмі Taskrd. Але насправді я вважаю, що я взагалі в режимі чи іншому: або я використовую Bitbucket Cards для організації того, що я роблю далі, або для перегляду списку помилок, або я зайнятий кодуванням та введенням завдань / помилки, як вони трапляються у мене - все в режимі швидкого пожежі. Для цього 2-го режиму роботи Taskrd чудово підходить: я просто тримаю його відкритим на окремому моніторі і швидко ввожу проблеми під час роботи.

Отже, це охоплює ціль №1.

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

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


3

Якщо ви знайомі з використанням тегів TODO в Eclipse, простим кроком буде використання Mylyn . Це найголовніше, це простий список тодо. Але він також пов'язує контекст із завданнями - натисніть на завдання, щоб активувати його, зробіть деякі речі, а потім наступного разу, коли ви активуєте його, Eclipse відкриє відповідні класи та покаже вам відповідні методи. Ще сильніше, якщо ви врешті-решт перейдете до якоїсь іншої системи відстеження помилок, Mylyn може витягувати завдання з цих систем і представляти їх у вашому IDE.

Більшість завантажень Eclipse в наші дні Мілін постачається як стандарт. Просто знайдіть у списку списку завдань і починайте додавати завдання.


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

Я використовую теги TODO, потім використовую find / grep -o, щоб скласти собі список todo.
саль

3

Я використовую ліцензію стартера на $ 10 для Джира. Це дешево, і я це вже добре знаю з роботи.


2

Як і інші, тут я використовую або текстовий файл, або помилку відслідковування помилок, вбудовану в хостинг сервісу dvcs.

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

Наприклад, один із моїх особистих проектів став помітно популярним, і створити сайт Get Satisfaction для нього дуже добре. Насправді не "відслідковування помилок", але він чудово працював для запитів про помилки / функції.


2

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

Дивіться https://stackoverflow.com/questions/773818/distributed-projectmanagement-bug-tracking та https://stackoverflow.com/questions/1851221/distributed-bug-tracker-to-go-with-dvc?rq=1 для обговорення.


1

Для своїх особистих проектів я використовую Omnifocus.

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

Я ставлюся до помилок так само, як і вимоги / особливості в більшості аспектів.


2
Thx для відповіді: Ви не хочете детальніше розглянути, як ви використовуєте його спеціально для відстеження дефектів?
bedwyr

Дякуємо за оновлення! Цікаво побачити загальний інструмент todo, який використовується для управління дефектами.
bedwyr

Примітка. Тільки для продуктів Apple
Марк C

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

1

Для особистих проектів мені зазвичай достатньо TODO-коментарів та текстового файлу з TODO та помилками тощо.


1

Я використовую власну TheKBase (оскільки я перебуваю на OSX, я користуюся нею .Net у віртуальній машині або Mono, залежно від мого настрою). Тільки для одного одночасного користувача, але: Це дозволяє кілька ієрархій, тому він переходить від менеджера завдань до менеджера інформації, не пропускаючи кроків між ними. Плюс це відкритий код на Github і безкоштовно (це очевидно, я думаю).

Для допитливих тут інструкції .


1

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


У моїх невеликих особистих проектах для мене працює список ReSharper TODO.
Ніхто

1

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

Я розглядав Manymoon, Zoho Projects, Insightly, Redmine та Assmbla. Ми будемо експериментувати з інструментом Stand Up Free Stand Up . Це дуже простий 3 інтерфейс звітності на місцях, який задає кожному члену команди 3 питання: Що ви робили минулого тижня? Що ти будеш робити на цьому тижні? Які бар'єри у вас на шляху?

Зрештою, я думаю, що я буду дотримуватися JIRA, Google Docs та інструменту Assembla Stand Up, оскільки комбінація дає мені все необхідне.


1

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

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


Trac - це кошмар для налаштування та налаштування.

1

Я використовую Trac останні кілька років. Я також використовував Bugzilla та JIRA. Мої особисті та приватні консалтингові проекти стосуються Trac просто тому, що я звик до цього, і щоб проект міг пройти в моїй персональній програмі розробки, потрібно так мало зусиль, оскільки зусилля закінчуються. У мене є trac, пов'язаний з усім, що мені потрібно, включаючи SVN або Git і Хадсон (а точніше, Дженкінс зараз).

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


Trac - це кошмар для налаштування та адміністрування.

0

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


3
Це частково проблема: ментальний список, як правило, недостатній. Багато моїх дефектів реєструються подумки, а потім втрачаються з часом, коли з'являються нові функції та вдосконалення.
bedwyr

@bedwyr, якщо ви дотримуєтесь правила виправлення всіх відомих дефектів перед застосуванням нових функцій, це не проблема.
Кевін Лаїт

@Kevin, дефекти можна знайти в попередніх випусках, коли ви працюєте над останньою ітерацією проекту. Чи відразу б ви зупинили розробку на високоприоритетній функції, щоб виправити низький пріоритет, кутовий дефект у попередній версії? Якщо ні, то як їх відстежувати? У моєму випадку ментальний список недостатній.
bedwyr

@bedwyr Добре, я думаю, це питання переваги. Я фактично виправив би цей дефект негайно, оскільки ми говоримо про невеликий проект, який займається людиною. Якби я був у великій корпоративній обстановці, інша історія.
Кевін Лаїт

0

Якщо ви використовуєте ReSharper, він має a TODO tracker, який показує вам список усіх TODOs, NOTEs і BUGs у вашому рішенні. Він також виділяє їх у вашому коді в будь-якому обраному вами кольорі. Я вважаю це дійсно корисним у власних проектах.

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.