Когда Вы не должны использовать Механизм Правил? [закрытый]
Пока что что-то не предоставляет fullPage.js. Максимум, что вы можете сделать, это включить все эти последние разделы в последний раздел вашего сайта и затем использовать scrollOverflow:true для эмуляции нормального поведения прокрутки, как в в этом примере .
См. Эту демонстрацию онлайн
content
content
content
sub content
sub content
sub content
Используя что-то вроде этого:
sub-section{
height: 100vh;
width: 100%;
}
.sub-section{
background: red;
}
.sub-section:nth-child(1){
background: red;
}
.sub-section:nth-child(2){
background: blue;
}
7 ответов
Я очень нервничаю, когда вижу людей, использующих очень большие наборы правил (например, порядка тысяч правил в одном наборе правил). Это часто случается, когда механизм правил - это одноэлементное ядро, расположенное в центре предприятия, в надежде, что соблюдение правил DRY сделает их доступными для многих приложений, которым они нужны. Я бы никому не сказал, что механизм правил Rete с таким количеством правил хорошо понятен. Мне неизвестны какие-либо инструменты, которые могут проверять, чтобы убедиться, что конфликты не существуют.
Я думаю, что наборы правил разделения, чтобы держать их маленькими, являются лучшим вариантом.
Я недавно писал об этом в блоге.
Вы можете проверить это здесь -> http://www.codetoglory.com/?p=21
Вы должны действительно используйте его, когда у вас есть динамические правила, которые постоянно меняются, например, страховые, торговые и валютные домены.
Надеюсь, моя статья в блоге может дать вам хороший обзор.
Единственное, что я заметил как «обоюдоострый меч», это:
передача логики в руки нетехнического staff
Я видел эту работу великолепно, когда у вас есть один или два междисциплинарных гения с нетехнической стороны, но я также видел недостаток техники, приводящий к раздутию, большему количеству ошибок и, в целом, 4x развитию / стоимость обслуживания.
Таким образом, вам нужно серьезно рассмотреть вашу пользовательскую базу.
Я думал, что статья Алекса Пападимулиса была довольно проницательной: http://thedailywtf.com/articles/soft_coding.aspx
Она не является исчерпывающей, но у него есть некоторые хорошие моменты.
Это, безусловно, хорошее начало. Другая вещь, связанная с механизмами правил, заключается в том, что некоторые вещи понятны, детерминированы и просты. Удержание заработной платы является (или используется быть), как это. Вы могли бы выразить это как правила, которые будут решаться механизмом правил, но вы могли бы выразить те же правила, что и довольно простая таблица значений.
Итак, механизмы рабочих процессов хороши, когда вы выражаете долгосрочный процесс, который будет иметь постоянные данные. Механизмы правил могут делать то же самое, но вы должны делать много дополнительной сложности.
Механизмы правил хороши, когда у вас есть сложные базы знаний и вам нужен поиск. Механизмы правил могут разрешать сложные проблемы и могут быть быстро адаптированы к меняющимся ситуациям, но создают большую сложность для базовой реализации.
В По моему опыту, механизмы правил работают лучше всего, когда выполняются следующие условия:
- Четко определенная доктрина для вашей проблемной области
- Высококачественные (предпочтительно автоматизированные) данные, которые помогают управлять большей частью ваших входных данных
- Доступ к экспертам в предметной области
- Разработчики программного обеспечения, имеющие опыт создания экспертных систем
Если какая-либо из этих четырех черт отсутствует,
Я приведу 2 примера из личного опыта, где использование движка правил было плохой идеей, возможно это поможет:-
- В прошлом проекте я заметил, что файлы правил (в проекте использовались Drools) содержали много java кода, в том числе циклы, функции и т.д. По сути, это были java-файлы, маскирующиеся под файл правил. Когда я спросил архитектора о его обосновании проекта, мне сказали, что "правила никогда не предназначались для поддержки бизнес-пользователей"
Урок: Они по какой-то причине называются "бизнес-правилами", не используют правила, когда вы не можете спроектировать систему, которую могут легко поддерживать/понимать бизнес-пользователи.
- Другой случай; в проекте использовались правила, потому что требования были плохо определены/понимались и часто менялись. Решением команды разработчиков было широкое использование правил, чтобы избежать частых внедрений кода.
Lesson: Требования, как правило, сильно меняются во время первоначальных изменений релиза и не оправдывают использование правил. Используйте правила, когда ваш бизнес меняется часто (не требования). Eg:- Программное обеспечение, которое делает ваши налоги будут меняться каждый год, так как меняется налоговое законодательство и использование правил является отличной идеей. Релиз 1.0 веб-приложения будет меняться часто по мере того, как пользователи определят новые требования, но стабилизируется с течением времени. Не используйте правила в качестве альтернативы развертыванию кода.