- ข้อโต้แย้งคือ ปัญหายากหลัก ๆ ของการพัฒนาซอฟต์แวร์ส่วนใหญ่ไม่ได้เกิดขึ้นภายในโค้ด แต่เกิดที่ ขอบเขต (Boundary) ซึ่งเป็นจุดที่โค้ดกับโค้ด หรือระบบกับระบบ มาพบกัน
- ขอบเขต = จุดที่ความสนใจ ความรับผิดชอบ และบริบทที่แตกต่างกันมาพบกัน
- การแยกฟังก์ชัน การทำโมดูลาร์ การใช้ไมโครเซอร์วิส ฯลฯ แทบทุกการกระทำในการพัฒนาล้วนเป็นการสร้างขอบเขต
- ความย้อนแย้งคือ เราสร้างขอบเขตขึ้นมาเพื่อจัดการความซับซ้อน แต่ ตัวขอบเขตเองกลับกลายเป็นแหล่งกำเนิดของความซับซ้อนใหม่
ขอบเขตที่เกิดขึ้นในโค้ด
- ขอบเขตระหว่างผู้เรียก-ผู้ถูกเรียก: ความกำกวมของสัญญา เช่น การคืนค่า
null เทียบกับการ throw exception
- ขอบเขตของอินเทอร์เฟซ: กฎของ abstraction leak — ความซับซ้อนที่ซ่อนไว้สักวันหนึ่งจะทะลุขึ้นมาผ่านขอบเขต
- ขอบเขตของ dependency: API หรือไลบรารีภายนอกอาจเปลี่ยนแปลงได้โดยไม่มีสัญญาณล่วงหน้า
- ขอบเขตของการแปลงข้อมูล: เช่น object-relational impedance mismatch เมื่อข้ามขอบเขตแต่ละครั้ง ข้อมูลอาจบิดเบือนหรือสูญหาย
- ขอบเขตของความเชื่อถือ: ขอบเขตระหว่างข้อมูลที่ผ่านการตรวจสอบแล้วกับข้อมูลที่ยังไม่ผ่านการตรวจสอบ → เช่น การรับ webhook ที่ไม่มีลายเซ็น นำไปสู่ช่องโหว่ด้านความปลอดภัย
- ขอบเขตระหว่างการออกแบบ-การนำไปใช้จริง: ตั้งแต่ข้อกำหนด → การออกแบบ → การพัฒนา → การปฏิบัติการ ข้อมูลสูญหายสะสมในทุกขั้นตอน
ขอบเขตทางกายภาพ
- ขอบเขตของลำดับเวลา: สถานะอาจเปลี่ยนไประหว่างจุด asynchronous ต่าง ๆ และยิ่งรุนแรงกว่าในระบบกระจาย
- ขอบเขตของขนาด: เมื่อข้ามจุดวิกฤต จะไม่ได้เกิดแค่การเปลี่ยนแปลงเชิงปริมาณ แต่เป็นการเปลี่ยนแปลงเชิงคุณภาพ
- ขอบเขตของสภาพแวดล้อม: เกิดเรื่องแบบ “บนเครื่องผมมันใช้ได้”
- ขอบเขตของโครงสร้างพื้นฐาน: เมื่อแยกบริการออกจากกัน จะไม่สามารถรับประกันความเป็นอะตอมมิกได้
ขอบเขตที่เกิดขึ้นระหว่างผู้คน
- ขอบเขตขององค์กร: กฎของ Conway — โครงสร้างองค์กรเป็นตัวกำหนดโครงสร้างระบบ เมื่อมีการปรับทีม ขอบเขตของโค้ดกับขอบเขตขององค์กรอาจไม่ตรงกัน
- ขอบเขตของการสื่อสาร: เหมือนเกมส่งสาร ยิ่งความต้องการถูกส่งต่อไปหลายทอด เจตนาก็ยิ่งบิดเบือน และความรู้โดยนัยอาจไม่ถูกส่งต่อเลย
- ขอบเขตระหว่างผู้ใช้-นักพัฒนา: ขอบเขตที่นักพัฒนาสร้างขึ้นเพื่อความปลอดภัย อาจกลายเป็นกำแพงที่น่ารำคาญสำหรับผู้ใช้
วิธีรับมือกับขอบเขต
- จงมองเห็นขอบเขตที่ซ่อนอยู่: ให้สังเกตการพึ่งพากันที่มองไม่เห็นในโค้ด เช่น สองบริการใช้ตาราง DB เดียวกันร่วมกัน
- แพตเทิร์นไม่ใช่คำตอบเสมอไป: แพตเทิร์นเป็นเพียง “วิธีแก้ที่ได้ผลภายใต้เงื่อนไขบางอย่าง” เท่านั้น ห้ามนำไปใช้แบบไม่ลืมหูลืมตา
- สามคำถามที่ต้องถามเมื่ออยู่ต่อหน้าขอบเขต:
- อะไรกำลังข้ามขอบเขตนี้?
- ถ้าขอบเขตนี้พัง จะเกิดอะไรขึ้น?
- ใครเป็นผู้ดูแลขอบเขตนี้?
- การไม่ขีดเส้นขอบเขตก็เป็นทางเลือกหนึ่ง: เช่น คงสภาพ monolith ไว้ หรือหลีกเลี่ยงการแยกออกอย่างรีบร้อน
- ขอบเขตมีการวิวัฒน์: แยกแล้วรวม รวมแล้วแยกอีกซ้ำไปมา → จึงต้องมีการทบทวนอย่างสม่ำเสมอและมีสติ
ยังไม่มีความคิดเห็น