ว่าด้วยเรื่อง Build Quality In

สิ่งหนึ่งที่ได้เรียนรู้ในการพัฒนา software ที่มีคุณภาพ คือ อย่าแบ่งการพัฒนา software ออกเป็น

• การพัฒนา feature
• การปรับปรุงคุณภาพ

เนื่องจากมันส่งผลเสียตามมามากมาย !!

คุณสมบัติของ code ที่ยืดหยุ่นต่อการแก้ไขในอนาคต

ประกอบไปด้วย

• อ่านเข้าใจได้ง่าย
• สามารถเพิ่ม และ แก้ไขได้ง่าย โดยส่งผลกระทบน้อย
• มีจำนวน test coverage ที่ดี หรือครอบคลุมส่วนการทำงานหลัก ๆ

แต่ถ้า Developer ทำการเขียน code ที่แย่ ๆ หรือ คุณภาพแย่ ๆ ออกมา

แล้วรอเวลาสำหรับกลับมาแก้ไข code เช่น หลังจากทำการ deploy ไปยัง production แล้ว สิ่งที่ต้องกลับมาทำ มักจะประกอบไปด้วย

• ทำการเขียนเอกสารเพื่ออธิบาย code
• เขียนชุดการทดสอบ
• ทำการแก้ไข และ refactor code ในส่วนที่มันยุ่งเหยิง
• ทำการ review code

แปลกดีนะ เรามักจะทำแบบนี้กัน นั่นคือ ทำให้มันเสร็จ ๆ ไปก่อน แล้วเดี๋ยวค่อยกลับมาแก้ไข ซึ่งเราก็พบอีกว่า ไม่เคยกลับมาแก้ไขเลย นั่นคือ Later is Never !!

สาเหตุที่ทำให้เราแยกกิจกรรมเกี่ยวกับคุณภาพออกมา?

ในการพัฒนา software นั้นมักจะ ได้รับความกดดันมาจากฝั่ง business ที่ต้องการให้ส่งมอบ feature ให้เร็วที่สุด เป็นงานที่ยากมาก สำหรับการต่อรองเรื่องเวลากับทาง business ว่าต้องเพิ่มเวลาสำหรับเรื่องของคุณภาพ เนื่องจากค่าใช้จ่ายมันถูกกำหนดไว้แล้ว เพิ่มไม่ได้ ลดได้อย่างเดียว !! รวมทั้งเรื่องของเวลาที่เพิ่มเข้ามานั้น มันจะช่วยเพิ่มผลประโยชน์ทาง business อย่างไร ? มันวัดยากมาก ๆ นะ !! ดังนั้นแทนที่จะทำการต่อรอง เรื่อง scope และ เวลากับทาง business ซึ่งมันยากมาก ๆ ก็มาต่อรอง หรือ ลดในส่วนของการพัฒนาดีกว่า (Technical Practices) นั่นคือ พัฒนาให้มันเสร็จ ๆ ไปก่อนนั่นเอง (Good Enough Software) !!

โดยปกติการทำงานของ developer จะมีขั้นตอนดังนี้

• เขียน code เพื่อพัฒนาแต่ละ feature ให้เสร็จตามความต้องการ
• ทำการ clean up code, refactor code เพื่อทำให้ code ดีขึ้น ว่าด้วยเรื่องของคุณภาพ

ซึ่งแยกออกจากกันอย่างชัดเจน แต่ในการพัฒนา software เราจะพบกับสิ่งหนึ่ง คือ Dead Line นั่นคือ เราไม่มีเวลาแล้วนะ ดังนั้นสิ่งที่ developer ส่วนใหญ่จะทำคือ การตัดเรื่องของคุณภาพออกไปไงล่ะ !! และสนใจเพียงการพัฒนาระบบตาม functional requirement โดยไม่สนใจ non-functional requirement เลยแม้แต่น้อย !!

คำถามที่น่าสนใจคือ

สิ่งที่ developer บอกว่า งานเสร็จแล้ว ในความเป็นจริงมันเสร็จจริง ๆ หรือไม่ ? เช่น

• ทำการทดสอบ code ที่เขียนหรือไม่ ?
• ทำการทดสอบระบบทั้งหมดหรือไม่ ว่าสิ่งที่สร้างมันกระทบระบบหรือไม่ ?
• ทำ regression test หรือไม่ ?
• ทำการทดสอบทุก ๆ feature ของระบบหรือไม่ ?

ถ้ายังไม่ทำแล้ว จะบอกออกมาได้อย่างไรว่า งานเสร็จแล้ว !! อย่าส่งมอบงานที่มันยังไม่เสร็จนะ

โดยสรุปแล้ว

สิ่งที่แนะนำคือ อย่าแยกการพัฒนา กับ คุณภาพออกจากกัน มันต้องเดินไปด้วยกันเสมอ ตัวอย่างเช่น Test-Driven Development (TDD) นั่นคือ เราเขียน code และเขียน test ไปด้วยกันเสมอ ส่งผลทำให้เรามั่นใจได้ว่า code ทุกส่วนที่เราเขียนมันถูกทดสอบอยู่เสมอ และแน่นอนว่า มันย่อมมีจำนวน test coverage ที่สูงด้วย

สุดท้ายขอเน้นย้ำว่า Scope ของงานนั้นตัดได้ แต่เรื่องของคุณภาพนั้น ตัดไม่ได้นะครับ