SE บทที่ 2 — ออกแบบก่อนลงมือ · แบบแปลนก่อนตอกเสาเข็ม
ใช้ปุ่ม ← → เปลี่ยนสไลด์ได้SE TRACK — MODULE 2 · DESIGN
ออกแบบก่อนลงมือ — ให้ AI วาดแบบแปลนก่อนตอกเสาเข็ม
ก่อนเริ่มงานใหญ่ AI มักถามว่า "Before I start coding, I'll write a design doc first — want to review it?" — คนที่ไม่รู้มักตอบว่า "ไม่ต้อง ทำเลย" เพราะอยากได้ของเร็ว แล้วไปเจอตอนจบว่าโครงสร้างผิดทั้งหลัง ต้องรื้อใหม่แพงกว่าหลายเท่า บทนี้สอนให้อ่านเอกสารออกแบบของ AI ออก — และรู้ว่าทำไมคำตอบที่ถูกคือ "เอาสิ ขอดูก่อน"
เราไม่ต้องออกแบบเองแม้แต่บรรทัดเดียว — AI เป็นสถาปนิกให้ หน้าที่ของเราคืออ่านแบบแปลนแล้วเคาะ ก่อนอนุญาตให้ตอกเสาเข็ม
ทำไมต้องรู้
แก้เส้นดินสอบนกระดาษ ถูกกว่าทุบกำแพงจริง
01แก้ตอนออกแบบ = ถูกที่สุด
- บนแบบแปลน การย้ายห้องน้ำคือลบเส้นดินสอ 1 นาที — บ้านสร้างเสร็จแล้วคือทุบกำแพง เดินท่อใหม่
- ซอฟต์แวร์เหมือนกันเป๊ะ: แก้ในเอกสารออกแบบใช้เวลาไม่กี่นาที แก้ในโค้ดที่สร้างเสร็จแล้วอาจต้องรื้อเป็นวัน
02เอกสารออกแบบ = ภาษาที่เราอ่านออก
- โค้ดเราอ่านไม่ออก แต่เอกสารออกแบบเขียนเป็นภาษาคน — นี่คือด่านเดียวที่เจ้าของธุรกิจตรวจงานได้ก่อนโค้ดเกิด
- ปล่อยข้ามด่านนี้ = ครั้งถัดไปที่เห็นงานคือของสร้างเสร็จแล้ว
03AI ยิ่งเร็ว ยิ่งต้องมีแบบ
- AI เขียนโค้ดเร็วมาก — ถ้าทิศผิด มันจะพาเราหลงทางเร็วมากเช่นกัน
- เอกสารออกแบบคือการตรึงทิศก่อนออกตัว ต่อยอดจาก Requirement ที่ชัดแล้ว (บท SE1)
MENTAL MODEL ประจำบท
"แก้เส้นดินสอบนกระดาษ ถูกกว่าทุบกำแพงจริง — ให้ AI วาดแบบแปลนก่อนตอกเสาเข็มเสมอ"
ศัพท์ชุดที่ 1 · เอกสาร 4 แบบ
เอกสารออกแบบที่ AI จะเสนอทำให้เรา
DESIGN DOCแบบแปลนหลัก
- เอกสารอธิบายว่า "จะสร้างอย่างไร" — มีส่วนประกอบอะไร ต่อกันยังไง เก็บข้อมูลแบบไหน
- ใช้หลังจาก Requirement ชัดแล้ว (บท SE1) แต่ก่อนลงมือเขียนโค้ด
- AI: "I'll write a design doc first"
BLUEPRINTภาพรวมทั้งระบบ
- แผนภาพรวมของระบบ + แนวทางการสร้าง — คำนี้กว้าง ต้องระบุว่าอยากได้อะไรบ้าง (ดูสไลด์ถัดไป)
- ใช้ตอนเริ่มระบบใหม่ เพื่อให้เราและ AI เห็นภาพเดียวกัน
ADRสมุดบันทึกการตัดสินใจ
- Architectural Decision Record — บันทึก 1 การตัดสินใจสำคัญ: เลือกอะไร มีทางเลือกอะไรบ้าง ทำไมถึงเลือก
- เหมือนสมุดจดว่า "ทำไมบ้านหลังนี้เลือกเสาแบบนี้" — 6 เดือนผ่านไปไม่ต้องถามซ้ำ
- AI: "I recommend an ADR for this decision"
IMPLEMENTATION PLANแผนลงมือทีละขั้น
- แผนการลงมือทำจริง: แก้ไฟล์ไหนก่อน-หลัง ทดสอบตรงไหน ปล่อยของยังไง
- ขอทุกครั้งก่อนให้ AI แก้งานใหญ่หลายไฟล์ — เหมือนตารางงานผู้รับเหมารายสัปดาห์
- AI: "let me create an implementation plan"
ตัวอย่างจริง: ร้านค้าจะเก็บข้อมูลลูกค้าจาก LINE OA — Design Doc บอกว่าระบบหน้าตาเป็นยังไง · ADR จดว่า "ทำไมเลือกเก็บใน Google Sheets ไม่ใช่ฐานข้อมูลจริง" · Implementation Plan บอกว่าลงมือขั้นไหนก่อน
ศัพท์ชุดที่ 2 · ส่วนประกอบในแบบแปลน
เปิด Design Doc มาแล้วเจออะไร — อ่านให้ออกทีละส่วน
- 1Architecture โครงบ้านทั้งหลัง
โครงสร้างระดับสูงของระบบ — มีกี่ส่วน แต่ละส่วนต่อกันยังไง · ภาพรวมเรียก HLD (High-Level Design) ส่วนแบบขยายรายละเอียดจุดต่อจุดเรียก LLD (Low-Level Design) — เราอ่านแค่ HLD ก็พอ LLD เป็นของ AI
- 2Component ห้องแต่ละห้อง
ส่วนประกอบที่มีหน้าที่ชัดเจน 1 อย่าง เช่น "ส่วนรับข้อความ LINE" "ส่วนบันทึกข้อมูลลูกค้า" "ส่วนส่งข้อความตอบกลับ" — บ้านที่ดีแบ่งห้องชัด ไม่ใช่โถงเดียวทำทุกอย่าง
- 3API Contract สัญญาระหว่างห้อง
ข้อตกลงว่าแต่ละส่วนคุยกันด้วยอะไร: ส่งอะไรเข้า ได้อะไรออก ถ้าพลาดแจ้งยังไง — เหมือนสัญญาว่าปลั๊กไฟทุกห้องใช้ขากลมเหมือนกัน เปลี่ยนเครื่องใช้ไฟฟ้าได้โดยไม่ต้องเดินสายใหม่
- 4Data Model ผังตู้เก็บเอกสาร
แบบจำลองว่าเก็บข้อมูลอะไรบ้าง และโยงกันยังไง เช่น "ลูกค้า 1 คน มีได้หลายออเดอร์" — ส่วนนี้เราตรวจได้ดีที่สุด เพราะเรารู้จักข้อมูลธุรกิจตัวเองดีกว่า AI
- 5Design Pattern แบบบ้านสำเร็จรูปที่พิสูจน์แล้ว
รูปแบบการแก้ปัญหาที่ช่างทั่วโลกใช้ซ้ำจนพิสูจน์แล้วว่าดี — ได้ยิน AI พูดชื่อ pattern แปลก ๆ ไม่ต้องจำ แค่รู้ว่ามันหมายถึง "ใช้สูตรมาตรฐาน ไม่ได้มั่วเอง"
Blueprint ที่ดีต้องมีอย่างน้อย: ① ระบบนี้เกี่ยวข้องกับใคร/ระบบอะไรบ้าง (System Context) · ② Components หลัก · ③ เส้นทางข้อมูล + จุดเชื่อมต่อ (Data Flow / API) · ④ Data Model · ⑤ เรื่องความปลอดภัยและการยืนยันตัวตน · ⑥ แผนปล่อยของและทางถอยถ้าพัง — ถ้า AI ส่ง Blueprint มาไม่ครบ ขอเพิ่มได้เลย
ศัพท์ชุดที่ 3 · คำที่มาพร้อมการตัดสินใจ
4 คำที่ AI ใช้ตอนขอให้เรา "เลือก"
TRADE-OFFได้อย่าง เสียอย่าง
- การแลกข้อดีด้านหนึ่งกับข้อเสียอีกด้าน — ไม่มีตัวเลือกไหนดีหมดทุกด้าน
- ตัวอย่าง: เก็บลูกค้า LINE OA ใน Google Sheets = เริ่มไว ฟรี แต่พอลูกค้าหลักหมื่นจะเริ่มช้าและชนขีดจำกัด · ฐานข้อมูลจริง = รองรับโตได้ แต่ตั้งต้นช้ากว่า
- AI: "this involves a trade-off: X vs Y" — คนเลือกต้องเป็นเรา
TECHNICAL DEBTหนี้ทางเทคนิค
- ต้นทุนในอนาคตจากการเลือกทางลัดวันนี้ — เหมือนกู้เงินเปิดร้าน: เปิดได้เร็วขึ้น แต่มีดอกเบี้ยรอจ่าย
- เป็นหนี้ได้ ไม่ผิด — แต่ต้องรู้ตัวและจดไว้ ไม่ใช่ติดหนี้แบบไม่มีบัญชี
- AI: "we're taking on technical debt here"
REFACTORINGจัดบ้านใหม่ ของเท่าเดิม
- ปรับโครงสร้างโค้ดภายในให้สะอาดขึ้น โดยไม่เปลี่ยนพฤติกรรมที่ผู้ใช้เห็น — เหมือนจัดสต๊อกหลังร้านใหม่ หน้าร้านขายเหมือนเดิม
- นี่คือวิธีจ่ายคืน Technical Debt
- AI: "I'll refactor this before adding the feature"
BREAKING CHANGEของใหม่ทำของเดิมพัง
- การเปลี่ยนที่ทำให้ของเดิมที่เชื่อมต่ออยู่ใช้ต่อไม่ได้ — เหมือนย้ายประตูหน้าร้าน ลูกค้าประจำเดินมาเจอกำแพง
- ตรงข้ามคือ Backward Compatibility = ของใหม่มา ของเดิมยังใช้ได้
- AI: "this is a breaking change" — คำนี้ต้องหยุดอ่านทุกครั้ง
⭐ หัวใจของบท
ตารางแปลภาษา AI — ได้ยินแบบนี้ ต้องทำยังไง
| AI พูดว่า | กำลังจะเกิดอะไร | เราควรทำอะไร |
|---|---|---|
| "I'll write a design doc first" | จะวาดแบบแปลนก่อนเขียนโค้ด | ✅ ดีที่สุด — รอเอกสาร แล้วอ่านก่อนอนุมัติให้ลงมือ |
| "This involves a trade-off: X vs Y" | มี 2 ทางที่ได้อย่างเสียอย่าง — AI กำลังส่งการตัดสินใจมาให้เรา | 🟡 อ่านแล้วเราต้องเลือก — ถามต่อได้ว่า "ที่ยอดขายระดับร้านเรา ทางไหนคุ้มกว่า" |
| "This is a breaking change" | ของเดิมที่ต่อกับระบบอยู่จะใช้ไม่ได้ | ⚠️ หยุดก่อน — ถามว่ากระทบใครบ้าง มีวิธีทำแบบไม่พังของเดิม (backward compatible) ไหม |
| "We're taking on technical debt here" | เลือกทางลัดวันนี้ มีต้นทุนต้องจ่ายคืนภายหลัง | 🟡 รับได้ แต่ให้จดไว้ — สั่ง "บันทึกหนี้ก้อนนี้ไว้ในเอกสาร แล้วบอกด้วยว่าควรจ่ายคืนเมื่อไหร่" |
| "I recommend an ADR for this decision" | การตัดสินใจนี้สำคัญ ควรจดเหตุผลกันลืม | ✅ ให้ทำเลย — อนาคตจะไม่ต้องถามซ้ำว่า "ทำไมตอนนั้นเลือกแบบนี้" |
| "I'll refactor this before adding the feature" | จัดโครงสร้างภายในก่อน พฤติกรรมที่ผู้ใช้เห็นเหมือนเดิม | ✅ ปกติ — ขอให้ยืนยันด้วยว่าของเดิมยังทำงานเหมือนเดิม (วิธีตรวจอยู่บท SE6) |
| "Let me create an implementation plan" | จะวางแผนลงมือทีละขั้นก่อนแก้หลายไฟล์ | ✅ ดี — อ่านลำดับขั้น แล้วถามว่า "ขั้นไหนเสี่ยงสุด ถ้าพังถอยยังไง" |
สูตรจำเร็ว: design doc / ADR / plan = AI กำลังทำสิ่งที่ถูก ปล่อยและอ่าน · trade-off / technical debt = การตัดสินใจเป็นของเรา · breaking change = ไฟเหลืองกะพริบ ถามก่อนเสมอ
กันหลงทาง
5 คู่ที่คนสับสนบ่อยที่สุด
| คู่ศัพท์ | ต่างกันตรงไหน |
|---|---|
| HLD vs LLD | HLD = ภาพรวมทั้งบ้าน มีห้องอะไร ต่อกันยังไง (เราอ่านอันนี้) · LLD = แบบขยายจุดต่อจุด ระดับสายไฟรายเส้น (ของ AI ไม่ต้องอ่าน) |
| Design Doc vs ADR | Design Doc = แบบแปลนทั้งงาน "จะสร้างอย่างไร" · ADR = บันทึก 1 การตัดสินใจ "ทำไมถึงเลือกแบบนี้" — งานเดียวมี Design Doc 1 ฉบับ แต่มี ADR ได้หลายใบ |
| Blueprint vs Implementation Plan | Blueprint = ภาพรวมว่าระบบหน้าตาเป็นยังไง · Implementation Plan = แผนลงมือเรียงลำดับว่าทำอะไรก่อน-หลัง — แบบบ้าน vs ตารางงานผู้รับเหมา |
| Refactoring vs แก้ Bug | Refactoring = จัดโครงสร้างใหม่ พฤติกรรมต้องเหมือนเดิม · แก้ Bug = ตั้งใจเปลี่ยนพฤติกรรมจากผิดให้ถูก — ถ้า refactor แล้วระบบทำงานต่างไป แปลว่ามีอะไรพัง |
| Breaking Change vs Backward Compatibility | คู่ตรงข้ามกัน: Breaking Change = ของใหม่มา ของเดิมพัง · Backward Compatibility = ของใหม่มา ของเดิมยังใช้ได้ — เวลาสั่งงาน AI พูดได้เลยว่า "ขอแบบ backward compatible" |
ประโยคสั่งที่ใช้ได้จริง: "ก่อนลงมือ ขอ design doc สั้น ๆ + บอกด้วยว่ามี trade-off หรือ breaking change ตรงไหน" — ประโยคเดียว ใช้ศัพท์ครบครึ่งบท
QUICK-CHECK · กดดูเฉลย
จริงหรือไม่? — เช็คก่อนปิดบท
1 · "ให้ AI เขียนโค้ดเลยดีกว่า — เขียนเอกสารออกแบบก่อนคือเสียเวลา"
ไม่จริง — เอกสารออกแบบใช้เวลาไม่กี่นาที แต่เป็นด่านเดียวที่เราตรวจทิศทางได้ก่อนโค้ดเกิด · แก้บนกระดาษถูกกว่าทุบกำแพงจริงเสมอ ยิ่งงานใหญ่ยิ่งคุ้ม
2 · "Technical Debt แปลว่าโค้ดพัง ต้องรีบให้ AI แก้ทันที"
ไม่จริง — Technical Debt คือทางลัดที่ยังใช้งานได้ แต่มีต้นทุนสะสมรอในอนาคต เหมือนหนี้ที่ยังไม่ครบกำหนด · สิ่งที่ต้องทำคือ "จดไว้และวางแผนจ่ายคืน" ไม่ใช่ตกใจแก้ทุกก้อนทันที
3 · "AI บอกว่าจะ refactor — แสดงว่าหน้าร้านเราจะเปลี่ยนไป ต้องเตรียมแจ้งลูกค้า"
ไม่จริง — refactoring คือจัดโครงสร้างภายในโดยพฤติกรรมภายนอกเหมือนเดิม ลูกค้าไม่ควรเห็นความต่างเลย · ถ้าเปลี่ยนแล้วหน้าร้านต่างไป นั่นไม่ใช่ refactoring แล้ว — ทักได้เลย
KEY TAKEAWAY
Design Doc = แบบแปลน · ADR = สมุดจดเหตุผล · Trade-off = เราเป็นคนเลือก · Breaking change = ไฟเหลือง ถามก่อน
กฎเหล็กประจำบท: "ยังไม่เห็นแบบแปลน อย่าให้ตอกเสาเข็ม — AI ออกแบบ เราอ่านแล้วเคาะ"