prototype

Files (3)

• LOGIC.md
• SKILL.md
• UI.md

SKILL.md (first lines)

# Prototype

prototype คือ **code ใช้แล้วทิ้งที่มีไว้ตอบคำถาม** ตัวคำถามคือสิ่งที่กำหนดรูปร่างของมัน

## เลือก branch

ระบุก่อนว่ากำลังตอบคำถามไหน — จาก prompt ของ user, จาก code รอบ ๆ, หรือถามตรง ๆ ถ้า user อยู่แถวนั้น:

- **"logic / state model แบบนี้เวิร์คไหม?"** → [LOGIC.md](LOGIC.md) สร้าง terminal app เล็ก ๆ แบบ interactive ที่ดัน state machine ผ่าน case ที่คิดตามบนกระดาษได้ยาก
- **"หน้าตาควรเป็นยังไง?"** → [UI.md](UI.md) สร้าง UI หลาย variation ที่ต่างกันแบบสุดขั้วบน route เดียว สลับได้ผ่าน URL search param และแถบลอยด้านล่างจอ

สอง branch นี้ให้ผลลัพธ์ที่ต่างกันมาก — เลือกผิดเท่ากับเสีย prototype ทั้งตัวไปเปล่า ๆ ถ้าคำถามกำกวมจริง ๆ และติดต่อ user ไม่ได้ ให้ default ไปที่ branch ที่เข้ากับ code รอบ ๆ มากกว่า (module ฝั่ง backend → logic; page หรือ component → UI) แล้วระบุสมมติฐานนั้นไว้ที่ด้านบนสุดของ prototype

## กติกาที่ใช้กับทั้งสอง branch

1. **ใช้แล้วทิ้งตั้งแต่วันแรก และทำเครื่องหมายให้ชัดว่าเป็นแบบนั้น** วาง code ของ prototype ไว้ใกล้จุดที่มันจะถูกใช้จริง (ข้าง ๆ module หรือ page ที่กำลัง prototype ให้) เพื่อให้ context ชัดเจน — แต่ตั้งชื่อให้คนที่เปิดผ่านมาเห็นก็รู้ทันทีว่านี่คือ prototype ไม่ใช่ production สำหรับ UI route แบบใช้แล้วทิ้ง ให้ทำตาม routing convention ที่โปรเจกต์ใช้อยู่แล้ว อย่าคิดโครงสร้าง top-level ใหม่ขึ้นมาเอง
2. **รันได้ด้วยคำสั่งเดียว** ใช้อะไรก็ได้ที่ task runner เดิมของโปรเจกต์รองรับ — `pnpm <name>`, `python <path>`, `bun <path>` ฯลฯ user ต้องเริ่มมันได้โดยไม่ต้องคิดเลย
3. **ไม่มี persistence โดย default** state อยู่ใน memory เท่านั้น persistence คือสิ่งที่ prototype กำลัง _ตรวจสอบ_ ไม่ใช่สิ่งที่มันควรพึ่งพา ถ้าคำถามเกี่ยวข้องกับ database โดยตรง ให้ใช้ scratch DB หรือ local file ที่ตั้งชื่อบอกชัด ๆ ทำนอง "PROTOTYPE — ลบทิ้งได้"
4. **ข้ามความเนี้ยบไปเลย** ไม่ต้องมี test ไม่ต้องมี error handling เกินกว่าที่ทำให้ prototype _รันได้_ ไม่ต้องมี abstraction ประเด็นคือเรียนรู้อะไรบางอย่างให้เร็ว
5. **โชว์ state ออกมา** หลังทุก action (ฝั่ง logic) หรือทุกครั้งที่สลับ variant (ฝั่ง UI) ให้ print หรือ render state ที่เกี่ยวข้องทั้งหมดออกมา เพื่อให้ user เห็นว่าอะไรเปลี่ยนไป
6. **เก็บผลเมื่อเสร็จ** เอาการตัดสินใจที่ผ่านการพิสูจน์แล้วไปใส่ใน code จริง แล้วเก็บตัว prototype ไว้เป็น **primary source**: commit มันลง branch ใช้แล้วทิ้ง นอก main และทิ้ง context pointer ชี้ไปที่ branch นั้นไว้บน issue ของงาน implement เก็บคำตอบไว้ด้วย — ข้อสรุปและคำถามที่มันช่วยตอบ — ใน issue หรือใน commit ส่วน branch main เก็บไว้แค่การตัดสินใจที่ผ่านการพิสูจน์แล้วเท่านั้น

From Boom-Vitt/skills-thai, MIT.

More from Boom-Vitt/skills-thai