Trac.

February 22nd, 2007

На мой взгляд, Trac – одна из лучших, если не самая лучшая, bug tracking система для малых и средних по размеру проектов. Особая прелесть Trac состоит в том, что она органично объединяет вики, интеграцию с Subversion и ведение списка задач/ошибок. Именно то, что нужно команде для ведения проекта. Более того, стандартная функциональность позволяет организовать рецензирование кода, не смотря на то, что никакой специальной поддержки рецензирования в Trac нет.

Кстати, существует плагин, добавляющий в Trac средства рецензирования: PeerReviewPlugin.

Итак что для этого нужно? Во-первых, поскольку Trac не может визуализировать посторонний diff, нужно позаботится о дополнительных ветках в структуре репозитория. Изначально, каждое изменение должно производиться в ветке, специально выделенной для рецензирования и лишь после внесения всех исправлений, изменения будут копироваться в основную ветку. Напрашивается вот такая схема:

/trunk
	/feature_foo
		/feature_foo_review
	/feature_bar
		/feature_bar_review
	/bugs
		/bugs_review

Update: Замечу, что не смотря на отступы на схеме, все ветки создаются в одном и том же каталоге branches. Отступы на схеме нужно только чтобы показать порядок синхронизации веток, т.е. “trunk <-> feature_foo <-> feature_foo_review”, но не “trunk <-> feature_foo_review” напрямую.

Изменения сначала попадают в ветку «xxx_review». Отрецензированный код затем копируется в ветку «feature_xxx» или «bugs». Далее, изменения, пройдя соответствующее тестирования попадут в «trunk». В большом проекте такая иерархия может быть многоуровневой, однако все «_review» ветки будут оставаться в самом низу.

Также имеет смысл использовать отдельные «_review» ветки для каждого разработчика:

/trunk
	/feature_foo
		/feature_foo_xxx_review
		/feature_foo_yyy_review
		/feature_foo_zzz_review
	/feature_bar

Тем самым разработчики не будут мешать друг другу, коммитя непроверенный код.

Во-вторых, Trac предлагает очень удобные средства для просмотра изменений в репозитории.

Trac changeset viewer.

Автор кода может просто добавить ссылку на changeset с изменениями [xxx] в комментариях к задаче (ticket), а затем присвоить задачу рецензенту. По завершению просмотра рецензент добавит свои комментарии по коду и присвоит задачу обратно автору кода.

В сложных случаях, когда изменение охватывает несколько changeset-ов поможет страница anydiff, которая, как следует из её названия, позволяет сравнивать любые части репозитория и любые ревизии кода.

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

Ну и наконец обязательно нужно настроить рассылку уведомлений и обязательно использовать перекрестные ссылки: комментарии к задаче должны ссылаться на код, а комментарии к изменениям в репозитории должны ссылаться на соответствующую задачу. Хотя это нужно не только для рецензирования. :-)

,

  1. ryfm
    February 26th, 2007 at 04:10 | #1

    а здесь инфа по настройке
    standalone http://rsdn.ru/forum/?mid=1769977
    и вместе с apache http://rsdn.ru/Forum/Message.aspx?mid=1778590&only=1
    правда где про апач, я с аутентификацией чуть с глючил, но думаю это не проблема.

  2. February 26th, 2007 at 05:06 | #2

    Я правильно понял что рамочным предположением является то, что 100% кода должно быть проведено через рецензирование?

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

  3. February 26th, 2007 at 05:08 | #3

    Еще один вопрос.

    В каких случаях, по вашему, оправданее применять процесс рецензирования основанный на патчах, примерно так как это делается в Open Source проектах?

  4. ryfm
    February 26th, 2007 at 06:26 | #4

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

    зы. тоже самое и для программистов на Java в среде Idea тоже от jetbrains.

  5. ryfm
    February 26th, 2007 at 06:27 | #5

    зы. про FxCop думаю никому напоминать не надо :)

  6. February 26th, 2007 at 06:40 | #6

    Да, FxCop хорош. Правда, много времени уходит на притирание набора включенных проверок к проекту и команде, но оно того стоит.

  7. Not a kernel guy
    February 26th, 2007 at 10:02 | #7

     

    Я правильно понял что рамочным предположением является то, что 100% кода должно быть проведено через рецензирование?

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

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

    Само собой. Чем больше компнент зависит от кода (читай чем больше проект или популярнее библиотека) и чем больше ущерб от ошибок (финансы, 24×7 системы) – тем тщательнее приходится проверять код.

    В каких случаях, по вашему, оправданее применять процесс рецензирования основанный на патчах, примерно так как это делается в Open Source проектах?

    Я использую примерно такую градацию (от наименее строгого варианта к наиболее строгому):

    1. Код не рецензируются вообще;
    2. Код рецензируется после того, как попадает в production ветку;
    3. Код рецензируется до того, как попадает в production ветку. Автор кода имеет право проигнорировать мнение рецензента, если считает нужным;
    4. Рецензент должен дать свое разрешение на чекин.

    1 & 2 имеет смысл только для совсем маленьких и незначительных проектов. Выбор между 3 & 4 зависит от мобильности команды и от “проверенности” уровня разрабочиков.

    Скажем, если компания пишет коммерческий продукт, то строгости 4-ого варианта будут только мешать. Разработчики соответствуют некоторому минимальному уровню компетентности, сидят в одном офисе, материально заинтересованы и т.п. При возникновении проблем они могут быть решены достаточно оперативно.

    С другой стороны в Open Source поекте патч может прислать кто угодно и качество присланого кода заранее не известно. Основное средство коммуникаций – e-mail тоже не обеспечивает нужной мобильности. Соотвественно используется 4-ый вариант. Хотя основные разработчики (как правило авторы проекта и наиболее активные и проверенные участноки) пользуются 2 или 3-им вариантом.

    В общем всё зависит от:

    1. Размера проекта;
    2. Его популярности;
    3. Мобильности и уровня разработчиков.
  1. No trackbacks yet.
Comments are closed.