Comments 12
Для приложения, основной целью которого была генерация стат отчётов, я оказывается пользовался RDD, правда не так формально. Позже считал его разновидностью DDD.
Отлично! Было бы любопытно узнать о конкретных ситуациях — о таких, когда взгляд на отчёт заставлял полностью что-то поменять в приложении. У вас были такие случаи?
Был — потребовался отчёт с динамически задаваемыми столбцами («конструктор отчётов»). До того были фактически «захардкоденные» отчёты по двум, редко трём, связанным таблицам, где первая почти всегда была общей для всех, а вторая специфична для отчёта. Пришлось вводить в БД таблицы с метаданными, стандартизировать основную схему, кое-где отказавшись от нормализации, дабы не вводить «рекурсивные функции» и четырёхэтажные джойны. Из-за изменений схемы пришлось также перелопачивать существующие формы и отчёты (об автоматическом тестировании тогда не знал, потому словил прилично багов вида «забыл вот-тут изменить»). Но в итоге, создав «конструктор» смог перевести «захардкоденные» отчёты в набор настроек «конструктора» («шаблоны»), фактически избавившись от необходимости «хардкодить» новые отчёты, а лишь создавать шаблоны, и, при необходимости, новые таблицы/поля в БД. В принципе, позже пара пользователей (из десятка) научились сами формировать новые шаблоны отчётов по существующим данным, а меня вызывали только когда нужны были изменения в схеме и/или формах.
Спасибо большое за столь подробный комментарий.
На DevCon'е подходило много народу обсудить RDD и кое-кто приводил примеры из своего опыта, один в один как вы здесь написали.
А вообще, проблема создания отчётов конечными пользователями стоит очень остро. Всем хочется максимально делегировать эту функцию непосредственно потребителями отчётов, но зачастую либо архитектура базы слишком сложна, либо наворочен сам дизайнер отчётов. Мы, например, в XtraReports имеем End-User Designer для конечных пользователей и постоянно делаем его всё более расширяемым, чтобы каждый мог максимально «подогнать» его под требования своих пользователей.
На DevCon'е подходило много народу обсудить RDD и кое-кто приводил примеры из своего опыта, один в один как вы здесь написали.
А вообще, проблема создания отчётов конечными пользователями стоит очень остро. Всем хочется максимально делегировать эту функцию непосредственно потребителями отчётов, но зачастую либо архитектура базы слишком сложна, либо наворочен сам дизайнер отчётов. Мы, например, в XtraReports имеем End-User Designer для конечных пользователей и постоянно делаем его всё более расширяемым, чтобы каждый мог максимально «подогнать» его под требования своих пользователей.
Раньше ни разу не слышал про RDD, но мне тоже кажется что это часть DDD, потому как при создании домена поднимаются вопросы как будут использовать те или иные объекты, в частности, в отчетах.
Не знаю, если кому-то будет удобно считать RDD частью DDD, я не возражаю. Как не буду настаивать и на том, чтобы применять RDD в чистом виде — ведь следуя только этому подходу тоже можно наворотить бед.
На мой взгляд RDD хорош тем, что помогает взглянуть на приложение с другой стороны, чтобы посмотреть, что можно улучшить, что надо поменять. Плюс, есть ещё один хороший вывод из RDD — когда вы получаете от заказчика тех.задание, обязательно требуйте включить в него макеты отчётов, которые ему могут понадобиться. Если будет упираться и оставлять на потом — настаивайте, ибо потом может быть мучительно больно.
На мой взгляд RDD хорош тем, что помогает взглянуть на приложение с другой стороны, чтобы посмотреть, что можно улучшить, что надо поменять. Плюс, есть ещё один хороший вывод из RDD — когда вы получаете от заказчика тех.задание, обязательно требуйте включить в него макеты отчётов, которые ему могут понадобиться. Если будет упираться и оставлять на потом — настаивайте, ибо потом может быть мучительно больно.
Автор честно признается, что «Мы называем такой подход RDD — Report-Driven Design». Думаю, что как вид анализа при построении моделей и доменов такой подход необходим, но как отправная точка и основной механизм — этого недостаточно, а зачастую приведет к таким же печальным последствиям, как описывается в начале статьи.
Очень часто отчеты создаются без оглядки. Поэтому в них многое может быть не учтено. Сколко раз было, когда куча отчетом сводится к одному или, в принципе, сами по себе не имеют смысла и ничего не показывают из-за отсутствия естественных связей. Чаще всего именно при подходе от объектов учета, их взаимодействия и картины бизнеса, в целом, отчеты упрощаются, меняются до неузнаваемости и конечные пользователи удивляются: «Как это раньше не пришло в голову все так разложить?!».
Очень часто отчеты создаются без оглядки. Поэтому в них многое может быть не учтено. Сколко раз было, когда куча отчетом сводится к одному или, в принципе, сами по себе не имеют смысла и ничего не показывают из-за отсутствия естественных связей. Чаще всего именно при подходе от объектов учета, их взаимодействия и картины бизнеса, в целом, отчеты упрощаются, меняются до неузнаваемости и конечные пользователи удивляются: «Как это раньше не пришло в голову все так разложить?!».
>Чаще всего именно при подходе от объектов учета, их взаимодействия и картины бизнеса, в целом, отчеты упрощаются, меняются до неузнаваемости и конечные пользователи удивляются: «Как это раньше не пришло в голову все так разложить?!».
Тут многое зависит разрабатываете вы решение для задач пользователей (а то и их формулируете) или просто автоматизируете существующее решение. Во втором случае и задачу-то знать не нужно по большому счёту, достаточно понять существующий алгоритм. Можно высказать мнение по поводу не оптимальности существующего решения или неверной формулировке задачи, но вероятность того, что только испортите отношения с заказчиком не нулевая.
Тут многое зависит разрабатываете вы решение для задач пользователей (а то и их формулируете) или просто автоматизируете существующее решение. Во втором случае и задачу-то знать не нужно по большому счёту, достаточно понять существующий алгоритм. Можно высказать мнение по поводу не оптимальности существующего решения или неверной формулировке задачи, но вероятность того, что только испортите отношения с заказчиком не нулевая.
Это похоже больше на «рабовладельческий строй» и теории программирования и разработки, тогда, тут не причем :-) Бездумно автоматизировать какой смысл? От этого проиграют все — и вы и заказчик.
Вообще, подход «задачу-то знать не нужно по большому счёту, достаточно понять существующий алгоритм» уже обговаривали не одно поколение и пока он не выдерживает испытания временем. Т.е. в краткосрочной перспективе (срубить бабла и свалить), это проходит, а в поддержке заваливает все.
Вообще, подход «задачу-то знать не нужно по большому счёту, достаточно понять существующий алгоритм» уже обговаривали не одно поколение и пока он не выдерживает испытания временем. Т.е. в краткосрочной перспективе (срубить бабла и свалить), это проходит, а в поддержке заваливает все.
Я про ситуации, когда заказчик не делегирует функцию анализа, а тем более изменения бизнес-процессов исполнителю. Он хочет их автоматизировать, но не более. Грубо говоря, вместо создания/внедрения системы электронного документооборота заказывает систему учёта бумажного документооборота. Причины разные могут быть — от нехватки бюджета и требований законодательства до «мы всегда так делали» и «не учите меня как вести мой бизнес». И что, отказывать такому заказчику и ждать того, кто понимает, что автоматизация существующих процессов может быть лишь затыканием дыр в организации процессов в целом?
Выберите «Iterate» или «Increment» для четвёртого I.
Sign up to leave a comment.
Report-Driven Design