Code Review یعنی قبل از Merge، حداقل یک نفر دیگر diff را بخواند. هدف پیدا کردن باگ و انتقال دانش است، نه خرد کردن نویسنده.
🎯 اهداف یادگیری
- نظر را روی کد بگذاری نه روی آدم
- از Prefixهای متعارف استفاده کنی
- Review در VS Code را Submit کنی نه فقط کامنت محلی
- بدانی Approve مسئولیت است
🧭 اصول
- نیت نویسنده را فرض خیر بگذار
- سؤال بپرس قبل از حکم («اینجا race ممکن است؟» نه «این غلط است»)
- nit را برچسب بزن تا با blocker قاطی نشود
- تحسین کن — الگوی خوب را تکرارپذیر کن
- خارج از scope را Issue کن نه گروگان PR
پیشوندهای رایج:
| برچسب | معنی |
|---|---|
nit: |
سلیقه؛ اجباری نیست |
suggestion: |
بهتر است |
blocker: |
بدون این Merge نکن |
question: |
نمی‌فهمم، توضیح بده |
praise: |
این را بیشتر انجام بده |
از ۲۰۲۵ Copilot Code Review هم نظر می‌دهد؛ آن را لایهٔ اول بدان نه جایگزین انسان. نظر AI را بدون خواندن Approve نکن.
🖱️ ریویو در VS Code
- PR را Checkout کن و واقعاً اجرا کن — نه فقط diff
- روی خط Add Comment — می‌توانی suggestion بگذاری (
```suggestion) - چند کامنت pending بمانند
- Submit Review با یکی از: Comment / Approve / Request Changes
کامنت بدون Submit
Pending فقط روی ماشین توست. نویسنده چیزی نمی‌بیند تا Submit کنی.
✅ چک‌لیست نویسنده قبل از درخواست ریویو
- خودت diff را از بالا تا پایین خواندی
- فایل debug و
.envنیست - تست جدید برای رفتار جدید
- CI سبز
- توضیحات PR کامل است
✅ چک‌لیست ریویوکننده
- صحت: آیا باگ منطقی هست؟
- امنیت: تزریق، رمز، XSS، secret
- طراحی: آیا API پایدار می‌ماند؟
- تست: آیا فقدان پوشش هست؟
- مشاهده‌پذیری: لاگ و خطا
سؤالات مصاحبه (با پاسخ)
Mid — Request Changes یعنی چه؟ Merge معمولاً قفل می‌شود تا همان نفر یا سیاست re-request برگردد.
Senior — LGTM بدون نگاه؟ بدهی اعتماد. در حادثه، امضای تو روی تاریخچه است. Ruleset «dismiss stale reviews» را روشن کن تا push جدید Approve کهنه را باطل کند.
✅ جمع‌بندی
ریویو مهارت اجتماعی + فنی است. ابزار را در فصل ۱۱ دیدی؛ فرهنگ را اینجا. بدون هر دو، CI فقط تئاتر است.
فصل بعد: GitHub CLI — قدرت ترمینال.