การเปิดและปิดคุณสมบัติ UI (หรืออื่น ๆ ) ขึ้นอยู่กับวันที่ - รหัสกลิ่นหรือไม่

เรามีระบบอันยิ่งใหญ่ที่เขียนใน ASP.NET 2.0 ที่เราต้องเพิ่มฟังก์ชั่นบางอย่าง ปัญหาคือผลิตภัณฑ์บางอย่างมีคุณสมบัติ UI ที่จะต้องเปิดใช้งานสำหรับธุรกิจที่เริ่มต้นหลังจากวันที่แน่นอน (และอื่น ๆ ปิด) ในขณะที่หน้าจะต้องเหมือนกันสำหรับธุรกิจที่มีอยู่

ฉันกำลังผลักดันให้มีการเขียนหน้าใหม่สำหรับธุรกิจใหม่เนื่องจากฉันพบความคิดเกี่ยวกับสวิตช์ JavaScript UI ที่อิงตามวันที่และการผสมตัวควบคุมเว็บสำหรับธุรกิจเก่าและใหม่ให้เป็น "ไม่เรียบร้อย" (สำหรับคำที่ดีกว่า )

การฝึกฝนให้มี UI ตามเวลาเป็นคุณลักษณะที่เป็นที่ยอมรับอย่างกว้างขวางและหากไม่เป็นเช่นนั้นความเสี่ยงที่ทราบกันดีในการใฝ่หาแนวทางปฏิบัตินั้นคืออะไร?

ไม่มีอะไรผิดปกติกับการปรับแต่ง UI ตามคุณลักษณะที่เปิดใช้งานสำหรับลูกค้าหรือประเภทการปรับใช้ที่เลือกไว้ แต่การเปลี่ยนแปลงควร

1. ขึ้นอยู่กับการตั้งค่าสถานะที่มีความหมายเช่น "HAVE_EXPORT" เพื่อเปิด / ปิดตัวเลือกการส่งออกไม่ใช่การเปรียบเทียบวันที่แปลก ๆ UI ไม่มีธุรกิจที่รู้ว่ากฎธุรกิจเกี่ยวกับสิ่งที่เผยแพร่เมื่อใดมันควรปฏิบัติตามภารกิจ UI เท่านั้นและปฏิบัติตามคำแนะนำเฉพาะ UI
2. ได้รับการควบคุมด้านเซิร์ฟเวอร์เพื่อให้ลูกค้าไม่สามารถเปิดใช้งานคุณลักษณะที่ไม่ได้ชำระเงินอย่างซ่อนเร้น

(หมายเหตุว่าตรงข้าม - โรคคุณลักษณะ Abling หลังจากระยะเวลาหนึ่ง - เป็นใหญ่ไม่มีไม่มีถ้าคุณไม่ได้สื่อสารอย่างชัดเจนว่าคุณกำลังขายรุ่นทดลองใช้เวลา จำกัด เช่นการสร้าง. ระเบิดเวลาภายใต้สถานการณ์อื่น ๆ ที่จะทำให้คนเกลียด คุณเร็วกว่าเกือบทุกอย่าง)

ความต้องการของตัวเองไม่ได้มีปัญหา แต่มีวิธีที่ดีและไม่ดีที่จะใช้มัน หากคุณมีรหัสคัดลอกและวางทั่วสถานที่ที่มีลักษณะ:

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

มันคงเป็นเรื่องยากที่จะรักษาแม้ว่ามันจะดูเร็วขึ้นในขณะนี้ ตัวอย่างเช่นในบางครั้งลูกค้าเก่าบางรายอาจต้องการรูปลักษณ์ใหม่ บางทีในบางจุดอาจมีการกำหนดค่าที่สามพร้อมกับวันที่ตัดออก

