วันนี้ได้อ่านบทความเรื่อง Technical Debt: What It Is & Isn’t
ทำการอธิบายเกี่ยวกับ TEchnical Debt
หรือ หนี้ทางเทคนิคจากการพัฒนา software ได้ชัดเจน และ เข้าใจง่าย
ดังนั้น จึงนำมาแปลกันนิดหน่อย
ในการพัฒนา software นั้น
เราต้องพยายามหลีกเลี่ยง
ลดสิ่งที่ทำให้การพัฒนามีปัญหา
ลดสิ่งที่ทำให้ความเร็วในการพัฒนาลดลง
ดังนั้น เราควรทำความรู้ และ เข้าใจกับ Technical debt
แต่เมื่อพูดถึง Technical debt แล้ว มักจะเกิดคำถามขึ้นมามากมาย
เช่น
- จริง ๆ แล้วมันคืออะไร ?
- อะไรบ้างที่ใช่ และ ไม่ใช่ ?
- มันมีที่มาอย่างไร ?
- เมื่อไรเราจึงยอมให้สร้าง ?
- มันส่งผลกระทบต่อการพัฒนาอย่างไร ?
- ทำการจัดการอย่างไร ?
- จะลดมันลงไปได้อย่างไร ?
- จะหลีกเลี่ยงมันอย่างไร ?
ดังนั้นมาหาคำตอบกันนิดหน่อย ดังนี้
Technical debt มันคืออะไรกันแน่ ?
คำนี้ถูกใช้งานครั้งแรกโดยคุณ Ward Cunningham อธิบายไว้ดังนี้
Technical debt มันคือสิ่งที่คุณบอกว่า
เดี๋ยวค่อยทำ
เดี๋ยวค่อยกลับมาทำ
เดี๋ยว …
และสิ่งเหล่านั้นมันกลับมาทำร้ายเราในอนาคต
และสิ่งเหล่านั้นมันกลับเป็นสาเหตุของการพัฒนาที่ช้าลง
ตัวอย่างเช่น ไม่ยอมทำการ refactor code เป็นต้น
แต่งานบางอย่างมันก็ไม่ใช่ Technical debt นะ
ถ้าคุณสามารถส่งมอบงานที่ดีเพียงพอให้กับลูกค้าได้
เช่น User Interface อาจจะไม่เป็นไปตามมาตรฐาน แต่สามารถทำงานได้ดี เป็นต้น
คุณ Martin Fowler อธิบายไว้ดังนี้
ถ้าคุณต้องการเพิ่ม feature ใหม่ ๆ เข้าไปในระบบ
แล้วพบว่ามันมี 2 วิธีการ คุณจะเลือกวิธีไหนระหว่าง
- เพิ่มได้รวดเร็ว แต่ code มันรกรุงรังมาก ๆ นั่นหมายถึง มันจะแก้ไขยากแน่นอน
- ใช้เวลานานกว่าวิธีแรกนะ แต่ code และระบบมันแจ่มมาก ๆ
คุณจะเลือกวิธีการไหน ?
คุณ Robert C. Martin หรือ Uncle Bob อธิบายไว้ดังนี้
สิ่งที่มันยุ่งเหยิงนั้น ไม่ใช่ Technical debt
สิ่งที่มันยุ่งเหยิง มัน ก็คือ สิ่งที่มันยุ่งเหยิง !!
การที่จะติดสินใจว่าอะไรคือ Technical debt หรือไม่นั้น
มันขึ้นอยู่กับงานนั้น ๆ ว่ามีข้อจำกัด หรือ เงื่อนไขอะไรบ้าง
แต่การตัดสินใจทำ หรือ ไม่ทำอะไร
มักจะเกิดมาจากความขี้เกียจ และ ไม่เป็นมืออาชีพ
และมักจะไม่มีโอกาสมาชดใช้ หรือ แก้ไขอีก
รวมทั้ง มันทำให้คุณพลาดสิ่งที่ดี ๆ ไปอีกมากมาย
ดังนั้น ถ้า code ที่คุณสร้างขึ้นมามันยุ่งเหยิง วุ่นวาย แล้ว
มันก็คือ code ที่แย่ ๆ นั่นเอง เปลี่ยนเป็นอย่างอื่นไม่ได้
มาดูตัวอย่างของ Technical debt ในโลกการพัฒนาสิ
Developer มักจะพบเจอ และ ทำกันอยู่เป็นประจำ คือ
สร้าง และ แก้ไขไฟล์ source code ที่มีขนาดใหญ่มาก ๆ
มีขนาดใหญ่จน developer ไม่กล้าแตะต้อง
เพราะว่า มันเกิดความผิดพลาดได้ง่ายมาก ๆ
และที่สำคัญทุกคนในทีมรู้ว่า
จะต้องแก้ไขไฟล์นี้อย่างไร เพื่อทำให้มันจัดการได้ง่ายขึ้น
นั่นคือ การแบ่งออกเป็นไฟล์เล็ก ๆ
แต่ ….
ถ้าแก้ไขตอนนี้ จะต้องทำให้งานที่ทำอยู่ช้าไปอย่างน้อย x สัปดาห์ !!
ดังนั้นอย่าเพิ่มทำมันเลย เดี๋ยวก่อน เอาไว้ทำทีหลัง … ( Later == Never )
เมื่อไรก็ตามที่เราทำการเพิ่ม หรือ แก้ไข code
โดยไม่ทำการ refactor code ก่อนแล้ว
มันคือ การเพิ่ม Technical debt เข้าไปยังระบบ
และถ้าทำแบบนี้ไปเรื่อย ๆ จะพบว่า
คุณจะทำการแก้ไข และกลับมา refactoring ยากขึ้นอย่างต่อเนื่อง
ที่สำคัญ Technical debt มันก็มีดอกเบี้ยด้วยนะ
ดอกเบี้ยนั้นก็คือ ความซับซ้อนของระบบที่เพิ่มขึ้นอย่างต่อเนื่อง
ยิ่งนับวันยิ่งโต
ยิ่งนับวันยิ่งซับซ้อน
ยิ่งนับวันยิ่งยุ่งเหยิง
การจะกลับมาแก้ไข ยิ่งเป็นไปได้ยาก
อยากฝากไว้ว่า
เมื่อไรก็ตามที่ developer มีความรู้สึกว่า
ไม่มีเวลาเขียน code ที่มันเรียบง่าย
ไม่มีเวลาเขียน code ที่ดี
ไม่มีเวลาเขียน code ที่ดูแลรักษาง่าย
นั่นบ่งบอกถึงปัญหาของ developer เช่น
ไม่มีประสบการณ์ในการเขียน code มากพอ
ไม่มีความเป็นมืออาชีพในสิ่งที่ตนเองทำ
มาถึงตรงนี้ น่าจะพอทำให้เข้าใจว่า
Technical debt คืออะไร เป็นอย่างไร
และอะไรที่ไม่ใช่บ้างแล้วนะ
ดังนั้น คุณควรเริ่มจัดการ Technical debt ได้แล้ว
ไม่เช่นนั้น คุณจะอยู่ในกงกรรมกงเกวียน
ของการสร้าง แก้ไข ลบ สร้างใหม่ แก้ไข ลบ สร้างใหม่ …
