𝗖𝗼𝗱𝗲 𝗗𝘂𝗽𝗹𝗶𝗰𝗮𝘁𝗶𝗼𝗻 𝗜𝘀 𝗖𝗵𝗲𝗮𝗽𝗲𝗿 𝗧𝗵𝗮𝗻 𝗪𝗿𝗼𝗻𝗴 𝗔𝗯𝘀𝘁𝗿𝗮𝗰𝘁𝗶𝗼𝗻𝘀
นักพัฒนาต่างหลงรักหลักการ DRY
คุณต้องการหลีกเลี่ยงการเขียนโค้ดซ้ำซาก คุณต้องการโค้ดที่สง่างามและนำกลับมาใช้ใหม่ได้
แต่เป้าหมายนี้มักจะนำไปสู่กับดักที่เรียกว่า: การสร้าง Abstraction เร็วเกินไป (premature abstraction)
การเขียนโค้ดซ้ำอาจให้ความรู้สึกที่ผิด แต่ถึงอย่างนั้น การทำโค้ดซ้ำ (duplication) มักจะมีราคาที่ต้องจ่ายน้อยกว่าการสร้าง Abstraction ที่แย่
เราพยายามสร้างระบบแบบโมดูลที่สมบูรณ์แบบ เรามองหารูปแบบ (patterns) และดึงตรรกะ (logic) ออกมาเพื่อจัดการกับความซับซ้อน
Abstraction ที่ออกแบบมาอย่างดีจะช่วยให้ซอฟต์แวร์ขยายตัวได้ (scale)
แต่ Abstraction จำนวนมากถูกสร้างขึ้นเร็วเกินไป หากคุณยังไม่เข้าใจปัญหาอย่างถ่องแท้ Abstraction ของคุณจะกลายเป็นภาระแทน
การสร้าง Abstraction ที่ผิดพลาดก่อให้เกิดปัญหาหลายประการ:
- Over-engineering: คุณสร้างโซลูชันที่ซับซ้อนเกินความจำเป็นสำหรับปัญหาที่เรียบง่าย
- Rigidity: โค้ดของคุณจะแก้ไขได้ยาก เพราะมันพยายามคาดเดาอนาคตที่อาจไม่เกิดขึ้นจริง
- Obscured Intent: ตรรกะทางธุรกิจ (Business logic) ถูกซ่อนอยู่ภายใต้ชั้นของ generic interfaces ซึ่งทำให้การดีบั๊ก (debugging) ทำได้ยาก
- Tight Coupling: ส่วนต่างๆ ของระบบจะยึดติดกับตัว Abstraction เองจนเกินไป
ต้นทุนที่ตามมานั้นสูงมาก คุณต้องเสียเวลาไปกับการต่อสู้กับสถาปัตยกรรม (architecture) ของตัวเอง แทนที่จะได้แก้ปัญหาให้ผู้ใช้งาน มันทำให้ทีมทำงานช้าลงและทำให้การทำ refactoring เป็นเรื่องยาก
ผมไม่ได้บอกให้คุณใช้วิธี copy and paste กับทุกอย่าง แต่ผมกำลังเสนอแนวทางที่เน้นการใช้งานจริง (pragmatic approach)
จงใช้การทำโค้ดซ้ำแบบมีการควบคุม (controlled duplication) เป็นเครื่องมือหนึ่ง ใช้มันในส่วนที่ความต้องการ (requirements) เปลี่ยนแปลงอย่างรวดเร็ว หรือในส่วนที่คุณยังมีความไม่แน่นอนอยู่
รอจนกว่าคุณจะเห็นรูปแบบ (pattern) ที่ชัดเจนเสียก่อน แล้วค่อยสร้าง Abstraction