Полезно ли отслеживать историю задач и ошибок в проектах, разработанных одним человеком?

Question

У меня есть trac, настроенный для моих частных и рабочих проектов, и у меня есть возможность определять задачи или описывать ошибки там. Поскольку большую часть времени я работаю над этими проектами в одиночку, я обычно решаю написать списки TODO на листах бумаги. Когда задание выполнено, я просто вычеркиваю его из листа. Когда полная страница задач завершена, лист отбрасывается.

Я знаю, что мог связать SVN-коммиты и отслеживать заявки, указав номер заявки в журнале коммитов, но для меня кажется более практичным просто написать полное объяснение в сообщениях коммитов. Что я пропускаю, не отслеживая задачи и ошибки?

Только для статистики, за последние 4 года интенсивного использования svn мне приходилось возвращаться назад к своим собственным проектам примерно 4 раза и просматривать историю сторонних проектов около 20 раз, но ни одного случая не было. когда мне пришлось проверять уже закрытые задачи и ошибки в моей собственной разработке.

Answer 1

Я не вижу убедительных причин использовать инструмент отслеживания для разработки для одного человека.Однако позвольте мне перечислить мои мысли и позволить вам принять решение.

• Если конкретная ошибка / функция имеет несколько коммитов.Если это записано в инструменте отслеживания, это поможет сгруппировать несколько коммитов в одном месте.Это также поможет реализовать подобную функцию в будущем.Тем не менее, вы можете утверждать, что в самом сообщении о фиксации вы можете получить подробные сведения о фиксации.

• При работе над множеством ошибок / функций.Есть несколько редакторов, которые позволяют вам сохранить состояние, в котором вы работаете в редакторе.Например, если вы отлаживаете ошибку, которая включает 3 разных файла, то при открытии этой конкретной ошибки все три файла будут открыты со всеми точками останова и всем, что у вас было.Это позволит вам выполнять многозадачность между различными ошибками / функциями.

• Используя инструмент отслеживания, вы можете получить статистику, такую ​​как скорость, с которой происходят исправления ошибок, записывать этапы, сопоставлять различные ошибки.

• Инструментом отслеживания можно поделиться с клиентами для создания ошибок.Кроме того, они могут знать статус ошибок на том же уровне.

• Кроме того, отслеживая в электронном виде, было бы легче редактировать его, когда у вас есть обновления, которые станут беспорядком, поддерживающим их вбумаги в долгосрочной перспективе.

Answer 2

Я работаю один над некоторыми клиентскими проектами, использующими Trac, и я добавил плагин синхронизации и оценки, а также плагин TracBurndown. Затем я могу ввести требования / изменения клиента в виде билетов с приблизительным временем работы над этим вопросом.

Для определенного этапа я могу с помощью нажатия клавиши увидеть, сколько часов работы у меня осталось до того, как я закончу, и это отображается в виде графика, который иногда увеличивается (!) (То есть обнаружение новых дефектов / требований, быть исправлено, чтобы завершить другой билет).

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

Answer 3

Я использую Trac, даже для своих проектов с одним человеком.Вехи и приоритеты помогают понять, над чем я должен работать сейчас и над чем я должен работать позже.И когда проекты прерываются «реальной жизнью» на несколько месяцев, эта запись помогает освежить мою память о том, что я делал и почему.

Что касается отслеживания истории билетов, выкогда-нибудь была ошибка или функция, которую вы хотели сделать, но после некоторой работы над ней обнаружилось, что это вообще плохая идея?Это не обязательно приводит к сетевому изменению дерева исходных текстов, но запись этой информации в трекере ошибок помогает вам, когда вы потом задумываетесь, почему функция, над которой вы работали в прошлом году, отсутствует в коде.1004 * По существу: Нет такого понятия, как проект с одним человеком. Всегда есть как минимум 1) ты и 2) ты на год старше.Этот второй парень знает больше, чем вы, но также забыл много вещей ...

_{Раскрытие информации: я один из разработчиков Trac}

Answer 4

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

Answer 5

JIRA вместе с websvn сообщает вам месяцы после исправления, какие файлы были затронуты с помощью полной разницы.Вы никогда не забудете проблему и будете планировать релиз практически бесплатно.По мере отслеживания времени ваши оценки улучшатся, что сделает разработку более предсказуемой.