Code review หรือ peer review มันคือ
แนวปฏิบัติหลักของการพัฒนา software
ซึ่งทีมพัฒนา software จะต้องปฏิบัติอยู่อย่างสม่ำเสมอ
สามารถทำได้หลายลักษณะเช่น
- Pre-merge ทำการ review code ก่อน merge code เข้า branch หลัก เพื่อป้องกันความผิดพลาดต่างๆ
- Post-merge ทำการ review หลังจากที่ทำการ merge code แล้ว โดยมักจะเป็นกิจกรรมที่ถูกกำหนดไว้แล้ว (regular review) เพื่อหาข้อผิดพลาด และ สิ่งที่ผิดปกติต่างๆ
โดยในบางทีมทำทั้งสองแบบก็จะเยี่ยมมากๆ นะ
แต่เท่าที่เห็น แค่มี Code review ก็ยากลำบากล่ะ !!
ถ้าเทียบ code review ก็น่าจะคล้ายกับ White-box testing
ซึ่งทาง tester จะทำการมองหา defect จาก source code ทั้งหมด
รวมทั้งยังเป็นเครื่องมือสำหรับการเพิ่มคุณภาพของ software
และช่วยกระตุ้นทีมให้ทำงานได้ดีขึ้นอีกด้วย
แต่ว่า code review มันก็ใช่ว่าจะทำได้ง่ายๆ นะ แต่มันพูดกันง่ายมากๆ
- ทำ code review สิ ?
- ทำ code review แล้วหรือยัง ?
เพราะว่า เท่าที่พบว่าส่วนใหญ่มักจะทำผิดด้วยนะสิ
และก็พบว่ามักจะทำผิดเหมือนๆ กันเสียด้วย
ส่วนผมก็ผิดมามากเช่นเดียวกัน !!
ดังนั้น มาดูกันหน่อยแนวปฏิบัติที่ดีสำหรับการทำ code review เป็นอย่างไร ?
1. No Fear
ผู้ทำการ review code ควรจะทิ้งความกลัวต่างๆ ออกไปซะ เช่น
กลัวว่าเจ้าของ code จะโกรธ
ซึ่งนั่นคือ ทัศนคติที่แย่ หรือ ไปในเชิงลบทันที
เพราะว่ามันส่งผลให้คุณภาพของ code ลดลง แถมทีมก็จะรู้สึกไม่ดีอีกด้วย
ดังนั้นสิ่งที่ผู้ทำการ review code ต้องพึงระลึกไว้ก็คือ
- ชัดเจน
- มีความจริงใจ
- ตรงไปตรงมา
ถ้าคุณไม่ชอบ code ชุดนั้น ก็บอกไปว่าไม่ชอบ
แต่ต้องคำอธิบายด้วยว่าทำไม และ แก้ไขอย่างไรได้บ้าง
กลัวว่า ถ้าเราปฏิเสธ code ชุดนี้แล้วมันจะทำให้ release ไม่ทัน !!
แล้วคนในทีมก็จะบอกว่า คนที่ทำการ review code นั่นแหละคือ คอขวด ที่ทำให้ release ไม่ทัน
แบบนี้แสดงว่า ทีมที่คุณทำงานอยู่เป็นทีมที่ดีแล้วหรือ ?
ทีมพัฒนา software ที่มีความเป็นมืออาชีพนั้น
ต้องเข้าในบทบาท และ หน้าที่ของตนเองเสมอ
ถ้า code ที่มันแย่ๆ ถูกปฏิเสธจากผู้ทำการ review
แสดงว่าผู้สร้าง code นั้นแย่นะ
ซึ่งถ้าคุณมีความเป็นมืออาชีพจริงๆ
คุณจะต้องหยิบยกสิ่งที่แย่ๆ นั้นออกมาให้คนอื่นๆ รู้ด้วย
เพื่อทำให้เห็นว่าสมาชิกแต่ละคนในทีม
ต้องได้รับการปรับปรุง และ เรียนรู้เพิ่มเติมอย่างไร
ไม่ใช่ปิดปังไว้ตลอดเวลา
ดังนั้น มันคือวิธีการปรับปรุงทีมงานให้ดีขึ้นอยู่ตลอดเวลา
กลัวว่า สิ่งที่พูดออกไปมันดูน่าโง่ จะถูกหัวเราะเยาะ !!
ให้เปลี่ยนมุมมองว่า นั่นแสดงว่า เรายังขาดความรู้ในเรื่องนั้นๆ นะ
เช่น เราพูดออกไปว่า เราไม่รู้ว่าจะทำอะไรต่อไป
มันดีกว่าการเงียบนะ และพยายามบอกว่า code ของฉันไม่มี bug หรอกนะ
คุณอย่าดูถูก หรือ อายตัวเอง ว่าจะ comment อะไรโง่ๆ ออกไป
มันดีกว่าไหม ที่คุณจะอยู่เฉยๆ เงียบๆ แล้วคิดว่าฉันนี่แหละดูดี ฉลาด !!
ไม่น่าจะคิดแบบนั้นนะครับ
ดังนั้น อย่ากลัวที่ตัวเองจะทำผิด หรือ comment แบบโง่ๆ ออกไป
ทุกๆ ความคิดเห็นมันมีประโยชน์เสมอ
ทำในสิ่งที่ถูกต้อง และ พูดในสิ่งที่คุณคิดออกไป
เท่านั้นเป็นพอ
2. No Compromise
หลังจากที่คุณไม่กลัวที่จะพูด จะวิจารณ์อย่างสร้างสรรค์แล้ว
ว่า code มันไม่ดีเพราะว่าอะไร อย่างไร
เพื่อให้ทางเจ้าของ code หรือ ทีม ทำการ refactor หรือ เขียนใหม่
แล้วอะไรต่อไปดีล่ะ ?
ก็กลับไปแก้ไขไงล่ะ … แต่มันจะง่ายไปไหม
เท่าที่พบมา โดยธรรมชาติแล้ว เจ้าของ code ก็คือ นักพัฒนามืออาชีพ
แน่นอนว่าย่อมไม่กลัวใช่ไหม ?
และมีความเชื่อมั่นว่า สิ่งที่ทำไปนั้นมันคือ สิ่งที่ถูกต้อง
ส่วนสิ่งที่คุณทำการ review และ comment นั้น มันคือสิ่งที่ไม่ถูกต้อง หรือ ไร้สาระ
ถ้าเกิดเหตุการณ์ในรูปแบบนี้ คุณจะจัดการอย่างไรดีล่ะ ?
คำตอบ
สิ่งที่แย่ที่สุดสำหรับเหตุการณ์นี้ก็คือ การประนีประนอมยอมกัน (Compromise)
เป็นสิ่งที่ทำให้ code ของระบบคุณมันแย่ลงแบบรวดเร็วที่สุด
เคยได้ยินประโยคนี้ไหมครับ
Let’s make peace just to stop fighting
แล้วคิดว่าเขาจะหยุดสู้รบกันไหม ….
คำตอบคือ ไม่ … code ของคุณก็เช่นกัน
ดังนั้นแทนที่จะมาประนีประนอมยอมกัน ลองทำแบบนี้ดูบ้างไหม ?
1. ผู้ทำการ review code บอกว่า OK คุณถูกแล้ว เดี๋ยวเรากลับมา review/comment ใหม่
ผู้ review ยอมรับในความผิดพลาดทันที
ผู้ review อาจจะไม่ชอบ code ชุดนั้น
แต่ทางเจ้าของ code ได้ทำการอธิบาย และ ให้เหตุผลที่ดี ว่า code ชุดนั้นมันมีประโยชน์อะไร
และคุณก็ยอมรับเหตุผลนั้นด้วย
หรือ อาจจะพูดว่า ฉันผิดเอง เป็นสิ่งที่แสดงว่าทางผู้ review code นั้นวุฒิภาวะเพียงพอ
2. ผู้ทำการ review code บอกว่า ไม่สามารถยอมรับ code ชุดนี้ได้เลย
โดยจะต้องมีเหตุผลเพียงพอ และ ทุกๆ คนในทีมเห็นชอบร่วมกันว่ามันไม่ดี
ต้องทำการแก้ไข ไม่ว่าจะ refactor หรือ rewrite ทั้งหมดก็ตาม
ประเด็นนี้ทำให้ทั้งทีมได้เรียนรู้ใหม่อีกด้วย
3. บางคนอาจจะบอกว่า ฉันทำตามที่ architect สั่งมา หรือ ออกแบบมานะ !!
สิ่งที่ควรทำก็คือ เชิญ architect คนนั้นเข้ามายังกิจกรรม code review ด้วยเสมอ
เพื่อสอบถาม อธิบาย เมื่อเกิดปัญหาขัดแย้งขึ้นมา
ซึ่งบางครั้งสิ่งที่คิดว่าใช่ในตอนแรก อาจจะผิดตอนที่สร้างก็ได้
ดังนั้น จำเป็นต้องเรียนรู้ซึ่งกันและกันนะครับ
ดังนั้น จะต้องมีใครที่ผิดหรือถูกเสมอ
จะไม่มีการประนีประนอมนะ หรือผ่านไปที
แต่ต้องมีความยึดหยุ่น และ เรียนรู้กันอยู่ตลอดเวลา
ผู้ทำการ review ต้องอย่าเชื่อว่าสิ่งที่ตนเองไม่ชอบ มันถูกเสมอนะ
ทีมก็เช่นเดียวกัน
3. No Bullshit
ถ้าผ่านมาทั้งสองข้อ แล้วยังหาข้อสรุปสำหรับ code ชุดนั้นไม่ได้ล่ะ
จะทำอย่างไรดี ?
การจะเชิญกรรมการมาตัดสินก็อาจจะเร็วไป
สิ่งที่ทำได้คือ การโน้มน้าวด้วยเหตุและผล
ซึ่งมันคือการสอน เรียนรู้ซึ่งกันและกัน
คุณอาจจะรู้บางสิ่ง ที่คนอื่นไม่รู้
และเช่นกันคุณอาจจะไม่รู้บางสิ่ง ที่คนอื่นรู้ด้วย
แต่สิ่งที่พูด และ อธิบาย หรือ สอนออกมา นั้นต้องมีเหตุผล
สามารถพิสูจน์ หรือ ทำให้เห็นได้ชัดเจน
ไม่ใช่พูดแต่ศัพท์หรูๆ ที่ทำให้คนอื่นๆ ฟังไม่เข้าใจ
ดังนั้น เรื่องความรู้พื้นฐานในสิ่งต่างๆ มันจำเป็นมากๆ
เพื่อทำให้คนอื่นเข้าใจ และ เห็นด้วย
ขอย้ำว่า ต้องแสดงให้เห็น
ไม่ใช่ใช้เหตุผลทำนองว่า
ฉันเขียน Java มาแล้ว 15 ปีนะ ….
ในหัวของทุกคนคือ แล้วไงว่ะ … แต่ไม่กล้าพูดมันออกมา
แต่ถ้าคุณไม่สามารถโน้มน้าวด้วยเหตุผล และ แสดงให้เห็นได้
ให้คุณลองคิดอีกครั้งว่า คุณอาจจะผิดก็ได้นะ
จงจำไว้ว่า สิ่งที่คุณต้องทำก็คือ
พิสูจน์ให้เห็นได้ว่า code ชุดนั้นมันแย่จริงๆ นะ
ด้วยเหตุผล และ การแก้ไข ว่าทำอย่างไร
4. No Offense
สิ่งสุดท้าย มันคือสิ่งที่ยากสุดๆ สำหรับการ review code
นั่นคือ คุณต้องมีความเป็นมืออาชีพ มีความจริงใจ
ไม่ว่า code จะแย่อย่างไร
ไม่ว่าทีม หรือ เจ้าของ code จะดื้อรั้นเพียงใด
จะไม่มีการโจมตี หรือ ต่อว่า ใดๆ ทั้งสิ้น
คุณจะต้องอดทน และ ต้องหาวิธีโน้มน้าวให้ได้
วันนี้คุณทำ Code Review แล้วหรือยัง ?
