สัปดาห์ที่ 14

นำเสนอโครงงานเว็บและจัดทำเอกสารประกอบ

CLO5 CLO6
📑 สารบัญ
📖 ทฤษฎี

1. การนำเสนอโปรเจกต์เทคนิค (Demo-Driven Presentation)

สัปดาห์สุดท้ายของการพัฒนาคือโอกาสแสดงให้เห็นว่าทีมสร้างระบบจริงที่ใช้งานได้ รูปแบบที่ได้ผลดีที่สุดคือ Demo-Driven Presentation — เปิดด้วยปัญหา แล้วสาธิตระบบสดทันทีโดยไม่เสียเวลากับ Slide มากเกินไป

โครงสร้างการนำเสนอที่แนะนำ (รวม 12–15 นาที):

  • บทนำ (2 นาที) — ชื่อโปรเจกต์ ชื่อทีม ปัญหาในชีวิตจริงที่ต้องการแก้ และ Target Users ว่าคือใคร
  • Demo สด (7–8 นาที) — สาธิต User Flow จริงตั้งแต่ต้นจนจบ เช่น ลูกค้าจอง → ระบบบันทึก → Admin ยืนยัน แสดงให้ครบทุก Feature หลัก
  • สถาปัตยกรรมระบบ (2 นาที) — เทคโนโลยีที่ใช้ โครงสร้าง Frontend/Backend และ Database Schema สั้นๆ
  • Retrospective (1–2 นาที) — สิ่งที่ทำสำเร็จ อุปสรรคที่พบ และสิ่งที่จะพัฒนาต่อถ้ามีเวลา
  • ถาม-ตอบ (2–3 นาที) — เตรียมตอบคำถามจากอาจารย์และเพื่อน 
  Demo-Driven Presentation Flow
  ─────────────────────────────────────────────────
  [ปัญหา] → [Demo Live] → [Tech Stack] → [Retro]
      2 นาที      7-8 นาที     2 นาที      1-2 นาที
  ─────────────────────────────────────────────────
  เปิดด้วย: "ปัญหาจริงที่ทีมเราเจอคือ..."
  Demo:      เปิด URL จริง ทำ User Flow สดๆ
  ปิดด้วย:  "ถ้ามีเวลาเพิ่ม เราจะพัฒนา..."
  ─────────────────────────────────────────────────
เคล็ดลับ — ซ้อมกับเวลาจริง

ซ้อมการนำเสนอพร้อมจับเวลาอย่างน้อย 2–3 ครั้งก่อนวันจริง ทุกคนในทีมต้องมีส่วนพูด แสดงให้เห็นว่าทุกคนเข้าใจระบบทั้งหมด ไม่ใช่แค่คนที่เขียนโค้ดส่วนนั้น เตรียม Backup เป็น Video Recording ไว้ในกรณีที่เน็ตหลุดหรือระบบมีปัญหาระหว่าง Demo

2. การเขียน README.md ที่ดี

README.md คือประตูบานแรกของโปรเจกต์ — นักพัฒนาหรืออาจารย์ที่เปิด Repository จะอ่านไฟล์นี้ก่อนเสมอ README ที่ดีช่วยให้ผู้อื่น Clone แล้วรันระบบได้ภายใน 5 นาที โดยไม่ต้องถามเจ้าของโปรเจกต์

องค์ประกอบสำคัญของ README ที่ครบถ้วน:

  • ชื่อโปรเจกต์และคำอธิบาย — หนึ่งประโยคสั้นๆ บอกว่าระบบทำอะไร สำหรับใคร และแก้ปัญหาอะไร
  • ลิงก์ Demo — URL ที่ Deploy แล้วใช้งานได้จริง ไม่ใช่แค่ localhost
  • ฟีเจอร์หลัก — รายการ Feature ที่ทำเสร็จแล้ว ใช้ Checkbox - [x] สำหรับเสร็จแล้วและ - [ ] สำหรับยังไม่ได้ทำ
  • Tech Stack — เทคโนโลยีทั้งหมดที่ใช้ทั้ง Frontend, Backend และ Database
  • วิธีรันในเครื่อง — คำสั่งทีละขั้นตอนที่ชัดเจนและทดสอบแล้วว่าใช้งานได้จริง
  • สมาชิกทีม — ชื่อ รหัสนักศึกษา และหน้าที่ในทีม
หมายเหตุ — README เป็น Living Document

อัปเดต README ทุกครั้งที่เพิ่ม Feature หรือเปลี่ยน Tech Stack README ที่ล้าสมัยกว่าโค้ดจริงสร้างความสับสนมากกว่าไม่มี README เลย เขียนและทดสอบคำสั่งใน README บนเครื่องใหม่ที่ไม่เคย Clone มาก่อนจะมั่นใจได้ว่าใช้ได้จริง

