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

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

·

การเขียนโค้ดที่ดี ไม่ได้แค่ให้คนอื่นอ่านเข้าใจ — แต่ต้อง “ร่วมพัฒนาได้โดยไม่ต้องถาม” นี่คือแนวทางมาตรฐานที่ 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 ได้อย่างมีประสิทธิภาพ

TypeDescriptionExample Commit Message
featAdd a new featurefeat: add Line login feature for user auth
fixFix a bugfix: resolve token not refreshing after login
docsDocumentation changes onlydocs: update README with login instructions
styleCode style changes (no logic changes)style: reformat code to match ESLint rules
refactorCode restructure without changing behaviorrefactor: move logic from controller to service
testAdd or update teststest: add unit tests for user service
choreMaintenance 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!


🧾 สรุป

หมวดกฎสำคัญ
🌐 CommonPrettier + ESLint, commit เป็น Conventional, limit 300 lines
🧩 Frontendใช้ TS, ชื่อ component ชัด, หลีกเลี่ยง inline-style
⚙️ Backendแยก layer ชัดเจน, controller บาง, ใช้ NestJS อย่างมีโครงสร้าง
🗃️ Databasesnake_case, มี created_at, ใช้ index และ constraint

🎥 รับชมวิดีโอประกอบได้ที่นี่: Coding Guidelines ที่ Dev Team ทุกทีมควรมี!


💡 แนวทางเหล่านี้ไม่ใช่กฎตายตัว แต่เป็นแนวทางเริ่มต้นที่ทำให้ทีมเดินไปในทางเดียวกันได้เร็วขึ้น ปรับให้เหมาะกับ context ของทีมคุณได้เลยครับ!


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