|
Важно иметь документированную постановку задачи. Ее составление обычно является задачей консультанта, но некоторые представители последних ограничиваются порой следующим: "Нужно, чтобы в заказах работала наценка." С этим надо бороться. Отсутствие такой документации - самая неприятная штука. Видим код, но что он призван делать, как его тестировать, с какими модулями работает - непонятно.
Что касается чисто технической документации, то, по моему опыту, таблицы с именами элементов только захламляют папку проекта. Из названия элемента или поля уже должно быть ясно, за что он отвечает. Пример: "xxxDocumentTable.InvoiceAmountCur" вместо "TabKr.Sum22". А проект со всеми элементами, оставленный в приложении, и перекрестные ссылки отметают дальнейшие вопросы. Для сложных разработок полезно иметь модель данных, нарисованную в каком-либо CASE-средстве.
|