หากคุณต้องการให้คำสั่งนี้ปรากฏขึ้นในรหัสของคุณหนึ่งครั้งโดยเฉพาะอย่างยิ่งในฝั่งเซิร์ฟเวอร์ อย่างไรก็ตามคุณต้องการหลีกเลี่ยงการทำซ้ำทั้งแอปพลิเคชันและทำการเปลี่ยนแปลง ค้นหารหัสทั่วไปและแยกตัวออกมาจากนั้นสร้างฟังก์ชั่นแยกขนาดเล็กสำหรับชิ้นส่วนที่แตกต่างกัน จากนั้นเปิดใช้งานหรือปิดใช้งานฟังก์ชั่นเหล่านั้นได้จากที่เดียว

มันเป็นข้อกำหนดและในขณะที่มันส่งกลิ่น - โดยทั่วไปการกำหนดค่าตามค่าวันที่และเวลา - ไม่มีเหตุผลที่เวลาไม่สามารถใช้ในการเปลี่ยน UI ของคุณ เคสคลาสสิกเป็นจอแสดงผล satnav ที่เปลี่ยนจากสีสดใสในเวลากลางวันเป็นธีมมืดในตอนกลางคืน (และถ้าคุณทุ่มเทจริงๆสีที่ไม่ออกเสียงอยู่ระหว่างนั้น)

อย่างไรก็ตามสิ่งหนึ่งที่ฉันสามารถแนะนำเป็นการปรับปรุงคือการลบแนวคิดของวันที่ที่เปิดใช้งานการควบคุม แต่เป็นหมายเลขเวอร์ชัน เวอร์ชันตั้งค่าการกำหนดค่า UI (เช่นคุณมีการตั้งค่าสถานะเพื่อบอกว่ากำหนดค่าสำหรับ NewCustomer และในอนาคตสามารถขยายเพื่อรองรับการควบคุมเพิ่มเติมที่ NewNewCustomer ต้องการและอื่น ๆ ) ง่ายต่อการจัดการกับโค้ดและมีกลิ่นที่ดีกว่า

จากนั้นคุณมีปัญหา 1 ข้อเท่านั้นซึ่งตั้งค่าหมายเลขรุ่นตามเกณฑ์บางอย่างและสามารถทำได้โดยการตรวจสอบวันที่วันนี้อาจเป็นตัวเลือกการกำหนดค่าฝั่งเซิร์ฟเวอร์ในภายหลังหรือแม้แต่คุกกี้ที่กำหนดโดยผู้ใช้เข้าสู่ระบบในบางครั้ง อนาคต.

สิ่งนี้รู้สึกเหมือนเป็นกรณีพิเศษของคำถามทั่วไปที่มากขึ้น: เป็นวิธีปฏิบัติที่ไม่ดีหรือไม่ที่จะปิดใช้งานคุณลักษณะ UI สำหรับเหตุผลเฉพาะตามกฎที่กำหนดไว้ล่วงหน้าหรือไม่ คำตอบคือ "ไม่แน่นอน" โดยเฉพาะการส่งวันที่อาจเป็นเรื่องยุ่งยากเพราะวันที่และเวลานั้นยากแต่โดยทั่วไปแล้วไม่มีเหตุผลที่ดีที่จะไม่ทำหากเป็นสิ่งที่ธุรกิจของคุณต้องการ

หากการเปลี่ยนแปลงนั้นเกี่ยวข้องกับวัตถุประสงค์ทางธุรกิจเฉพาะเจาะจงที่มีความอ่อนไหวด้านวันแสดงว่าเป็นความชั่วร้ายที่จำเป็น

หากนี่เป็นเรื่องเกี่ยวกับการปรับใช้การแก้ไขกับโปรแกรมที่จะเปลี่ยนโปรแกรมอย่างถาวรและการออกแบบเก่าจะไม่ถูกนำมาใช้อีกครั้งดังนั้นจะเป็นการดีกว่าที่จะปรับใช้การอัปเดตในเวลาที่ถูกต้อง

ฟังดูดี เป็นเรื่องปกติมากที่ UI จะปรับให้เข้ากับผู้ใช้ที่แตกต่างกันเช่นที่นี่ในสแต็กโอเวอร์โฟลว์คุณสมบัติที่แตกต่างกันถูกเปิดใช้งานหรือปิดการใช้งานตามกรรมของผู้ใช้แต่ละคน

