?

Log in

No account? Create an account
November 2016   01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30
cartoon

А как вообще документируют историю исправлений и план разработки

Posted on 2008.05.23 at 17:04
Tags: , ,
Re: А как вообще документируют историю исправлений и план ра
http://rsdn.ru/Forum/message/2470480.1.aspx

Здравствуйте, FDSC, Вы писали:

FDS>Люди! Подскажите мне...
FDS>Какие есть способы записи изменений в программе (т.е. того, что изменено и почему изменено), записей обнаруженных багов.

FDS>Вообще, насколько подробно эти вещи документируются в разных методологиях и какие программные средства для этого используются.
FDS>Понятное дело, что одним комментарием к ревизии в SVN дело, наверное, не ограничивается...

FDS>Интересует как теория, так и впечатления от применения этой теории.


Комментарий к коммиту в системе контроля версий, описывающий суть изменений, с обязательным указанием в теле комментария номера (или ссылки на) задачи или описания ошибки в системе контроля работ (task tracker). От задачи или ошибки в трекере будет ссылка на проектную документацию/требования, или будет прикреплена информация и переписка по поводу ошибки, начиная с момента ее обнаружения.

Таким образом, task tracker и система контроля версий являются основной и наиболее достоверной документацией к системе. Пользуясь ими, всегда можно определить автора каждой строки кода, найти чекин, которым она было добавлена, понять, частью каких изменений она является, и получить детальное описание причин появления этой правки. Без подобной системы поддерживать legacy-код практически невозможно, а любой код становится рано или поздно legacy, поэтому внедрение task-tracker + VCS + процедур с ними связанных мы рассматриваем как первый необходимый шаг для организации разработки, не зависящий от применяемых процессов разработки.

FDS>Кто-нибудь составляет план тестирования по уже готовому коду, что бы проверить соответствие ожиданий и реальности именно по коду (а не по ТЗ)?
Бывало, но только для наиболее критичных кусков, так как это очень трудоемко (это обыкновенно разделяемый код, кторый используется в десятках разным мест). Также следует обратить внимание на автоматизированное unit- и системное тестирование, которое должно являться частью процесса разработки и проводится автоматически при ночных билдах. Один из возможных вариантов — запретить закрывать задачи в трекере без наличия чекина успешно работающих unit-тестов c адекватным тестовым покрытием — хотя бы по метрике "строки кода".

FDS>Как нормальные люди составляют расписание разработки проекта. Т.е., представим себе, у нас есть задание на относительно сложную систему. Скажем, проектирования каких-нибудь сооружений (упппс). Допустим, что мы хотим для начала сделать небольшую систему проектирования отдельного узла конструкции и его продавать. Т.е. сначала хотим спроектировать и закодировать более простую систему, не очень-то думая о большой.

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

FDS>Вопрос: как в начале разработки описать, что мы собираемся сначала сделать такую-то структуру классов, а затем видоизменить её в другую структуру классов в такой-то последовательности при этом тестируя сначала то-то и то-то, а потом то-то и то-то? Ээ, предполагается, что не словами, а если и словами, то как-то структурировано, что бы можно было понять общий замысел архитектора.

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

Насчет планов — правильный подход при составлении планов — "от тестов". Опишите и сгруппируйте тестовые сценарии, выделяйте тесты уровня модуля, системные тесты, а также тест-кейсы среднего уровня — функционалные тесты, которые свзяывают несколько модулей воедино для выполнения некоторого набора осмысленных функций. Описание сценариев (use cases, user stories, etc), из которых вы получите тест-кейсы среднего уровня, является входной информацией для проверки дизайна, разработки тестов, и разработки общего плана. Ваш план сильно выиграет, если вы будете держать группировку задач в нем от тестов среднего уровня. Это упростит вам управление приоритетами (только сценарии имеют прямую связь с приоритетами — именно они являются связующим звеном), сделает план верхнего уровня читабельнее и устойчивее к изменениям, уменьшит процент ошибок интеграции и риск провала проекта в конце.

Comments:


Ilya Obshadko
xfyre at 2008-05-23 13:22 (UTC) (Link)
Комментарий к коммиту в системе контроля версий, описывающий суть изменений, с обязательным указанием в теле комментария номера (или ссылки на) задачи или описания ошибки в системе контроля работ (task tracker). От задачи или ошибки в трекере будет ссылка на проектную документацию/требования, или будет прикреплена информация и переписка по поводу ошибки, начиная с момента ее обнаружения.

это, конечно, прекрасно, но программистов придется нещадно пи$дить, чтобы они писали осмысленные комментарии, либо пропатчить CVS/SVN так чтобы он не давал коммитить без ссылки на issue :)

мне интересно, есть ли практический опыт подобного? можно ли это сделать без насилия, например, над исходниками того же CVS? и как именно? давно хочу сделать такое как минимум в двух проектах.
zhiraffanjut
zhiraffanjut at 2008-05-23 13:53 (UTC) (Link)
pre-commit checks в SVN и в CVS реализуются на раз-два. С автоматическим битьём по рукам в случае попытки сфилонить.
squadette at 2008-05-23 14:00 (UTC) (Link)
эти прекрасные люди будут ставить туда точичьку
см. форумы

