# 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)


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://www.saladpuk.com/basic/agile-methodology/code-review.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.