Здравствуйте, Gaperton, Вы писали:
G>Комментарий к коммиту в системе контроля версий, описывающий суть изменений, с обязательным указанием в теле комментария номера (или ссылки на) задачи или описания ошибки в системе контроля работ (task tracker). От задачи или ошибки в трекере будет ссылка на проектную документацию/требования, или будет прикреплена информация и переписка по поводу ошибки, начиная с момента ее обнаружения.
А что это за системы? Можно какую-нибудь свободно распространяемую например (если такая есть)?
G>Таким образом, task tracker и система контроля версий являются основной и наиболее достоверной документацией к системе. Пользуясь ими, всегда можно определить автора каждой строки кода, найти чекин, которым она было добавлена, понять, частью каких изменений она является, и получить детальное описание причин появления этой правки. Без подобной системы поддерживать legacy-код практически невозможно, а любой код становится рано или поздно legacy, поэтому внедрение task-tracker + VCS + процедур с ними связанных мы рассматриваем как первый необходимый шаг для организации разработки, не зависящий от применяемых процессов разработки.
Возникает вопрос: представим себе, что я хочу узнать о некоторой строке кода дополнительную информацию и откуда она взялась. Значит, я должен найти каким-то (непонятным мне образом) в task tracker информацию об этой строке, и там уже будет ссылка на файлы и соотв. ревизию в SVN, например. Не слишком ли это долго? Т.е. скажем, если я хочу узнать, что изменилось в классе с предыдущей версии и почему, то я должен 1. найти сделать сравнение исходников нескольких версий 2. прочитать кучу связанной с ними документации. При этом я могу не найти нужную мне информацию, связанную с классом, в данной версии, потому что она, скажем, относится к более ранним изменениям.
Проще говоря, как автоматизировать получение о некотором классе программы всей информации, связанной с некоторым куском кода, что бы не пришлось сравнивать десяток различных ревизий между собой и искать всю документацию начиная с основания проекта (что бы всё это делалось само)?
G>Если вы заранее знаете, что структура классов будет изменена в следующей итерации — спроектируйте сразу структуру для следующей итерации, после чего в первой итерации реализуйте необходимое подмножество. Так лучше.
А если я не могу спроектировать точную структуру классов для следующей итерации, а сама её реализация, даже её части, существенно затруднит написание первой версии проекта?
Как мне быть тогда? Скажем, я могу получить при написании первой версии важную информацию о необходимой структуре всей системы. Т.е. первая версия заодно используется как исследовательское приложение ко второй, более сложной
G> Ваш план сильно выиграет, если вы будете держать группировку задач в нем от тестов среднего уровня. Это упростит вам управление приоритетами (только сценарии имеют прямую связь с приоритетами — именно они являются связующим звеном), сделает план верхнего уровня читабельнее и устойчивее к изменениям, уменьшит процент ошибок интеграции и риск провала проекта в конце.
