
Code Review Checklist 5 มิติ: Correctness, Security, Performance, Style, Test Coverage
พรอมต์สำหรับ developer ที่ต้องการ code review เชิงลึก ครอบคลุม 5 มิติหลัก พร้อมระบบ status icon และ verdict สรุป ช่วยให้ review ได้ครบถ้วนและสม่ำเสมอทุกครั้ง
เริ่มต้นที่นี่
ตัวอย่างผลลัพธ์ที่จะได้
ก่อนเริ่มลงมือปรับพรอมต์ ดูตัวอย่างผลลัพธ์ที่คุณจะได้จริงเพื่อให้แน่ใจว่าพรอมต์นี้ตรงกับงานที่ต้องการ
1. Correctness ⚠️
- ❌ ไม่มีการตรวจสอบว่า
resultว่างเปล่าก่อน accessresult[0]— จะเกิดIndexErrorหาก user ไม่พบใน database - ⚠️ ไม่มีการ validate ประเภทของ
user_idก่อนนำไปใช้ — หาก client ส่ง non-string มาอาจเกิด runtime error - ✅ Logic หลักของการ query ตรงกับ intent ที่ระบุใน context
2. Security ❌
- ❌ SQL Injection: ต่อ string โดยตรงด้วย
"SELECT * FROM users WHERE id = " + user_id— ต้องเปลี่ยนเป็น parameterised query เช่นdb.execute("SELECT * FROM users WHERE id = ?", (user_id,))โดยเด็ดขาด - ❌ Sensitive data leak:
print(f"Fetched user: {result[0]}")อาจ log ข้อมูล sensitive เช่น password hash หรือ PII ออก stdout/log file - ⚠️ ไม่มีการตรวจสอบ authorisation ว่า caller มีสิทธิ์ดู user คนนี้หรือไม่
3. Performance ⚠️
- ⚠️
SELECT *ดึงทุก column — ควรระบุ column ที่จำเป็น (เช่นid, name, email) เพื่อลด network payload - ✅ ไม่มี N+1 query ใน function นี้
- ✅ ไม่มี loop ที่ไม่จำเป็น
4. Style & Readability ⚠️
- ⚠️ ไม่มี type hint — ควรเพิ่ม
user_id: strและ-> dictเพื่อให้ IDE และ reviewer เข้าใจ contract ของ function - ⚠️ ไม่มี docstring อธิบาย parameters, return value และ exceptions ที่อาจเกิดขึ้น
- ✅ ชื่อ function และตัวแปรอ่านเข้าใจง่าย โครงสร้างกระชับ
5. Test Coverage ❌
- ❌ ไม่พบ unit test สำหรับ function นี้เลย
- ❌ ขาด test case: user ไม่พบใน database (empty result)
- ❌ ขาด test case: SQL injection input เพื่อยืนยันว่า fix แล้วได้ผล
- ❌ ขาด test case:
user_idเป็น None หรือ invalid type
Verdict: Request Changes
มี SQL Injection vulnerability ระดับ critical และ sensitive data รั่วไหลใน log ซึ่งต้องแก้ไขและเพิ่ม test coverage ก่อน merge โดยเด็ดขาด
ขั้นตอนที่ 1
ปรับให้เข้ากับงานของคุณ
แก้ค่าตัวแปรด้านล่าง พรอมต์ฉบับสมบูรณ์จะอัพเดทอัตโนมัติพร้อมก๊อปไปวางใน Claude หรือ ChatGPT ได้ทันที
You are a senior software engineer conducting a thorough code review. Analyse the following Python code and evaluate it across exactly five dimensions. For each dimension, list specific findings as bullet points using status icons (✅ pass · ⚠️ warning · ❌ issue). End with a **Verdict**: Approve / Request Changes / Reject, plus a one-sentence rationale.
## Code context
ฟังก์ชัน get_user() รับ user_id จาก HTTP request parameter แล้ว query ข้อมูลผู้ใช้จาก database เพื่อส่งคืนเป็น API response
## Code to review
```Python
def get_user(user_id):
query = "SELECT * FROM users WHERE id = " + user_id
result = db.execute(query)
print(f"Fetched user: {result[0]}")
return result[0]
```
## Review dimensions
### 1. Correctness
- Does the logic match the intended behaviour?
- Are edge cases handled (null, empty, overflow, off-by-one)?
- Are all error conditions caught and handled?
### 2. Security
- Is user input validated and sanitised before use?
- Are there injection risks (SQL, XSS, shell command)?
- Are secrets or sensitive data exposed in logs or responses?
- Are authentication and authorisation checks present where needed?
### 3. Performance
- Are there unnecessary loops, N+1 queries, or redundant computation?
- Is memory allocation proportionate to the task?
- Are expensive operations cached or deferred where appropriate?
### 4. Style & Readability
- Do names follow project conventions and clearly express intent?
- Are functions/classes small, single-purpose, and well-named?
- Is non-obvious logic accompanied by a brief comment?
### 5. Test Coverage
- Are unit tests present for the new or changed logic?
- Do tests cover both happy paths and edge/error cases?
- Are assertions specific and mocks meaningful?
## Output format
Return a Markdown report structured as:
- One H2 heading per dimension with an overall status icon
- Bullet-point findings (with ✅ / ⚠️ / ❌ prefix per item)
- A final **Verdict** section: `Approve` | `Request Changes` | `Reject` with a one-sentence rationaleขั้นตอนที่ 2
เข้าใจเทคนิคที่ซ่อนอยู่
คลิกที่ส่วนไฮไลต์ในพรอมต์เพื่อกระโดดไปดูคำอธิบายเทคนิคแต่ละจุด ใช้ความเข้าใจนี้เพื่อปรับพรอมต์อื่นของคุณเองในภายหลัง
Analyse the following {{language}} code and . For each dimension, list specific findings as bullet points using . End with a **Verdict**: Approve / Request Changes / Reject, plus a one-sentence rationale. ## Code to review ```{{language}} {{code}} ``` ## Review dimensions ### 1. Correctness - Does the logic match the intended behaviour? - Are edge cases handled (null, empty, overflow, off-by-one)? - Are all error conditions caught and handled? ### 2. Security ### 3. Performance - Are there unnecessary loops, N+1 queries, or redundant computation? - Is memory allocation proportionate to the task? - Are expensive operations cached or deferred where appropriate? ### 4. Style & Readability - Do names follow project conventions and clearly express intent? - Are functions/classes small, single-purpose, and well-named? - Is non-obvious logic accompanied by a brief comment? ### 5. Test Coverage - Are unit tests present for the new or changed logic? - Do tests cover both happy paths and edge/error cases? - Are assertions specific and mocks meaningful? ## Output format
- 1Role assignment
“You are a senior software engineer conducting a thorough code review.”
การกำหนด role เป็น senior engineer ทำให้โมเดลเลือกใช้มาตรฐานระดับสูงในการประเมิน แทนที่จะ review แบบผิวเผินในฐานะผู้อ่านทั่วไป
- 2Evaluation framework constraint
“evaluate it across exactly five dimensions”
การระบุจำนวนมิติแน่นอน (exactly five) บังคับให้โมเดลครอบคลุมทุกมิติโดยไม่ข้ามหรือรวมมิติเข้าด้วยกัน ทำให้ผลลัพธ์สม่ำเสมอทุกครั้ง
- 3Sub-question checklist
“- Is user input validated and sanitised before use? - Are there injection risks (SQL, XSS, shell command)? - Are secrets or sensitive data exposed in logs or responses? - Are authentication and authorisation checks present where needed?”
การแตก dimension แต่ละมิติเป็น sub-question เฉพาะเจาะจง ป้องกันไม่ให้โมเดลตอบแบบกว้างเกินไป และบังคับให้ตรวจสอบประเด็นที่สำคัญแต่มักถูกมองข้าม
- 4Graduated severity scale
“status icons (✅ pass · ⚠️ warning · ❌ issue)”
ระบบ icon 3 ระดับบังคับให้โมเดลแยกแยะความรุนแรงของปัญหา ทำให้ reviewer สามารถ prioritize สิ่งที่ต้องแก้ไขก่อนได้ทันที
- 5Output format constraint
“Return a Markdown report structured as: - One H2 heading per dimension with an overall status icon - Bullet-point findings (with ✅ / ⚠️ / ❌ prefix per item) - A final **Verdict** section: `Approve` | `Request Changes` | `Reject` with a one-sentence rationale”
การกำหนด output format อย่างละเอียดทำให้ผลลัพธ์นำไปใช้ใน PR comment หรือ documentation ได้ทันที โดยไม่ต้องจัดรูปแบบเพิ่มเติม
- 6Context grounding
“## Code context {{context}}”
การให้ context แยกออกมาจากโค้ด ช่วยให้โมเดลเข้าใจ intent ของโค้ดก่อน review จึงสามารถตรวจจับ logic ที่ผิดจาก requirement ได้แม่นยำกว่าการดูโค้ดอย่างเดียว
ขั้นตอนที่ 3
เห็นความต่าง พรอมต์ทั่วไป vs พรอมต์ที่ใช้เทคนิค
คนส่วนใหญ่เริ่มต้นด้วยคำสั่งสั้นๆ แบบฝั่งซ้าย แต่ผลลัพธ์มักไม่ตรงใจและต้องถามซ้ำหลายรอบ พรอมต์แบบฝั่งขวาแก้ปัญหานี้ด้วยเทคนิคที่อธิบายข้างต้น
พรอมต์แบบที่ใช้กันทั่วไป
ช่วย review โค้ดนี้ให้หน่อย
พรอมต์แบบที่ใช้เทคนิคข้างบน
กำหนด role เป็น senior engineer, แบ่ง 5 มิติชัดเจนพร้อม sub-question, ใช้ status icon 3 ระดับ, กำหนด output format แบบ Markdown, จบด้วย Verdict พร้อม rationale
ทำไมแบบที่ใช้เทคนิคถึงดีกว่า
พรอมต์แบบเดิมไม่ระบุว่าต้องการ review ในมิติใดบ้าง โมเดลจึงมักตอบแบบกว้างและข้ามประเด็น security หรือ test coverage ไป พรอมต์ที่ดีกว่ากำหนด framework 5 มิติพร้อม sub-question เฉพาะ ทำให้โมเดลตรวจสอบได้ครบถ้วนและสม่ำเสมอทุกครั้ง ระบบ status icon และ verdict ช่วยให้นำผลไปใช้ใน PR comment ได้ทันทีโดยไม่ต้องแปลงรูปแบบเพิ่มเติม
พรอมต์ที่เกี่ยวข้อง
ลองพรอมต์อื่นในแนวเดียวกัน

