เจาะประเด็น
Technical Debt
ซอฟต์แวร์ไม่มีวันพังเพราะ "เพิ่มของ" แต่พังเพราะ "ปล่อยให้แย่" ไม่มีขีดจำกัดจริงๆ
ตึกสร้างสูงเกินไปพังแน่นอน แต่โค้ดที่แย่ลงไปเรื่อยๆ ไม่มีวันถึงจุดที่ "พอกันที" — นี่คือสิ่งที่นักพัฒนาทุกคนต้องรู้ไว้
ทีมข่าว เอไอไทย.com
⏱ อ่าน 3 นาที
เคยสงสัยไหมว่าทำไมระบบที่ "ยังรันได้" ถึงกลายเป็นนรกสำหรับคนดูแลทีหลัง? คำตอบคือโค้ดมันแย่ลงได้ไม่มีวันจบ — และนั่นคือหายนะที่เงียบที่สุดในวงการเรา
หากคุณเคยทำงานกับโค้ดเบสขนาดใหญ่ที่ผ่านมือคนมานับสิบๆ คน คุณจะรู้ทันทีว่า Zach Kehs พูดถึงอะไร — และมันเจ็บปวดแค่ไหน
ข้อเปรียบเทียบของเขามันโคตรจะคม: ตึกที่คุณเติมชั้นและห้องไปเรื่อยๆ ไม่มีวันจบ มันจะถึงจุดที่โครงสร้างรับไม่ไหวแล้วพังลงมาแน่นอน แต่ซอฟต์แวร์ไม่เหมือนกัน มันไม่มี "จุดพัง" จากน้ำหนักของโค้ดที่เพิ่มขึ้นโดยตรง — มันแค่... แย่ลงเรื่อยๆ อย่างไม่มีที่สิ้นสุด
ฟังดูเหมือนเรื่องดีใช่ไหม? "ไม่มีวันพัง" — แต่เปล่าเลย นี่คือคำสาปที่เลวร้ายที่สุดของวงการเรา เพราะการที่โค้ด "แย่ลงได้เสมอ" แปลว่ามันจะแย่ลงจริงๆ โดยที่ไม่มีใครสังเกตเห็นจนกว่าจะสายเกินไป
ลองคิดดู: ทุกครั้งที่เรา "แก้ปัญหาเฉพาะหน้า" เพิ่ม layer ของ abstraction ที่ไม่จำเป็น หรือลด performance ลงนิดหน่อยเพื่อให้ส่งงานทันเดดไลน์ มันไม่ได้ทำให้ระบบพังทันที — มันแค่สะสมความเลวร้ายไว้ใต้พรมอย่างเงียบๆ แล้ววันหนึ่งคุณจะพบว่าทีมพัฒนาทั้งทีมใช้เวลาหนึ่งสัปดาห์เพื่อเพิ่มฟีเจอร์ที่จริงๆ แล้วควรใช้เวลาแค่สองชั่วโมง
ความต่างระหว่างตึกกับซอฟต์แวร์คือ ตึกมีวิศวกรโครงสร้างที่ต้องคำนวณทุกครั้งที่เติมชั้น แต่โค้ดของเราไม่มี "วิศวกรโครงสร้าง" ที่คอยบอกว่า "ไม่ได้นะ เพิ่มอีกไม่ได้แล้ว" — มันรับได้เสมอ จนกระทั่งวันหนึ่งคุณต้อง rewrite ทั้งระบบเพราะไม่มีใครกล้าแตะมันอีกต่อไป
ตรงนี้แหละที่ผมคิดว่ามันน่ากลัวกว่าที่ Zach พูดไว้เสียอีก เพราะการที่โค้ด "แย่ลงได้เสมอ" ไม่ใช่แค่เรื่องเทคนิค — มันคือกับดักทางจิตวิทยาของทีมพัฒนาทุกทีม
เวลาตึกเริ่มทรุด คุณเห็นรอยแตก คุณรู้ว่าต้องซ่อม แต่เวลาระบบเริ่มช้าลง หรือโค้ดเริ่มอ่านยากขึ้น มันไม่มีการแจ้งเตือน ไม่มีเสียงเตือนดังขึ้นมา มันแค่ค่อยๆ กัดกร่อน productivity ของทีมไปทีละนิด จนทุกคนคิดว่านี่คือ "ธรรมชาติ" ของการทำงาน แล้วก็ยอมรับมันไปโดยปริยาย
และนี่คือจุดที่ผมอยากฟันธง: โค้ดที่แย่ลงไม่มีวันทำให้ระบบ "พัง" ในความหมายที่เราจับต้องได้ แต่�มันจะค่อยๆ ฆ่าความสามารถในการแข่งขันของผลิตภัณฑ์คุณอย่างช้าๆ — จนวันหนึ่งคู่แข่งออกฟีเจอร์ที่คุณทำไม่ได้ เพราะโค้ดคุณมันรุงรังเกินกว่าจะเพิ่มอะไรเข้าไปได้อีก
ดังนั้น คำถามที่แท้จริงไม่ใช่ "โค้ดเราจะแย่แค่ไหน" แต่คือ "เราจะรู้ได้ยังไงว่าถึงจุดที่ต้องหยุด แล้วเริ่มจัดการมันจริงจัง" — และนั่นคือสิ่งที่ไม่มีเครื่องมือไหนวัดได้ มีเพียงวินัยของทีมเท่านั้น
ฟังไว้เลย: ซอฟต์แวร์ไม่มีวัน "พังเพราะเพิ่มของ" แต่มันจะตายเพราะ "ปล่อยให้แย่โดยไม่มีใครกล้าจัดการ" — ถ้าทีมคุณยังเมิน technical debt เพราะคิดว่า "เดี๋ยวค่อยแก้" ขอบอกตรงๆ ว่า "เดี๋ยว" นั้นอาจไม่มีวันมาถึง และคุณจะได้ rewrite ทั้งระบบเป็นของขวัญปีใหม่แทน
ที่มา: Simon Willison's Weblog — อ่านต้นฉบับ
ความคิดเห็น 3
กำลังโหลดความคิดเห็น...