เหตุผลที่คุณไม่ชอบก็คือมันเพิ่มความซับซ้อนเมื่อเทียบกับโซลูชันที่ทุกคนเห็น UI เดียวกัน อย่างไรก็ตามความซับซ้อนนั้นดูเหมือนจะเป็นความซับซ้อนที่สำคัญเช่น มันเป็นความต้องการทางธุรกิจไม่ใช่สิ่งประดิษฐ์ของการตัดสินใจทางสถาปัตยกรรมที่ไม่ดี แน่นอนว่ามันจะมีค่าใช้จ่าย (ซึ่งคุณควรสื่อสารกับธุรกิจ) แต่ถ้าธุรกิจตัดสินใจว่ามันคุ้มค่ากับค่าใช้จ่ายคุณต้องดำเนินการต่อไป

ความเสี่ยงที่ทราบ: ความเสี่ยงที่ใหญ่ที่สุดน่าจะได้รับการทดสอบ UI ในการกำหนดค่าต่างๆ หากคุณเริ่มที่จะเปิดหรือปิดการใช้งานคุณสมบัติ UI สำหรับกลุ่มผู้ใช้ที่หลากหลายคุณจะได้รับการกำหนดค่าที่เป็นไปได้อย่างรวดเร็ว

คุณควรตรวจสอบให้แน่ใจว่าได้ใช้ข้อ จำกัด ในเลเยอร์ตรรกะทางธุรกิจดังนั้นคุณจึงตรวจสอบว่าลูกค้าไม่สามารถดำเนินการที่ไม่ได้รับอนุญาตแม้ว่า UI จะไม่ทำให้เป็นไปได้ตั้งแต่แรก:

สิ่งที่คุณกำลังอธิบายคือแนวคิดของการออกเดทที่มีประสิทธิภาพซึ่งไม่ได้หมายความว่าเป็นแนวคิดที่แปลกใหม่และที่สำคัญคือปัญหาทางโลกซึ่งคุณสามารถนำไปใช้ในรูปแบบชั่วคราวได้

โดยเฉพาะอย่างยิ่งสิ่งที่คุณจะทำอย่างไรในฐานข้อมูลของคุณใช้การวันที่มีผลอย่างใดอย่างหนึ่งรูปแบบโมดูลหรือรูปแบบรุ่น (ในที่นี้จะเรียกว่าเป็นส่วนประกอบ) การจัดเก็บข้อมูลเมตาบางอย่างเกี่ยวกับส่วนประกอบเหล่านั้นและวันที่เริ่มต้น / สิ้นสุดของพวกเขาที่มีประสิทธิภาพ แน่นอนคุณจะต้องการข้อมูลบางอย่างเกี่ยวกับผู้ใช้ของคุณในแอปพลิเคชันเช่นกัน

ดูเหมือนคุณอาจมีเหตุผลที่น่าสนใจมากกว่านี้ในการพิจารณาการเขียนแอปพลิเคชันนี้ใหม่ หากปัญหาการออกเดทที่มีประสิทธิภาพเป็นปัญหาเดียวของคุณฉันขอแนะนำว่าการใช้การนัดหมายที่มีประสิทธิภาพอาจเป็นตัวเลือกที่ดีกว่า ถ้าไม่คุณจะต้องประเมินสิ่งนั้นตามสถานการณ์ของคุณ

มันเป็นคุณสมบัติสลับกับการเปิดใช้งานตามวันที่ - ซึ่งถูกต้องสมบูรณ์ ลองนึกภาพว่าคุณสมบัตินี้มีไว้สำหรับใช้ในช่วงเวลาโปรโมชันเท่านั้นหรือต้องสิ้นสุดลงเมื่อกฎระเบียบของรัฐบาลใหม่เริ่มขึ้นในวันที่กำหนด

คุณกำลังทำงานใน APS.NET และ JavaScript แต่การทำงานเฟรมสลับคุณลักษณะ Java Togglz มีกฎการเปิดใช้งานตามวันที่ (และเวลา!) โดยเฉพาะ