วิธี Audit โครงสร้าง Next.js Project — ลบ Dead Code, จัดไฟล์, และทำความสะอาด .gitignore ใน 47 นาที

เวลาอ่าน: 12 นาที | อัปเดตล่าสุด: 27 กุมภาพันธ์ 2026

23 ไฟล์อยู่ผิดที่ 8 ไฟล์ dead code ที่ไม่มีใครเรียกใช้ .gitignore ที่ขาด 6 patterns — ผม audit โปรเจกต์ Next.js 14 ที่มี 149 pages แล้วจัดการทุกอย่างใน 47 นาที พร้อม prompt และ step-by-step ทำตามได้เลย

ทำไม Next.js Project ถึง "รก" ได้ง่ายขนาดนี้?

Next.js App Router project ที่โตเร็วจะสะสม technical debt ในรูปแบบ "ไฟล์ผิดที่" เฉลี่ย 15-30 ไฟล์ภายใน 6 เดือนแรก — โดยเฉพาะ solo developer ที่ทำทุกอย่างคนเดียว ตั้งแต่ design, code, deploy จนลืม housekeeping. ผมเจอปัญหาเดียวกันนี้กับ Idea2Logic ที่มี 149 pages และ source code กว่า 200+ ไฟล์.

ปัญหามี 3 กลุ่มหลัก:

กลุ่ม 1 — ไฟล์ plan/doc กระจายเต็ม root
ไฟล์อย่าง ARCHITECTURE_DIAGRAM.md, PRODUCTION_PLAN.md, PROJECT_PLAN.md.bak กองอยู่ข้างๆ package.json. มองแล้วไม่รู้ว่าอันไหนสำคัญ อันไหนทิ้งได้.

กลุ่ม 2 — Dead code ที่ "ตั้งใจทำ" แต่ไม่เคยสำเร็จ
LINE Login integration ที่ return 501 every time. Component ที่สร้างไว้แต่ไม่มี page ไหนใช้. ผม track ดูแล้ว — มันกิน maintainability โดยไม่มีประโยชน์อะไรเลย.

กลุ่ม 3 — .gitignore ที่ล้าสมัย
ไฟล์ .bak, *_TEMP*, demo HTML ที่ควร ignore แต่ไม่มี pattern รองรับ.

พูดตรงๆ — โปรเจกต์ Next.js ส่วนใหญ่ที่ผมเห็นก็เป็นแบบนี้. ไม่ใช่เรื่องแปลก แต่ถ้าปล่อยไว้มันจะแย่ลงเรื่อยๆ.

วิธี Audit โครงสร้าง Next.js Project ทำยังไง — 5 ขั้นตอน?

การ audit โครงสร้าง Next.js project ทำได้ใน 5 ขั้นตอนหลัก: (1) scan root directory หาไฟล์ผิดที่ (2) ตรวจ dead code ด้วย grep (3) ตรวจ .gitignore gaps (4) ย้าย/ลบไฟล์ (5) build verify. ผม audit Idea2Logic ที่มี 149 pages เสร็จใน 47 นาที ลบ dead code 8 ไฟล์ ย้ายไฟล์ 27 ชิ้น.

Step 1: Scan Root Directory (5 นาที)

เปิด terminal แล้วดูว่า root มีอะไรบ้างที่ไม่ควรอยู่:

ls -1 *.md *.txt *.bak 2>/dev/null | head -20

ของผมเจอ 10 ไฟล์ .md ที่ไม่ใช่ README หรือ CLAUDE.md — ทั้ง ARCHITECTURE_DIAGRAM, PRODUCTION_PLAN, COMPLIANCE_CHECKLIST, IMPROVEMENT_PLAN ฯลฯ

กฎง่ายๆ: root directory ควรมีแค่ config files (package.json, tsconfig.json, next.config.mjs) กับ README. อย่างอื่นย้ายไป docs/.

Step 2: ตรวจ Dead Code (10 นาที)