3. Technical Documentation: API Docs และ DB Schema Diagram

นอกจาก README เอกสารทางเทคนิคที่สำคัญสำหรับโปรเจกต์ Full Stack คือ API Documentation และ Database Schema Diagram ทั้งสองช่วยให้ทีมทำงานร่วมกันได้อย่างมีประสิทธิภาพ และเป็นหลักฐานแสดงการออกแบบระบบในการส่งงาน

API Documentation ควรมีข้อมูลต่อไปนี้สำหรับทุก Endpoint:

  • Method และ Path — เช่น GET /api/services หรือ POST /api/bookings
  • คำอธิบาย — Endpoint นี้ทำอะไร สำหรับใคร ต้องการ Authentication หรือไม่
  • Request Body / Query Params — ข้อมูลที่ต้องส่งมา พร้อม Type และว่า Required หรือ Optional
  • Response ตัวอย่าง — JSON ที่คืนกลับมาเมื่อสำเร็จ (200/201) และเมื่อเกิด Error (400/401/404)

DB Schema Diagram ที่ดีแสดงตารางทั้งหมด คอลัมน์ Data Type Primary Key (PK) Foreign Key (FK) และ Relationship ระหว่างตาราง สร้างได้ฟรีด้วยเครื่องมือเช่น dbdiagram.io หรือ draw.io 

  ตัวอย่าง DB Schema (ระบบจองบริการ)
  ─────────────────────────────────────────────────
  [users]               [services]
  ───────               ──────────
  id (PK, uuid)         id (PK, uuid)
  email (unique)        name
  password_hash         price
  role (user/admin)     duration_min
  created_at            created_at

  [bookings]
  ──────────
  id (PK, uuid)
  user_id (FK) ──────► [users.id]
  service_id (FK) ────► [services.id]
  booking_date
  booking_time
  status (pending/confirmed/cancelled)
  created_at
  ─────────────────────────────────────────────────
เคล็ดลับ — เขียน API Docs ก่อนเขียนโค้ด

ทีมที่แบ่ง Frontend และ Backend ควรตกลง API Contract ผ่านเอกสารก่อน เริ่มเขียนโค้ด Frontend สามารถ Mock ข้อมูลจาก API Docs ได้ทันทีโดยไม่ต้องรอ Backend เสร็จ ทำให้ทั้งสองฝั่งทำงานได้พร้อมกัน

4. Deployment Checklist ก่อน Demo

การ Deploy ระบบขึ้น Production ก่อนวันนำเสนอเป็นสิ่งสำคัญมาก การรัน Demo จาก localhost มีความเสี่ยงสูงหากมีปัญหาเรื่อง Port, Environment Variables หรือ Database Connection ใช้ Checklist นี้ก่อนวันนำเสนอ 

  Deployment Checklist ก่อน Demo
  ─────────────────────────────────────────────────
  Backend (Cloudflare Workers)
  - [ ] wrangler deploy สำเร็จ ไม่มี Error
  - [ ] Environment Variables ใน Workers Dashboard ครบ
        (SUPABASE_URL, SUPABASE_ANON_KEY, JWT_SECRET)
  - [ ] ทดสอบ API จาก URL จริงด้วย curl หรือ Postman
  - [ ] CORS อนุญาต Domain ของ Frontend แล้ว

  Frontend (Cloudflare Pages / Vercel)
  - [ ] Build สำเร็จ (npm run build ไม่มี Error)
  - [ ] VITE_API_URL ชี้ไปที่ Backend URL จริง (ไม่ใช่ localhost)
  - [ ] Deploy แล้ว เปิดด้วย URL จริงในหลายเบราว์เซอร์
  - [ ] ทดสอบบน Mobile ด้วย

  Database (Supabase)
  - [ ] มีข้อมูลตัวอย่างครบ (สินค้า/บริการอย่างน้อย 5 รายการ)
  - [ ] มี User ทดสอบทั้ง admin และ user ปกติ
  - [ ] Row Level Security (RLS) ตั้งค่าถูกต้อง
  - [ ] ทดสอบ Register/Login/CRUD ครบทุก Flow
  ─────────────────────────────────────────────────
ข้อควรระวัง — ทดสอบบนเครื่องที่จะนำเสนอจริง

ทดสอบระบบบนเครื่องและเครือข่ายอินเทอร์เน็ตที่จะใช้นำเสนอจริงอย่างน้อย 1 วันก่อน บางครั้งเครือข่าย WiFi ของมหาวิทยาลัยบล็อกพอร์ตบางพอร์ต หรือ Cloudflare Workers ยังไม่ได้ Deploy ล่าสุด ตรวจสอบให้แน่ใจก่อนเริ่มนำเสนอ

