Должен ли я хранить списки дел в контроле источника?

У меня есть некоторые проблемы с поиском наилучшего способа хранения списков todo для программирования.Должен ли я хранить списки дел в контроле источника?

я считаю следующее: список

один Todo в системе управления версиями для каждого проекта
список мастер TODO (с общими задачами) в личной папке в системе управления версиями

Как вы находите это?

Что вы предложите?

Редактировать:

Спасибо за предложения. Я использую систему отслеживания ошибок (BugTracker.NET) для ошибок и задач, которые связаны с запросами других людей, чтобы они могли видеть статус. И я использую // TODO в коде.

У меня есть много дополнительных заметок о том, что делать. Вы порекомендовали бы также помещать это в трекер ошибок (особенно, если невозможно поставить их как // TODO в код)?

источник

2009-03-12 Ole Lynge

является задачи int для кого-то или для вас? –

@JB King: Задачи в основном предназначены для меня; но некоторые могут быть и для других. –

Почему вы не используете систему отслеживания ошибок?

примеры: Bugzilla Mantis Trac

и многие другие ...

источник

2009-03-12 13:21:47 chburd

http://ifdefined.com/bugtrackernet.html - отличный бесплатный. – NikolaiDante

trac, mantis, bugzilla - все хорошо. Вы также можете классифицировать TODO и ошибки (и потенциально связать их) – basszero

Bugzilla - это с открытым исходным кодом и написан на C#, если вы хотите расширить функциональность. Мы использовали его внутренне более года для наших работ по техническому обслуживанию и не испытывали серьезных проблем с ним. –

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

источник

2009-03-12 13:22:27 leppie

Я хотел бы использовать http://rememberthemilk.com или http://basecamphq.com

источник

2009-03-12 13:23:21

Система слежения ошибки является важным инструментом развития.

У вас также может быть простой веб-список Todo, такой как RtM.

Наконец, вы также можете использовать // TODO «закладки» в своем коде, поскольку IDE предоставляет функции, чтобы их легко найти.

источник

2009-03-12 13:23:41 romaintaz

Я использую OnTime2008, у которого есть бесплатная версия для одного разработчика (до 5 клиентов) для отслеживания моих проектов разработки. Бугзилла была бы еще одним хорошим подходом. Не уверен, что я хочу отслеживать изменения в моем списке «todo», так как мне никогда не нужно будет отбрасывать эти изменения, я хочу, чтобы все записи были записаны, бородавки и все!

источник

2009-03-12 13:24:12 Lazarus

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

Хорошим примером является Doxygen.Учитывая TODO в коде:

// TODO: fix potential non-assigment of var 
int my_var;

Doxygen сможет вытащить эту информацию (вы даже можете настроить фильтры для произвольных аннотации, как FIXME BUG LOOK_HERE и так далее) и а) оставить запись Todo для конкретного class/interface и b) составить список todos для всего проекта.

Кроме того, ваши тодо и списки дел будут контролироваться версиями, а списки (то есть документация) легко сгенерированы с нуля.

Итак, подведем: Комбинация Doxygen, система SCM (any будет делать) и bugzilla получите вас и работает в кратчайшие сроки.

Update: Проверьте this git hook, что создает проблемы GitHub из несделанных в ваших возвратах

И общую записку к вопросу о том, не используя несделанные в вашем коде есть хорошая вещь (TM): Глупый с инструментом все еще дурак.

источник

2009-03-12 13:26:54 Steen

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

@ v.oddou: вся эта схема (довольно простая) заключается в том, что препятствие для пересмотра каждой проблемы остается низким. Если один todo требует крупного рефакторинга, я думаю, что это здорово, что проблема сохраняется в свете. Необходимость рефакторинга не исчезнет только потому, что TODO не маркирует его. – Steen

Обычно я думаю о предметах TODO, пока я кодирую. Часто, чтобы не прерывать мой поток мышления, я быстро вложу комментарий // TODO: комментарий, который быстро описывает то, что я думал, а затем продолжаю кодирование.

Важно не потерять тот факт, что что-то нужно сделать!

Позже я вернусь и создаю билет в своем программном обеспечении для отслеживания проблем .. вы используете программное обеспечение для отслеживания проблем? :) После этого TODO можно удалить из кода.

Попробуйте использовать согласованный тег комментария, чтобы вы могли легко grep их позже (текстовый поиск).

Многие среды разработки распознают определенные теги и помогают находить и управлять ими.

Не бойтесь помещать их в код и старайтесь не поддерживать две разные копии одного TODO.

источник

2009-03-12 13:27:28

Один список дел в исходном контроле для каждого проекта. С небольшим вниманием это станет вашим Scrum burndown данными. Небольшая вырезка и вставка создают диаграмму для управления.
Явные комментарии TODO в коде - эти должны соответствовать списку задач. Важное значение имеет периодическая ручная синхронизация и приоритизация.
Bugzilla для отслеживания ошибок (отличного от прогнозного списка задач)

источник

2009-03-12 13:27:34

Если вы используете TFS, вы получаете возможность использовать рабочие элементы для представления Todo элементов списка. Они могут быть отнесены к людям, связанный с возвратами, есть детали, прикрепленных к ним, и т.д.

источник

2009-03-12 13:38:22

Я люблю Basecamp HQ

Вы можете контролировать много вещей оттуда в отношении управления проектами.

Я бы порекомендовал этот сайт.

источник

2009-03-12 13:52:41

Да, если у вас нет системы отслеживания проблем. Удостоверьтесь, что он находится в текстовом формате (проблемы, связанные с новой строкой), поэтому каждый может редактировать-commit-объединить файл в одно и то же время.

В противном случае просто получите трекер.

источник

2009-03-12 20:55:19 cherouvim

В Eclipse (для Java), есть очень красивый вид, который позволит вам управлять Todos:

посмотреть все из них, независимо (открытого) проекта они находятся на
имеет три уровня приоритета для них
использовать несколько ключевых слов, означающих разные вещи для своей команды (например, FIXME может быть актуальным с высоким приоритетом, ПРОДЛИТЕ может быть будущей возможностью расширения с низким приоритетом и т.дом ..)

источник

2009-10-02 13:07:48 KLE

Должен ли я хранить списки дел в контроле источника?

ответ

Смежные вопросы