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

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

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

FDS>А что это за системы? Можно какую-нибудь свободно распространяемую например (если такая есть)?

Мы применяем связку Subversion (контроль версий) + JIRA (лучший в мире трекер) + Confluence (вики-портал интегрирующийся с JIRA).

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

FDS>Возникает вопрос: представим себе, что я хочу узнать о некоторой строке кода дополнительную информацию и откуда она взялась. Значит, я должен найти каким-то (непонятным мне образом) в task tracker информацию об этой строке, и там уже будет ссылка на файлы и соотв. ревизию в SVN, например. Не слишком ли это долго? Т.е. скажем, если я хочу узнать, что изменилось в классе с предыдущей версии и почему, то я должен 1. найти сделать сравнение исходников нескольких версий 2. прочитать кучу связанной с ними документации. При этом я могу не найти нужную мне информацию, связанную с классом, в данной версии, потому что она, скажем, относится к более ранним изменениям.

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

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

Насчет изменений — любая система контроля версий дает тебе возможность посмотреть изменения от версии к версии. Короче, читай мануалы.

FDS>Проще говоря, как автоматизировать получение о некотором классе программы всей информации, связанной с некоторым куском кода, что бы не пришлось сравнивать десяток различных ревизий между собой и искать всю документацию начиная с основания проекта (что бы всё это делалось само)?

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

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

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

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

Это нормально, так бывает. В этом случае надо максимально урезать функционал первой версии, чтобы оставить только высокорискованные части — пусть она будет прототипом. Возможно, будет целесообразно собрать несколько простых прототипов на выброс, чтобы проверить те или иные решения. Зависит от конкретики, короче.

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

FDS>Есть в сети где-нибудь пример такого плана?

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