การเขียนโค้ดที่ดี ไม่ได้แค่ให้คนอื่นอ่านเข้าใจ — แต่ต้อง “ร่วมพัฒนาได้โดยไม่ต้องถาม” นี่คือแนวทางมาตรฐานที่ dev team ควรใช้เพื่อให้โค้ดสะอาด อ่านง่าย และร่วมมือกันได้อย่างมีประสิทธิภาพ
✅ กฎกลางที่ใช้ร่วมกัน (Global Rules)
- ใช้ Prettier + ESLint เพื่อจัดรูปแบบโค้ดอัตโนมัติ
- เขียน Commit ด้วย Conventional Commits
- ทุก PR ต้องมีการ Review ก่อน Merge
- อธิบาย function/class ที่สำคัญด้วย JSDoc หรือ Comment
- แยก code ตามหน้าที่ (Single Responsibility Principle)
🧩 Frontend Standards
📛 Naming
camelCase
→ ตัวแปร, ฟังก์ชันPascalCase
→ Componentkebab-case
→ ชื่อไฟล์- ชื่อ component ควรสื่อความหมาย เช่น
UserCard
,LoginForm
📁 Folder Structure (React/Next.js)
/components/Button/index.tsx
/pages/index.tsx
/utils/formatDate.ts
/types/user.ts
💡 Best Practices
- ใช้ TypeScript เท่านั้น
- Component หรือ Page ควรมีขนาด ไม่เกิน 300 บรรทัด
- 📏 300 บรรทัด: ขนาดเหมาะสม อ่านง่าย ดูแลง่าย
- ⚠️ 500 บรรทัด: เริ่มใหญ่เกินไป ควรพิจารณาแยก logic ออก
- 🚨 1000+ บรรทัด: ควบคุมยาก ทำให้ debug, test และ review ลำบากมาก
- หลีกเลี่ยง inline-style → ใช้ Tailwind CSS หรือ CSS Module
- Logic ที่ซ้ำกันควรย้ายไป
/utils
- Component ที่ใช้บ่อยควรเขียน Storybook หรือ Unit Test
⚙️ Backend Standards
📛 Naming
camelCase
→ ตัวแปร, ฟังก์ชันPascalCase
→ Classsnake_case
→ Database field, REST Path (/get_user_profile
)
📁 Folder Structure (NestJS)
/user/
user.controller.ts
user.service.ts
user.module.ts
dto/create-user.dto.ts
💡 Best Practices
- ใช้ async/await เท่านั้น ห้าม
.then()
- หลีกเลี่ยง business logic ใน controller
- Config ควรอยู่ใน ENV เท่านั้น
- ต้องมี Logger และ Unit Test ทุก endpoint
- ใช้ Interceptor เพื่อจัดการ logic กลาง เช่น:
- Logging request/response
- แปลง response format ให้ standardized
- ตรวจจับ error หรือ response time
🗃️ Database Standards
📛 Naming
- Table: plural + snake_case เช่น
users
,product_reviews
- Field: snake_case เช่น
created_at
,user_id
💡 Best Practices
- ใช้
id
เป็น primary key เสมอ (UUID หรือ auto-increment) - เพิ่ม
created_at
,updated_at
ทุกตาราง - ใส่ Foreign Key และ Constraint ให้ครบ
- ใช้ migration tools เช่น Prisma, Diesel
- เพิ่ม Index กับ field ที่ใช้ query บ่อย
🧪 Dev Tools & Workflow
- ใช้ Git Flow หรือ Trunk-based workflow
- ใช้ CI ตรวจ Lint/Build/Test ทุก PR
- เขียน README พร้อมตัวอย่าง
.env.example
- มีเอกสาร API และ DB Schema บน Notion หรือ Swagger
📝 ตัวอย่างการเขียน Commit ด้วย Conventional Commits
เพื่อให้ประวัติการเปลี่ยนแปลง (Git History) ของโปรเจคอ่านง่าย และสามารถเชื่อมต่อกับระบบ CI/CD, Automation, Release ได้อย่างมีประสิทธิภาพ
Type | Description | Example Commit Message |
---|---|---|
feat | Add a new feature | feat: add Line login feature for user auth |
fix | Fix a bug | fix: resolve token not refreshing after login |
docs | Documentation changes only | docs: update README with login instructions |
style | Code style changes (no logic changes) | style: reformat code to match ESLint rules |
refactor | Code restructure without changing behavior | refactor: move logic from controller to service |
test | Add or update tests | test: add unit tests for user service |
chore | Maintenance tasks (build, deps, etc.) | chore: update Prisma to latest version |
Pro Tip: Use VS Code + Conventional Commits Extension to make writing commit messages easier and standardized!
🧾 สรุป
หมวด | กฎสำคัญ |
---|---|
🌐 Common | Prettier + ESLint, commit เป็น Conventional, limit 300 lines |
🧩 Frontend | ใช้ TS, ชื่อ component ชัด, หลีกเลี่ยง inline-style |
⚙️ Backend | แยก layer ชัดเจน, controller บาง, ใช้ NestJS อย่างมีโครงสร้าง |
🗃️ Database | snake_case, มี created_at , ใช้ index และ constraint |
🎥 รับชมวิดีโอประกอบได้ที่นี่: Coding Guidelines ที่ Dev Team ทุกทีมควรมี!
💡 แนวทางเหล่านี้ไม่ใช่กฎตายตัว แต่เป็นแนวทางเริ่มต้นที่ทำให้ทีมเดินไปในทางเดียวกันได้เร็วขึ้น ปรับให้เหมาะกับ context ของทีมคุณได้เลยครับ!
✍️ ผมจะมาอัปเดตบทความนี้ให้เรื่อย ๆ นะครับ เขียนตอนที่ยุ่ง ๆ กลั่นออกมาได้แค่นี้ก่อน ถ้าทีมคุณมีแนวทางน่าสนใจเพิ่มเติมก็คอมเมนต์หรือแชร์กันได้เลยครับ 🙂