บทเรียนสำคัญของ Low-Level Design: โครงสร้างข้อมูลไม่ใช่ถ้วยรางวัลทางเทคนิค

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

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

• ค้นหาข้อมูลวัตถุที่เจาะจง: นึกถึง HashMap
• จัดการงานตามลำดับความสำคัญ: นึกถึง Heap
• ประมวลผลงานตามลำดับการมาถึง: นึกถึง Queue
• รักษาบริบทข้อมูลล่าสุด: นึกถึง Stack
• ค้นหาค่าจากชุดข้อมูลบางส่วน: นึกถึง Trie
• นำทางความสัมพันธ์ระหว่างข้อมูล: นึกถึง Graph

ภาพประกอบจากคลังภาพสต็อก ไม่ใช่ภาพจากเหตุการณ์จริง

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