Kiedy NIE należy używać silnika reguł? [Zamknięte]

108

Mam całkiem przyzwoitą listę zalet korzystania z silnika reguł, a także kilka powodów, aby ich używać, potrzebuję listy powodów, dla których NIE powinieneś używać silnika reguł

Najlepsze, jakie do tej pory mam, to:

Mechanizmy reguł nie są tak naprawdę przeznaczone do obsługi przepływu pracy lub wykonywania procesów, podobnie jak silniki przepływu pracy lub narzędzia do zarządzania procesami przeznaczone do wykonywania reguł.

Jakieś inne ważne powody, dla których nie powinieneś ich używać?

BlackTigerX
źródło

Odpowiedzi:

34

Bardzo się denerwuję, gdy widzę ludzi używających bardzo dużych zestawów reguł (np. Rzędu tysięcy reguł w jednym zestawie). Dzieje się tak często, gdy silnik reguł jest singletonem znajdującym się w centrum przedsiębiorstwa w nadziei, że przestrzeganie reguł DRY sprawi, że będą dostępne dla wielu aplikacji, które ich wymagają. Przeciwstawiłbym się komukolwiek, kto powiedziałby mi, że silnik reguł Rete z tak wieloma regułami jest dobrze zrozumiany. Nie znam żadnych narzędzi, które mogą sprawdzić, czy konflikty nie istnieją.

Myślę, że zestawy reguł partycjonowania, aby były małe, są lepszym rozwiązaniem. Aspekty mogą być sposobem na udostępnienie wspólnego zestawu reguł dla wielu obiektów.

Wolę prostsze, bardziej oparte na danych podejście, gdy tylko jest to możliwe.

duffymo
źródło
1
Czy ustalenie, czy są jakieś konflikty, nie byłoby wariantem problemu z zatrzymaniem?
TMB
Nie wiem, czy tak to nazwiesz. Jakie zmiany przy użyciu tej nazwy? Nic, co mogę zobaczyć ...
duffymo
@duffymo jakieś przykłady „podejścia opartego na większej ilości danych”?
jack.the.ripper
Jasne: umieść swoje dane w jednej tabeli decyzyjnej i zapytaj, aby uzyskać potrzebne odpowiedzi. Nie ma potrzeby stosowania silnika reguł Rete.
duffymo
151

Podam 2 przykłady z własnego doświadczenia, w których użycie silnika reguł było złym pomysłem, może to pomoże: -

  1. W poprzednim projekcie zauważyłem, że pliki reguł (projekt korzystał z Drools) zawierały dużo kodu java, w tym pętle, funkcje itp. Były to zasadniczo pliki java udające plik reguł. Kiedy zapytałem architekta o jego uzasadnienie dla projektu, powiedziano mi, że „Zasady nigdy nie miały być utrzymywane przez użytkowników biznesowych”.

Lekcja : Nie bez powodu nazywane są one „Regułami biznesowymi”. Nie używaj reguł, gdy nie możesz zaprojektować systemu, który może być łatwo utrzymywany / zrozumiały dla użytkowników biznesowych.

  1. Inna sprawa; W projekcie zastosowano reguły, ponieważ wymagania były słabo zdefiniowane / zrozumiane i często się zmieniały. Rozwiązanie zespołu programistów polegało na szerokim użyciu reguł, aby uniknąć częstego wdrażania kodu.

Lekcja : Wymagania często się zmieniają podczas początkowych zmian w wydaniu i nie gwarantują użycia reguł. Użyj reguł, gdy Twoja firma często się zmienia (nie wymagania). Np .: - Oprogramowanie, które oblicza Twoje podatki, będzie się zmieniać co roku, gdy zmieniają się przepisy podatkowe, a stosowanie reguł to doskonały pomysł. Wersja 1.0 aplikacji internetowej będzie się często zmieniać, gdy użytkownicy będą identyfikować nowe wymagania, ale z czasem będzie się stabilizować. Nie używaj reguł jako alternatywy dla wdrażania kodu. Wcześniejsze