งานโค้ด
อธิบาย Legacy Code ให้ทีมใหม่เข้าใจเร็ว พร้อม Flag จุดเสี่ยงและ Tech Debt
ให้ AI วิเคราะห์โค้ดเก่าที่ซับซ้อน สรุปการทำงาน ชี้จุดเสี่ยง และจัดทำ tech debt log พร้อม effort estimate เพื่อให้ทีมใหม่เริ่มต้นได้อย่างปลอดภัยและมีทิศทางชัดเจน

งานโค้ด
สร้าง Test Cases ครอบคลุมจาก Function Spec
สร้าง test suite จาก function specification ที่ครอบคลุมทั้ง happy path, edge cases และ adversarial inputs พร้อม rationale ของแต่ละ test และ runnable code ในภาษาและ framework ที่เลือก ช่วย developer เขียน test อย่างเป็นระบบและตรวจจับ bug ที่ซ่อนอยู่ได้อย่างมีประสิทธิภาพ

งานโค้ด
เขียน Architecture Decision Record (ADR) สำหรับการตัดสินใจทางเทคนิค
สร้าง ADR ที่ครบถ้วนและอ่านง่าย บันทึกบริบท ตัวเลือกที่พิจารณา เหตุผลการตัดสินใจ และ trade-off ที่ยอมรับ ช่วยให้ทีมปัจจุบันและนักพัฒนารุ่นต่อไปเข้าใจว่าทำไมจึงตัดสินใจเช่นนั้น

งานโค้ด
อธิบาย Error Message ให้เข้าใจง่ายพร้อมแก้ทีละขั้นและป้องกันซ้ำ
พรอมต์สำหรับนักพัฒนาที่ต้องการอ่าน error message ที่ซับซ้อนให้เข้าใจง่าย รับคำแนะนำแก้ไขทีละขั้นตอน และเรียนรู้วิธีป้องกันไม่ให้ปัญหาเดิมเกิดซ้ำในอนาคต