review-code
ในการพัฒนา software นั้นการทำงานเป็นทีมมันสำคัญมาก ๆ
ยิ่งเรื่องของ code ที่มีคุณภาพ (Code Quality) ยิ่งสำคัญมากขึ้นไปอีก
แต่สิ่งยากกว่าคือ จะทำการ review code อย่างไรดี ?

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

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

เหตุผลที่ 1 คือ เป็นการสอน developer คนอื่น ๆ ในทีม

เนื่องจากในการพัฒนา software นั้นมันมีความซับซ้อนสูงมาก ๆ
แต่ละคนอาจจะรู้เพียง 5-10% เท่านั้น
ทำให้เราไม่รู้เลยว่า สิ่งที่ได้แก้ไขหรือเพิ่มเข้าไปนั้นส่งผลอะไรต่อระบบบ้าง
มันเป็นทั้งของจำกัดของคน และ ต้นเหตุของปัญหาหลาย ๆ อย่าง

ดังนั้นถ้าต้องการแบ่งปันความรู้หรือสอนคนอื่น ๆ ในทีม
ให้มีความรู้ในสิ่งที่เรารู้
วิธีการที่ดีมาก ๆ คือ การ review code และ pair programming

จะทำให้เราเห็นความเชื่อมโยงต่าง ๆ ของระบบ
นั่นทำให้เราเห็นผลกระทบโดยรวมมากยิ่งขึ้น

เหตุผลที่ 2 คือ ปรับปรุงเรื่องคุณภาพของ code

สิ่งที่นักพัฒนาส่วนใหญ่คิดคือ
ต้องทำให้งานเสร็จเร็ว ๆ !!
แต่เรื่องของคุณภาพนั้นเอาไว้ทีหลัง

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

จากสิ่งที่เหล่านี้เป็นเหตุผลอีกว่า
ทำไมนักพัฒนาไม่ทำการทดสอบ code ที่ตนเองเขียนขึ้นมา ?

จากสิ่งที่เหล่านี้เป็นเหตุผลอีกว่า
ทำไมเราต้องจ้าง Tester/QA มาทดสอบระบบ ?

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

เหตุผลที่ 3 คือ การสร้างวัฒนธรรมในการพัฒนาของทีม

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

และที่สำคัญแต่ละทีมก็ควรมีการ review code ที่แตกต่างกันไป
ตามลักษณะของทีม
ตามลักษณะของคน
ตามลักษณะของงาน
ไม่ควรใช้รูปแบบเดียวกันในทุก ๆ ระบบ

เหตุผลที่ 4 คือ ทำให้เรามีความเชื่อมั่นมากขึ้น

ถ้าคุณทำงานเพียงคนเดียว
แน่นอนว่า คุณย่อมเขียน code เพื่อตัวเอง
ไม่ต้องมาสนใจว่า code ที่เขียนมานั้นจะอ่านง่ายหรือยาก
นั่นคือ ไม่ได้สนใจเรื่องคุณภาพ

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

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

คำถามที่น่าสนใจ คือ ทีมของคุณทำการ review code บ้างหรือยัง ?

หรือว่าเพียงเขียน code ให้มันเสร็จ ๆ ไปก่อน
และสุดท้ายก็มาด่าทอกัน จากนั้นก็แก้ ๆ กันต่อไป ++

หรือคิดเพียงว่า
ทำงานให้ได้มาก ๆ
ส่วนคุณภาพเอาไว้ทีหลัง !!