สิ่งที่ได้เรียนรู้จากการทำ Code Review

บ่อยครั้งมีโอกาสทำการ review code ของระบบต่าง ๆ
โดยก่อนที่จะเริ่ม review นั้น มักจะถามก่อนว่า

• เป้าหมายของการ review code คืออะไร ?
• ผลลัพธ์ที่คาดหวังจากการ review code เป็นอย่างไร ?
• ทำการตัดสินใจต่อไปอย่างไร หลังจากการ review ?

สิ่งที่น่าแปลกใจก็คือ เราจะรู้ว่าเรามีปัญหาเรื่อง คุณภาพ
ก็ต่อเมื่อมันทำให้เราช้าลงไปอย่างมาก
ทำไมนะ ?

ตัวอย่างเช่น
ในการ review code แต่ละครั้ง ล้วนเกิดมาจากปัญหาทั้งสิ้น
เพราะว่า code เหล่านั้นทำให้ค่าใช้จ่าย และการ regression มันสูงขึ้นเรื่อย ๆ

ซึ่งมันเป็นเหตุผลที่ไม่เหมาะสมนักสำหรับการทำ code review
เนื่องจากทำไปก็ไม่มีอะไรดีขึ้น หรือทำไปคุณก็คือผู้แพ้ และ ผู้สูญเสียอยู่ดี

การทำ code review นั้น
เราจะไม่ทำการ blame หรือไม่ตำหนิใครคนใดคนหนึ่ง
เราทำเพื่อปรับปรุงคุณภาพของคน
เราทำเพื่อให้ developer ได้เรียนรู้
เราทำเพื่อให้ developer ได้เติบโต

ดังนั้นเราต้องเปลี่ยนจากการเข้ามา audit
ไปเป็นการเข้ามาทำงานร่วมกับทีม
ด้วยการกำหนดก่อนว่า ปัญหาที่แท้จริงคืออะไรกันแน่ ?
เพื่อทำให้เราเข้าใจว่าสิ่งที่กำลังสร้างมันเป็นอย่างไร
เพื่อทำให้เข้าใจว่าระบบมันมีการเติบโตอย่างไร
เพื่อทำให้เข้าใจซึ่งกันและกัน
ก่อนที่จะทำงานด้วยกันแบบ win-win

การทำ code review นั้นเพื่อโอกาสในการปรับปรุง

อย่างที่บอกไปว่ามันไม่ใช่การเข้ามา audit code
แต่เป็นการเข้ามาเพื่อ พูดคุยกับทีมว่า
ผลลัพธ์ที่ได้จากการพัฒนามันเป็นอย่างไรบ้าง
แล้วเรามีแผนที่จะแก้ไข และ ปรับปรุงมันอย่างไร

การทำ code review ควรทำบ่อย และ ต่อเนื่อง
ลองคิดดูสิว่า
ถ้าคุณทำการ review code จำนวน 5,000 บรรทัดในครั้งเดียว
มันคงไม่ใช่เรื่องที่น่าสนุกเลยใช่ไหม ?

และการ review code มันทำให้เราเข้าใจปัญหา
ซึ่งนั่นทำให้เราแก้ไขได้ง่ายขึ้นนั่นเอง

แต่การทำ code review นั้น ไม่ง่ายนะ !!

เราตัดสินใจได้อย่างไรว่า code ไหนดี หรือ ไม่ดี ?
ใช้ประสบการณ์ ?
ใช้ความรู้สึกส่วนตัว ?
ก็อาจจะได้นะ หรือคุณคิดว่าอย่างไร ?

แต่เชื่อเถอะว่า
คุณไม่สามารถทำการ review code ได้ทุกบรรทัดหรอกนะ
ดังนั้น เราจึงต้องการเครื่องมือพวก Static code analysis มาช่วย
เพื่อทำให้เราเห็น และ เข้าใจ code ในมุมมองต่าง ๆ มากขึ้น

แต่ในบางเรื่องมันก็ไม่สามารถใช้เครื่องมือ หรือ ตัวเลขวัดได้ เช่น
code ชุดนี้มันอ่านง่ายนะ
code ชุดนี้มันดูแลรักษาง่ายนะ
code มัน clean นะ

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

อย่าลืมนะว่า
เราทำการ review code เพื่อหาโอกาส และ แนวทางในการปรับปรุง
ดังนั้น developer จึงมีความสำคัญมาก ต้องเข้าร่วมด้วยเสมอ
เพื่อให้ได้ข้อมูลเริ่มต้นที่ถูกต้อง และ ชัดเจน
ไม่มีใครรู้ปัญหาที่แท้จริงมากไปกว่าคนทำงานหรอกนะ !!

