No+time+to+explain_a27db0_3273653
ไม่ว่าจะเป็น 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 กลายเป็นคอขวด หรือ ปัญหานะ

เนื่องจากเป้าหมายของมัน เพื่อช่วยให้ระบบที่ทำการพัฒนาดีขึ้นอย่างต่อเนื่อง