Czy włączanie i wyłączanie funkcji interfejsu użytkownika (lub innych) na podstawie dat - zapach kodu?

Mamy okropny system napisany w ASP.NET 2.0, do którego musimy dodać trochę funkcjonalności. Problem polega na tym, że określony produkt ma funkcje interfejsu użytkownika, które muszą być włączone dla firmy zainicjowanej po określonej dacie (a inne wyłączone), podczas gdy strona musi wyglądać tak samo dla istniejącej firmy.

Zwracam się o przepisanie strony dla nowej firmy, ponieważ instynktownie znajduję pomysł przełączników interfejsu użytkownika JavaScript opartych na dacie i mieszania kontrolek internetowych dla starej i nowej firmy jako „nieporządnych” (z braku lepszego słowa) ).

Czy praktyka polegająca na korzystaniu z interfejsu użytkownika opartego na czasie jest powszechnie akceptowaną praktyką, a jeśli nie, jakie są znane zagrożenia związane z realizacją tego działania?

Nie ma nic złego w ulepszaniu interfejsu użytkownika w oparciu o to, które funkcje są włączone dla klienta lub jakie typy wdrożenia wybrali, ale zmiana powinna

1. zależą od znaczących flag, np. „HAVE_EXPORT”, aby włączyć / wyłączyć opcję eksportu, a nie od dziwnych porównań dat. Interfejs użytkownika nie ma biznesu znającego regułę biznesową dotyczącą tego, co zostało opublikowane, kiedy powinien wypełniać tylko swoje zadanie interfejsu użytkownika i przestrzegać instrukcji specyficznych dla interfejsu użytkownika.
2. Kontroluj po stronie serwera, aby klient nie mógł w tajemniczy sposób włączyć funkcji, za które nie zapłacił.

(Należy pamiętać, że przeciwnie - dis abling cechy po pewnym czasie - jest głównym no-no chyba, że wyraźnie komunikowane, że jesteś sprzedaży czasowo ograniczona wersja próbna Tworzenie takich. Bomby zegarowe w żadnych innych okolicznościach będzie ludzie nienawidzą jesteś szybszy niż cokolwiek innego.)

Samo wymaganie nie jest problematyczne, ale istnieją dobre i złe sposoby jego realizacji . Jeśli kod został skopiowany i wklejony w całym miejscu, które wygląda:

if (businessInitiationDate > cutoffDate)
  enableNewControlsForThisOneLittlePiece();
else
  enableOldControlsForThisOneLittlePiece();

To będzie szalenie trudne do utrzymania, nawet jeśli wydaje się w tej chwili szybsze. Na przykład, może w pewnym momencie niektórzy starsi klienci będą chcieli nowy wygląd. Może w pewnym momencie nastąpi trzecia konfiguracja z własną datą graniczną.

Idealnie byłoby, gdyby instrukcja if pojawiła się dokładnie w kodzie, najlepiej po stronie serwera. Jednak chcesz także uniknąć powielania całej aplikacji i wprowadzania zmian. Znajdź wspólny kod i podziel go na czynniki, a następnie utwórz małe oddzielne funkcje tylko dla różnych części. Następnie włącz lub wyłącz te funkcje z jednego centralnego miejsca.

Jest to wymóg i chociaż wydaje się śmierdzący - w zasadzie konfiguracja oparta na wartości datetime - nie ma powodu, dla którego nie można użyć czasu do zmiany interfejsu użytkownika. Klasyczna obudowa to wyświetlacz satnav, który zmienia się z jasnych kolorów w ciągu dnia na ciemny motyw w nocy (a jeśli jesteś naprawdę oddany, stonowany kolor pomiędzy).

Jedną rzeczą, którą mogę zasugerować jako ulepszenie, jest usunięcie koncepcji daty, która umożliwia sterowanie, ale numer wersji. Wersja ustawia konfigurację interfejsu użytkownika (tzn. Masz flagę, mówiącą o konfiguracji dla NewCustomer, a w przyszłości można ją rozszerzyć, aby uwzględnić dodatkowe elementy sterujące, których chce NewNewCustomer itd.). Jest to o wiele łatwiejsze w obsłudze w kodzie i ładniej pachnie.

