✅ เป้าหมายของ Code Review
| เป้าหมาย | อธิบาย |
|---|---|
| 💡 ความถูกต้อง | ไม่มี bug หรือ logic ผิด |
| 🧼 ความสะอาด (Clean Code) | อ่านง่าย, สื่อความหมาย, ไม่ hardcode |
| ♻️ การนำกลับมาใช้ซ้ำ | ลด code duplication |
| 🔒 ความปลอดภัย | ป้องกัน SQL Injection, XSS |
| 📏 สอดคล้องกับ coding standard | ตาม style guide ทีม |
| 🧪 ทดสอบได้ง่าย | มี unit test / coverage ดี |
| 📄 มี doc หรือ comment เมื่อจำเป็น | ทำให้โค้ดเข้าใจในอนาคต |
👀 ขั้นตอนการ Review Code
1. อ่าน context ก่อน
- อ่านชื่อ branch, ชื่อ PR
- อ่าน description, ticket (JIRA, GitHub Issues)
2. ดูโครงสร้างโดยรวม
- เปลี่ยนเฉพาะ scope ที่ระบุไว้ไหม?
- โค้ดแยกชั้น, แยก logic ดีไหม?
3. ไล่ดูรายบรรทัด
- ตั้งชื่อดีไหม? →
processData()หรือvalidateInvoiceBeforeSubmit()? - ฟังก์ชันใหญ่เกินไปไหม? (> 50 บรรทัด ควร refactor)
- ทำ side-effect หรือไม่ (เปลี่ยน state global)?
- ใช้ magic number หรือไม่?
4. พิจารณาเรื่อง Test
- มี test ครอบคลุม logic ใหม่หรือไม่?
- กรณีผิดพลาดมี test หรือไม่?
- ใช้ mock/stub อย่างเหมาะสม?
5. ดูผลกระทบจากโค้ดนี้
- touch module อื่นไหม?
- เสี่ยงเกิด regression ไหม?
📝 ตัวอย่างข้อสังเกตที่ควรจดไว้
| ประเด็น | ตัวอย่าง |
|---|---|
| ❌ ชื่อไม่สื่อ | temp1 → approvedInvoiceCount |
| ❌ Function ยาวเกิน | calculateTaxAndCheckStatusAndSendEmail() |
| ✅ แยก logic ดีมาก | checkPermission() / calculateDiscount() |
❌ ใช้ if ซ้อนกันลึก | → แยกเป็น function หรือใช้ guard clause |
| ❌ มี query ฝังใน controller | → ควรย้ายไป service/repository |
✍️ Checklist Template สำหรับ Code Review
[ ] โค้ดอ่านง่าย ตั้งชื่อดี
[ ] แยก logic ดี ไม่จับรวมหลายอย่าง
[ ] ไม่มี hardcode / magic number
[ ] มี test ครอบคลุม + pass
[ ] ไม่ break compatibility / test เดิม
[ ] ปลอดภัย (no SQL injection, null-safe)
[ ] ใช้ resource/database อย่างเหมาะสม
[ ] ตรงตาม style guide ทีม
[ ] ไม่มี duplicate code

ใส่ความเห็น