Стоит ли в программном коде фиксировать договоренности с заказчиком
Что имеется ввиду:
Когда Вы договариваетесь с заказчиком о том как будет работать Ваша доработка, Вы всегда обговариваете некоторый набор ограничений, при которых доработка будет работать.
| Пример | ОТОБРАЗИТЬ |
|---|---|
Как правильно поступать в случае договоренностей (ограничений)
Впишите в программный код — проверки, что пользователь правильно использует Вашу доработку
| Пример | ОТОБРАЗИТЬ |
|---|---|
Что не стоит делать при вставке «ограничений по договоренности»
В примере с построением отчета — не желательно выдавать сообщение о том, что пользователь «не прав» и что он должен указать определенные параметры. Ведь мы строим систему, которая облегчает жизнь пользователя, а не требует от него нажимать как можно больше кнопок. Поэтом если известно, что по умолчанию мы строим отчет за весь период — просто проведем преобразование периода.
К чему приводит отсутствие фиксирования договоренностей в программном коде
Все очень просто: пока с Вашей доработкой работает конкретно тот человек, которому Вы рассказывали про то, какие есть ограничения с доработкой — то всё хорошо и человек «правильно» пользуется Вашими доработки. Но как только человек со стороны пользователя передает Ваши доработки в руки другого человека (в рамках или не в рамках компании-заказчика) то часто он забывает о том, что в системе есть «ограничения по договоренностям» и не рассказывает другому человеку про эти договоренности.
Даже если Вы при разработке учли договоренности в документации, то для нового человека может быть очень много документации и он может просто не обратить внимание, при прочтении документации на то, что ограничения — существенны.
И вот тогда начинается потеря как времени пользователей — они не могут правильно построить отчет, видят не те данные и т.д., так и Вашего времени — поскольку начинают пользователи требовать от программиста внимания, чтобы он исправил эти ошибки!
Примерно как это может происходит рассказано тут.
Спорный момент о неявных преобразованиях. Может оказаться что программа преобразовывает данные, так как договорились, но тот кто строит отчет ожидает увидеть другие данные и тоже будет считать что отчет работает не верно.
Думаю что выход будет в том, что при таких неявных преобразованиях всё-таки сообщать пользователю о выполненных автоматически преобразованиях
Просто неявные преобразования — нужно их применять «с умом», т.е. нужно понимать, что если период не выбран то в этом случае (как и во всех стандартных отчетах) в 1С — это подразумевает выборку данных за весь период… и других вариантов тут просто нет.
Если же неявное преобразование подразумевает множество вариантов — тогда да, тогда можно и спросить о том, что делать…
Но писать каждый раз сообщение пользователю — смысла — нет, т.к. после того как отчет запуститься 100 раз — никто уже просто не будет обращать внимание на то, что написано внизу — в сообщениях.
Можно конечно подумать по поводу хитрой системы, которая бы первые пару раз предупреждала пользователя, но потом к нему не приставала (возможно периодически спрашивала) — но такое решение — это отдельный «головняк», который вряд-ли захочет оплачивать заказчик при заказе доработок. А вот если использовать какое-то стандартное решение, то да… это вполне себе применимо…