5. Retrospective: สิ่งที่ทำได้ดี / สิ่งที่จะพัฒนาต่อ

Retrospective หรือการทบทวนหลังโปรเจกต์เป็นส่วนสำคัญของ Agile Methodology ช่วยให้ทีมเรียนรู้จากประสบการณ์จริงและนำไปปรับใช้ในโปรเจกต์ต่อไป ในการนำเสนอสัปดาห์นี้ให้ทีมแชร์ Retrospective สั้นๆ 2–3 ประเด็น

กรอบ Retrospective ที่ใช้ได้ง่ายมีสามส่วน:

  • สิ่งที่ทำได้ดี (Went Well) — Feature ที่ภูมิใจที่สุด การทำงานทีมที่ราบรื่น เทคโนโลยีที่เลือกแล้วช่วยได้มาก
  • อุปสรรคที่พบ (Challenges) — ปัญหาที่ใช้เวลาแก้นานที่สุด ความเข้าใจผิดในทีม หรือเทคโนโลยีที่ยากกว่าที่คาด
  • สิ่งที่จะพัฒนาต่อ (Next Steps) — Feature ที่อยากเพิ่มถ้ามีเวลา การแก้ไข Technical Debt หรือการปรับปรุง Performance และ Security 
  Retrospective Template
  ─────────────────────────────────────────────────
  ✅ Went Well
     - Deploy บน Cloudflare Workers ครั้งแรกสำเร็จ
     - ทีมใช้ GitHub Pull Request ทุก Feature
     - Supabase Auth ง่ายกว่าที่คิด

  ❌ Challenges
     - CORS ใช้เวลาแก้ 3 ชั่วโมงวันแรก
     - Type ใน TypeScript ที่ซับซ้อนทำให้ช้า
     - ประสานงานหน้า API ยากเมื่อ Backend ยังไม่เสร็จ

  🚀 Next Steps
     - เพิ่มระบบ Email Notification
     - เพิ่ม Unit Tests บน Backend
     - ปรับ UI ให้รองรับ Dark Mode
  ─────────────────────────────────────────────────
หมายเหตุ — Retrospective ไม่ใช่การโทษกัน

เป้าหมายของ Retrospective คือการเรียนรู้ ไม่ใช่การหาว่าใครผิด พูดถึงกระบวนการและสถานการณ์ ไม่ใช่บุคคล ทุกปัญหาที่พบในโปรเจกต์นี้ เป็นประสบการณ์ที่มีค่าสำหรับการทำงานจริงในอนาคต

💻 โค้ดตัวอย่าง
README.md — โครงสร้าง README ที่ดี Markdown 
# ชื่อโปรเจกต์

> คำอธิบายสั้น 1-2 ประโยค

## Demo
[ลิงก์เว็บไซต์ที่ deploy แล้ว](https://my-project.workers.dev)

## ฟีเจอร์หลัก
- [ ] ฟีเจอร์ 1
- [ ] ฟีเจอร์ 2

## Tech Stack
- Frontend: Vite + React + TanStack Router/Query + Shadcn/ui
- Backend: Hono บน Cloudflare Workers
- Database: Supabase (PostgreSQL)

## วิธีรันในเครื่อง
```bash
# Frontend
cd frontend && npm install && npm run dev

# Backend
cd backend && npm install && npx wrangler dev
```

## สมาชิกทีม
| ชื่อ | รหัสนักศึกษา | หน้าที่ |
|------|-------------|--------|
| สมชาย | 6601001 | Frontend |
| สมหญิง | 6601002 | Backend |
API_DOCS.md — เอกสาร API อย่างง่าย Markdown 
## BookEasy API

Base URL: `https://bookeasy-api.workers.dev`

### GET /api/services
ดึงรายการบริการทั้งหมด

**Response 200:**
```json
{
  "success": true,
  "data": [
    { "id": "uuid", "name": "ตัดผมชาย", "price": 150, "duration_min": 45 }
  ]
}
```

### POST /api/bookings
สร้างการจองใหม่ (ต้องมี Authorization header)

**Request Body:**
```json
{ "service_id": "uuid", "booking_date": "2026-07-10", "booking_time": "09:00" }
```
← สัปดาห์ก่อน
โครงงานเว็บแอปพลิเคชันทางธุรกิจ: วิเคราะห์ ออกแบบ และพัฒนา (ทีม)
สัปดาห์ถัดไป →
Deploy บน Cloudflare Workers, Testing & สรุปรายวิชา