> For the complete documentation index, see [llms.txt](https://www.saladpuk.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://www.saladpuk.com/basic/agile-methodology/code-review.md).

# Code Review

## 😢 ปัญหา

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

{% hint style="success" %}
**แนะนำให้อ่าน**\
บทความนี้เป็นส่วนหนึ่งของบทความ [👦 Agile Methodology](https://saladpuk.gitbook.io/learn/basic/agile-methodology) หากเพื่อนๆสนใจอยากศึกษาการทำ Agile แบบเต็มรูปแบบก็สามารถกดลิงค์สีฟ้าๆเพื่อเข้าไปดูได้เลยนะ
{% endhint %}

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

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

## 🤔 Code Review คือไร ?

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

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

![](/files/-Lusq3ZY23n2xxv1zWWi)

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

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

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

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

![https://www.indiamart.com](/files/-LtpUuDTatTlHwrsMZQF)

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

{% hint style="success" %}
**แนะนำให้อ่าน**\
เรื่องที่จะมาช่วยในการจัดการ Bad Code นั้นมีหลายเรื่องเลย ลองไล่อ่านได้จากบทความพวกนี้ได้เบย

* [👶 Clean Code](https://saladpuk.gitbook.io/learn/basic/clean-code)
* [👶 Code Smells](https://saladpuk.gitbook.io/learn/basic/code-smells)
* [👶 สิ่งที่คนเขียนโค้ดมักเข้าใจผิด](https://saladpuk.gitbook.io/learn/basic/mist)
* [👦 SOLID Design Principles](https://saladpuk.gitbook.io/learn/basic/solid)
* [👦 Test-Driven Development](https://saladpuk.gitbook.io/learn/software-testing/tdd101)
* [👦 Bottlenecks of Software](https://saladpuk.gitbook.io/learn/basic/bottlenecks)
* [🤴 Design Patterns](https://saladpuk.gitbook.io/learn/software-design/designpatterns)
  {% endhint %}

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

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

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

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

![https://www.forbes.com/sites/rajatbhageria](/files/-LnNb8L2MYbn8OGT6YGO)

### 🔥 เริ่มจาก Pull Request

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

![](/files/-Lsf-kpXfNZ2vAMpaVXo)

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

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

![http://geek-and-poke.com](/files/-LoQkGuU3T4owD47amcV)

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

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

![https://theanvilnewsletter.blogspot.com/2016/09/extending-right-fist-of-fellowship-from.html](/files/-LnFVbN54l8yDA0HpMhy)

### 🔥 Coding Standard

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

![https://docs.improbable.io/unity/alpha/contributions/unity-gdk-coding-standards](/files/-LqlDyibFGmvmOC-p94H)