Exception Handling (การจัดการข้อยกเว้น)

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

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