ทำไมต้องทำ Code Review ด้วยล่ะ ?

ผมเชื่อว่า หลาย ๆ บริษัท หลาย ๆ ทีม
มีการนำ Code Review มาใช้งานแล้ว
เนื่องจากมันมีเหตุผลดี ๆ มากมาย

แต่กลับพบว่า ผู้นำไปใช้งานกลับหลงลืม
เป้าหมายพื้นฐานของ Code Review ไปเสียหมด !!

ทำให้
Code Review กลับกลายเป็นกิจกรรมที่น่ารังเกียจ
Code Review กลับกลายเป็นกิจกรรมที่น่ากลัว
Code Review กลับกลายเป็นกิจกรรมที่ไม่มีใครชอบ
Code Review กลับกลายเป็นกิจกรรมที่กล่าวโทษ
Code Review กลับกลายเป็นกิจกรรมที่หาคนผิดมาลงโทษ

ทำไมนะ ?

ก่อนอื่นตอบคำถามก่อนว่า ทำไมเราต้องการ Code Review ล่ะ ?

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

แต่การนำไปใช้งานจริง ๆ ของแต่ละที่
ล้วนต่างบริบทกันอย่างมาก
ซึ่งไม่ขอพูดถึง
แต่จะขอถามคำถามดีกว่า
เริ่มกันเลย

• ทำบ่อยไหม อย่างไร ?
• ทำก่อน หรือ หลังการ merge code ?
• มีคนเข้าร่วมกี่คน ?
• ทีมมีขนาดเท่าไร ?
• ลักษณะของทีมเป็นอย่างไร เช่น Distribuited team หรือไม่ ?
• จำนวนเฉลี่ยของ code ที่ทำการ review ในแต่ละครั้ง ?
• จำนวน class, method, line of code เป็นหลักสิบ หรือ ร้อย หรือ พัน ในแต่ละครั้ง ?
• ในการ review มีคนที่มีอำนาจในการ reject code หรือไม่ ?
• มีกี่คนที่สามารถ reject code ได้ ?
• ใครกันที่สามารถแก้ไข code ส่วนนั้น ๆ ได้ เช่น คนสร้าง หรือ ใครๆ ก็ได้ ?
• คุณคิดว่า Code Review ของคุณคือ session ที่ทำอะไร ?

คำตอบจากคำถามเหล่านี้
ให้ลองกลับไปดูเป้าหมายด้านบน
ก็จะรู้ได้เองว่า Code Review ของคุณมาถูกทางหรือไม่ ?

บ่อยครั้งที่พบว่า Code Review มันคือสิ่งที่เลวร้าย และ เจ็บปวดมาก !!

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

ดังนั้น Code Review ไม่ได้ช่วยอะไรให้ดีขึ้นเลย
ถ้าคุณทำการ review code จำนวนเยอะ ๆ ในครั้งเดียว
หรือทำการ review code ห่างกันนานมาก ๆ
หรือทำการ review code เพื่อหาคนผิด หรือ ต่อว่า

มันกลับกลายทำให้ผู้ทำการ review หรือ คนอื่น ๆ เจ็บปวด
แถมปวดหัวอีกต่างหาก
ดังนั้น เปลี่ยนมา review code บ่อย ๆ เล็ก ๆ ดีกว่า
รวมทั้งแนวคิดของการ review code ด้วย
นั่นคือ ต้องทำการฝึกฝน และ ปรับเปลี่ยนขั้นตอนการทำงานซะ

เมื่อไรเราควรทำ Code Review ?

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

ลองคิดดูสิว่า ถ้าคุณทำการ merge code สัปดาห์ละครั้ง มันจะนรกเพียงใด
ผมมองไม่เห็นเลยว่า Code Review จะมีผลดีอะไร

ต้องการกระจายความรู้ และ ไม่ต้องทำงานที่ไม่จำเป็น
มักจะใช้ Code Review ร่วมกับ Pair programming เสมอ
เพราะว่ามันทำให้เกิดการ review code อยู่ตลอดเวลา
พร้อมกับกระจายความรู้ให้แต่ละคู่อีกด้วย
รวมทั้งการทำงานเป็นคู่ จะช่วยลดการสร้าง code
และกิจกรรมที่ไม่จำเป็นออกไปอีกด้วย
เช่น การเล่น facebook, line เป็นต้น !!

ใช้ในการสัมภาษณ์คนเข้าทำงานไงล่ะ !!
ส่วนใหญ่ resume มักจะโกหก
แต่ผมเชื่อว่า code มันไม่โกหก
ดังนั้น การให้ทำ assignment เพื่อเขียน code สร้างระบบ
จากนั้นนำ code ชุดนั้นมา review
มันน่าจะทำให้เราเห็นอะไรดี ๆ ในตัว developer คนนั้นเยอะขึ้นไปอีก

เมื่อไรเราไม่ควรทำ Code Review ?

• หลังจากที่ code ทำการ merge ไปยัง production แล้ว มันช้าไปแล้วที่จะแก้ไข !!
• เมื่อมีจำนวน code มากมายที่ต้อง review ซึ่งมันทั้งเจ็บทั้งปวด และไม่ได้ช่วยทำให้อะไรดีขึ้นเลย
• ทำเมื่อเกิด bug ขึ้นมา ส่วนใหญ่มันคือ หาคนผิดมาก่อนแก้ไขนะ !!
• ทำการตรวจสอบ coding standard !! มันบ่งบอกว่าทีมขาดข้อตกลงเรื่องของคุณภาพอย่างมาก ดังนั้นควรตกลงกันใหม่นะ

คำแนะนำ ควร Pair programming ร่วมกับ Code Review เสมอ

เพื่อทำให้ Code Review มันง่าย และ รวดเร็ว
ยังไม่พอ ให้ทำการเปลี่ยนคู่ด้วยนะ
เพื่อทำให้ความรู้กระจายไปยังทุก ๆ คนในทีมได้อย่างรวดเร็วอีกด้วย
แถมการทำงานเป็นคู่
มันยังทำให้เราได้ feedback จากคู่ของเราได้รวดเร็วอีกด้วย
ซึ่ง code ที่ได้จากการ pair นั้น
มันจะมีโอกาสผ่านสูงมาก เมื่อต้องทำการ review

สุดท้ายแล้ว ถ้าทำอะไรก็ตามควรมีเป้าหมายก่อนเสมอ

ถ้าไม่มีเป้าหมาย
การทำ code review หรือ อะไรก็ตาม
ก็จะไร้ซึ่งคุณค่า กลับทำให้เกิดแต่ผลเสียมากกว่าผลดี

มีสติก่อน start นะครับ
อย่านำมาใช้เพียงเพราะว่า เขาบอกว่ามันดี !!

Reference Websites
http://codurance.com/2015/09/29/codereview/
http://blog.code-cop.org/2015/07/external-code-reviews.html