Wtedy masz tylko 1 problem, który polega na ustawieniu numeru wersji na podstawie niektórych kryteriów, i można to zrobić przez sprawdzenie daty dzisiaj, być może opcję konfiguracji po stronie serwera później, lub nawet plik cookie, który jest ustawiany przez logowanie użytkownika jakiś czas w przyszłość.

Wydaje się to szczególnym przypadkiem bardziej ogólnego pytania: czy złą praktyką jest wyłączanie funkcji interfejsu użytkownika z określonych powodów zgodnie z wcześniej zdefiniowanymi regułami? Zatem odpowiedź brzmi „oczywiście nie”. W szczególności przekazywanie dat może być trudne, ponieważ daty i godziny są trudne , ale na ogół nie ma dobrego powodu, aby tego nie robić, jeśli wymagają tego wymagania biznesowe.

Jeśli zmiany mają związek z jakimś konkretnym celem biznesowym, który jest wrażliwy na datę, to jest to zło konieczne.

Jeśli chodzi o wdrażanie wersji programu, która zmieni program na stałe, a stary projekt nigdy nie będzie ponownie używany, lepiej po prostu wdrożyć aktualizację we właściwym czasie.

Brzmi dobrze. Interfejs użytkownika jest dość często dostosowywany do różnych użytkowników, np. Tutaj przy przepełnieniu stosu różne funkcje są włączane lub wyłączane w zależności od karmy konkretnego użytkownika.

Powodem, dla którego ci się nie podoba jest to, że w oczywisty sposób zwiększa złożoność rozwiązania, w którym wszyscy widzą ten sam interfejs użytkownika. Jednak złożoność wydaje się być podstawową złożonością , tj. jest to wymóg biznesowy, a nie artefakt złej decyzji architektonicznej. Oczywiście będzie to wiązało się z pewnym kosztem (który powinieneś przekazać firmie), ale jeśli firma zdecyduje, że jest tego warte, możesz wdrożyć go.

Znane zagrożenia: największym ryzykiem jest prawdopodobnie przetestowanie interfejsu użytkownika w różnych konfiguracjach. Jeśli zaczniesz iść w kierunku włączania / wyłączania funkcji interfejsu użytkownika dla różnych grup użytkowników, możesz szybko uzyskać eksplozję możliwych konfiguracji.

Należy również upewnić się, że zastosowano ograniczenia w warstwie logiki biznesowej, aby upewnić się, że klienci nie mogą wykonywać operacji, na które nie mają pozwolenia, nawet jeśli interfejs użytkownika nie powinien przede wszystkim:

To, co opisujesz, to koncepcja efektywnego randkowania , która w żadnym wypadku nie jest nowatorskim pomysłem, a jej rdzeniem jest rodzaj problemu doczesnego, do którego możesz zastosować wzór czasowy .

Zasadniczo to, co zrobiłbyś w bazie danych, to zastosowanie daty wejścia w życie w celu utworzenia modułów lub wersji formularzy (zwanych tutaj komponentami), przechowywanie niektórych metadanych dotyczących tych składników oraz ich dat rozpoczęcia / zakończenia. Oczywiście będziesz potrzebować również danych o swoich użytkownikach w aplikacji.

Wygląda na to, że masz inne, bardziej przekonujące powody, aby rozważyć przepisanie tej aplikacji. Jeśli Twoim jedynym problemem są skuteczne randki, sugeruję, że lepszym rozwiązaniem może być wdrożenie skutecznego randkowania. Jeśli nie, musisz to ocenić na podstawie własnego scenariusza.

Jest to funkcja przełączana z aktywacją na podstawie daty - co jest całkowicie ważne. Wyobraź sobie, że ta funkcja mogła być używana tylko w okresie promocyjnym, lub musiała zakończyć się, gdy w określonym dniu wejdzie nowa regulacja rządowa.

Pracujesz w APS.NET i JavaScript, ale działanie ramki przełączania funkcji Java Togglz ma konkretną regułę aktywacji opartą na dacie (i czasie!) .