คิดอย่างไรกับการทำ Code Review

ไม่ว่าจะเป็น Code review, Test-Driven Development และ Continuous Integration ล้วนเป็นแนวปฏิบัติที่เกิดขึ้นมา เพื่อทำให้มั่นใจว่า code ที่ถูกสร้างขึ้นมาในแต่ละวัน มันมีคุณภาพที่ดีขึ้น โดยหลายทีม หลายองค์กร ได้นำไปใช้ในการพัฒนา software แต่หลาย ๆ ที่ก็ไม่นำแนวปฏิบัติเหล่านี้ไปใช้งาน หรือนำไปใช้แล้วกลับก่อให้เกิดปัญหาแทน ดังนั้นมาดูเหตุผลหลัก ๆ ว่ามันคืออะไร ?

Code review มันใช้เวลานานมาก ๆ

ในโลกของการพัฒนา software นั้น ในแต่ละวันของการพัฒนานั้น เรามักจะพร่ำบอกว่า ไม่มีเวลา เรามักจะพร่ำบอกว่า เวลาน้อยไป และทุก ๆ ระบบจะพบว่ามันไม่เคยส่งงานไ้าตามเวลาที่ตกลงไว้เลย ดังนั้น สิ่งที่เรามักจะทำกัน คือ ตัดทุกสิ่งทุกอย่างที่มันใช้เวลาออกไป รวมทั้งสิ่งที่ช่วยทำให้คุณภาพของระบบที่สร้างมันดีขึ้นด้วย !!

ดังนั้นแทนที่จะทำ Code review ก็ให้ programmer ทำการพัฒนา code ให้เร็วที่สุด ทดสอบเอง ซึ่งไม่รู้ว่าทดสอบแบบไหน แต่จะบอกว่า งานเสร็จแล้ว โดยไม่ได้สนใจโครงสร้างของ code และ ระบบเลย

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

คนที่ Review code มองเพียงแต่ภาพใหญ่ และ กลายเป็นคอขวด !!

ทีม หรือ องค์กร ที่มีตำแหน่งเพื่อทำการ Review Code โดยเฉพาะ มักจะพบว่า คนคนนั้นมันคือ คอขวดของการพัฒนาไปในทันที ลองคนนี้หยุดทำงานสิ ทุกสิ่งทุกอย่างต้องหยุดอย่างแน่นอน ยังไม่พอนะ ถ้าทำการ review นาน ๆ ครั้ง ถ้าทำการ review เพียงภาพใหญ่ของระบบ โดยไม่สนใจส่วนเล็ก ๆ เลย มันน่าจะไม่ถูกต้องมากนัก

ดังนั้นขอแนะนำการทำ Code Review นิดหน่อย

ให้ทำ Code review เหมือนกับการ hack เข้าไปยังคนคนนั้น ว่าเขาคิดอย่างไร ? ว่าทำไมเขาคิดอย่างนั้น ? มันง่ายมากที่หาจุดที่ไม่ดีใน code มันง่ายพอ ๆ กับการแก้ไข ( แต่ก็ไม่ค่อยแก้ไข เพราะว่า ไม่มีเวลา !! ) ในแต่ละวัน programmer แต่ละคนสามารถที่ ทำการ rename ชื่อตัวแปร ชื่อ method ได้จำนวนมาก ๆ สามารถทำการ extract code ไปยัง method ใหม่ ๆ ได้จำนวนมาก ๆ สามารถแก้ไขรูปแบบ code ที่ไม่ดี ได้จำนวนมาก ๆ สามารถแก้ไข Bug ได้ จำนวนมาก ๆ ปล. ถ้ามีเครื่องมือดี ๆ นะ แต่ว่าไม่สามารถ แก้ไขโครงสร้าง และ สถาปัตยกรรมของระบบได้ แก้ไขปัญหาเรื่อง performance ของระบบได้ แก้ไขข้อมูลที่ไม่ถูกต้องบน production ได้ เพราะว่า ระบบยังทำงานอยู่

มาถึงตรงนี้ สิ่งที่ควรทำคืออะไรล่ะ ?

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

จะทำ Code Review ให้ดี

แนะนำให้ทำบ่อย ๆ ซึ่งนั่นหมายถึง การทำ peer review และ pair programming แทนซะ รวมทั้งอย่าให้ Code Review กลายเป็นคอขวด หรือ ปัญหานะ เนื่องจากเป้าหมายของมัน เพื่อช่วยให้ระบบที่ทำการพัฒนาดีขึ้นอย่างต่อเนื่อง