Coding Guidelines ที่ Dev Team ทุกทีมควรมี!

May 12, 2025 · boychawin

การเขียนโค้ดที่ดี ไม่ได้แค่ให้คนอื่นอ่านเข้าใจ — แต่ต้อง “ร่วมพัฒนาได้โดยไม่ต้องถาม” นี่คือแนวทางมาตรฐานที่ 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 → Component
kebab-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 → Class
snake_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 ของทีมคุณได้เลยครับ!

✍️ ผมจะมาอัปเดตบทความนี้ให้เรื่อย ๆ นะครับ เขียนตอนที่ยุ่ง ๆ กลั่นออกมาได้แค่นี้ก่อน ถ้าทีมคุณมีแนวทางน่าสนใจเพิ่มเติมก็คอมเมนต์หรือแชร์กันได้เลยครับ 🙂