Code Review

🤔 อยากให้ทีมเก่งขึ้น แต่ไม่มีเวลาสอนทำไงดี ?

😢 ปัญหา

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

แนะนำให้อ่าน บทความนี้เป็นส่วนหนึ่งของบทความ 👦 Agile Methodology หากเพื่อนๆสนใจอยากศึกษาการทำ Agile แบบเต็มรูปแบบก็สามารถกดลิงค์สีฟ้าๆเพื่อเข้าไปดูได้เลยนะ

😄 วิธีแก้ปัญหา

เราก็ต้องหาซักช่วงเวลานึงในแต่ละรอบการส่งงาน มาทำสิ่งที่เรียกว่า Code Review กันนั่นเอง ซึ่งเจ้า code review คืออะไร เดี๋ยวเรามาลองทำความเข้าใจกันเลยละกัน

🤔 Code Review คือไร ?

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

ซึ่งการทำ Code Review แต่ละครั้งมันจะมีวัตถุประสงค์ของมันเองแล้วแต่หน้างานว่า เราอยากทำให้ทีมได้พัฒนาในเรื่องไหน

🤔 ต้องทำไรบ้าง ?

การทำ Code Review มีหลายแบบม๊วก แล้วแต่บริษัทว่าเขาทำกันแบบไหน ดังนั้นเรื่องนี้ไม่มีกฏตายตัว แต่สิ่งที่ต้องมีในการทำ Code Review มี 3 อย่างคือ

  1. มีโค้ดที่จะเอามารีวิว - ปรกติจะใช้โค้ดที่ทีมเขียนในงานจริงๆมาเอารีวิว เพราะมันเป็นของที่เกิดขึ้นกับทีมจริงๆ มันมีปัญหาจริงๆ ซึ่งมันจะสะท้อนถึงทีมเราได้ดีที่สุด (ถ้าไม่ได้จะเอาโค้ดตัวอย่างที่อื่นมาก็ได้ แต่ส่วนใหญ่ทีมจะไม่จำ ต้องเล่นเองเจ็บเอง)

  2. มีคนมานั่งฟัง - โดยปรกติก็คือเจ้าคนที่เขียนโค้ดเองนั่นแหละ และเอาคนในทีมทั้งหมดมานั่งฟังด้วยได้จะดีมาก เพราะมันจะเป็นการสอนทีเดียวได้ทุกคน

  3. มีการให้คำแนะนำ - โดยการนั่งดูโค้ดที่เอามารีวิว เพื่อคุยกันว่าโค้ดแบบนี้ มันดี หรือ มันต้องปรับแก้ตรงไหน เพื่อช่วยสอนให้ทีมได้เรียนรู้ข้อดีข้อเสียในแต่ละแบบ

จากที่ว่าการทำ Code Review ถ้าจะให้มีประสิทธิภาพสูงสุดคือ การได้นั่งคุยกัน ไม่ใช่การส่ง code มาแล้วเราตีกลับให้เขาไปแก้ เพราะ เราอาจจะต้องอธิบายว่ามันเป็น Good Code หรือ Bad Code ยังไง และรวมถึงในบางทีคนในทีมก็อาจจะร่วมเสนอแนะการแก้ปัญหาเข้ามาร่วมด้วยก็ได้

https://www.indiamart.com

ซึ่งโดยหลักเราก็จะแนะนำแนวทางในการออกแบบ การใช้ Code Smell การใช้ Design Patterns ที่เหมาะสมกับงาน บลาๆ ซึ่งอย่างที่บอกว่ามันแล้วแต่ไม่มีกฎอะไรตายตัวเลย

แนะนำให้อ่าน เรื่องที่จะมาช่วยในการจัดการ Bad Code นั้นมีหลายเรื่องเลย ลองไล่อ่านได้จากบทความพวกนี้ได้เบย

🤔 ก่อนทำมีอะไรแนะนำไหม ?

มีแนะนำหลายเรื่องตามนี้เลยละกัน

🔥 อย่าทำ Review เยอะเกิน

เวลาที่หัดรีวิวอย่าเอาโค้ดมาเยอะๆแล้วไล่รีวิวมันทั้งหมด ไม่งั้นเราจะทำรีวิวได้แค่ 1-2 ครั้งแล้วทุกคนจะบอกว่าเหนื่อย/เสียเวลา และไม่มีใครอยากทำอีก รวมถึงคนที่จัดทำด้วย ดังนั้นให้เริ่มจากแค่โค้ดบางส่วนก่อนไม่เกิน 30 นาที - 1 ชั่วโมงก็ยังได้

https://www.forbes.com/sites/rajatbhageria

🔥 เริ่มจาก Pull Request

โดยปรกติตอนที่เราเริ่ม Review เราอาจจะเริ่มจากการทำ Pull Request เข้ามาก็ได้นะ เพราะมันจะได้ focus เป็นเรื่องๆไป และโค้ดน่าจะไม่เยอะจนเกินไป

🔥 อย่าพูดแต่เรื่องแย่ๆ

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

http://geek-and-poke.com

🔥 รีวิวงานไม่ใช่รีวิวคน

ในการรีวิวเราต้องแยกคนกับโค้ดออกจากกัน เพราะ ของที่เราจะมาคุยกันคือตัวโค้ด ไม่เกี่ยวกับคนเขียน เพราะโค้ดกับคนเขียนโค้ดเป็นคนละอย่างกัน ไม่อย่างนั้นได้มีตีกันแน่ๆ ดังนั้นในแต่ละองค์กรควรจะต้องมีวัฒนธรรมที่สามารถพูดคุยกันโดยไม่สนใจหัวโขน + ยอมรับข้อผิดพลาดที่เกิดขึ้น อีกทั้งยังพร้อมที่จะแก้ไขของเหล่านั่นได้ เพราะบ่อยครั้ง Junior ก็มีมุมมองที่ดีกว่า Senior ได้ และมันเป็นการช่วยส่งเสริมให้แต่ละคนได้แสดงความสามารถ + เรียนรู้ได้เร็วขึ้นอีกด้วย

https://theanvilnewsletter.blogspot.com/2016/09/extending-right-fist-of-fellowship-from.html

🔥 Coding Standard

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

https://docs.improbable.io/unity/alpha/contributions/unity-gdk-coding-standards