| name | design-an-interface |
| description | สร้าง interface design หลายแบบที่ต่างกันสุดขั้วสำหรับ module หนึ่ง โดยใช้ sub-agent แบบ parallel ใช้เมื่อ user อยากออกแบบ API, สำรวจตัวเลือกของ interface, เปรียบเทียบรูปทรงของ module หรือพูดถึง "design it twice" |
Design an Interface
อิงจากแนวคิด "Design It Twice" ในหนังสือ "A Philosophy of Software Design": ไอเดียแรกของคุณแทบไม่เคยเป็นไอเดียที่ดีที่สุด สร้าง design หลายแบบที่ต่างกันสุดขั้ว แล้วค่อยเปรียบเทียบ
Workflow
1. เก็บ Requirements
ก่อนออกแบบ ต้องเข้าใจก่อนว่า:
ถามว่า: "module นี้ต้องทำอะไรได้บ้าง? ใครจะเป็นคนใช้?"
2. สร้าง Design (Sub-Agent แบบ Parallel)
spawn sub-agent 3 ตัวขึ้นไปพร้อมกันด้วย Task tool แต่ละตัวต้อง produce แนวทางที่ต่างกันสุดขั้ว
Prompt template for each sub-agent:
Design an interface for: [module description]
Requirements: [gathered requirements]
Constraints for this design: [assign a different constraint to each agent]
- Agent 1: "Minimize method count - aim for 1-3 methods max"
- Agent 2: "Maximize flexibility - support many use cases"
- Agent 3: "Optimize for the most common case"
- Agent 4: "Take inspiration from [specific paradigm/library]"
Output format:
1. Interface signature (types/methods)
2. Usage example (how caller uses it)
3. What this design hides internally
4. Trade-offs of this approach
3. นำเสนอ Design
โชว์แต่ละ design พร้อม:
- Interface signature - types, methods, params
- ตัวอย่างการใช้งาน - caller ใช้มันจริง ๆ ยังไงในทางปฏิบัติ
- มันซ่อนอะไรไว้ - ความซับซ้อนที่เก็บไว้ข้างใน
นำเสนอทีละ design เพื่อให้ user ซึมซับแต่ละแนวทางได้ก่อนถึงขั้นเปรียบเทียบ
4. เปรียบเทียบ Design
หลังโชว์ครบทุก design แล้ว เปรียบเทียบกันในแง่:
- ความเรียบง่ายของ interface: method น้อยกว่า, params เรียบง่ายกว่า
- General-purpose vs specialized: ความยืดหยุ่น vs ความโฟกัส
- ประสิทธิภาพของ implementation: รูปทรงนี้เปิดทางให้ internals ทำงานได้มีประสิทธิภาพไหม?
- ความลึก (depth): interface เล็กที่ซ่อนความซับซ้อนไว้เยอะ (ดี) vs interface ใหญ่แต่ implementation บาง (แย่)
- ใช้ให้ถูกได้ง่าย vs ใช้ผิดได้ง่าย
อภิปราย trade-off เป็นร้อยแก้ว ไม่ใช่ตาราง เน้นจุดที่ design แตกต่างกันมากที่สุด
5. สังเคราะห์
บ่อยครั้ง design ที่ดีที่สุดเกิดจากการรวม insight จากหลายตัวเลือกเข้าด้วยกัน ถามว่า:
- "design ไหนเข้ากับ use case หลักของคุณที่สุด?"
- "มีชิ้นส่วนจาก design อื่นที่ควรหยิบมาผสมไหม?"
เกณฑ์การประเมิน
จากหนังสือ "A Philosophy of Software Design":
ความเรียบง่ายของ interface: method น้อยกว่า params เรียบง่ายกว่า = เรียนรู้ง่ายและใช้ถูกต้องได้ง่ายกว่า
General-purpose: รองรับ use case ในอนาคตได้โดยไม่ต้องแก้ แต่ระวังการ generalize เกินจำเป็น
ประสิทธิภาพของ implementation: รูปทรงของ interface เปิดทางให้ implement ได้มีประสิทธิภาพไหม? หรือบังคับให้ internals ต้องเขียนแบบฝืน ๆ?
ความลึก (depth): interface เล็กที่ซ่อนความซับซ้อนไว้เยอะ = deep module (ดี) interface ใหญ่แต่ implementation บาง = shallow module (เลี่ยง)
Anti-Patterns
- อย่าปล่อยให้ sub-agent produce design ที่คล้ายกัน - ต้องบังคับให้ต่างกันสุดขั้ว
- อย่าข้ามขั้นเปรียบเทียบ - คุณค่าอยู่ที่ contrast
- อย่าลงมือ implement - นี่เป็นเรื่องรูปทรงของ interface ล้วน ๆ
- อย่าประเมินจากความยาก-ง่ายของการ implement
