แนะนำ 5 วิธี สำหรับการจัดการ Technical Debt

เรื่องของ Technical Debt หรือ หนี้ทางเทคนิค
มันน่าจะเป็นปัญหา หรือ ประเด็นถกเถียงกันอย่างมากในหลาย ๆ องค์กร
ดังนั้น เรามาเรียนรู้วิธีการจัดการมันดีกว่าไหม ?
เพื่อช่วยลด หรือ บรรเทาปัญหาเหล่านี้ลงไป

ผมเชื่อว่าหลาย ๆ คน ทีม และ องค์กร
ต่างรู้จักกับคำว่า Debt หรือ หนี้
แน่นอนว่าในส่วนของการพัฒนา software ก็มีหนี้เช่นเดียวกัน
นั่นคือ Technical Debt

แต่ส่วนมากมักจะไม่ค่อยสนใจในเรื่องนี้มากมัก !!

ตัวอย่างเช่น
Developer รู้ว่าสิ่งที่กำลังพัฒนามันคือ Technical Debt
แต่เดี๋ยวเราค่อยกลับมาแก้ไขในอนาคตก็ได้
ตอนนี้ทำแบบนี้กันไปก่อน
โดยไม่คำนึงผลกระทบที่จะเกิดขึ้นในอนาคตอันใกล้เลย

เนื่องจากในความเป็นจริงแล้ว Technical Debt
มันคือชื่อ ที่พยายามบอกถึง
ผลกระทบที่ตามมาจากการกระทำต่าง ๆ ในการพัฒนา software
ดังนั้น สิ่งที่เราควรกระทำ ก็คือ
การกระทำที่ส่งผลกระทบน้อยที่สุด และ ง่ายที่สุดนั่นเอง
แต่ว่า มันยากนะเออ !!

ดังนั้นขอแนะนำวิธีการจัดการ Technical Debt เพื่อให้นำมาใช้งานได้ง่ายขึ้น

1. คุณมี Automated test ในระดับ System/Application test หรือไม่ ?

สิ่งที่ทุกระบบควรจะต้องมี คือ
การทดสอบในระดับ system และ application
เพื่อใช้ตรวจสอบการทำงานว่าถูกต้องตามที่คาดหวังไว้หรือไม่
ไม่ใช่มีเพียงการทดสอบในระดับ class และ method เท่านั้น
ที่สำคัญต้องทำการทดสอบแบบอัตโนมัติอีกด้วย

เนื่องจากเราต้องการรู้ว่า
มีส่วนใดของระบบที่อาจก่อให้เกิดความเสี่ยง
ทำให้เราสามารถปรับปลี่ยน และ แก้ไขได้รวดเร็ว
โดยไม่กระทบ หรือ กระทบการทำงานโดยรวมน้อยที่สุด

มันจะช่วยลดปัญหาและเวลาในการทำ regression test
และลดผลกระทบต่าง ๆ ไปอย่างมาก

วันนี้คุณมี Automated test แล้วหรือยัง ?

2. ห้ามลืมกฎของลูกเสือ หรือ Boy Scout Rule

ท่องจำประโยคนี้ไว้ให้ขึ้นใจ และ ลงมือทำซะ

Leave the code better than you found it

มันคือการปรับปรุง code อย่างต่อเนื่อง
เมื่อใดที่คุณเห็นว่า code มันไม่ดี
ให้รีบทำการแก้ไขมันซะ

อย่าเพียงแค่พูดว่า code ชุดนี้มันแย่
แต่ให้ลงมือทำว่า มันแย่อย่างไร และทำอย่างไรให้มันดีขึ้น

เรื่องเหล่านี้มันคือ วัฒนธรรมของทีม และ องค์กร ที่ต้องสร้างมันขึ้นมา

ขอให้จำไว้ว่า ลงมือทำ มากกว่า พูด

3. Code เป็นของทุกคน ไม่ใช่เป็นของใครคนใดคนหนึ่ง หรือ ทีมใดทีมหนึ่ง

ตัวอย่างเช่น
Developer A ทำการพัฒนา feature A
โดยต้องไปใช้งาน Class B ซึ่งไม่เกี่ยวกับการพัฒนา feature A เลย
แต่เห็นว่า Class B นั้นมันไม่ดี ต้องได้รับการปรับปรุง
Developer A ควรทำอย่างไรดี ?

ถ้าตอบว่า
ทำไม่ได้หรอกนะ ต้องให้คน หรือ ทีมที่ดูแลแก้ไข
นั่นคือ ปัญหาที่ต้องได้รับการแก้ไข
มิเช่นนั้น code ที่ไม่ดี จะไม่ได้รับการปรับปรุงเลย

ปัญหาเหล่านี้มันเกิดจากกลายกรณี
แต่ขอให้ทำการแก้ไขเป็นกรณีไป
มิเช่นนั้น จะไม่สามารถนำ Boy Scout Rule มาใช้ได้ดีเท่าที่ควร

4. ทำ Pair programming และ Code review ซะ

ถ้าต้องการลดความเสี่ยงต่าง ๆ ของการพัฒนา software ลง
จำเป็นต้องมีการทำ code review เสมอ

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

แต่สิ่งที่ช่วยทำให้ code review มีประสิทธิภาพมากขึ้น คือ
การทำ pair programming นั่นเอง
ทำงานด้วยกัน ช่วยกันแบ่งปันความคิดเห็น
และช่วยการทำ code review แบบเล็ก ๆ และ ตลอดเวลา
ซึ่งทำให้การทำ code review รวมง่าย และ รวดเร็วขึ้นมาก

5. ตั้งคำถามกับตัวเอง หรือ ทีมว่า ทำไมต้องเขียน comment เพื่ออธิบาย code ด้วย

มันเป็นเรื่องที่มีการถกเถียงกันอย่างมาก
ว่าใน code ควรทำการ comment หรือไม่ ?

ขอตอบเลยว่า อันนี้ก็ไม่รู้เหมือนกัน
แต่สิ่งที่คุณต้องถามตัวเองก่อนก็คือ
เขียน comment ไปทำไม ?
เขียน comment ไปเพื่ออะไร ?

ถ้าคุณตอบได้ และสมเหตุสมผล
ก็น่าจะได้คำตอบว่า ควร หรือ ไม่ควรเขียน comment

ตัวอย่างเช่น
ถ้าตอบว่าเขียน comment เพราะว่า code ส่วนนี้มันอ่านไม่รู้เรื่อง และ ซับซ้อน
วิธีการแก้ไขมันไม่น่าจะเป็นการ comment code นะ
แต่ควรจะเป็นการปรับปรุง
code ให้อ่านรู้เรื่องขึ้น
code ให้ซับซ้อนน้อยลง

ถ้าตอบว่า เขียนเพราะว่า งานมันเร่งมาก จึงทำการ hack และเขียนเพื่อบอกให้ระวัง code ส่วนนั้น ๆ
มันดูมีเหตุผลที่ดีนะ ว่าไหม ?
แต่อย่าลืมกลับมาแก้ไขนะ !!

สุดท้ายแล้ว

ขอให้ Developer ทุกคนลองนำคำแนะนำทั้ง 5 ข้อนี้ ไปใช้งานดูนะครับ
น่าจะช่วยทำให้จัดการ และ ทำงานกับ Technical Debt ได้ง่ายขึ้น

ดังนั้น หยุดพูด หยุดถกเถียง และ ลงมือทำกันเถอะนะ