เพิ่มประสิทธิภาพให้ code review (ตอน 1)

“Code review” หนึ่งในพิธีกรรมศักดิ์สิทธิ์ที่เราเชื่อว่าถ้าทำแล้วโค้ดจะมีประสิทธิภาพและคุณภาพมากขึ้น

ทำไมถึงเรียกว่าศักดิ์สิทธิ์?

ก็เพราะว่าไม่ค่อยมีใครกล้าแตะมันยังไงล่ะ

  • หลายครั้งที่น้องจูเนียร์ตัวน้อยก็ไม่อาจเอื้อมที่จะไปบอกพี่ซีเนียร์ได้ว่า “พี่ฮับๆ ผมมีวิธีเขียนโค้ดนี้ที่ดีกว่านี้ฮับ”
  • พี่ซีเนียร์บางคนอาจมีรัศมีความน่าเชื่อถือสูงส่งจนทำให้พูดอะไรน้อง ๆ ก็ทำตามไปหมด
  • และมีอีกหลายเหตุการณ์ที่ยังคงทำให้การรีวิวโค้ดกลายเป็นการ “ตรวจการบ้าน” เท่านั้น

ถ้าหากลองสำรวจแล้วสิ่งเหล่านี้ยังเป็นปัญหาอยู่ให้ลองเริ่มจาก

1. Set stage ก่อนเริ่มรีวิวกันหน่อย

อย่าลืมว่าหลักใหญ่ใจความของการรีวิวโค้ดคือการ “แชร์” และการแชร์จะเกิดขึ้นไม่ได้เลยหากสมาชิกไม่สะดวกใจที่จะเป็นส่วนหนึ่งของกิจกรรม ด้วยความเกรงใจหรืออะไรก็แล้วแต่ ส่วนวิธีที่เคยทำมาก็คือการตั้งข้อตกลงที่ทุกคนยอมรับได้ เอาไว้ในที่ที่ทุกคนมองเห็นครับ เขียนไปเลยตัวใหญ่ ๆ บนกระดาน

ตัวอย่าง

— เราสามารถพูดกันตรงไปตรงมาได้เพื่อความชัดเจนในการรีวิวโค้ด

— ทุกคนสามารถพูดถึงทุกคนได้ไม่ว่าจะเป็นโค้ดของใคร

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


2. หาทางออก ไม่ต้องหาคนผิด

แน่นอน ไม่มีใครชอบให้คนอื่นมาบอกว่าตัวเราผิดหรือสิ่งที่เราทำมันผิด แต่หากทีมเห็นโค้ดที่ต้องปรับปรุงหรือทำให้ดีกว่านี้ได้ ให้ไปโฟกัสที่โค้ด ไม่ใช่ที่คน และเป็นประโยคในเชิงสร้างสรรค์ หากโฟกัสที่คนเค้าอาจจะไม่กล้าเอาโค้ดตัวเองมารีวิวอีกเลยจากการปรับปรุงจะกลายเป็นการซุกโค้ดได้

ตัวอย่าง

int a = 23 ;

“ผมว่าคุณตั้งตัวแปรอ่านไม่รู้เรื่องเลยนะ ไม่มีอะไรสื่อความหมายเลย”

กับ

ตัวแปรนี้น่าจะใช้ชื่อที่สื่อความหมายกว่านี้เช่น count หรือ …ฯลฯ”

ถามตัวเองว่า ชอบแบบไหนครับ


3. อย่ารอจนโค้ดก้อนใหญ่เกินไป

เมื่อรอให้เวลาล่วงเลยก็เขียนโค้ดได้เยอะ เมื่อเขียนโค้ดได้เยอะ โค้ดก็ก้อนใหญ่ เมื่อโค้ดก้อนใหญ่ ก็ใช้เวลารีวิวแสนจะนานกว่าจะหมด พอใช้เวลานานก็หมดพลังกันหมดวิธีที่ง่ายที่สุดคืออย่าปล่อยให้นานเกินไปครับ

ควรมี code review meeting อย่างน้อยที่สุดสัปดาห์ละครั้ง ครั้งละไม่เกิน 1–1.5 ชั่วโมง

บล็อกนี้ชักจะยาว งั้นตัดจบเอาไว้แค่นี้ก่อนแล้วบล็อกต่อไปมาต่อกัน ยังมีอีกเพียบเลยครับ

อ่านต่อได้ใน -> part 2