Là bật và tắt các tính năng UI (hoặc khác) dựa trên ngày - một mùi mã?

Chúng tôi có một hệ thống khủng khiếp được viết bằng ASP.NET 2.0 mà chúng tôi cần thêm một số chức năng. Vấn đề là một sản phẩm nhất định có các tính năng UI phải được bật cho doanh nghiệp được bắt đầu sau một ngày nhất định (và các sản phẩm khác đã tắt), trong khi trang phải xuất hiện tương tự cho doanh nghiệp hiện tại.

Tôi đang cố gắng viết lại trang cho doanh nghiệp mới vì theo bản năng tôi thấy ý tưởng về các chuyển đổi UI UI dựa trên ngày và việc trộn các điều khiển web cho doanh nghiệp cũ và mới là "không gọn gàng" (vì muốn có một từ tốt hơn ).

Có phải thực tiễn có các tính năng UI dựa trên thời gian là một thực tiễn được chấp nhận rộng rãi và nếu không, những rủi ro đã biết khi theo đuổi quá trình hành động đó là gì?

Không có gì sai khi điều chỉnh UI dựa trên các tính năng nào được bật cho khách hàng hoặc loại triển khai nào họ đã chọn, nhưng thay đổi nên

1. phụ thuộc vào các cờ có ý nghĩa, ví dụ "Lawr_EXPORT" để bật / tắt tùy chọn xuất, không dựa trên các so sánh ngày lạ. UI không có doanh nghiệp biết quy tắc kinh doanh về những gì đã được xuất bản khi nào, nó chỉ nên hoàn thành nhiệm vụ UI và tuân theo các hướng dẫn cụ thể về UI.
2. Được kiểm soát phía máy chủ, để khách hàng không thể lén lút kích hoạt các tính năng mà họ chưa trả tiền.

(Lưu ý rằng điều ngược lại - dis tính năng abling sau một thời gian nhất định - là một lớn không-không trừ khi bạn đã thông báo rõ ràng rằng bạn đang bán một phiên bản thử nghiệm thời gian hạn chế Tạo như vậy. Bom thời gian trong mọi trường hợp khác sẽ làm cho mọi người ghét bạn nhanh hơn hầu hết mọi thứ khác.)

Yêu cầu tự nó không có vấn đề, nhưng có những cách tốt và xấu để thực hiện nó. Nếu bạn có mã được sao chép và dán khắp nơi giống như:

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

Điều đó sẽ trở nên điên rồ khó duy trì, ngay cả khi nó có vẻ nhanh hơn vào lúc này. Ví dụ, có thể tại một số điểm, một số khách hàng lớn tuổi sẽ muốn giao diện mới. Có thể tại một thời điểm nào đó sẽ có một cấu hình thứ ba với ngày giới hạn riêng của nó.

Lý tưởng nhất là bạn muốn câu lệnh if này xuất hiện chính xác một lần trong mã của bạn, tốt nhất là ở phía máy chủ. Tuy nhiên, bạn cũng muốn tránh chỉ sao chép toàn bộ ứng dụng và thực hiện thay đổi. Tìm mã chung và tính hệ số đó, sau đó tạo các hàm riêng biệt nhỏ cho các phần khác nhau. Sau đó kích hoạt hoặc vô hiệu hóa các chức năng đó từ một vị trí trung tâm.

Đó là một yêu cầu và trong khi nó dường như có mùi - về cơ bản cấu hình dựa trên giá trị thời gian - không có lý do nào có thể sử dụng thời gian để thay đổi giao diện người dùng của bạn. Trường hợp cổ điển là màn hình satnav thay đổi từ màu sáng vào ban ngày sang chủ đề tối vào ban đêm (và nếu bạn thực sự tận tâm, một màu bị tắt ở giữa).

Tuy nhiên, một điều tôi có thể đề xuất là một cải tiến là loại bỏ khái niệm ngày cho phép điều khiển, nhưng số phiên bản. Phiên bản đặt cấu hình UI (nghĩa là bạn có cờ để cấu hình cho NewCustomer và trong tương lai có thể được mở rộng để phục vụ cho các điều khiển bổ sung mà NewNewCustomer muốn, v.v.). Điều này dễ dàng hơn nhiều để xử lý mã, và có mùi thơm hơn nhiều.

Sau đó, bạn chỉ có 1 vấn đề là đặt số phiên bản dựa trên một số tiêu chí và điều này có thể được thực hiện bằng kiểm tra ngày hôm nay, có thể là tùy chọn cấu hình phía máy chủ sau hoặc thậm chí là cookie được đặt bởi người dùng đăng nhập một thời gian tương lai.

