![]() |
#1 |
Участник
|
Как Вы документируете доработки
Уважаемый All, участвую в проекте, где сделаны довольно большие доработки, я бы сказал, разработки
![]() |
|
![]() |
#2 |
Участник
|
Документировать необходимо - это железно!
Мы ведем документацию в двух видах 1. Заполняем таблицу измененных элементов, с указанием разработчика, проекта, цели изменений 2. По данному FD оформляем AD, с указанием всех изменений в стандартном функционале + описание алгоритмов FD и AD связанно храним в накопленном опыте. Если все это добросовестно оформлять, то другому грамотному разработчику будет не проблема вникнуть. Другое дело, когда работы ведуться в авральном режиме - тогда уже не до документации |
|
![]() |
#3 |
Banned
|
Важно иметь документированную постановку задачи. Ее составление обычно является задачей консультанта, но некоторые представители последних ограничиваются порой следующим: "Нужно, чтобы в заказах работала наценка." С этим надо бороться. Отсутствие такой документации - самая неприятная штука. Видим код, но что он призван делать, как его тестировать, с какими модулями работает - непонятно.
Что касается чисто технической документации, то, по моему опыту, таблицы с именами элементов только захламляют папку проекта. Из названия элемента или поля уже должно быть ясно, за что он отвечает. Пример: "xxxDocumentTable.InvoiceAmountCur" вместо "TabKr.Sum22". А проект со всеми элементами, оставленный в приложении, и перекрестные ссылки отметают дальнейшие вопросы. Для сложных разработок полезно иметь модель данных, нарисованную в каком-либо CASE-средстве. |
|
![]() |
#4 |
Участник
|
Спасибо большое. Буду знать, за что бороться
![]() |
|