Увімкнення та вимкнення функцій інтерфейсу користувача (або інших) на основі дат - кодовий запах?

У нас в ASP.NET 2.0 написана жахлива система, якій потрібно додати деяку функціональність. Проблема полягає в тому, що певний продукт має функції інтерфейсу, які потрібно ввімкнути для бізнесу, розпочатого після певної дати (а інші вимкнено), тоді як сторінка має бути такою ж, як для існуючого бізнесу.

Я наполягаю на перезаписі сторінки для нового бізнесу, оскільки інстинктивно знаходжу ідею перемикачів інтерфейсу JavaScript на основі дат, а змішування веб-елементів управління для старого та нового бізнесу стає "неохайним" (для бажання кращого слова ).

Чи є практика використання інтерфейсу, заснованого на часі, широко прийнята практика, і якщо ні, то які відомі ризики здійснення цього курсу дій?

Немає нічого поганого в налаштуванні інтерфейсу користувача, залежно від того, які функції увімкнено для клієнта або які типи розгортання вони обрали, але зміни повинні

1. залежать від значущих прапорів, наприклад "HAVE_EXPORT", щоб увімкнути / вимкнути опцію експорту, а не на дивні порівняння дат. Користувальницький інтерфейс не має жодної справи, яка знає ділове правило про те, що було опубліковано коли, воно повинно виконувати лише своє завдання інтерфейсу та дотримуватися конкретних інструкцій.
2. Будьте контрольовані на стороні сервера, щоб клієнт не міг вмикати функції, за які він не заплатив.

(Зауважимо , що зворотне - Дис abling особливо після певного часу - не є великим ні-ні , якщо ви не ясно повідомили , що ви продаєте часу обмежена пробну версію Створення таких. Бомби уповільненої дії при будь-яких інших обставин змусить людей ненавидіти ви швидше, ніж майже все інше.)

Сама вимога не є проблематичною, але є хороші та погані способи її виконання . Якщо ви скопіювали і вклеїли код по всьому місту, який виглядає так:

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

Це буде божевільно важко підтримувати, навіть якщо це здається швидшим на даний момент. Наприклад, можливо, у якийсь момент новий старий клієнт захоче новий вигляд. Можливо, в якийсь момент з’явиться третя конфігурація з власною датою відсічення.

В ідеалі, ви хочете, щоб це, якщо заява точно входила один раз у ваш код, бажано на стороні сервера. Однак ви також хочете уникати дублювання всієї програми та внесення змін. Знайдіть загальний код і розчленуйте його, а потім створіть невеликі окремі функції лише для різних частин. Потім увімкніть або вимкніть ці функції з одного центрального місця.

Це вимога, і хоча це виглядає смердючим - в основному конфігурацією, заснованою на значенні дати, - немає ніяких причин, щоб час зміни вашого інтерфейсу користувача не використовувався. Класичний випадок - це сатневий дисплей, який вночі змінюється від яскравих кольорів у денний до темних тем (а якщо ви справді віддані, приглушений колір посередині).

Однак одне, що я можу запропонувати як поліпшення, - це видалити концепцію дати, яка дозволяє контролювати, але номер версії. Версія встановлює конфігурацію інтерфейсу користувача (тобто у вас є прапор, який слід сказати, налаштований для NewCustomer, і в майбутньому його можна розширити, щоб задовольнити додаткові елементи управління, які NewNewCustomer бажає тощо). Це набагато простіше в роботі з кодом, і пахне набагато приємніше.

Тоді у вас є лише 1 випуск, який встановлює номер версії на основі деяких критеріїв, і це можна зробити сьогодні, перевіривши дату, можливо, пізніше параметр налаштування на стороні сервера або навіть файл cookie, який встановлюється входом користувача деякий час у майбутнє.

Це схоже на особливий випадок більш загального питання: чи погана практика відключити функції інтерфейсу з конкретних причин відповідно до заздалегідь визначених правил? Отже, відповідь - "звичайно, ні". Зокрема, вручення дати може бути складним, оскільки дати та час складні , але в цілому немає жодної вагомої причини цього не робити, якщо це вимагає ваших бізнес-вимог.

Якщо зміни пов'язані з якоюсь конкретною діловою метою, залежною від дати, то це є необхідним злом.

Якщо мова йде про розгортання версії до програми, яка буде постійно змінювати програму, а старий дизайн більше ніколи не буде використовуватися, то краще просто розгорнути оновлення в потрібний час.

Звучить чудово. Досить поширеним є пристосування інтерфейсу користувача до різних користувачів, наприклад, тут у потоковому потоці ввімкнено або відключено різні функції на основі карми окремого користувача.

Причина, яка вам не подобається, полягає в тому, що це, очевидно, додає складності відносно рішення, де всі бачать один і той же інтерфейс користувача. Однак складність, здається, є суттєвою складністю , тобто. це ділова вимога, а не артефакт поганого архітектурного рішення. Звичайно, це матиме вартість (яку ви повинні повідомити бізнесу), але якщо бізнес вирішить, що це коштує, ви будете вперед його впроваджувати.

Відомі ризики: найбільший ризик - це, мабуть, тестування інтерфейсу користувача у різних конфігураціях. Якщо ви почнете спускатись із шляху вмикання / відключення функцій інтерфейсу користувача для різних груп користувачів, ви можете швидко отримати вибух можливих конфігурацій.

Ви також повинні переконатися в застосуванні обмежень в шарі бізнес-логіки, щоб ви переконалися, що клієнти не можуть виконувати операції, до яких вони не дозволені, навіть якщо інтерфейс не повинен в першу чергу робити це можливим:

Те, що ви описуєте, - це концепція ефективного знайомства , яка аж ніяк не є новітньою ідеєю, а по суті є тимчасовою проблемою, до якої можна застосувати тимчасову схему .

По суті, те, що ви робите у вашій базі даних, - це застосувати дату набрання чинності або до модулів форми, або до форм версій (тут позначаються як компоненти), зберігаючи деякі метадані про ці компоненти та їх ефективні дати початку / кінця. Звичайно, вам також знадобляться деякі дані про ваших користувачів у програмі.

Схоже, у вас можуть бути ще деякі вагоміші причини розглянути можливість перезапису цього додатка. Якщо ефективні проблеми знайомства є вашими єдиними проблемами, я б припустив, що, можливо, найкраще реалізувати ефективні знайомства. Якщо ні, то вам доведеться оцінити це за вашим сценарієм.

Це функція перемикання функцій із активацією на основі дати - що цілком справедливо. Уявіть, чи ця функція використовувалась лише протягом рекламного періоду, або мала завершитись, коли в певну дату розпочнеться нова постанова уряду.

Ви працюєте в APS.NET та JavaScript, але робота з функцією перемикання кадрів Java Togglz спеціально має правило активації на основі дати (та часу!) .