สิ่งหนึ่งที่ได้เรียนรู้ในการพัฒนา 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 ของงานนั้นตัดได้
แต่เรื่องของคุณภาพนั้น ตัดไม่ได้นะครับ