VDev
źródło
1
Myślę, że dobrym sposobem na przeformułowanie twojej lekcji nr 2 jest „nie implementuj DSL, kiedy wiesz, że abstrakcja zawarta w DSL może się zmienić”. Projektowanie i wdrażanie DSL to proces wymagający dużej ilości zasobów, którego celem jest zbieranie nagród w przyszłości. Jeśli musisz odtwarzać DSL w każdym cyklu, silnik reguł nie będzie jeszcze dobrze dopasowany, dopóki nie nastąpi pewna stabilizacja.
TEN UŻYTKOWNIK POTRZEBUJE POMOCY
DSL może obciążać zasoby, ponieważ interpretowane języki programowania są ciężkie, ale mogą być również statyczne i kompilowane przy zmianie, tak jak inne języki kompilowane.
Matthew Whited
19

Jestem wielkim fanem silników reguł biznesowych, ponieważ mogą one znacznie ułatwić Ci życie jako programista. Jednym z pierwszych doświadczeń, jakie miałem podczas pracy nad projektem hurtowni danych, było znalezienie procedur składowanych zawierających skomplikowane struktury CASE rozciągające się na całe strony. Debugowanie było koszmarem, ponieważ bardzo trudno było zrozumieć logikę stosowaną w tak długich strukturach CASE i określić, czy masz nakładanie się reguły na stronie 1 kodu z inną ze strony 5. Ogólnie ponad 300 takich reguł osadzonych w kodzie.

Kiedy otrzymaliśmy nowe wymaganie dotyczące rozwoju czegoś, co nazywa się Accounting Destination, które obejmowało obsługę ponad 3000 reguł, wiedziałem, że coś musi się zmienić. Pracowałem wtedy nad prototypem, który później stał się rodzicem tego, co teraz jest silnikiem Custom Business Rule, zdolnym do obsługi wszystkich standardowych operatorów SQL. Początkowo używaliśmy Excela jako narzędzia do tworzenia treści, a później stworzyliśmy aplikację ASP.net, która pozwoli użytkownikom biznesowym definiować własne reguły biznesowe bez konieczności pisania kodu. Teraz system działa dobrze, z bardzo małą liczbą błędów i zawiera ponad 7000 reguł obliczania tego miejsca docelowego księgowania. Nie sądzę, by taki scenariusz był możliwy po prostu na sztywno.

Jednak takie podejście ma pewne ograniczenia:

  • Musisz mieć zdolnych użytkowników biznesowych, którzy doskonale rozumieją działalność firmy.
  • Przeszukiwanie całego systemu (w naszym przypadku hurtowni danych) wymaga dużego nakładu pracy, aby określić wszystkie zakodowane na stałe warunki, które mają sens w przełożeniu na reguły obsługiwane przez Business Rule Engine. Musieliśmy również zadbać o to, aby te wstępne szablony były w pełni zrozumiałe dla użytkowników biznesowych.
  • Potrzebujesz aplikacji służącej do tworzenia reguł, w której zaimplementowane są algorytmy wykrywania nakładających się reguł biznesowych. W przeciwnym razie skończysz z wielkim bałaganem, w którym nikt już nie zrozumie wyników, jakie osiągają. W przypadku błędu w komponencie ogólnym, takim jak niestandardowy silnik reguł biznesowych, debugowanie może być bardzo trudne i wymaga obszernych testów, aby upewnić się, że rzeczy, które działały wcześniej, działają również teraz.

Więcej szczegółów na ten temat można znaleźć w poście, który napisałem: http://dwhbp.com/post/2011/10/30/Implementing-a-Business-Rule-Engine.aspx

Ogólnie rzecz biorąc, największą zaletą korzystania z silników reguł biznesowych jest to, że pozwala użytkownikom odzyskać kontrolę nad definicjami reguł biznesowych i tworzeniem treści, bez konieczności udawania się do działu IT za każdym razem, gdy muszą coś zmienić. Zmniejsza również obciążenie pracą zespołów programistów IT, które mogą teraz skupić się na tworzeniu rzeczy o większej wartości dodanej.

Twoje zdrowie,

Nicolae

Nicolae Guse
źródło
18

Jedyny punkt, który zauważyłem jako „miecz obosieczny”, to:

oddanie logiki w ręce nietechnicznego personelu

Widziałem, jak to działa świetnie, gdy masz jednego lub dwóch multidyscyplinarnych geniuszy po stronie nietechnicznej, ale widziałem również brak techniki prowadzący do nadęcia, większej liczby błędów i ogólnie 4x kosztów rozwoju / utrzymania.

