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

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

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



Кто-нибудь составляет план тестирования по уже готовому коду, что бы проверить соответствие ожиданий и реальности именно по коду (а не по ТЗ)?



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

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

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

Здравствуйте, 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), из которых вы получите тест-кейсы среднего уровня, является входной информацией для проверки дизайна, разработки тестов, и разработки общего плана. Ваш план сильно выиграет, если вы будете держать группировку задач в нем от тестов среднего уровня. Это упростит вам управление приоритетами (только сценарии имеют прямую связь с приоритетами — именно они являются связующим звеном), сделает план верхнего уровня читабельнее и устойчивее к изменениям, уменьшит процент ошибок интеграции и риск провала проекта в конце.

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

Software configuration management

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

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

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

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

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


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

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

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

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

Здравствуйте, 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>Есть в сети где-нибудь пример такого плана?

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

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

Здесь — довольно пространное описание процесса на русском.