Ilya Obshadko
xfyre at 2008-05-23 14:06 (UTC) (Link)
ну помимо условия "непустой комментарий" можно придумать и условие навроде

( $comment =~ /\#(\d+)/ ) && $bugzilla->has_bug ( $1, $committerUsername )

или с CVS-ом такие сложные конструкции не работают?

squadette at 2008-05-23 14:07 (UTC) (Link)
у тебя всё ещё CVS?..
Ilya Obshadko
xfyre at 2008-05-23 14:12 (UTC) (Link)
в основном да, мне лень апгрейдиться, а любимая схема релизменеджмента на нем отлично работает
squadette at 2008-05-23 14:08 (UTC) (Link)
хуки и в CVS, и в Svn работают по stdin/errorlevel.

только не забудь на пятый перл проапгрейдиться!
Gaperton
gaperton at 2008-05-24 12:55 (UTC) (Link)
Пишется скрипт, который посылает mail на специальную группу рассылки, в котором будет описание коммита включая комментарий. Очень хорошо в этом письме указывать количество добавленных-измененных строк кода (считаеся скриптом). Очень полезно - активность видна как на ладони.

И если прекрасный человек напишет точку, он немедленно получит штраф.
kubert
kubert at 2008-06-30 07:11 (UTC) (Link)

Штрафы и ограничения - Саботаж - Развал проекта

Как быть если штрафы и ограничения ведут к саботажу проекта "прекрасными людьми"?
Можно ли привить человеку желание комментировать коммиты иначе как палкой? Если да, то как?
Насколько сложно (или легко) собрать комманду, в которой каждый понимает свою ответственность перед остальными участниками и проектом в целом?
Gaperton
gaperton at 2008-06-30 07:40 (UTC) (Link)

Re: Штрафы и ограничения - Саботаж - Развал проекта

Для начала прекрасному человеку объясняют, зачем это надо. И учат, как пользоваться чужими комментариями.

Надо это затем, чтобы другой человек мог в режиме annotate определить, кто автор каждой строки кода, и по какой причине она добавлена.

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

В комментарии должно быть написано, например: номер дефекта, + общее описание изменения.

Или: номер задачи, общее описание что добавлено.

Или: просто - что он добавил.

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

Способы ненавязчиво заставить:
1) на коммит вешается триггер, который вынуждает указывать номер дефекта или задачи. Для этого - должна быть в полном порядке база учета работ, это бывает не всегда, и уже требует хорошей организованности.
2) Завести публичную группу рассылки checkin, на которую подписать всех. Отлично стимулирует писать комментарии, потому что многим хочется, чтобы коллеги знали об их успехах.
3) Вместо штрафа - завести небольшую премию в 100 баксов за регулярное соблюдение правила. Это то же самое, что штраф на самом деле, но люди воспринимают это гораздо лучше.
Gaperton
gaperton at 2008-06-30 07:44 (UTC) (Link)

Re: Штрафы и ограничения - Саботаж - Развал проекта

Вообще - прививать это одной только палкой не правильно. Это лишено смысла, если люди не знают, как такими комментариями пользоваться - тогда они бесполезны. А пользоваться они ими начнут только при поддержке и модификации чужого кода.
Gaperton
gaperton at 2008-06-30 07:52 (UTC) (Link)

Re: Штрафы и ограничения - Саботаж - Развал проекта

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

А во-вторых - я сам никогда по факту никогда не выписывал штрафов, и вряд ли буду это делать. В данном случае, я бы скорее откатил его чекин, и сказал ему, что наличие комментария является необходимым условием, чтобы его задачи считались завершенными. И что я верю в то, что он, как человек с высшим образованием, в состоянии написать несколько предложений не только на C# и С++, но и на литературном русском языке, кратко описывающих всю глубину, мощь, и суть его изменений, чтобы его коллеги смогли их понять и оценить.
Gaperton
gaperton at 2008-06-30 07:59 (UTC) (Link)

Re: Штрафы и ограничения - Саботаж - Развал проекта

Но если он и после этого напишет точку, то я за себя не ручаюсь :)

Тогда, вероятно, я спрошу его, что мне надо сделать, чтобы он уважал своих коллег и меня, и следовал простым и необременительным правилам. Пусть подумает, и скажет что-нибудь. Я ему варианты буду подкидывать - например - оштрафовать? Поможет?

Вот так я реально делал. Вообще, этот прием действует гораздо сильнее собственно самого штрафа - по себе знаю :).
Gaperton
gaperton at 2008-05-24 13:01 (UTC) (Link)
Поставить JIRA, включить интеграцию с CVS/SVN, поставить плагин, который не дает коммитить есть не указан номер задачи. Все.

Либо написать свой хук, как советут ниже
Previous Entry  Next Entry