เขียน PR และ README ที่ดี

ทำไมการเขียนเทคนิคถึงสำคัญ

ใน code review คำอธิบาย PR ของคุณคือจุดเริ่มต้นสำหรับผู้ตรวจสอบ คำอธิบาย PR ที่ดีช่วย:

• ✅ ให้ผู้ตรวจสอบเข้าใจได้อย่างรวดเร็วว่าคุณทำอะไร
• ✅ ลดคำถามไปมา
• ✅ แสดงว่าคุณคิดรอบคอบ

โครงสร้างมาตรฐานของคำอธิบาย PR: What/Why/How/Testing

1. What (ทำอะไรไป)

สรุปสั้นๆ หนึ่งประโยค

Refactor authentication flow to support OAuth2 and magic link sign-up

สำนวนสำคัญ:

• Add X — เพิ่มฟีเจอร์ใหม่
• Fix X — แก้ bug
• Refactor X — เขียน code ใหม่ (ไม่เปลี่ยนฟังก์ชัน)
• Optimize X — ปรับปรุงประสิทธิภาพ

2. Why (ทำไมถึงทำ)

ส่วนที่มักถูกละเลยมากที่สุด อธิบายบริบทและแรงจูงใจ

Why:
- Users requested passwordless sign-up option
- Current session-based auth doesn't scale to multiple domains

3. How (ทำอย่างไร)

ภาพรวมเทคนิคระดับสูง

How:
1. Created JWT service using Web Crypto API
2. Replaced SessionMiddleware with AuthMiddleware
3. Added OAuth2 routes for Google/GitHub sign-in

Breaking changes:
- Clients now need to store and send JWT in Authorization header

4. Testing (ทดสอบอย่างไร)

Testing:
- Manual testing: Verified OAuth2 sign-in with Google and GitHub
- Existing auth tests pass (147 tests)
- Added 23 new tests

Template คำอธิบาย PR

## What
[สรุปหนึ่งประโยค]

## Why
- [เหตุผล 1]
- [เหตุผล 2]

## How
1. [การเปลี่ยนแปลง 1]
2. [การเปลี่ยนแปลง 2]

## Testing
- [คุณทดสอบอะไร]

## Related
Closes #123

กับดักไวยากรณ์ในการเขียนเทคนิค

1. กาล (ข้อผิดพลาดที่พบบ่อยที่สุด)

หลักการ: ปัจจุบันกาลสำหรับสิ่งที่ code ทำ, อดีตกาลสำหรับการเปลี่ยนแปลงที่คุณทำ

ผิด	ถูก
”The function was created to handle X"	"The function handles X"
"The code will validate input"	"The code validates input”

2. Passive voice มากเกินไป

Passive	Active (ดีกว่า)
“The JWT is generated by the server"	"The server generates the JWT"
"Breaking changes were introduced"	"This PR introduces breaking changes”

3. ความแตกต่างละเอียดระหว่างคำพ้องความหมาย

คำ	การใช้งาน
Add	เพิ่มฟีเจอร์ใหม่: “Add OAuth2 support”
Fix	แก้ bug: “Fix race condition in cache”
Refactor	ปรับปรุง code โดยไม่เปลี่ยนฟังก์ชัน
Optimize	ปรับปรุงประสิทธิภาพ

Checklist ด่วนสำหรับ PR

• ส่วน What อธิบายการเปลี่ยนแปลงอย่างชัดเจน
• ส่วน Why มีเหตุผลทางธุรกิจหรือเทคนิค
• ส่วน How แสดงการออกแบบระดับสูง
• ส่วน Testing ระบุการครอบคลุมการทดสอบ
• ไม่มี passive voice มากเกินไป
• ลิงก์ไปยัง issue ที่เกี่ยวข้อง (ถ้ามี)