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