ขั้นตอนนี้สำคัญที่สุด. Dead code คือ code ที่มีอยู่แต่ไม่ถูกเรียกใช้ — มันไม่ทำร้ายอะไรตอน runtime แต่มันทำร้าย developer ที่ต้องอ่านมัน.

# หา component ที่ไม่มี page import
for f in src/components/**/*.tsx; do
  name=$(basename "$f" .tsx)
  count=$(grep -r "$name" src/app/ --include="*.tsx" -l | wc -l)
  if [ "$count" -eq 0 ]; then
    echo "ORPHAN: $f"
  fi
done

ของผมเจอ SchemaScript.tsx — component ที่สร้างไว้สำหรับ structured data แต่ไม่มี page ไหน import เลย.

อีกเคส — LINE Login integration. ผมเขียน 4 ไฟล์เต็มๆ: src/lib/line/client.ts, src/components/account/LineConnect.tsx, src/app/api/auth/line-connect/route.ts, src/app/api/auth/line-connect/callback/route.ts

ทุกไฟล์ return 501. Supabase ไม่ support LINE Login. ผมรู้มาตั้งนานแต่ไม่เคยลบ.

Step 3: ตรวจ .gitignore (5 นาที)

# ดูว่ามี tracked files ที่ไม่ควร track ไหม
git ls-files | grep -E "\.(bak|tmp)$"

# ตรวจว่า .gitignore ครอบคลุมพอไหม
cat .gitignore | wc -l

ของผมพบว่าไม่มี pattern สำหรับ *.bak, *_TEMP*, demo HTML files. ไฟล์ PROJECT_PLAN.md.bak นั่งอยู่ใน git history มาตลอด.

Step 4: ย้าย + ลบ (15 นาที)

ขั้นนี้ต้องระวัง — ไฟล์ที่ git track อยู่ต้องใช้ git mv ไม่ใช่ mv ธรรมดา:

# ไฟล์ที่ tracked → git mv
git mv COMPLIANCE_CHECKLIST.md docs/
git mv IMPROVEMENT_PLAN.md docs/

# ไฟล์ที่ untracked → mv ธรรมดา
mv ARCHITECTURE_DIAGRAM.md docs/
mv PRODUCTION_PLAN.md docs/

# Dead code → ลบเลย
rm src/components/shared/SchemaScript.tsx
rm -rf src/lib/line/
rm src/components/account/LineConnect.tsx
rm -rf src/app/api/auth/line-connect/

ข้อควรระวัง: ก่อนลบ dead code ต้อง grep ให้แน่ใจก่อนว่าไม่มีไฟล์อื่น import มัน:

grep -r "SchemaScript" src/ --include="*.tsx" --include="*.ts"
grep -r "LineConnect" src/ --include="*.tsx" --include="*.ts"

Step 5: Build Verify (12 นาที)

rm -rf .next && npm run build

ถ้า build ผ่าน 0 errors = เสร็จ. ถ้ามี error = มี import ที่ลืมแก้.

ของผม build ผ่านรอบแรกเลย — 149 pages, 0 errors, 0 warnings ที่เกี่ยวกับ dead code.

Manual Audit vs AI-Assisted Audit ต่างกันยังไง?

ทั้ง manual audit และ AI-assisted audit ทำ project structure cleanup ได้ แต่ AI-assisted เร็วกว่า 2-3 เท่า เพราะ AI scan โครงสร้าง classify ไฟล์ และ generate cleanup commands ได้ภายในไม่กี่วินาที. ผมใช้ Claude ช่วย audit Idea2Logic ลดเวลาจาก ~2 ชั่วโมง (ถ้าทำเอง) เหลือ 47 นาที.

Prompt อะไรที่ใช้ Audit Project ได้จริง?

prompt ที่ดีสำหรับ audit project structure ต้องให้ AI role ที่ชัด กำหนด scope ว่าตรวจอะไร และบอก format output ที่ actionable — ไม่ใช่แค่ "ตรวจ project ให้หน่อย" ที่ผลลัพธ์กว้างจนใช้ไม่ได้. ผมใช้ 2 prompts นี้กับ Claude แล้วได้ผลดี.

