ถอดรหัสความคิดเซียนโค้ด: เปลี่ยนเงื่อนไขซ้ำซากให้เป็นระเบียบด้วย Pattern Recognition
เจาะลึกวิธีมองทะลุโค้ด if/else ยาวเหยียด แล้วเปลี่ยนมาใช้ Dispatch Table เพื่อโค้ดที่สะอาดและดูแลรักษาง่ายขึ้น
ภาพประกอบจากคลังภาพสต็อก ไม่ใช่ภาพจากเหตุการณ์จริง
- ปัญหาโค้ด if/else ยาวเหยียดมักเกิดจากการมองไม่เห็นรูปแบบที่ซ่อนอยู่
- การใช้ Dispatch Table หรือ Strategy Pattern ช่วยลดการคัดลอกโค้ดซ้ำซ้อน
- การมองปัญหาเป็นรูปทรงช่วยให้การเขียนโค้ดและการเพิ่มฟีเจอร์ใหม่กลายเป็นเรื่องง่าย
การตรวจรับโค้ด (Pull Request) ชิ้นหนึ่งในโปรเจกต์อาจให้ความรู้สึกเหมือนกำลังเผชิญหน้ากับบอทในเกมอาร์เคดแนวเรโทรที่ไม่มีตัวช่วยแก้ตัว โค้ดต้นเหตุคือชุดคำสั่ง if/else if/else ขนาดมหึมาที่ทำหน้าที่จัดการ JSON Payload รูปแบบต่างๆ จาก API ภายนอก โดยในแต่ละกิ่งก้านของเงื่อนไขต่างก็ทำหน้าที่แทบจะเหมือนกันทุกประการ นั่นคือตรวจสอบความถูกต้องของฟิลด์ข้อมูล แปลงข้อมูลให้เข้ากับ Internal Model ของระบบ และเรียกใช้งาน Service โดยมีสิ่งเดียวที่แตกต่างกันคือโครงสร้างของวัตถุข้อมูลขาเข้าเท่านั้น
ทุกครั้งที่มีการเพิ่ม Endpoint ใหม่ นักพัฒนาจำเป็นต้องคัดลอกบล็อกโค้ดทั้งหมด ปรับแก้ชื่อฟิลด์เล็กน้อย และได้แต่ภาวนาว่าจะไม่เผลอลืมเครื่องหมายจุลภาค (Comma) การตรวจทานโค้ดลักษณะนี้จึงดูคล้ายกับการพยายามแก้รูบิคด้วยการหมุนสุ่มหน้าไปเรื่อยๆ ซึ่งบางครั้งอาจฟลุกสำเร็จ แต่ส่วนใหญ่แล้วกลับสร้างความยุ่งเหยิงให้ใหญ่ขึ้นกว่าเดิม
คำถามที่มักวนเวียนอยู่ในหัวคือเหตุใดจึงต้องเขียนตรรกะเดิมซ้ำแล้วซ้ำเล่า คำตอบที่ซ่อนอยู่อย่างโจ่งแจ้งก็คือการที่เรามองไม่เห็นรูปแบบ (Pattern) ที่แท้จริงนั่นเอง
การทำ Pattern Recognition ในงานเขียนโปรแกรมไม่ใช่เรื่องของสัญชาตญาณลอยๆ แต่เป็นการฝึกมองหาโครงสร้างพื้นฐานที่ซ้ำรอยเดิมในปัญหาต่างๆ (Isomorphism) เมื่อนักพัฒนาสามารถแยกแยะส่วนที่เปลี่ยนแปลง (Varying part) ออกจากส่วนที่คงที่ (Invariant) ได้ จะช่วยลดความซับซ้อนของ Cyclomatic Complexity ในระบบลงได้อย่างมหาศาล ซึ่งเป็นรากฐานสำคัญของสถาปัตยกรรมซอฟต์แวร์ที่ดี
จุดเปลี่ยนทางความคิดเกิดขึ้นในขณะที่กำลังรีแฟกเตอร์ยูทิลิตี้ขนาดเล็กที่แปลงรายการ User ID ให้กลายเป็น Set โดยตระหนักได้ว่าไม่ได้กำลังเขียนอัลกอริทึมใหม่ทุกครั้ง แต่กำลังประยุกต์ใช้โซลูชันที่มีรูปทรงแบบเดียวกัน นั่นคือ รับอินพุตเข้ามา แปลงสภาพมันเสีย แล้วส่งต่อให้กับผู้บริโภคข้อมูล (Consumer) ที่มีพฤติกรรมสม่ำเสมอ
กล่าวคือ ปัญหาที่แท้จริงไม่ใช่การคิดว่า "จะจัดการกับ Payload X อย่างไรดี?" แต่คือ "จะส่งต่อการแปลงข้อมูลให้ถูกตัวตามคีย์ที่กำหนดได้อย่างไร?" ซึ่งนี่คือปัญหาคลาสสิกของ Dispatch Table หรือ Strategy Pattern นั่นเอง
โมเมนต์แห่งความกระจ่างแจ้งเกิดขึ้นเมื่อมองดูชุดเงื่อนไขแล้วพบว่า แต่ละกิ่งก้านสามารถถูกแสดงออกมาให้อยู่ในรูปของฟังก์ชันได้ โดยเซียนโค้ดจะมองเห็นรูปแบบเหล่านี้ได้ทันทีว่า ตรรกะเงื่อนไขที่ซ้ำซากจำเจสามารถแปลงไปเป็นตารางพฤติกรรม (Table of Behaviors) ได้ และเมื่อมองเห็นแล้ว โค้ดก็จะเขียนตัวมันเองขึ้นมาได้ทันที
ภาพประกอบจากคลังภาพสต็อก ไม่ใช่ภาพจากเหตุการณ์จริง
ภาพประกอบจากคลังภาพสต็อก ไม่ใช่ภาพจากเหตุการณ์จริง
การมองเห็นรูปแบบจะเปลี่ยนภาระงานดูแลรักษาโค้ดที่น่าเบื่อหน่ายให้กลายเป็นเหมือนการต่อเลโก้ที่ลงล็อกพอดี ซึ่งช่วยให้สามารถจัดการงานได้ง่ายขึ้น และในมุมมองที่กว้างขึ้น กรอบความคิดนี้ยังขยายขอบเขตไปไกลกว่า API Dispatchers ทุกครั้งที่พบเห็นบล็อก if/switch ที่ยาวเหยียด ให้ลองตั้งคำถามว่า "ส่วนใดคือส่วนที่เปลี่ยนแปลง? และเราสามารถเปลี่ยนมันให้กลายเป็นคีย์ได้หรือไม่?" นั่นคืออาวุธลับของนักพัฒนาแถวหน้า ที่ไม่ได้แค่มองแค่การเขียนโค้ด แต่เป็นการมองหารูปทรงของปัญหาเพื่อนำรูปแบบที่พิสูจน์แล้วกลับมาใช้ใหม่
ที่มา: Dev.to
พบข้อมูลผิดพลาดในบทความนี้? แจ้งปัญหาบทความนี้
ความคิดเห็น
แสดงความคิดเห็น