คุณสร้างสมดุลระหว่างการรีบส่งงานให้ทันเส้นตายกับการสร้างให้ถูกต้องเพื่อความบำรุงรักษาง่ายอย่างไร?

Question

Accepted Answer

ไม่มีคำตอบตายตัว และนั่นแหละคือประเด็น **ความเร็ว กับ ความบำรุงรักษาง่าย ขึ้นอยู่กับบริบท** — คุณจับคู่ระดับความเข้มงวดให้เข้ากับ **ความเดิมพัน (stakes)** และ **อายุการใช้งานที่คาดไว้** ของโค้ด prototype ที่ใช้แล้วทิ้งกับแกนหลักของระบบ payments สมควรได้มาตรฐานที่ต่างกันมาก หน้าที่ของ lead คือทำการแลกเปลี่ยน (trade-off) นั้น **อย่างจงใจ** ไม่ใช่ปล่อยให้มันเกิดขึ้นโดยบังเอิญ

## กรอบในการตัดสินใจ

ถามสามคำถามก่อนจะตัดมุม

- **สิ่งนี้จะอยู่ไปนานแค่ไหน?** การทดลองหนึ่งสัปดาห์เขียนแบบลวกๆ ได้ แต่ core service ที่คุณต้องดูแลไปอีกหลายปีนั้นทำไม่ได้
- **รัศมีความเสียหายเป็นเท่าไรถ้ามันพัง?** ความเดิมพันที่สูงขึ้น (เงิน, ข้อมูล, ความปลอดภัย, การเปลี่ยนแปลงที่ย้อนกลับยาก) หมายถึงมาตรฐานที่สูงขึ้น
- **มันยากแค่ไหนที่จะเปลี่ยนในภายหลัง?** โค้ดที่เปลี่ยนทดแทนได้ถูกๆ ยอมรับทางลัดได้ ส่วน interface และ data model ที่เป็นโครงรับน้ำหนักนั้นยอมไม่ได้

## ทางลัดแบบจงใจ กับ แบบบังเอิญ

- ทางลัดแบบ **จงใจ** ถูกตั้งชื่อ, กำหนดขอบเขต และ **ติดตามในฐานะหนี้ (debt)** (ตั๋วงาน, `// TODO`, บันทึกใน RFC) คุณรู้แน่ชัดว่าแลกอะไรไปและเพราะอะไร
- ทางลัดแบบ **บังเอิญ** คือการกัดเซาะคุณภาพอย่างเงียบๆ ไม่มีใครตัดสินใจ ไม่มีใครติดตาม และมันทบต้น

คง **แกนหลักให้สะอาด** แม้อยู่ภายใต้แรงกดดัน คือ ขอบเขตที่ตั้งชื่อดี และเส้นทางวิกฤตที่มี test ผลักความรกไปไว้ที่ขอบซึ่งฉีกทิ้งได้ในราคาถูก

## เจรจาสามเหลี่ยม อย่าแอบลดคุณภาพ

เมื่อเส้นตายกระชั้น ทางที่ซื่อสัตย์คือการเจรจา **ขอบเขตหรือเวลา** ใหม่กับผู้มีส่วนได้ส่วนเสีย ไม่ใช่แอบส่งของที่เปราะบางออกไป "เราทำทันวันที่กำหนดได้ด้วยฟีเจอร์ A และ B แต่ C จะเลื่อนไปหนึ่งสัปดาห์" คือการพูดคุยจริง การแอบส่งโค้ดที่เปราะบางคือการใช้ความเร็วในอนาคตของทีมโดยไม่มีใครยินยอม

## ทำไมจึงสำคัญ

ทีมที่ปรับให้เน้นความเร็วเสมอจะจมในหนี้ ส่วนทีมที่ขัดเงาเกินจำเป็นเสมอจะพลาดตลาด คุณค่าของ lead คือวิจารณญาณ — การปรับเทียบความเข้มงวดให้เข้ากับบริบท และทำให้การแลกเปลี่ยน **มองเห็นได้และมีเจ้าของ** เพื่อให้ทางลัดของวันนี้เป็นทางเลือกที่ทีมจ่ายคืนได้ ไม่ใช่ความประหลาดใจที่ทีมต้องรับสืบทอด