Prompt 1: Project Structure Audit

ใช้กับ: Claude / ChatGPT | ระดับ: กลาง

คุณเป็น Senior Software Architect ที่เชี่ยวชาญ {{framework}} project structure

Audit โครงสร้างไฟล์ของโปรเจกต์นี้:
- Framework: {{framework}}
- Root directory มีไฟล์: {{root_files}}
- Source structure: {{src_structure}}

ตรวจ 4 เรื่อง:
1. ไฟล์ที่อยู่ผิด directory (ควรย้ายไปไหน?)
2. Dead code / orphan components (ไฟล์ที่ไม่มีใครเรียกใช้)
3. .gitignore ที่ขาด patterns อะไร
4. ไฟล์ temp/backup ที่ควรลบ

ตอบเป็นตาราง:
| ไฟล์ | ปัญหา | Action | คำสั่ง |
ทุกแถวต้องมี shell command ที่รันได้เลย

ห้ามตอบว่า "ขึ้นอยู่กับ" — ฟันธงว่าควรทำอะไร

Variables:

• {{framework}} = Next.js 14 App Router / Nuxt 3 / SvelteKit / อื่นๆ
• {{root_files}} = ผลจาก ls -1 ใน root directory
• {{src_structure}} = ผลจาก find src -type f | head -50

ทำไม prompt นี้ได้ผล: กำหนด role (architect) + output format (ตาราง + commands) + constraint (ห้าม hedge) ชัดเจน. AI ไม่มีทางตอบกว้างๆ เพราะบังคับให้มี command ทุกแถว.

Prompt 2: Dead Code Scanner

ใช้กับ: Claude (แนะนำ — เข้าใจ code context ดีกว่า) | ระดับ: กลาง-สูง

คุณเป็น Code Quality Lead ที่เชี่ยวชาญ {{framework}}

วิเคราะห์ code ต่อไปนี้แล้วหา dead code:

{{code_snippet}}

Dead code หมายถึง:
1. Component ที่ไม่มี page route import
2. Function ที่ไม่ถูกเรียกใช้จาก file อื่น
3. API route ที่ return error code เสมอ (501, 503)
4. Import statement ที่ import แล้วไม่ใช้

ตอบเป็น:
| ไฟล์/Function | ประเภท Dead Code | เหตุผล | ลบได้เลย? | ก่อนลบต้องทำอะไร? |

ถ้ามี dependency chain (A import B, B import C) → บอกลำดับที่ต้องลบ

Variables:

• {{framework}} = Next.js 14 App Router
• {{code_snippet}} = วาง code ที่สงสัยว่าเป็น dead code

ทำไม prompt นี้ได้ผล: กำหนดนิยาม "dead code" ชัดเจน 4 ข้อ → AI ไม่มั่ว. บังคับให้ตอบ "ก่อนลบต้องทำอะไร" → ป้องกัน build error.

โปรเจกต์ Next.js มีกี่ประเภทไฟล์ที่มักอยู่ผิดที่?

ไฟล์ที่อยู่ผิดที่ใน Next.js project แบ่งได้ 5 ประเภท: (1) documentation ที่กองใน root (2) temp/backup files (3) demo/test assets ใน public/ (4) dead code ที่ถูก commit (5) draft content ที่ไม่เกี่ยวกับ code. จากการ audit Idea2Logic ผมเจอทั้ง 5 ประเภท รวม 35 ไฟล์.

รวม 35 ไฟล์ที่ต้องจัดการ — 8 ไฟล์ลบทิ้ง, 27 ไฟล์ย้ายที่.

บอกตรงๆ ว่าตอนเห็นตัวเลขนี้ผมตกใจ. ผมคิดว่าแค่ 5-6 ไฟล์ ปรากฏว่า 35.

.gitignore ที่ดีสำหรับ Next.js ต้องมีอะไรบ้าง?

