|
Документирование разработки
|
|||
---|---|---|---|
#18+
Доброго времени суток всем! ситуация такая: один программист передает разработку другому. Как такого расписанного проекта со скопом задач нет, ТЗ писали внутри предприятия, поэтому написали, как написали... имеем то, что имеем. Я рассуждаю с точки зрения программиста: как документировать свою разработку, чтобы по максимуму передать свои знания, максимально быстро подключить к работе нового специалиста. Нужно отдать ему исходники и документацию, чтобы больше он меня не беспокоил. Что скажет сообщество? ... |
|||
:
Нравится:
Не нравится:
|
|||
13.01.2008, 17:33 |
|
Документирование разработки
|
|||
---|---|---|---|
#18+
Сначала надо максимально полно описать предметную область. Это необходимо. Если это будет, остальное можно уже по коду самому понять. Но этого не достаточно для быстрого включения в проект. Необходимо еще описать архитектуру ПО, все типовые технические решения и отдельно описать все отклонения. Ну и совсем в идеале все процессы из предметной области привязать к программе. Если все делать по хорошему, то это очень большая работа. ... |
|||
:
Нравится:
Не нравится:
|
|||
13.01.2008, 19:35 |
|
Документирование разработки
|
|||
---|---|---|---|
#18+
полное описание действительно большая работа, соизмеримая в данном случае со всей выполненной работой... В моем случае работает один программист, поэтому планировалось, что работа будет в голове одного человека, а сейчас нужно передать то, что у него в голове. Перефразирую вопрос, как уважаемое сообщество защищает свои небольшие разработки от смены разработчиков, удержание разработчиков в данном случае не подходит... ... |
|||
:
Нравится:
Не нравится:
|
|||
13.01.2008, 20:16 |
|
Документирование разработки
|
|||
---|---|---|---|
#18+
1. Делаем "понятный" код. Так как зачастую это единственное что есть это очень важно. Рефакторинг если надо и т.д. Комментарии - по мере необходимости. Все не тривиальные вещи должны быть закоментированы. И конечно описание интерфейсов всех классов. Желательно с использованием автогенерации хелпа по исходникам. 2. Делаем принципиальную схему приложения (например в нотации UML). Это не должна быть схема всего на свете, но основную архитектуру должна описывать. 3. Делаем краткое описание предметной области и "функционала" системы. Это не полноценное ТЗ, а некий "быстрый" старт. На мой взгляд это тот минимум, что поможет достаточно быстро войти в работу новому человеку. Порядок изучения конечно обратный - 3-2-1. Если имеется еще что-то (нормальное ТЗ, нормальная модель системы, описание БП, модульные тесты, документация пользователя, ...) то это конечно большой плюс. Но к сожалению бывает это не часто :( ... |
|||
:
Нравится:
Не нравится:
|
|||
13.01.2008, 20:42 |
|
Документирование разработки
|
|||
---|---|---|---|
#18+
Я бы еще добавил спецификцию требований - перечень (дерево) требований со статусами и приоритетами - что выполнено, а что нужно выполнить... Это поможет не только описать текущую ситуацию, но и определить приоритеты дальнейшего развития программы (она ведь будет развиваться?) ... |
|||
:
Нравится:
Не нравится:
|
|||
14.01.2008, 01:02 |
|
|
start [/forum/topic.php?fid=37&fpage=12&tid=1555669]: |
0ms |
get settings: |
10ms |
get forum list: |
13ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
25ms |
get topic data: |
11ms |
get forum data: |
2ms |
get page messages: |
41ms |
get tp. blocked users: |
1ms |
others: | 14ms |
total: | 123ms |
0 / 0 |