Story#3 – How Technical Debt Works
Visit: https://codingugly.com/?p=16
เกริ่นนำ
ในการพัฒนาซอฟท์แวร์ด้วย Agile Development เรามักจะได้ยินบ่อยๆว่า deliver the right app, on time และ on budget แต่มีคำอยู่คำหนึ่งที่ dev ทุกคนเคยผ่านตามาบ้างคือ technical debt (อ่านว่า เด็ท ตัวบีไม่ออกเสียงนะครับ) และมันอาจเป็นสาเหตุที่ทำให้ product deliverables เกิดอาการเป๋ไปได้ หากไม่ได้ถูกจัดการอย่างเป็นระบบและสม่ำเสมอ
เช่นเมื่อกลางปีที่แล้ว ผมมีโปรเจคนึงไม่สามารถ upgrade ไป version ใหม่ได้ เพราะไม่ได้ upgrade software stacks ตามระยะ สุดท้ายต้องรื้อโค้ด ปัญหานี้เกิดบ่อยกับ startup ที่ต้องปล่อย app สู่ตลาดอย่างรวดเร็ว ออก features ใหม่ๆตามรอบ iterations อยู่ตลอดเวลา การหาเวลา upgrade จึงทำได้ยาก
ดังนั้นมาดูกันว่า technical debt มันทำงาน และจะจัดการกับมันอย่างไร
Technical debt ในสายตาของ product team
คำว่า Technical Debt หรือ “หนึ้ทางเทคนิค” เป็นคำเปรียบเปรย เหมือนหนี้ที่เราทราบอยู่แล้วว่าอะไรจะเกิดตามมา เรายอมให้เกิดหนี้ตอนนี้เพราะต้องการ benefit บางอย่างก่อน เช่น เราอยากได้ feature ใหม่ ที่พอใช้งานได้และเสร็จออกมาตามเวลา เราเลยยอมแลก (tradeoff)
แต่สุดท้ายปัญหาเหล่านี้ อาจจะสะสมและต้องมาตามแก้ปัญหาภายหลัง ซึ่งก็เหมือนกับการตามใช้หนี้ และหากกระทบส่วนอื่นๆ ด้วย (regression) อาจจะหนักกว่าตรงที่มีดอกเบี้ยด้วย
Developer ทุกคนทราบดี เวลา Technical debt จะเกิด เรามักหาเหตุผลต่างๆมารองรับ choice ที่เราเลือก
product manager ต้องการ “do the thing right” หรือกล่าวได้ว่า ทำให้ถูกใจลูกค้าตาม requirements ก่อน
ทีมพัฒนาต้องการ “do the right thing” คือทำให้ถูกต้องไปเลย ไม่ต้องกลับมาแก้
บ่อยครั้งที่เราเลือกข้อแรก จึงทำให้เกิดหนี้ และมาตามจ่ายทั้งต้นและดอกในภายหลัง
Tech debt ที่ดีมีบ้างหรือเปล่า
Technical debt ถูกสร้างภาพให้เป็นผู้ร้าย หากมีเยอะจะทำให้ software เรามีความเสี่ยง (risks) และเพิ่ม features ใหม่ลำบาก ถือว่าเป็นความจริงอยู่บ้าง แต่การเกิดของ technical debt บางครั้งก็มาจากความตั้งใจที่ดี เช่นเพื่อเทสตลาดว่าที่เราทำจะถูกใจลูกค้าหรือเปล่า หรือการที่เราไม่สามาถที่จะ design อะไรที่ใหญ่โต (big upfront design) อย่างใน water fall model แล้วสุดท้ายไม่มีใครต้องการ
จึงสำคัญมากที่เราต้องนำมันเข้ามาอยู่ใน workflow ของเรา เพื่อที่เราจะได้แก้ไข การเปิด ticket เกี่ยวกับการ refactoring หรือ upgrade ทิ้งไว้ เพื่อ make sure ว่า มันจะได้รับการ manage ก็เป็นเรื่องที่ต้องทำ เหมือนในชีวิตจริง ที่เราไม่สามารถปล่อยให้เกิดหนี้สะสมและยอมจ่ายแต่ดอกเบี้ยไปเรื่อยๆ โดยไม่ทำอะไรเลย
อะไรไม่ใช่ tech debt บ้าง
อย่างที่กล่าวไปแล้วด้านบนว่า เรารู้และยอมรับให้ tech debt มีอยู่ เพราะมันคือวิธีที่ดีที่สุดที่จะได้ product/features อย่างรวดเร็วทันใจ แต่บางครั้งความผิดพลาดเช่น bugs, mistake หรือ failures จะไปอ้างกับลูกค้าว่าเป็น tech debt ไม่ได้ ยกตัวอย่างเช่น
Defects หรือ bugs (แต่หากเรายอมรับและไม่แก้ มันจะกลายเป็น tech debt ที่สะสมในระบบ)
Design ที่ผิดพลาด และต้องรื้อ code ไม่ใช่แค่ refactor บาง functions
ไม่ได้ประเมินปัญหา bottleneck หรือ scalability ไว้ก่อน
เลือกเทคโนโลยี และ infrastructures ที่ผิดพลาดตั้งแต่แรก
… เป็นต้น
นั่นคือการที่เราลืมวางแผนหรือไม่ได้ทำบางอย่างที่ควรทำ ไม่ใช่ technical debt
หากเราไม่แยกให้ออกว่าอันไหนใช่ ไม่ใช่ technical debt แล้วไปบอกลูกค้าหรือ partners จะเกิดความคลาดเคลื่อน และทำให้เค้าคิดว่าเราไม่ได้แสดงความจริงใจ
เราจะจัดการกับ technical debt อย่างไร
อยากขีดเส้นใต้เอาไว้ว่า การไม่จัดการกับ technical debt อย่างทันท่วงที เป็นหนทางที่อันตรายในการทำ software และในทางกลับกันการทำให้ technical debt ในระบบน้อยที่สุด จะทำให้ software เรามี agility สูงและสามารถรองรับ features ใหม่ ให้ลูกค้าได้ใช้ไปนานๆ ดังนั้นการลดจำนวน technical debt ลงจึงสำคัญมาก ก่อนที่มันจะควบคุมไม่ได้
สิ่งที่ต้องทำในการจัดการกับ technical debt
บอกให้ Product Owner ทราบว่า technical debt มีราคาที่ต้องจ่าย ดังนั้นหลีกเลี่ยงมันซะตั้งแต่แรกหากเป็นไปได้ บอกเค้าว่า “do the thing right” ดีกว่า
ทำให้ technical debt อยู่ใน workflow เปิด ticket และจัดการมันเหมือนเป็น new user story หรือ bug fix อย่าเอาไปซ่อนไว้
เขียน automated test ให้ครอบคลุมให้มากที่สุด (>80% coverage) เพราะยิ่งจับบั๊กได้ดีเท่าไหร่ ยิ่งทำให้เรากล้า refactor เพื่อกำจัด technical debt ออกไป
ทำการ review code ให้เข้มข้น มองหา code smells และแก้ไข สร้าง quality mindset
เพิ่มทักษะให้ทีมงานให้มี skill ที่เพียงพอ จะทำให้ code มี quality มากขึ้น การ pair programming หรือการให้ dev เลือก ticket มาทำเอง เรียนรู้ best practices และลองสิ่งใหม่ๆ เป็นตัวกระตุ้นที่ดี
ที่สำคัญ ทุกคนในทีมไม่ว่าจะเป็นระดับ management, engineers ไปจนถึง designers ต้องตระหนักถึงการมีอยู่ของมันและร่วมกันจัดการอย่างเป็นระบบ
บทสรุป
การที่มี technical debt ไม่ใช่เป็นสิ่งไม่ดี เพียงแต่เราต้องควบคุมมันให้ได้ เพื่อพัฒนา product ที่ตอบโจทย์ธุรกิจไปนานๆ การที่มี technical debt เยอะทำให้โค้ดมีคุณภาพต่ำ จะแก้ไขอะไรก็ลำบาก เพราะไม่แน่ใจจะกระทบส่วนใดบ้าง ทำให้ทีมท้อแท้และหมดกำลังใจในการแก้ไขปัญหาในที่สุด
TSAClub