.gitignore ที่ดีสำหรับ Next.js project ต้องครอบคลุม 4 กลุ่ม: (1) build artifacts (.next/, out/) (2) dependencies (node_modules/) (3) environment files (.env*) (4) project-specific patterns (backup, temp, demo files). Next.js default .gitignore มักขาดกลุ่มที่ 4 ซึ่งทำให้ไฟล์ขยะหลุดเข้า git.

patterns ที่ผมเพิ่มเข้าไป:

# project artifacts
*.bak
*_TEMP*
*_temp*
docs/blog-drafts/
docs/archive/
public/demo-*.html

6 patterns เท่านี้กัน 90% ของไฟล์ขยะที่จะหลุดเข้ามาในอนาคต.

Dead Code แบบไหนที่อันตรายที่สุด?

dead code ที่อันตรายที่สุดคือ "stub code ที่เกือบจะทำงาน" — code ที่มี logic จริงแต่ return error เสมอ เพราะ developer คนต่อไป (หรือตัวเองในอนาคต) จะเสียเวลาพยายามทำให้มัน work แทนที่จะเขียนใหม่. LINE Login integration ของผมเป็นตัวอย่างที่ชัดมาก — 4 ไฟล์ มี logic ครบ แต่ return 501 ทุกครั้ง.

ผมแบ่ง dead code เป็น 3 ระดับความอันตราย:

ระดับ 1 — Harmless (ลบได้เลย):

• Orphan component ที่ไม่มี page import
• Unused utility function
• ตัวอย่าง: SchemaScript.tsx ของผม

ระดับ 2 — Misleading (ต้องลบ + แก้ reference):

• Component ที่ถูก import แต่ไม่ render (commented out)
• API route ที่มีอยู่แต่ไม่ถูกเรียกจาก frontend
• ตัวอย่าง: LineConnect.tsx ที่ถูก import ใน account page

ระดับ 3 — Dangerous (ต้องลบ + cleanup ทุกที่):

• Stub code ที่ return error — developer จะเสียเวลาพยายาม fix
• Feature flag ที่ตั้งไว้แต่ไม่มีทาง enable
• ตัวอย่าง: LINE OAuth flow ที่ Supabase ไม่ support

ผมเสียเวลา 2 ชั่วโมงไปกับ LINE Login ก่อนจะรู้ว่า Supabase ไม่ support. ถ้ามีคน audit ก่อนหน้านี้แล้วลบทิ้ง ผมจะประหยัดเวลาได้ 2 ชั่วโมง 100%.

ผลลัพธ์จากการ Audit — ก่อน vs หลัง เป็นยังไง?

ก่อน audit — root directory มี 13 ไฟล์ .md + 1 folder Blog/ + 1 folder PHASE_REPORTS/ ที่ไม่เกี่ยวกับ code. หลัง audit — root เหลือแค่ 3 ไฟล์ (README.md, CLAUDE.md, PROJECT_PLAN.md) สะอาดขึ้น 77%. Dead code ลดจาก 8 ไฟล์เป็น 0 และ build ผ่าน 0 errors.

ก่อน Audit:

root/
├── ARCHITECTURE_DIAGRAM.md    ← ผิดที่
├── Blog/                       ← ผิดที่ (7 files)
├── COMPLIANCE_CHECKLIST.md     ← ผิดที่
├── IMPROVEMENT_PLAN.md         ← ผิดที่
├── PHASE_REPORTS/              ← ผิดที่ (13 files)
├── PRODUCTION_PLAN.md          ← ผิดที่
├── PROJECT_PLAN.md.bak         ← ลบทิ้ง
├── PROJECT_PLAN_TEMP.txt       ← ลบทิ้ง
├── public/demo-*.html          ← ลบทิ้ง
├── src/lib/line/               ← dead code (2 files)
├── src/components/.../LineConnect.tsx  ← dead code
├── src/components/.../SchemaScript.tsx ← dead code
├── src/app/api/auth/line-connect/     ← dead code (2 files)
└── ...configs (ถูกที่แล้ว)

หลัง Audit:

