Показать сообщение отдельно
Старый 23.10.2019, 17:29   #35  
trud is offline
trud
Участник
Лучший по профессии 2017
 
1,038 / 1629 (57) ++++++++
Регистрация: 07.06.2003
Записей в блоге: 1
Цитата:
Сообщение от belugin Посмотреть сообщение
2 вида пользователей: разработчик и функциональный консультант.
Разработчик может сконфигурировать модель данных и добавить новые виды источников данных (например, написать специальный класс, чтобы работало быстро). Функциональный консультант может сконфигурировать как выводить эти данные в каком-то формате. Консультант также может вносить небольшие правки в том, что сконфигурировано разработчиком, делать модели и простые меппинги на структуру данных.
А зачем они это будут делать? Ну т.е. я вот к примеру делал один из бесконечных вариантов выгрузки платежей в банк(по моему похожее на класс CustVendChequeUS). Т.е. изначально пользователи запросили выгрузку в текстовый файл определенной структуры. Передали ее консультанту. Он разработал дизайн, что нужен текстовый файл, и как эти поля заполнять. Этот дизайн передали в разработку. Я задублировал текущий класс, сделал свои исправления. Передал на тест. Они в форматах платежа выбрали этот класс, протестировали. Консультант совсем не горел желанием "вносить небольшие правки" т.е. файл утверждается банком и не меняется.
Изменения там не сказать что были элементарные, т.е. потребовалось лезть в таблицы SpecTrans, как-то замороченно вычислять суммы, вычислять итоговые строки, т.е. писать код.
Это как-бы стандартная задача, на каком этапе тут возникает ER?
Ну т.е. расчитывать что типичный консультант не знающий структуры данных будет что-то конфигурировать нельзя, ему нужен уже готовый файл платежа. Как разработчику зачем мне выбирать для разработки ER рискуя налететь на то, что какое-то требование/запрос трудно или нельзя реализовать в ER?