Điều này cảm thấy giống như một trường hợp đặc biệt của một câu hỏi tổng quát hơn: đó có phải là một thực tiễn xấu để vô hiệu hóa các tính năng UI vì lý do cụ thể theo các quy tắc được xác định trước? Câu trả lời, sau đó, "tất nhiên là không." Việc bàn giao ngày nói riêng có thể khó khăn vì ngày và giờ rất khó khăn , nhưng theo nguyên tắc chung, không có lý do chính đáng nào để không làm điều đó nếu đó là những gì yêu cầu kinh doanh của bạn yêu cầu.

Nếu những thay đổi liên quan đến một số mục đích kinh doanh cụ thể nhạy cảm với ngày tháng, thì đó là một điều ác cần thiết.

Nếu đây là về việc triển khai một bản sửa đổi cho chương trình sẽ thay đổi chương trình vĩnh viễn và thiết kế cũ sẽ không bao giờ được sử dụng lại, thì tốt hơn hết là bạn nên triển khai một bản cập nhật vào đúng thời điểm.

Nghe có vẻ tốt. Điều khá phổ biến là giao diện người dùng thích ứng với các người dùng khác nhau, ví dụ ở đây trên stackoverflow các tính năng khác nhau được bật hoặc tắt dựa trên nghiệp lực của từng người dùng.

Lý do bạn không thích nó là vì nó rõ ràng làm tăng thêm độ phức tạp liên quan đến một giải pháp mà mọi người đều nhìn thấy cùng một giao diện người dùng. Tuy nhiên, sự phức tạp dường như là phức tạp thiết yếu , tức là. đó là một yêu cầu kinh doanh, không phải là một tạo tác của một quyết định kiến ​​trúc tồi. Tất nhiên nó sẽ có một chi phí (mà bạn nên giao tiếp với doanh nghiệp), nhưng nếu doanh nghiệp quyết định nó đáng giá, bạn hãy tiếp tục thực hiện nó.

Rủi ro đã biết: Rủi ro lớn nhất có lẽ là kiểm tra UI trong các cấu hình khác nhau. Nếu bạn bắt đầu đi vào con đường kích hoạt / vô hiệu hóa các tính năng UI cho nhiều nhóm người dùng khác nhau, bạn có thể nhanh chóng nhận được sự bùng nổ của các cấu hình có thể.

Bạn cũng nên đảm bảo thực hiện các hạn chế trong lớp logic nghiệp vụ, để bạn xác minh rằng khách hàng không thể thực hiện các thao tác mà họ không được phép, ngay cả khi giao diện người dùng không nên thực hiện ngay từ đầu:

Những gì bạn đang mô tả là khái niệm hẹn hò hiệu quả , không có nghĩa là một ý tưởng mới lạ và cốt lõi là một loại vấn đề tạm thời mà bạn có thể áp dụng mô hình thời gian .

Về cơ bản những gì bạn sẽ làm trong cơ sở dữ liệu của mình là áp dụng một ngày hiệu lực cho các mô-đun mẫu hoặc phiên bản biểu mẫu (sau đây gọi là các thành phần), lưu trữ một số siêu dữ liệu về các thành phần đó và ngày bắt đầu / kết thúc hiệu quả của chúng. Tất nhiên bạn cũng sẽ cần một số dữ liệu về người dùng của mình trong ứng dụng.

Có vẻ như bạn có thể có một số lý do hấp dẫn khác để xem xét viết lại ứng dụng này. Nếu vấn đề hẹn hò hiệu quả là vấn đề duy nhất của bạn, tôi khuyên bạn nên thực hiện hẹn hò hiệu quả là một lựa chọn tốt hơn. Nếu không, bạn sẽ phải đánh giá điều đó dựa trên kịch bản của bạn.

Đây là một tính năng chuyển đổi với kích hoạt dựa trên ngày - hoàn toàn hợp lệ. Hãy tưởng tượng nếu tính năng này chỉ được sử dụng trong thời gian khuyến mại hoặc phải kết thúc khi một quy định mới của chính phủ có hiệu lực vào một ngày nhất định.

Bạn đang làm việc trong APS.NET và JavaScript, nhưng khung chuyển đổi tính năng Java hoạt động Togglz đặc biệt có quy tắc kích hoạt dựa trên ngày (và thời gian!) .