- Codebase Drag คือสภาพของ codebase ที่ทำให้ทุกงานใช้เวลานานเกินความจำเป็น และเพราะมันไม่ปรากฏอยู่ในแดชบอร์ดหรือรายงานสปรินต์ จึงทำให้ฝ่ายบริหารเข้าใจผิดว่าเป็น 'ปัญหาคน' วนซ้ำเป็นวงจรเดิม
- จากผลการ Audit codebase ตลอดหลายปี พบว่า 5 สัญญาณเดิม ปรากฏซ้ำ ๆ และมีการเสนอรูบริกวินิจฉัยชื่อ 'การตรวจสอบ Codebase Drag' ที่ให้คะแนนเชิงปริมาณ 0~2 คะแนน
- 5 สัญญาณ ได้แก่ การประเมินเวลาแบบขอโทษ, ความกลัวการ deploy, ไฟล์ที่ห้ามแตะ, คำลวงของ coverage, เวลาจนถึง commit แรก ซึ่งทั้งหมดล้วนมีต้นตอจาก ปัญหาคุณภาพของ codebase และต้องแยกให้ออกจากเรื่องความสามารถของคน
- ยิ่งเป็นวิศวกรที่มีประสบการณ์ ก็ยิ่งมองเห็นความเสี่ยงใน codebase ได้ชัดและเคลื่อนไหวอย่างระมัดระวังมากขึ้น จึงเกิด ความย้อนแย้งที่กลับดูช้ากว่าเดิม และถ้ามองผิดว่าเป็นปัญหาคน ก็จะยิ่งเพิ่มแต่ process จนให้ผลเสีย
- หากได้ 4 คะแนนขึ้นไป แปลว่าจำเป็นต้องลงทุนกับ codebase โดยตรง และถ้าได้ 7 คะแนนขึ้นไป ถือว่าอยู่ในระดับที่ต้องมี การแทรกแซงเชิงโครงสร้างโดยทันที
Codebase Drag คืออะไร
- Codebase Drag คือภาวะที่ codebase ทำให้ทุกงานใช้เวลานานเกินความจำเป็น และไม่ปรากฏในรายงานสปรินต์หรือแดชบอร์ด
- ตัวอย่าง: ทีมฝั่ง client ใช้วิศวกร 2 คนเป็นเวลา 1 สัปดาห์เพื่อเพิ่มฟีเจอร์ export CSV ในแอดมินพาเนล — ทั้งที่งานจริงมีปริมาณแค่ 1 วัน แต่เวลาที่เหลือหมดไปกับการทำความเข้าใจว่าจะปรับโค้ดเดิมอย่างไรให้ปลอดภัย
- เมื่อความเร็วของทีมลดลงซ้ำ ๆ ฝ่ายบริหารมักตัดสินว่าเป็น ปัญหาด้านบุคลากร แล้วตอบสนองด้วยการปรับโครงสร้างองค์กร เพิ่ม process หรือเปลี่ยนคน แต่ทีมถัดไปก็ยังชนกำแพงเดิม
- ต้นตอของปัญหาไม่ใช่ bug, ฟีเจอร์ที่ขาดหาย หรือ technical debt ตามความหมายทั่วไป แต่คือ ตัว codebase เอง
5 สัญญาณของ Codebase Drag
1. การประเมินเวลาแบบขอโทษ (Apology Estimate)
- คือสถานการณ์ที่วิศวกรประเมินฟีเจอร์ที่จริง ๆ ใช้ 3 วันว่าอาจต้องใช้ 2 สัปดาห์ ซึ่งฝ่ายบริหารมักเข้าใจผิดว่าเป็นการ เผื่อเวลาเกินจริง
- แต่เหตุผลจริงคือ การ coupling ระหว่างโมดูล เช่น การแก้ billing module อาจไปกระทบ notification system และโครงสร้างที่ทำให้ไม่รู้ได้แน่ชัดว่าผลกระทบจะลามไปไกลแค่ไหน
- เช่น hidden default scope หรือ callback ที่ซ้อนลึก ทำให้ไม่สามารถคาดเดา ขอบเขตผลกระทบของการเปลี่ยนแปลง (blast radius) ได้ หากไม่ได้อ่านโค้ดไปครึ่งระบบ
- ถ้าระยะเวลาจริงยาวกว่าที่คาดอย่างสม่ำเสมอ 2~3 เท่า นั่นไม่ใช่ปัญหาการประเมิน แต่คือ ต้นทุนของ codebase
2. ความกลัวการ deploy (Deploy Fear)
- ทีมเริ่มหลีกเลี่ยงการ deploy วันศุกร์ หรือรวมการ deploy เป็นก้อนใหญ่แล้วปล่อย release ไม่บ่อย
- ทีมลูกค้าทีมหนึ่งมีธรรมเนียมไม่เป็นทางการว่าห้าม deploy หลังวันพุธ — เพราะการ deploy วันพฤหัสฯ 3 ครั้งก่อนหน้านั้นลงเอยด้วย incident ช่วงสุดสัปดาห์
- สาเหตุคือ ไม่มี rollback strategy, test ไม่น่าเชื่อถือ และ pipeline deploy ใช้เวลา 45 นาที
- ตามเกณฑ์ DORA ทีมระดับ elite มีอัตราเปลี่ยนแปลงล้มเหลวต่ำกว่า 5% และ deploy ได้ทันทีเมื่อต้องการ แต่ทีมนี้ deploy ได้เพียงสัปดาห์ละครั้งและต้องลุ้นทุกครั้ง
3. ไฟล์แบบ 'อย่าไปแตะมัน' (Don't Touch That File)
- แทบทุกที่มักได้ยินประโยคว่า “อย่าไปแตะไฟล์นั้น” ภายใน 2 วันแรก
- เช่น billing controller ที่มี
before_actionถึง 30 ตัว หรือ model ที่อยู่บนสุดของgit logแต่ในเชิงโครงสร้างกลับไม่มีใครกล้าแตะมาหลายปี
- เช่น billing controller ที่มี
- เมื่อรัน
git log --oneline --since="2 years ago"ไฟล์ที่ถูกแก้มากที่สุดก็มักเป็นไฟล์ที่ถูกเตือนเสมอ — หากมีแต่ patch เล็ก ๆ ซ้ำไปซ้ำมาและ ไม่มีงานเชิงโครงสร้าง นั่นคือรักษาแค่อาการแต่ปล่อยโรคไว้ - ต้นทุนที่แท้จริงคือฟีเจอร์ที่ควรอยู่ในโมดูลนั้นกลับถูก ไปทำไว้ที่อื่น และพนักงานใหม่ก็เรียนรู้ได้ภายในสัปดาห์แรกว่าต้องหลบไฟล์นั้นอย่างไร — codebase จึงเติบโตแบบบิดเบี้ยวรอบเขตต้องห้าม
4. คำลวงของ coverage (Coverage Lie)
- ตัวเลข test coverage 80% อาจดูสุขภาพดี แต่ความจริงอาจเป็นเพราะ test ของ serializer, helper และ utility ที่แทบไม่มีวันพังช่วยดันตัวเลขขึ้น ขณะที่ core model 3 ตัวที่แตะเรื่องเงินกลับไม่มี test เลย
- test suite จึงไม่ได้มีไว้จับ regression แต่มีไว้เพื่อ ทำให้ตัวชี้วัดดูดี — test ผ่าน แต่ production ก็ยังพังได้
- เวลา CI 40 นาทีทำให้นักพัฒนาหยุดรัน test บนเครื่องตัวเอง → ตัวเลข coverage จึงโกหกสองชั้น: ทั้งไม่ครอบคลุมส่วนสำคัญ และแม้แต่ test ที่มีก็ไม่ได้ถูกรันจริง
- คำถามที่ควรถามจริง ๆ ไม่ใช่ตัวเลข coverage แต่คือ “ครั้งสุดท้ายที่ test จับ bug ได้ก่อนขึ้น production คือเมื่อไร”
5. เวลาจนถึง commit แรก (Time to First Commit)
- คือเวลาที่ตั้งแต่ให้โน้ตบุ๊กกับวิศวกรใหม่ จนเขาเปิด PR ที่มี การแก้ bug จริงหรือฟีเจอร์เล็ก ๆ ได้
- codebase ที่ดีต่อสุขภาพ: 1~2 วัน
- codebase ที่มี drag: มากกว่า 2 สัปดาห์
- ลูกค้ารายหนึ่งเคยต้องใช้เวลาหลายสัปดาห์เพื่อตั้งค่าสภาพแวดล้อมพัฒนา แต่หลังแก้ไขแล้ว นักพัฒนาใหม่ใช้เวลาเพียง 15~20 นาทีในการตั้งค่าเสร็จ
- สาเหตุหลักคือ setup rot — สคริปต์
bin/setupไม่ได้อัปเดตหลังการเปลี่ยนแปลง environment ครั้งล่าสุด, seed data อ้างถึง table หรือ column ที่ไม่มีอยู่แล้ว, และมี environment variable ที่ไม่ถูกบันทึกไว้ 3 ตัวซึ่งจะรู้ว่าขาดก็ต่อเมื่อแอปชนตอนรัน - วิศวกรเดิมได้ซึมซับขั้นตอนที่ไม่มีเอกสารไว้แล้ว จึงเป็น พนักงานใหม่เท่านั้นที่เผยให้เห็นขนาดของความรู้โดยนัยที่ codebase นี้ต้องการได้อย่างแม่นยำ
ทำไมวิศวกรเก่ง ๆ ถึงดูช้าลงใน codebase ที่แย่
- 5 สัญญาณนี้ ทำงานร่วมกันแบบทับซ้อน และเพิ่ม overhead ให้ทุกงานในแบบที่ไม่มีใครชี้ให้เห็นได้ตรง ๆ ใน standup
- วิศวกรที่เคยทำฟีเจอร์เสร็จใน 2 วันที่บริษัทก่อน อาจต้องใช้ 1 สัปดาห์ใน codebase นี้ และแม้จะพยายามอธิบาย เหตุผลก็ฟังเหมือนข้อแก้ตัว
- งานวิจัย METR ปี 2025 พบว่านักพัฒนาที่มีประสบการณ์เมื่อใช้เครื่องมือ AI กลับช้าลง 19% — เป็นหลักฐานว่าคอขวดไม่ใช่การพิมพ์
- ยิ่งเป็นวิศวกรที่เก่งที่สุด ก็ยิ่งมองเห็นความเสี่ยงและเคลื่อนไหวอย่างระวังมากขึ้น รวมถึง ประเมินเวลาเผื่อไว้มากกว่าเดิม — ขณะที่วิศวกรที่ชำนาญน้อยกว่าอาจมองไม่เห็นความเสี่ยง จึง deploy เร็วกว่าแต่ทำ production ล่ม จนทั้งทีมยิ่งระวังตัวกว่าเดิม เป็นวงจรซ้ำ
- ลูกค้ารายหนึ่งเปลี่ยนทีมมาแล้ว 6 ทีมใน 10 ปี (รวมการเข้าซื้อกิจการทั้งหมด 2 ครั้ง) — รูปแบบซ้ำคือ ฝ่ายบริหารต้องการฟีเจอร์ → ข้ามการจัดการหนี้ → โค้ดเสื่อมจนกู้ไม่กลับ → เสนอ rewrite หรือแยก microservices → ระบบยิ่งแตกออกเป็นสองส่วนและแย่ลงกว่าเดิม
- หากฝ่ายบริหารตีความความช้าที่เกิดขึ้นว่าเป็นปัญหาคน ก็จะ ยิ่งเพิ่ม process ให้ทีมที่กำลังเจอแรงเสียดทานอยู่แล้ว และทำให้แย่ลง — การแทรกแซงที่ช่วยได้จริงมีเพียงการแก้ “เส้นทาง” นั้นโดยตรง
การตรวจสอบ Codebase Drag: วิธีวินิจฉัย
- ให้คะแนนทั้ง 5 สัญญาณข้อละ 0~2 คะแนน:
- 0 คะแนน: ไม่มีปัญหา
- 1 คะแนน: มีปัญหาบางส่วน
- 2 คะแนน: มีปัญหารุนแรง
- หากได้ 4 คะแนนขึ้นไป ควรลงทุนกับ codebase โดยตรงก่อนมาตรการอื่นใด
วิธีรับมือเมื่อ technical debt ฉุดทีมไว้
- เริ่มจากสัญญาณที่ได้คะแนนสูงสุดเพียงข้อเดียวก่อน — อย่าพยายามแก้ทุกอย่างพร้อมกัน
- ความกลัวการ deploy ได้ 2 คะแนน: ให้เริ่มจากความเร็วของ CI, การทำ rollback อัตโนมัติ, และการปรับให้ deploy เป็นหน่วยเล็กลง
- การประเมินเวลาแบบขอโทษได้อันดับ 1: ให้เริ่มจาก decouple โมดูลที่มี blast radius กว้างที่สุด
- เวลาถึง commit แรกได้ 2 คะแนน: ลงทุน 1 วันเพื่อแก้
bin/setupและเขียนเอกสาร environment แล้วจะคืนทุนได้กับการรับคนใหม่ทุกครั้งหลังจากนั้น
- หาก Rails ตามหลังอยู่หลายเวอร์ชัน การอัปเกรดเวอร์ชัน อาจเป็น forcing function ที่ทำให้การลงทุนนั้นสมเหตุสมผลขึ้น
- วัดผลเป็นรอบ 2 สัปดาห์: เลือกสัญญาณที่คะแนนสูงสุด → ทำ focused sprint → วัดตัวเลขที่เป็นรูปธรรม (ความถี่การ deploy, ความแม่นยำของการประเมิน, เวลาไปถึง PR แรก ฯลฯ)
- เหตุผลที่ขออนุมัติการลงทุนได้ยากคือ ต้นทุนของการไม่ทำมันมองไม่เห็น — ประโยคอย่าง “เรามี technical debt” สู้ “การ coupling ของ 3 โมดูลนี้ทำให้ทุกฟีเจอร์ใช้เวลานานขึ้นราว 2 เท่า” ไม่ได้ในแง่พลังในการโน้มน้าว
- 7 คะแนนขึ้นไป โดยทั่วไปคือระดับที่ควรเริ่มจากการ audit codebase เป็นเวลา 1 สัปดาห์
5 ความคิดเห็น
จริง เลกาซีโปรเจกต์นี่ตัวร้ายเงียบของวงการเลย
มีบางอย่างที่สู้สร้างใหม่ตั้งแต่ต้นยังจะดีกว่า
นี่มันเรื่องของฉันเลยนี่นา ..?
ดูเหมือนจะเป็นบทความที่สำคัญมากสำหรับการลดต้นทุนการบำรุงรักษา
เพราะแบบนี้ บางครั้งการเขียนใหม่ตั้งแต่ต้นจึงเร็วกว่าเสียอีก
ทุกคนต่างก็รู้ว่าการจัดระเบียบโค้ดเบสคือหนทางที่จะเพิ่มความเร็วได้ในระยะยาว แต่
มันก็เป็นคำพูดในระดับเดียวกับการบอกว่าถ้ากินดี ออกกำลังกาย และนอนให้พอ สุขภาพก็จะดีขึ้นนั่นแหละ