root/
├── CLAUDE.md          ✅
├── README.md          ✅
├── PROJECT_PLAN.md    ✅
├── docs/
│   ├── ARCHITECTURE_DIAGRAM.md
│   ├── COMPLIANCE_CHECKLIST.md
│   ├── IMPROVEMENT_PLAN.md
│   ├── PRODUCTION_PLAN.md
│   ├── blog-drafts/   (7 files)
│   ├── phase-reports/  (13 files)
│   └── archive/
└── ...configs + src (ไม่มี dead code)

ถ้าทำ Audit ประจำควรทำบ่อยแค่ไหน?

ทำ project structure audit ทุก 2-4 สัปดาห์ หรือก่อน major release — อย่าปล่อยให้เกิน 90 วัน. จากประสบการณ์ของผมกับ Idea2Logic ที่ commit เฉลี่ยวันละ 3-5 commits, ไฟล์เริ่ม "รก" ได้ภายใน 2 สัปดาห์ถ้าไม่ใส่ใจ.

ผมตั้ง rule ส่วนตัว 3 ข้อ:

1. ก่อน deploy production — audit ทุกครั้ง. ไม่เคยข้าม.
2. ทุก 2 สัปดาห์ — รัน audit script ตรวจ orphan files
3. หลัง feature ใหญ่เสร็จ — ลบ experiment code ที่ไม่ได้ใช้

คำถามที่พบบ่อย (FAQ)

Q: ลบ dead code แล้ว build พังทำยังไง?

A: ถ้า build error หลังลบ dead code — ดู error message ว่าไฟล์ไหน import module ที่ลบไป → ไปแก้ import ในไฟล์นั้น. ก่อนลบ dead code ทุกครั้งต้อง grep -r "ชื่อที่จะลบ" src/ ก่อนเสมอ เพื่อหา reference ทั้งหมด.

Q: ไฟล์ใน root directory อันไหนควรเก็บอันไหนควรย้าย?

A: เก็บใน root: config files (package.json, tsconfig.json, next.config.mjs, .eslintrc), README.md, CLAUDE.md (ถ้าใช้ AI assistant), LICENSE. ย้ายไป docs/: documentation อื่นทั้งหมด (plan, architecture, checklist, report). ลบทิ้ง: *.bak, *_TEMP*, ไฟล์ demo ที่ไม่ใช่ part ของ app.

Q: git mv กับ mv ต่างกันยังไง เมื่อไหร่ใช้อันไหน?

A: git mv ใช้กับไฟล์ที่ git track อยู่แล้ว — git จะรู้ว่าเป็น rename/move ไม่ใช่ delete + create ใหม่ ทำให้ history ยังอยู่. mv ธรรมดาใช้กับไฟล์ที่ไม่ได้ track (untracked files).

Q: ทำ audit ด้วย AI ปลอดภัยไหม ไม่กลัว AI ลบไฟล์สำคัญ?

A: ปลอดภัย ถ้าใช้ถูกวิธี — ให้ AI "วิเคราะห์" และ "แนะนำ" เท่านั้น ไม่ให้ AI รัน command เอง. Review ทุก command ที่ AI generate ก่อนรัน. ถ้าไม่แน่ใจ → อย่าลบ ย้ายไป archive/ แทน.

Q: Next.js project ขนาดเท่าไหร่ถึงควรทำ audit?

A: ทุกขนาด. แต่ยิ่งโปรเจกต์ใหญ่ยิ่งได้ประโยชน์มาก — project ที่มี 50+ pages จะมี dead code เฉลี่ย 5-10% ของ codebase. Idea2Logic ที่ 149 pages เจอ dead code 8 ไฟล์ = ~3% ซึ่งถือว่าน้อยเพราะผมทำคนเดียว.

Nat — Founder, Idea2Logic
Developer ที่ใช้ AI + Next.js + Supabase สร้างธุรกิจจริงทุกวัน
Disclosure: ผมไม่ได้รับ commission จาก tool ที่แนะนำในบทความนี้