Dlatego musisz poważnie rozważyć swoją bazę użytkowników.

Robert Gould
źródło
13
To twoja wina jako programisty, a nie wina użytkownika, jeśli nie może on używać twojego systemu lub jeśli stale osiąga z nim nieprzewidywalne rezultaty, niezależnie od tego, czy jest to BRE, czy nie. Powiedziałbym, że obwinianie użytkowników za ich niezdolność do używania twojego kodu jest absolutnie gorszym rodzajem programowania, jaki może mieć projekt.
Kizz
Chociaż jest to bardzo stary post, ale nie mogę się bardziej zgodzić. Myślę, że jeśli to możliwe, ludzie techniczni (lub dostawca) wykonają konfigurację dla klientów podczas procesu wdrażania / wdrażania, a następnie wszelkie większe zmiany na podstawie zgłoszeń serwisowych.
Eric Xin Zhang
Może ktoś przyda się do przeczytania fajnego artykułu Martina Fowlera na temat DSL: "Czy DSL pozwoli ludziom biznesu pisać reguły oprogramowania bez angażowania programistów?" martinfowler.com/bliki/BusinessReadableDSL.html
Robert Lujo
11

Myślałem, że artykuł Alexa Papadimoulisa był dość wnikliwy: http://thedailywtf.com/articles/soft_coding.aspx

Nie jest to wyczerpujące, ale ma kilka dobrych punktów.

Kowalstwo
źródło
2
problem polega na tym, że nie mówi się o prawdziwych silnikach reguł standardowych, tylko o własnych silnikach reguł, które są bardzo złym pomysłem, mówię o silnikach reguł standardowych (Blaze Advisor, ILog, Drools), które implementują algorytm RETE i zapewniają całość ekosystem do zarządzania regułami
BlackTigerX
niesamowity artykuł i myślę, że możesz przejść zbyt miękko ze standardowym silnikiem reguł, który czasami sprawia, że ​​rzeczy są bardziej złożone
Dean Hiller
1
Wyobraź sobie bank z milionem transakcji na godzinę, który utracił połączenie z mechanizmem reguł obliczania opłat na 30 minut, ponieważ programiści mają depolację, wyobraź sobie, że był to okres stabilności, w którym mają wiele wdrożeń dla poprawek, ile strat będą mieli po zatrzymaniu jednej usługi obrót akcjami, wymiana walut czy przelewy SWIFT? Ten artykuł jest jednym z najgorszych artykułów o programowaniu w ogóle
2
hragheb, skąd się bierze 30 minut przestoju? Giganci tacy jak Facebook stale wdrażają nowe oprogramowanie bez przestojów. Aplikacje można budować tak, aby obsługiwały aktualizowanie węzłów w partiach zamiast wyłączania całego systemu.
Lauri Harpf
10

WIELKI artykuł o tym, kiedy nie używać silnika reguł ... (a także kiedy go używać) ....

http://www.jessrules.com/guidelines.shtml

Inną opcją jest to, że jeśli masz liniowy zestaw reguł, które mają zastosowanie tylko raz w dowolnej kolejności, aby uzyskać wynik, jest stworzenie świetnego interfejsu i poproszenie programistów o napisanie i wdrożenie tych nowych reguł. Zaletą jest to, że jest niesamowicie szybki, ponieważ normalnie przechodziłbyś sesję hibernacji LUB sesję jdbc, a także wszelkie parametry, dzięki czemu masz dostęp do wszystkich danych aplikacji, ale w efektywny sposób. Z listą faktów może istnieć wiele zapętleń / dopasowań, które naprawdę mogą spowolnić system ..... To kolejny sposób na uniknięcie silnika reguł i możliwość dynamicznego wdrażania (tak, nasze świetne reguły zostały wdrożone w baza danych i nie mieliśmy rekursji ... albo spełniła regułę, albo nie). To tylko kolejna opcja… och i jeszcze jedna korzyść to brak nauki składni reguł dla przyszłych programistów.

To naprawdę zależy od twojego kontekstu. Silnik reguł ma swoje miejsce, a powyższa opcja to tylko kolejna opcja, jeśli masz w projekcie reguły, które możesz chcieć wdrożyć dynamicznie w bardzo uproszczonych sytuacjach, które nie wymagają silnika reguł.

