Technical Debt (หนี้ทางเทคนิค)

เรา มักถูกจับให้อยู่ในสถานการณ์ที่ไม่สามารถทำตามวิสัยทัศน์ทางเทคนิคได้ทุกตัวอักษร บ่อยครั้งเราต้องตัดสินใจตัดมุมบางอย่างเพื่อให้ได้ฟีเจอร์ที่เร่งด่วนออกมา นี่เป็นเพียง trade-off อีกอย่างหนึ่งที่เราจะต้องเจอ วิสัยทัศน์ทางเทคนิคของเรามีอยู่ด้วยเหตุผล ถ้าเราเบี่ยงเบนจากเหตุผลนี้ มันอาจให้ประโยชน์ระยะสั้นแต่มีต้นทุนระยะยาว แนวคิดที่ช่วยให้เราเข้าใจ trade-off นี้คือ technical debt เมื่อเราสะสม technical debt เหมือนกับหนี้ในโลกจริง มันมีต้นทุนที่ต่อเนื่องและเป็นสิ่งที่เราต้องการชำระคืน

บางครั้ง technical debt ไม่ใช่แค่สิ่งที่เราสร้างขึ้นจากการลัดขั้นตอน จะเกิดอะไรขึ้นถ้าวิสัยทัศน์ของเราสำหรับระบบเปลี่ยนไป แต่ไม่ใช่ทั้งระบบของเราที่ตรงกับมัน ในสถานการณ์แบบนี้ เราก็สร้างแหล่งที่มาของ technical debt ใหม่เช่นกัน

หน้าที่ของสถาปนิกคือมองภาพรวมและเข้าใจความสมดุลนี้ การมีมุมมองบางอย่างว่าระดับของหนี้อยู่ตรงไหนและควรเข้าไปมีส่วนร่วมตรงไหนเป็นเรื่องสำคัญ ขึ้นอยู่กับองค์กรของคุณ คุณอาจให้คำแนะนำเบาๆ ได้ แต่ให้ทีมเป็นคนตัดสินใจเองว่าจะติดตามและชำระหนี้อย่างไร สำหรับองค์กรอื่นๆ คุณอาจต้องมีโครงสร้างที่ชัดเจนกว่านี้ เช่น การเก็บ debt log ที่ถูกทบทวนเป็นประจำ