ยิ่งมีข้อมูลน้อย bug ยิ่งน้อยลงจริงหรือ
เมื่อเดือนก่อนมีโอกาสได้ดู VDO ของพี่ Chris เกี่ยวกับการตกหล่มของระบบที่สร้างด้วยหลักการ “ออกแบบฐานข้อมูลก่อน” ซึ่งใจความสำคัญที่เราได้นั้นมันมีอะไรมากกว่าแค่ database ซึ่งก็คือ “ยิ่งเรามีข้อมูลน้อยเท่าไร โอกาสที่ระบบ software จะเกิด error/bug นั้นก็จะน้อยลงตามไปด้วย”
ปัญหาของการออกแบบระบบโดยมองข้ามภาพรวม
ผู้พูดเน้นถึงปัญหาที่เจอเมื่อเริ่มการออกแบบจากโครงสร้าง database ก่อนที่จะเข้าใจตัวระบบทั้งหมด เช่น ออกแบบด้วยการวาด ER diagram ซึ่งส่วนใหญ่จะเน้นแค่การดูว่า database มีโครงสร้างเป็นอย่างไร ข้อมูลตรงตามความต้องการหรือไม่ เนื่องจากมันมักจะทำให้คน focus แค่โครงสร้างของข้อมูล และมองข้ามภาพรวมของระบบที่ใหญ่กว่านั้น
การออกแบบโครงสร้างแบบนี้มันจะมีโอกาสทำให้ระบบเกิดปัญหาได้มาก โดยเฉพาะเมื่อมีข้อมูลเยอะ ๆ ที่ต้องคอย update ตลอดเวลา
ยกตัวอย่าง
สมมุติว่าเรามีข้อมูลผู้ใช้งานอยู่ในระบบ ซึ่งผู้ใช้งานคนหนึ่งอาจจะทำหน้าที่หลายอย่างในระบบ เช่น เป็นทั้ง Admin และ Reviewer ถ้าเราเก็บข้อมูลทั้งหมดนี้ไว้ในตารางเดียวแบบไม่ได้จัดการให้ดี (เช่น ตาราง User
มี column Role1
, Role2
,…, RoleN
)
เวลาเปลี่ยนชื่อหรือข้อมูลของผู้ใช้งาน เราจะต้องมาไล่แก้ในทุก ๆ ตารางที่เกี่ยวข้อง ซึ่งถ้ามีสักหนึ่งตารางที่พลาดไป ไม่ได้เปลี่ยนแปลงข้อมูลตาม ระบบก็อาจจะเกิดข้อผิดพลาดได้
แต่ถ้าเราจัดการข้อมูลให้เป็นระเบียบมากขึ้น เช่น ใช้หลักการ normalization แยกตารางข้อมูลออกจากกันอย่างชัดเจน การแก้ไขข้อมูลในที่หนึ่งก็จะส่งผลให้ข้อมูลทั้งหมดถูก update ไปพร้อมกัน ทำให้โอกาสที่ระบบจะเกิด bug นั้นน้อยลง
อีกสักตัวอย่าง
สมมติเวลามี feature ใหม่ที่ต้องการให้เก็บข้อมูลสถานะการลบผู้ใช้งานเข้ามาเพิ่ม คนส่วนใหญ่จะคิดว่าการเพิ่มข้อมูลนี้เป็นเรื่องง่าย แค่เพิ่ม field ใหม่ในตารางฐานข้อมูลก็จบ (เช่น isDeleted
และ DeletedAt
)
แต่จริง ๆ แล้ว การเพิ่มข้อมูลแบบนี้อาจจะทำให้ระบบซับซ้อนขึ้น และมีโอกาสเกิดข้อผิดพลาดสูงขึ้นได้ เช่น
- ผู้ใช้งานถูกตั้งค่า
isDeleted
= True แต่ fieldDeletedAt
ไม่ถูก update ทำให้ไม่สามารถบอกได้ว่าผู้ใช้งานถูกลบเมื่อไหร่ DeletedAt
มีค่าแต่isDeleted
= False ซึ่งทำให้เกิดความสับสนว่า ผู้ใช้งานถูกลบหรือยัง
ยิ่งข้อมูลเยอะ ยิ่งมีโอกาสผิดพลาด
จากตัวอย่างข้างบน หนึ่งในหลักการที่สำคัญมากในการออกแบบระบบ คือ “ยิ่งข้อมูลน้อย ยิ่งมีโอกาสผิดพลาดน้อย” หรือถ้าอธิบายให้เข้าใจง่าย ๆ คือ ถ้าระบบมีข้อมูลให้น้อยที่สุดเท่าที่จำเป็น โอกาสที่ข้อมูลจะขัดแย้งหรือเกิดข้อผิดพลาดก็จะน้อยลงตามไปด้วย
ดังนั้นสิ่งที่ควรทำคือเวลาที่ออกแบบระบบควรมองทั้งภาพรวมและพยายามทำให้ระบบมีข้อมูลให้น้อยที่สุดเท่าที่จำเป็น อย่าเพิ่มข้อมูลเพียงเพราะคิดว่า “เผื่อไว้ก่อน” เพราะการเพิ่มข้อมูลเกินจำเป็นเนี่ยแหละที่มักจะทำให้ระบบมีปัญหาตามมา และอย่ามองข้ามความสำคัญของการออกแบบที่ถูกต้องตั้งแต่แรก เพราะมันจะช่วยลดปัญหาในระยะยาวได้มาก