Zasadniczo NIE używaj silnika reguł, jeśli masz prosty zestaw reguł i zamiast tego możesz mieć fajny interfejs ..... tak samo dynamicznie wdrażalny, a nowi programiści dołączający do twojego zespołu mogą nauczyć się go szybciej niż języka ślinek. (Ale to jest moja opinia)

Dean Hiller
źródło
7

Z mojego doświadczenia wynika, że ​​silniki reguł działają najlepiej, gdy są spełnione następujące warunki:

  1. Dobrze zdefiniowana doktryna dla Twojej problematycznej domeny
  2. Dane wysokiej jakości (najlepiej zautomatyzowane), aby pomóc w generowaniu większości danych wejściowych
  3. Dostęp do ekspertów merytorycznych
  4. Programiści z doświadczeniem w tworzeniu systemów eksperckich

Jeśli brakuje którejkolwiek z tych czterech cech, nadal może się okazać, że silnik reguł działa dla Ciebie, ale za każdym razem, gdy próbuję go z brakiem choćby jednej, mam kłopoty.

DaveParillo
źródło
to> _Deweloperzy oprogramowania z doświadczeniem w tworzeniu systemów eksperckich_ <Jeśli dokładnie przeczytasz dokumentację drools, zdasz sobie sprawę, że reguły biznesowe powinny być wdrażane przez programistów, którzy dobrze rozumieją algorytm Rete. Dostęp do parametryzacji reguł można zapewnić użytkownikom biznesowym za pośrednictwem arkuszy kalkulacyjnych lub CSV. Niemniej jednak reguły są opisywane przez użytkowników biznesowych, ale wdrażane są przez, jak powiedziałeś, programistów z doświadczeniem w systemach eksperckich. Drools Docs opisują to.
Matt Friedman,
1

To z pewnością dobry początek. Inną rzeczą w przypadku silników reguł jest to, że niektóre rzeczy są dobrze zrozumiane, deterministyczne i proste. Potrącenie z listy płac jest (lub powinno być) takie. Możesz to wyrazić jako reguły, które zostaną rozwiązane przez silnik reguł, ale możesz wyrazić te same reguły, co dość prosta tabela wartości.

Tak więc silniki przepływu pracy są dobre, gdy wyrażasz długoterminowy proces, który będzie miał trwałe dane. Silniki reguł mogą robić podobne rzeczy, ale musisz zrobić dużo dodatkowej złożoności.

Silniki reguł są dobre, gdy masz skomplikowane bazy wiedzy i potrzebujesz wyszukiwania. Silniki reguł mogą rozwiązywać skomplikowane problemy i mogą być szybko dostosowywane do zmieniających się sytuacji, ale nakładają dużą złożoność na podstawową implementację.

Wiele algorytmów decyzyjnych jest na tyle prostych, że można je wyrazić jako prosty program oparty na tabelach, bez złożoności wynikającej z prawdziwego silnika reguł.

Charlie Martin
źródło
0

Zdecydowanie polecam silniki reguł biznesowych, takie jak Drools, jako open source lub Commercial Rules Engine, takie jak LiveRules.

  • Kiedy masz wiele polityk biznesowych, które mają niestabilny charakter, bardzo trudno jest utrzymać tę część kodu podstawowej technologii.
  • Silnik reguł zapewnia dużą elastyczność struktury i jest łatwy do zmiany i wdrożenia.
  • Mechanizmów reguł nie należy używać wszędzie, ale należy go używać, gdy istnieje wiele zasad, w których regularne zmiany są nieuniknione.
muruga
źródło
0

Naprawdę nie rozumiem niektórych punktów, takich jak:
a) ludzie biznesu muszą bardzo dobrze rozumieć biznes lub;
b) brak zgody co do ludzi biznesu nie musi znać reguły.

Dla mnie, jako osoby po prostu dotykającej BRE , korzyści płynące z BRE to tak zwane umożliwienie systemowi dostosowania się do zmian biznesowych, dlatego skupia się na adaptacji do zmian.
Czy ma znaczenie, czy reguła ustawiona w czasie x różni się od reguły skonfigurowanej w czasie y, ponieważ:
a) ludzie biznesu nie rozumieją biznesu lub;
b) biznesmeni nie rozumieją zasad?

xw
źródło