หลังจากที่ในค่าย Spartan 3.0 นั้น เพิ่มช่วงเวลาการทำ Code review เข้าไป
โดยพาทำในตอนเช้า เพื่อดูว่า เมื่อวานทีมทำอะไรไปกันบ้าง
ช่วยกันดูว่าระบบที่พัฒนากันเป็นอย่างไร
มีอะไรที่ผิดปกติไหม
และอื่นๆ อีกมากมาย
แต่การที่จะทำ Code review ได้นั้น
ควรมีการกำหนดหรือพูดคุยกันในทีมก่อน
เพื่อสร้างแนวปฏิบัติเดียวกันของคนในทีม
โดยแนวปฏิบัติที่ขอแนะนำประกอบไปด้วย สิ่งต่างๆ ดังต่อไปนี้
1. ทำการ commit เล็กๆ
ถ้าทำการ commit เล็กๆ และบ่อยๆ ทำให้การทำ Code review สามารถทำได้ง่าย
ส่งผลถึงการแตกงานที่ต้องเล็กตามไปด้วย
ดังนั้นลองกลับไปดูว่าทีมของคุณ commit ใหญ่หรือเล็ก
ตัวอย่างที่ดูง่าย ถ้า commit บ่อยๆ น่าจะบ่งบอกว่าคุณ commit เล็กกว่าการ commit วันละครั้ง
ถ้า commit วันละครั้ง แนะนำให้ทำการแตกงานออกมาให้เล็กลงอีก
อย่าละเลยข้อความที่เขียนในการ commit ด้วยนะ
มันจะช่วยบอกว่าคุณทำอะไรไปบ้าง
มีประโยชน์มากๆ ต่อการทำ Code review
2. กำหนดขอบเขตของเวลาซะ
เพื่อทำให้มันชัดเจน เช่นทำในทุกๆ เช้า เวลา 30 นาที
แต่ถ้าทำไม่ได้จริงๆ ในเวลาที่กำหนด
ให้ทำการจัดเรียงลำดับความสำคัญของหัวข้อในการ review
จากสำคัญมากไปน้อย ถ้าหมดเวลาก็จบ
หรือถ้าทำไม่ได้จริงในช่วงเวลานั้น
ก็เพียงเปลี่ยนเวลาซะ
3. อย่าให้มี Code Review Manager นะ
คืออย่าให้มีคนที่ดูแลการทำ Code review เพียงคนเดียว
จะทำ Code review เมื่อไร ไอ้คนนี้ต้องมาทำตลอด
อาจจะให้เตุผลว่า ไม่มั่นใจว่า code ที่ไม่ผ่านตาไอ้คนนี้แล้ว มันอาจจะเกิดปัญหาได้
มันคือการสร้างคอขวดขึ้นมาอีก แถมจะดีไม่ดีก็ขึ้นอยู่กับคนๆ เดียว
มันแย่มากๆ
ดังนั้นควรกระจายความรู้ในเรื่องของการทำ Code review ไปให้สมาชิกในทีม
เพื่อให้มีความรู้ความเข้าใจ
ทำให้พัฒนา code ที่มีคุณภาพมากยิ่งขึ้น
เหมือนคอยเป็น coach ช่วยให้ทีมพัฒนาขึ้นอย่างต่อเนื่อง
4. สรุป Coding Guideline หรือมาตรฐานของทีมขึ้นมาซะ
ไม่ใช่ให้คนๆ เดียวมากำหนดนะครับ
แต่ทีมต้องมานั่งตกลงกัน ว่าอะไรทำได้ไม่ได้
ถ้าสิ่งที่ทำไม่ได้ จะทำได้เมื่อไร อย่างไร และต้องการความช่วยเหลืออะไร
มันคือเส้นทางการปรับปรุงให้ดีขึ้นเรื่อยๆ
แต่ต้องทำให้มั่นใจว่าทุกๆ คนเข้าใจเหมือนกัน
และสุดท้ายคุณจำเป็นต้องทำเครื่องมือบางอย่างมาช่วยตรวจสอบ
ตัวอย่างในค่ายที่นำมาก็คือ Sonar qube
5. สรุปหัวข้อในการทำ Code review ว่าจะทำอะไรบ้าง
เนื่องจากในโลกของการพัฒนาปัญหามันมีอยู่เยอะมากๆ
แล้วเรามักจะฟุ้งไปหมด
ยิ่งอะไรที่แย่ๆ นะ เราเหมารวมมาหมด
ดังนั้นควรสรุปเลยว่าหัวข้อที่จะทำการ Review มีอะไรบ้าง
เปรียบเสมือน checklist นั่นเอง
แน่นอนว่าทีมช่วยกันสรุปนะครับ
อย่าลืมว่าการพัฒนา software คือกระบวนการเรียนรู้ ดังนั้นทำตั้งแต่เนิ่นๆ
ตัวอย่างหัวข้อที่น่าสนใจ เช่น Code smell, DRY, SOLID, YAGNI และ KISS เป็นต้น
6. ทำเล็กๆ ดีกว่าไม่ทำ
ในการทำ Code review นั้นมันคือการแบ่งปันความเป็นเจ้าของ
ไม่ให้ใครเป็นเจ้าของส่วนนั้นหรือส่วนนี้
แต่ทุกๆ คนคือเจ้าของในทุกๆ ส่วน
และเป็นการแบ่งปันความรู้ซึ่งกันและกัน
ดังนั้น ถ้าเหลือเวลาการทำน้อยๆ ก็ให้ทำน้อยๆ
7. นำเครื่องมือที่เห็นว่ามีประโยชน์มาใช้
เมื่อทำไปเรื่อยๆ จะพบว่าระบบงานจะซับซ้อนไปเรื่อย
มีขนาดใหญ่ขึ้นเสมอ
ดังนั้นทีมจะเรียกร้องกันเองว่า เราน่าจะมีเครื่องมือมาใช้
เพื่อลดเวลาการ review และเพื่อประสิทธิภาพ
รวมทั้งลดแนวความคิดที่แอนเอียงหรือเข้าข้างตัวเองไปในตัว
สุดท้าย
ขอเน้นย้ำว่าการทำ Code review มีเป้าหมายเพื่อ
ทำให้ code ในระบบดีขึ้นกว่าเดิม ไม่จำเป็นต้อง perfect แต่ดีขึ้นกว่าเดิมเรื่อยๆ
แบ่งปันความรู้ต่างๆ ของระบบให้แก่ทุกๆ คนในทีม
และเป็นข้อตกลงของทุกๆ คนในทีมว่า code เราควรจะเป็นอย่างไร
แต่อย่ามองว่ามันเป็นกระบวนการที่สร้างมาเพื่อ ด่ากัน หาคนผิด …
หรือนำตัวเลขต่างๆ มาใช้ใน KPIs เพราะว่ามันจะกลายเป็น Killer Performance
มันก็ไร้ค่าในทีสุด …
Reference Website
นำรูปมาจาก simpleprogrammer.com
