แนะนำ 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 ได้ง่ายขึ้น

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