อย่าทำแบบนี้ เมื่อรีวิวโค้ด (Code Review Anti-Patterns)
Code Review เป็นหนึ่งในวัฒนธรรมการพัฒนาซอฟต์แวร์ที่ KBTG อยากจะปลูกฝังและสรรค์สร้างให้ยั่งยืนในตัว Developers ทุกคน เป็นธรรมดาขององค์กรขนาดใหญ่ที่การทำงานแบบ Silos เกิดขึ้นได้ทุกหนทุกแห่ง Code Review จะเข้ามาช่วยทลาย Silos นั้นและทำให้หลักการ “ยิ่งให้ ยิ่งได้” เกิดขึ้นจริงในทีมพัฒนาซอฟต์แวร์
ในยุคที่ “เวลา” คือต้นทุนสำคัญ การทำ Code Review ถือเป็นการลงทุนที่คุ้มค่า ถ้าเราทำมันได้อย่างถูกต้อง
หลายครั้งเหมือนกันที่ผมได้มีโอกาสคุยกับน้องๆ ที่เพิ่งเข้าทำงานในบริษัทและตอบคำถามเกี่ยวกับ “วิธีการเรียนรู้สิ่งต่างๆ ในที่ทำงาน” ผมชอบที่จะอธิบายง่ายๆ ว่าโดยพื้นฐานนั้นมีอยู่ 2 แบบ
- เรียนรู้สิ่งที่ดีและประยุกต์มาใช้ (Apply Best Practices)
- เรียนรู้ที่จะไม่ทำสิ่งที่แย่ (Avoid Anti-Patterns)
เราอาจจะไม่ต้องทำทั้งสองแบบก็ได้ แต่เราแค่เลือกมาใช้ให้เหมาะกับสถานการณ์ เหมาะกับสิ่งที่เราจะทำ เหมือนตอนเราทำข้อสอบ Multiple Choices สมัยเรียน บางทีเราไม่รู้คำตอบที่ถูกต้อง เราก็ใช้วิธีตัดตัวเลือกที่ไม่ถูกออก ยิ่งตัดได้เยอะเท่าไหร่ ตัวเลือกที่เหลืออยู่ก็จะยิ่งมีโอกาสถูกต้องขึ้นเท่านั้น บางครั้งวิธีนี้ก็เร็วกว่าการตั้งใจหาคำตอบที่ถูกแต่แรกด้วยซ้ำ
เข้าเรื่องเลยละกัน วันนี้ผมไม่ได้มากับบทความออริจินอลของตัวเอง แต่มาแปลสรุปบทความ Five Code Review Anti-Patterns ให้อ่านกันเพลินๆ พอดีได้ไปอ่านมาแล้วชอบ (เพราะมันโด๊นโดน) และตรงกับสิ่งที่บริษัทกำลังรณรงค์อยู่พอดี ต้นฉบับอยู่ด้านล่างครับ ไปตำกันได้เลย
1. เรื่องขี้ปะติ๋วเท่านั้นที่ฉันแคร์ (Nitpicking)
เราลองนึกภาพน้องนุ่งคนนึงที่ตั้งใจทำงานโพดๆ ในการวางโครงสร้างโค้ดเพื่อให้มันทำงานได้ดีที่สุด ก่อนหน้านั้นเขาทำการศึกษาและพิจารณาทางเลือกมาหลายทาง และคิดว่าได้เลือกสิ่งที่สมเหตุสมผล ว่าแล้วจึงทำการเขียน แก้ไข ปรับปรุงโค้ดในจุดใดที่โดนเจียว ทันทีที่เขาสร้าง MR/PR เข้าสู่กระบวนการรีวิว ฟีดแบคที่เขาได้รับนั้นคือ…
- ควรใช้ Tabs นะ อย่าใช้ Spaces
- ม่ายๆๆๆ ฉันไม่ชอบวงเล็บปีกกาที่ตรงนั้น
- น้องไม่ควรมีบรรทัดว่างๆ ที่ท้ายไฟล์นะ
- Enums ต้องใช้ตัวอักษรใหญ่ทั้งหมดสิ ไม่ควรใช้ตัวเล็กตัวใหญ่ผสมกัน
พวกนี้คือ Code Style ซึ่งสำคัญนะครับ ไม่ใช่ไม่สำคัญ แต่ประเด็นคือพวกนี้เราควรให้คอมพิวเตอร์ตรวจเพราะจะประหยัดเวลากว่าครับ ยิ่งไปกว่านั้น ปัจจุบันมีเครื่องมือสำหรับตรวจจับบั๊กและช่องโหว่จากการสแกนโค้ดได้ในเวลาเพียงไม่กี่วินาทีอีกด้วย เอาเวลาอันมีค่าของ Reviewers ไปรีวิวสิ่งที่คอมพิวเตอร์ไม่สามารถทำได้หรือทำได้ไม่ดีเถิดจะเกิดผล เช่น พวก Business Logic, Design Patterns, Performance Improvement ฯลฯ
Key Takeaways
- จัดทำ Code Style ของทีมและทำการ Check Style และแก้ไขก่อนการรีวิวซะ
- ถ้าให้ดีขึ้นไปอีก สามารถใช้เครื่องมือประเภท Code Scanning ทำการตรวจจับ Common Quality Issues และ Common Security Issues พร้อมทั้งแก้ไขให้เรียบร้อยก่อนเข้ากระบวนการ Code Review
2. เอาให้แน่ ฉันแก้ไม่ถูก (Inconsistent Feedback)
อย่านึกว่าต้องมี Reviewer หลายคนเท่านั้นถึงจะมีความเห็นไม่ตรงกันได้ แม้มี Reviewer คนเดียวก็บ้งได้ วันนี้มาแบบนึง พอเราไปแก้มา ครั้งหน้าเปลี่ยนใจละ สุนทรภู่ยังบอกว่าอย่าไว้ใจมนุษย์ มันแสนสุดลึกล้ำเหลือกำหนด
Key Takeaways
- ทั้ง Reviewer และ Author ควรเข้าใจสิ่งที่ทำอยู่ให้ลึกซึ้ง และหาข้อสรุปร่วมกันโดยพิจารณาตามลำดับความสำคัญ (Priority) ของสิ่งที่กำลังรีวิวเป็นสำคัญ ในบทความต้นฉบับเขาบอกว่าสถานการณ์แบบนี้มักเกิดขึ้นจากการที่ทีมเข้าใจสิ่งที่ทำเพียงผิวเผิน ทำให้ไม่สามารถหาข้อสรุปและจัดเรียงความสำคัญของสิ่งที่รีวิวกันอยู่ได้
3. เราเปลี่ยนดีไซน์กันทันไหม? (Last-Minute Design Changes)
คอมเมนต์สุดอลังการที่ฟังแล้วชวนจิตตกก็คือคอมเมนต์ในระดับของดีไซน์ภาพใหญ่หรือการวาง Architecture โดยรวมที่มีผลให้ผู้เขียนโค้ดต้องไปรื้อโค้ดเขียนใหม่หมด
มันอาจจะสมเหตุสมผลในเชิงเทคนิค แต่ในเชิงของการบริหารโปรเจคแล้ว “การ Review ดีไซน์ใน Code Review เป็นการกระทำที่ผิดเวลาไปหน่อย” เพราะโค้ดมันเสร็จแล้วไง บางทีใช้เวลาเกือบทั้ง Sprint ไปแล้ว Unit Test ก็เขียนเสร็จไปเรียบร้อยแล้ว เจอแบบนี้ต้องกินกาแฟเพื่อทำงาน ทำงานเพื่อซื้อกาแฟละทีนี้
Key Takeaways
- เราสามารถประยุกต์ Code Review มาใช้รีวิวดีไซน์ได้ แต่ควรทำในช่วงต้นก่อนที่จะลงมือโค้ด โดยสิ่งที่รีวิวอาจจะไม่ใช่โค้ด หากแต่เป็น Ideas, Prototypes, Diagrams หรือแม้แต่ Test Cases เพื่อให้ได้มาซึ่งฟีดแบ็คกันก่อนลงมือโค้ดจริง
- การต้องรื้อดีไซน์ในช่วงท้ายเป็นการใช้ต้นทุนไปอย่างเปล่าประโยชน์ และที่สำคัญคือทำให้ทีมงานเสียขวัญกำลังใจ และอาจจะเสียทีมเวิร์คโดยรวมได้
- เราสามารถใช้เทคนิคอื่นๆ มาช่วยลดโอกาสเกิดเหตุการณ์จิตตกเช่นนี้ได้ เช่น Pair Programming, Whiteboard Review หรือการคุยไอเดียกับ Tech Leads บ่อยๆ ก็ยังได้
4. รีวิวกันนิรันดร (Ping-Pong Reviews)
เมื่อรีวิวทำให้เกิดอิชชู่ แก้อิชชู่มาให้รีวิว วนไป วนไป เหมือนกับว่าสองเรานั้นเกิดมาเพื่อกันและกันชั่วฟ้าดินสลาย
ในบทความเขาบอกว่ามักมีสาเหตุมาจาก
- มี Reviewer แบบข้อ 1 (ขี้ปะติ๋ว) ที่ทำตัวแบบข้อ 2 (ไม่อยู่กับร่องกับรอย)
- ไม่มีการจัดทำวัตถุประสงค์และหลักปฏิบัติในการรีวิวที่ชัดเจนร่วมกัน จึงมักเกิดการรีวิวแบบ “การหาไปเรื่อยๆ”
- คอมเมนต์ไม่ชัดเจน ทำให้คนเขียนโค้ดกับคนรีวิวไม่เข้าใจกัน ประมาณว่าเกาไม่ถูกที่คัน ก็เกาไปเรื่อยๆ
Key Takeaways
- คอมเมนต์ต้องชัดเจนแจ่มแจ้ง ไม่กำกวม คนเขียนโค้ดต้องสามารถเข้าใจได้ว่าทำไปเพื่ออะไร ได้อะไร
- บางทีเราต้องการกรรมการผู้ทรงคุณวุฒิที่สามารถบอกได้ว่า “ทำแค่ไหนถึงจะเพียงพอ” เพื่อทำการตัดสินและจบการรีวิวไม่ให้ยืดเยื้อจนเกินไป
5. รีวิวกับผีสิ (Ghost Reviewer)
ผมอ่านอันนี้แล้วรู้สึกตลกนิดๆ เพราะมันเรียลมาก มันคืออาการของคนที่แบบ “ไม่มีอารมณ์จะรีวิวอะ” ซึ่งไม่ว่าคุณจะเป็นฝั่ง Reviewers หรือเป็น Author ก็แค่ไม่มีอารณ์จะรีวิวตอนนี้อ่ะ
ไม่ว่าจะด้วยเหตุผลอะไรก็ตาม บางคนอาจจะเหนื่อยเพราะรีวิวมาหลายครั้งหลายงานติดๆ กัน บางคนมีสิ่งที่สำคัญกว่าต้องทำ บางคนอาจจะรู้สึกว่าไม่พร้อม โค้ดที่เยอะเกินไปก็มีส่วนที่ทำให้เกิดความเบื่อหน่ายที่จะรีวิวได้เช่นกัน รวมไปถึงการมีประสบการณ์แย่ๆ กับการทำ Code Review มาก่อนที่อาจจะทำให้บางคนรู้สึกไม่อยากทำอีกต่อไป
โค้ดจะมี Value ก็ต่อเมื่ออยู่บน Production จงอย่าทำ Code Review ให้เสียเวลาไปโดยเปล่าประโยชน์
Key Takeaways
- โค้ดที่รีวิวควรมีปริมาณที่ไม่มากเกินไป ควรแบ่งจัดให้สามารถรีวิวได้ในหลักชั่วโมง เต็มที่ก็วันนึง นานไปจะเฉาเอา
- จัดให้มีเป้าหมายที่ชัดเจนในการรีวิวร่วมกัน อย่าสักแต่ว่า “หาทุกอย่างที่หาได้” เพราะสุดท้ายมันบั่นทอนแรงบันดาลใจ
- ผู้บริหารหรือหัวหน้าควรจัดแผนงานให้มีเวลาเพียงพอสำหรับการทำ Code Review ไม่ควรบีบ คั้น ปั่น เร่ง
จบละครับ บทความในสไตล์อ่านจบไว (หวังว่าจะ) ได้ประโยชน์ ถ้าพลิกอีกด้านถามว่า แล้ว Best Practices ในการทำ Code Review เป็นอย่างไร? ไว้บรรยากาศเป็นใจจะมาเล่าสู่กันฟังนะครับ ถ้าชอบก็ฝากกดไลค์ กดแชร์ สับตะไคร้ ตบมือ มินิฮาร์ท ได้หมด ถ้าสดชื่น
Happy Code Reviewing!
สำหรับชาวเทคคนไหนที่สนใจเรื่องราวดีๆแบบนี้ หรืออยากเรียนรู้เกี่ยวกับ Product ใหม่ๆ ของ KBTG สามารถติดตามรายละเอียดกันได้ที่เว็บไซต์ www.kbtg.tech
