การสร้างระบบ Front-End ให้ยังคงเข้าใจได้แม้ผ่านไป 10 ปี
เจาะลึกแนวคิดพัฒนาโค้ด Front-End ให้มีความยั่งยืนและอ่านรู้เรื่องในอีก 10 ปีข้างหน้า โดยเน้นความโปร่งใสของเหตุผลทางสถาปัตยกรรมซอฟต์แวร์
ภาพประกอบจากคลังภาพสต็อก ไม่ใช่ภาพจากเหตุการณ์จริง
- ความท้าทายของโค้ดเก่าไม่ใช่ฟังก์ชันการทำงานที่พัง แต่คือการสูญหายของเหตุผลเบื้องหลังการตัดสินใจ
- อายุการใช้งานที่ยาวนานของระบบ (Longevity) ไม่ใช่คุณสมบัติทางเทคโนโลยี แต่เป็นเรื่องของความสามารถในการอ่านออกและเข้าใจได้ (Legibility)
- การจัดการด้วยการประกาศให้ชัดเจนและตรวจสอบได้ แทนการใช้วิธีซ่อนเร้นหรือข้อตกลงโดยปริยาย
- เป้าหมายสูงสุดคือการสร้างโค้ดที่บุคคลภายนอกสามารถแกะรอยและเข้าใจเหตุผลได้ทันทีโดยไม่ต้องถามผู้สร้างเดิม
ลองเปิดดูชุดโค้ด (Codebase) เก่าแก่ที่ไม่มีสมาชิกในทีมปัจจุบันคนไหนเคยเขียนมาก่อน โค้ดยังคงทำงานได้ปกติ แต่ไม่มีใครตอบได้ว่าทำไมการตัดสินใจเฉพาะเจาะจงจึงถูกเขียนออกมาในรูปแบบนั้น ปัญหาไม่ได้อยู่ที่ฟังก์ชันการทำงานขาดหายไป แต่คือความสามารถในการสร้างเหตุผลเบื้องหลังโค้ดขึ้นมาใหม่ต่างหาก
ทีมพัฒนาซอฟต์แวร์มักมุ่งเน้นไปที่สิ่งที่ใช้งานได้จริงในปัจจุบัน เนื่องจากแรงกดดันจากกำหนดเวลาในสัปดาห์นี้ การตัดสินใจถูกทำขึ้นอย่างถูกต้องภายใต้ข้อจำกัดจริงโดยผู้ที่เข้าใจเหตุผลเป็นอย่างดี แต่เหตุผลเหล่านั้นกลับระเหยหายไปทันทีที่บุคคลเหล่านั้นย้ายไปทำงานอื่น แม้ว่าการตัดสินใจนั้นจะถูกต้องสมบูรณ์ก็ตาม
ภาพประกอบจากคลังภาพสต็อก ไม่ใช่ภาพจากเหตุการณ์จริง
โค้ดรอด บริบทไม่รอด ช่องว่างนี้คือหัวใจสำคัญที่บทความชุดนี้พยายามสื่อสารมาโดยตลอด ความยั่งยืนของระบบจึงไม่ใช่คุณสมบัติทางเทคโนโลยี แต่เป็นเรื่องของความสามารถในการอ่านและทำความเข้าใจ (Legibility) ระบบจะยังคงเข้าใจได้ในอีก 10 ปีข้างหน้า หากบุคคลภายนอกที่ไม่เคยพบกับผู้สร้าง สามารถแกะรอยเหตุผลได้จากตัวสิ่งประดิษฐ์นั้นเองโดยตรง
ในมุมมองวิศวกรรมซอฟต์แวร์ ปัญหา "Context Loss" หรือการสูญหายของบริบทการตัดสินใจ เป็นอุปสรรคสำคัญในการดูแลรักษาซอฟต์แวร์ระยะยาว การใช้สถาปัตยกรรมแบบประกาศ (Declarative) และการกำหนดข้อจำกัดทางสถาปัตยกรรมผ่านโค้ด เช่น CSS Layers หรือ Explicit Override Paths ช่วยลดภาระการจดจำและป้องกันไม่ให้โค้ดเสื่อมสภาพตามกาลเวลา (Software Entropy)
กลไกทั้งหมดที่ผ่านมาในซีรีส์นี้ ล้วนเป็นข้อกำหนดเดียวกันที่ถูกนำไปใช้ในสเกลที่ต่างกัน ได้แก่ การประกาศให้ชัดเจนแทนการซ่อนเงื่อน และการตรวจสอบได้โดยทุกคนที่อ่าน ไม่ใช่แค่คนที่อยู่ในห้องประชุมวันที่มีการตัดสินใจ สิ่งเหล่านี้ปรากฏผ่านรูปแบบต่างๆ เช่น:
- การรีเซ็ตที่ประกาศจุดยืนทางภาพอย่างชัดเจน เพื่อไม่ให้เกิดคำถามว่าการรีเซ็ตแอบแฝงรสนิยมของใครไว้
- เลเยอร์ที่ช่วยระงับข้อโต้แย้งล่วงหน้า เช่น @layer ghost_tokens, reset, baseline, forms, utilities ที่ทุกคนรู้ลำดับความสำคัญทันที
- พื้นผิวการทับซ้อน (Override surfaces) ที่ถูกกำหนดไว้อย่างชัดเจน 3 รูปแบบ
- คำศัพท์สถานะใน quell-light.js ที่ถูกจำกัดความหมายไว้อย่างตายตัวตั้งแต่ต้น
เป้าหมายของการพัฒนาไม่ใช่การสร้างเฟรมเวิร์กขึ้นมาใหม่อีกตัว แต่เป็นการช่วยให้นักพัฒนาค้นพบแพลตฟอร์มที่ตนมีอยู่แล้ว และทิ้งการตัดสินใจที่บุคคลภายนอกสามารถทำความเข้าใจได้ แม้ว่าผู้สร้างเดิมจะย้ายไปทำอย่างอื่นแล้วก็ตาม
ที่มา: Dev.to
พบข้อมูลผิดพลาดในบทความนี้? แจ้งปัญหาบทความนี้
ความคิดเห็น
แสดงความคิดเห็น