ในการพัฒนา 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 ส่วนไหน และ อย่างไรบ้าง ? มันช่วยทำให้เรามีความมั่นใจมากขึ้น ส่งผลให้ทั้งทีมมีความมั่นใจสูงขึ้นไปอีกด้วย