Re: А как вообще документируют историю исправлений и план ра
От: Gaperton http://gaperton.livejournal.com
Дата: 02.05.07 09:31
Оценка: 30 (4) +1
Здравствуйте, 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), из которых вы получите тест-кейсы среднего уровня, является входной информацией для проверки дизайна, разработки тестов, и разработки общего плана. Ваш план сильно выиграет, если вы будете держать группировку задач в нем от тестов среднего уровня. Это упростит вам управление приоритетами (только сценарии имеют прямую связь с приоритетами — именно они являются связующим звеном), сделает план верхнего уровня читабельнее и устойчивее к изменениям, уменьшит процент ошибок интеграции и риск провала проекта в конце.
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.