Code Review
🤔 อยากให้ทีมเก่งขึ้น แต่ไม่มีเวลาสอนทำไงดี ?
การทำซอฟต์แวร์โปรเจคนั้นจะเน้นไปที่ การทำงานเป็นทีม ซึ่งโดยปรกติคนในทีมแต่ละคนนั้นจะไม่เหมือนกัน ความเก่งไม่เท่ากัน นิสัยในการเขียนโค้ดไม่เหมือนกัน บลาๆ ซึ่งเจ้าเรื่องเหล่านี้แหละมันจะเป็นปัญหาในอนาคต เช่น งานนี้ต้องให้พี่คนนี้เขียนเท่ากัน เพราะพี่เขาเขียนเป็นคนเดียว หรือ เวลาที่เราต้องไปแก้โค้ดคนอื่นเราก็จะรู้มันเป็นสิ่งแปลกปลอม แล้วเราจะแก้ปัญหาโลกแตกนี้ยังไงดี ?
แนะนำให้อ่าน
บทความนี้เป็นส่วนหนึ่งของบทความ 👦 Agile Methodology หากเพื่อนๆสนใจอยากศึกษาการทำ Agile แบบเต็มรูปแบบก็สามารถกดลิงค์สีฟ้าๆเพื่อเข้าไปดูได้เลยนะ
เราก็ต้องหาซักช่วงเวลานึงในแต่ละรอบการส่งงาน มาทำสิ่งที่เรียกว่า 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 นั้นมีหลายเรื่องเลย ลองไล่อ่านได้จากบทความพวกนี้ได้เบย
มีแนะนำหลายเรื่องตามนี้เลยละกัน
เวลาที่หัดรีวิวอย่าเอาโค้ดมาเยอะๆแล้วไล่รีวิวมันทั้งหมด ไม่งั้นเราจะทำรีวิวได้แค่ 1-2 ครั้งแล้วทุกคนจะบอกว่าเหนื่อย/เสียเวลา และไม่มีใครอยากทำอีก รวมถึงคนที่จัดทำด้วย ดังนั้นให้เริ่มจากแค่โค้ดบางส่วนก่อนไม่เกิน 30 นาที - 1 ชั่วโมงก็ยังได้
https://www.forbes.com/sites/rajatbhageria
โดยปรกติตอนที่เราเริ่ม 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 เพื่อเป็นแนวทางในการเขียนโค้ดของทุกคนในทีม ซึ่งมันจะทำให้เราทำงานกับโค้ดของคนอื่นได้โดยไม่รู้สึกว่ามันเป็นของน่าขยะแขยงอีกต่อไปนั่นเอง
https://docs.improbable.io/unity/alpha/contributions/unity-gdk-coding-standards
Last modified 3yr ago