ชุมชน software engineering กำลังมีการถกเถียงอย่างเข้มข้นเกี่ยวกับหลักการพื้นฐานที่สำคัญที่สุดอย่างหนึ่ง นั่นคือโค้ดควรป้องกันสถานะที่ไม่ถูกต้องอย่างเข้มงวด หรือควรให้ความยืดหยุ่นเพื่อการเปลี่ยนแปลงในอนาคต การอภิปรายนี้มีจุดศูนย์กลางอยู่ที่หลักการออกแบบยอดนิยมที่เรียกว่า make invalid states unrepresentable ซึ่งสนับสนุนให้มีข้อจำกัดที่เข้มงวดในระบบซอฟต์แวร์เพื่อป้องกันบั๊กและปรับปรุงความน่าเชื่อถือ
ความขัดแย้งหลัก: Domain Models กับ Storage Representations
ส่วนใหญ่ของชุมชนโต้แย้งว่าการวิพากษ์วิจารณ์เดิมนั้นพลาดความแตกต่างที่สำคัญไป นักพัฒนาหลายคนเชื่อว่า domain models ควรยังคงเข้มงวดและมีการกำหนดที่ชัดเจน ในขณะที่ storage layers เช่น databases และ network protocols สามารถมีความยืดหยุ่นมากกว่า การแยกนี้ช่วยให้นักพัฒนาสามารถรักษา business logic ที่สะอาดในขณะที่รองรับความซับซ้อนของการจัดเก็บและส่งข้อมูลในโลกแห่งความเป็นจริง
การถกเถียงนี้เผยให้เห็นความเข้าใจผิดพื้นฐานเกี่ยวกับตำแหน่งที่ควรใช้ข้อจำกัด นักวิจารณ์โต้แย้งว่าการผสมผสาน database schemas กับ domain models นำไปสู่ความสับสนเกี่ยวกับจุดประสงค์ที่แท้จริงของหลักการนี้ พวกเขาแนะนำว่าการ parsing และ validation ควรเกิดขึ้นที่ขอบเขตระหว่างเลเยอร์เหล่านี้ ทำให้แต่ละส่วนสามารถทำหน้าที่ตามจุดประสงค์เฉพาะได้อย่างมีประสิทธิภาพ
ภาษาและเครื่องมือมีอิทธิพลต่อการตัดสินใจในการออกแบบ
ภาษาโปรแกรมมิ่งที่ใช้มีอิทธิพลอย่างมากต่อแนวทางที่ได้ผลดีที่สุด นักพัฒนาที่ทำงานกับภาษา functional ที่มี type system แข็งแกร่งเช่น Haskell , F# หรือ Rust รายงานความสำเร็จอย่างมากกับการบังคับใช้ข้อจำกัดที่เข้มงวด เพราะภาษาเหล่านี้ให้เครื่องมือ refactoring ที่ทรงพลังและการรับประกันใน compile-time Compiler จะตรวจจับปัญหาส่วนใหญ่ก่อนที่โค้ดจะไปถึงการใช้งานจริง ทำให้การเปลี่ยนแปลงปลอดภัยและคาดการณ์ได้มากขึ้น
ในทางตรงกันข้าม นักพัฒนาที่ใช้ภาษาที่มีความยืดหยุ่นมากกว่าหรือมี type systems ที่อ่อนแอกว่า พบว่าความยืดหยุ่นมักจะเหนือกว่าข้อจำกัดที่เข้มงวด หากไม่มีการสนับสนุนจาก compiler ที่แข็งแกร่ง ต้นทุนในการรักษาข้อจำกัดที่แข็งแกร่งอาจมากกว่าประโยชน์ที่ได้รับ โดยเฉพาะเมื่อความต้องการเปลี่ยนแปลงบ่อยครั้ง
ความเหมาะสมของภาษาโปรแกรมสำหรับข้อจำกัดที่เข้มงวด:
ความเหมาะสมสูง:
- Haskell , F , Rust , Swift
- ระบบประเภทข้อมูลที่แข็งแกร่งพร้อมการสนับสนุนการปรับโครงสร้างโค้ดที่ยอดเยี่ยม
ความเหมาะสมปานกลาง:
- Java , C , TypeScript
- เครื่องมือที่ดีแต่การจัดการข้อจำกัดมีความละเอียดมากกว่า
ความเหมาะสมต่ำกว่า:
- JavaScript , Python , Ruby
- ลักษณะแบบไดนามิกทำให้การบังคับใช้ข้อจำกัดมีความท้าทายมากขึ้น
บริบทมีความสำคัญ: Closed Systems กับ Open Systems
ประเภทของระบบที่กำลังสร้างมีผลกระทบอย่างมากต่อแนวทางที่เหมาะสมที่สุด Scientific computing, embedded systems และแอปพลิเคชันทางการเงินมักจะได้ประโยชน์จากข้อจำกัดที่เข้มงวด เพราะสถานะที่ไม่ถูกต้องอาจนำไปสู่ความล้มเหลวร้ายแรงหรือผลลัพธ์ที่ผิดพลาด ระบบเหล่านี้ทำงานในสภาพแวดล้อมที่ค่อนข้างปิดและมีความต้องการที่กำหนดไว้อย่างชัดเจน
Web applications และ distributed systems เผชิญกับความท้าทายที่แตกต่างกัน พวกเขาต้องจัดการกับ input จากผู้ใช้ที่คาดเดาไม่ได้ ผสานรวมกับบริการภายนอก และพัฒนาอย่างรวดเร็วตามความต้องการทางธุรกิจที่เปลี่ยนแปลง ในบริบทเหล่านี้ ความยืดหยุ่นบางอย่างในการแสดงสถานะสามารถป้องกันการออกแบบระบบใหม่ที่มีต้นทุนสูงเมื่อความต้องการเปลี่ยนแปลงอย่างหลีกเลี่ยงไม่ได้
ข้อจำกัดที่แข็งแกร่งยิ่งขึ้น ก็ยิ่งอันตรายมากขึ้น เมื่อฉันพูดว่าข้อจำกัดนั้นแข็งแกร่ง ฉันหมายความว่ามันยากมากที่จะยกเลิกหากคุณต้องการ
ประเภทข้อจำกัดตามความยากในการเปลี่ยนแปลง:
- ข้อจำกัดแบบอ่อน: การตรวจสอบความถูกต้องในระดับโค้ด (ง่ายต่อการแก้ไข)
- ข้อจำกัดระดับกลาง: โครงสร้างฐานข้อมูลที่ต้องการการย้ายข้อมูล
- ข้อจำกัดแบบแข็ง: ข้อกำหนดโปรโตคอลและสถาปัตยกรรมระบบแบบกระจาย
- ข้อจำกัดที่ไม่เปลี่ยนแปลงได้: ระบบ Blockchain และระบบบัญชีแยกประเภท
การหาสมดุลที่เหมาะสม
ชุมชนโดยทั่วไปเห็นด้วยว่าทั้งสองแนวทางมีข้อดี แต่สิ่งสำคัญคือการเลือกระดับ abstraction ที่เหมาะสมสำหรับข้อจำกัด เลเยอร์ภายในของระบบสามารถยังคงยืดหยุ่นและเป็นพื้นฐาน ในขณะที่เลเยอร์ภายนอกกำหนดข้อจำกัดเฉพาะทางธุรกิจ สถาปัตยกรรมแบบหอมหัวแป้นี้ช่วยให้ระบบปรับตัวกับความต้องการที่เปลี่ยนแปลงโดยไม่ต้องเขียนใหม่ทั้งหมด
การถกเถียงนี้ยังเน้นย้ำถึงความสำคัญของการพิจารณาต้นทุนการบำรุงรักษาระยะยาว แม้ว่าข้อจำกัดที่เข้มงวดสามารถป้องกันบั๊กได้หลายตัว แต่ก็อาจทำให้การเปลี่ยนแปลงบางประเภทมีต้นทุนสูงมาก ความท้าทายสำหรับ software architects คือการทำนายว่าข้อจำกัดใดจะยังคงเสถียรตลอดเวลา และข้อจำกัดใดที่อาจต้องพัฒนา
การอภิปรายที่กำลังดำเนินอยู่นี้สะท้อนถึงความตึงเครียดที่กว้างขึ้นใน software engineering ระหว่างความปลอดภัยและความยืดหยุ่น เมื่อระบบมีความซับซ้อนมากขึ้นและความต้องการมีความคล่องตัวมากขึ้น การหาสมดุลที่เหมาะสมจึงมีความสำคัญมากขึ้นสำหรับความสำเร็จในระยะยาว
อ้างอิง: 'Make invalid states unrepresentable' considered harmful