เริ่มต้นอย่างไรดีล่ะ ?

สำหรับ code review นั้น มักจะเจอ code จำนวนมาก
ทั้งหลักร้อย หลักพัน หลักหมื่นบรรทัดขึ้นไป

ก่อนเริ่ม เราต้องพยายามดึงข้อมูลต่าง ๆ
ออกมาจาก code เหล่านั้นให้ได้มากที่สุดเท่าที่จะทำได้

เริ่มด้วยการดูว่าใช้เทคโนโลยีอะไรบ้าง
แต่ถ้าไม่เข้าใจ หรือ ไม่คุ้นเคยกับเทคโนโลยีที่ใช้
ก็ต้องพยายามทำความเข้าใจ ด้วยการสร้าง project เล็ก ๆ ขึ้นมาเพื่อทดสอบ

จากนั้นทำการสุ่มเปิดไฟล์ต่าง ๆ ขึ้นมาดู
แล้วใช้ editor/IDE ช่วย หรือดูจาก code reference ต่อไป
แต่นี่เป็นเพียงการเริ่มต้น หรืออุ่นเครื่องเท่านั้น

เมื่อเราอุ่นเครื่องได้ที่ นั่นคือ เราเริ่มคุ้นชินกับ code ล่ะ
ต่อไปเราเริ่มลงในรายละเอียดเชิงลึก
ด้วยการนำเครื่องมือต่าง ๆ มาใช้งาน
เพื่อดูข้อมูลในมุมมองต่าง ๆ เช่น

• เรื่องขนาดของ code
• เรื่อง Complexity ของ code
• เรื่องของ coupling และ cohesion

จากนั้นเริ่มค้นหา Smell code และ code ที่อาจจะทำให้เกิดความผิดพลาดได้
ซึ่งเราจะได้ข้อมูลออกมาเพียบ !!

ปัญหา คือ จะแก้ไขอะไรก่อนหลังดีล่ะ ?
แนวทางที่ขอแนะนำคือ ให้ทำการแก้ไขพวก critical bug/issue ก่อนเลย
ซึ่งมันไม่ควรเกิดขึ้นในระบบของเราเลยนะ

ส่วนเรื่องอื่น ๆ ที่ควรดูต่อมาคือ

• Compiler warning ต่าง ๆ อย่าให้มี และห้าม ignore นะ
• พวก TODO หรือสิ่งที่ IDE สร้างแบบอัตโนมัติมาให้ ก็ไม่ควรมี
• การ cast type ที่เยอะเกินไป
• การใช้ instanceOf ให้ลด ละ เลิก ซะ
• การ ignore test จะทำไปทำไม ลบไปซะ
• พวก JavaDoc comment ที่ไร้ค่า หรือ ไม่ถูกใช้งาน

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

ในการทำ code review กับทีม ควรกำหนดเวลาไปให้ชัดเจนเลย
เพื่อทำให้ทีมเห็นความสำคัญ และ เข้าใจตรงกัน
รวมทั้งให้เข้าใจปัญหาต่าง ๆ ร่วมกัน

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

สุดท้าย code review อาจจะไม่มี หรือ นาน ๆ ครั้งก็เป็นได้
เพราะว่า ทีมพัฒนาสามารถควบคุมเรื่องเหล่านี้เองได้แล้ว !! (Self-manages team)

สุดท้ายเราต้องทำรายงานให้ Manager และ Team Lead หรือ ลูกค้า

ว่าผลจากการทำ code review เป็นอย่างไรบ้างนั้นเอง

แต่ขอเน้นย้ำว่า
ก่อนที่จะสรุปรายงานในเรื่อง bug/issue ต่าง ๆ ที่พบเจอนั้น
ขอให้พูดคุย และ สรุป กับทีมพัฒนาเสียก่อน
โดยให้ทำการอธิบายลงในรายละเอียดจนกว่า
ทีมพัฒนาจะมีความเห็นร่วมกันว่ามันเป็นปัญหาจริง ๆ นะ
หรือมันคือข้อจำกัด หรือ ระเบียบของทีม หรือ องค์กร

ผลที่ได้คือ เราจะได้รายงานที่มี bug/issue จริง ๆ
ซึ่งข้อมูลเหล่านี้จะช่วย และ สนับสนุนทีมพัฒนานั่นเอง

วันนี้คุณทำ code review กันอย่างไร ?