ریویو کردن — چیست، چگونه کد ریویو و بررسی PR کار می‌کند

Code review چیست

Code review — بررسی سیستماتیک کد توسط همکاران قبل از ادغام آن است. در زمینه Git این به معنای: توسعه‌دهنده یک pull request با تغییرات ایجاد می‌کند، بازبین‌ها را تعیین می‌کند و آن‌ها diff را مطالعه می‌کنند، نظرات می‌گذارند و رأی می‌دهند. بازبین می‌تواند درخواست تغییر (Request Changes)، تأیید PR (Approve) یا نظر کلی بگذارد.

Code review پنج هدف دارد: بهبود کیفیت کد (تشخیص نقص‌ها قبل از ورود به تولید)، گسترش دانش (بازبین با رویکردهای جدید آشنا می‌شود، نویسنده بازخورد دریافت می‌کند)، رعایت استانداردها (بررسی تطابق با code style و تصمیم‌های معماری)، کاهش bus factor (کد فقط توسط یک توسعه‌دهنده شناخته نمی‌شود) و ایجاد فرهنگ مسئولیت‌پذیری (نویسنده با دانستن اینکه کد بررسی می‌شود، دقیق‌تر می‌نویسد).

نقطه مقابل code review blind commit است: توسعه‌دهنده تغییرات را بدون ریویو به شاخه مشترک می‌فرستد. این رویکرد فقط در پروژه‌های تک‌کاربره یا برای hotfixهای فوری با ریویوی بعدی مجاز است. در توسعه حرفه‌ای تیمی، code review مرحله الزامی برای هر تغییری است، از جمله اصلاحات مستندات و پیکربندی.

در code review چه چیزی بررسی می‌شود

Code review باید سیستماتیک باشد، نه تصادفی. بازبین‌های با تجربه کد را به ترتیب مشخصی بررسی می‌کنند: اول معماری و منطق، بعد تست‌ها، سپس امنیت و کارایی، و در آخر — سبک و نام‌گذاری. این ترتیب تضمین می‌کند که مشکلات بحرانی قبل از خسته شدن بازبین دیده می‌شوند.

معماری و منطق: آیا کد مسئله را حل می‌کند، آیا انتزاع‌های اضافی وجود دارد، آیا اصول SOLID و DRY رعایت شده‌اند. کد پیچیده‌ای که در اولین خواندن به سختی قابل درک است — نشانه نیاز به بازسازی است. بازبین باید مطمئن شود که کد دقیقاً همان کاری را انجام می‌دهد که در وظیفه مشخص شده و عوارض جانبی خارج از محدوده مسئولیت خود ندارد.

تست‌ها: آیا تست‌های جدید همه سناریوها را پوشش می‌دهند — مثبت، منفی، موارد مرزی. آیا تست‌های موجود پس از تغییرات پاس می‌شوند. آیا تست‌های flaky وجود دارند که ناپایدار هستند. امنیت: عدم وجود SQL injection، XSS، نشت داده‌های حساس از طریق logها یا پاسخ‌های API. کارایی: کارایی الگوریتم‌ها، درخواست‌های اضافی به پایگاه داده، نشت منابع.

• معماری — صحت راه‌حل، رعایت SOLID، عدم over-engineering.
• منطق — مدیریت همه سناریوها، از جمله خطاها و موارد مرزی.
• تست‌ها — پوشش تغییرات جدید، عدم شکستن تست‌های قدیمی.
• امنیت — injectionها، XSS، CSRF، نشت داده از طریق logها.
• کارایی — پیچیدگی الگوریتم‌ها، درخواست‌های N+1، نشت حافظه.

اندازه ریویو: چرا 400 خط حداکثر است

محدودیت اندازه PR — مهمترین معیار کارایی code review است. تحقیق Cisco (2015) و آزمایش‌های بعدی SmartBear و Google نشان داد: با حجم ریویو بیش از 400 خط، توانایی بازبین در تشخیص نقص‌ها به شدت کاهش می‌یابد. اگر PR بیش از 400 خط باشد، خطاها با احتمالی بیش از تصادفی تشخیص داده نمی‌شوند.

اندازه بهینه: 200-400 خط برای یک PR. این حجم را بازبین می‌تواند در 30-60 دقیقه بررسی کند و تمرکز خود را حفظ کند. Google بیش از 200 خط در یک دور ریویو با تمرکز کامل را توصیه نمی‌کند. اگر تغییرات بیشتر است — وظیفه باید به چند PR متوالی تقسیم شود که هر کدام تغییر منطقی کاملی را اعمال می‌کند.

زمان ریویو: در عرض 24 ساعت از لحظه ایجاد PR. اگر ریویو چند روز طول بکشد، زمینه وظیفه از دست می‌رود و نویسنده مجبور است زمان را برای بازیابی زمینه هنگام پاسخ به نظرات تلف کند. تیم‌هایی با فرهنگ بالای code review SLA برای ریویو تعیین می‌کنند: مثلاً 4 ساعت برای تغییرات بحرانی و 24 ساعت برای تغییرات معمولی.

چگونه نظرات ریویو را درست بنویسیم

لحن نظرات — برای کارایی code review بسیار مهم است. نظر «این نادرست است» واکنش دفاعی ایجاد می‌کند و اطلاعات مفیدی به نویسنده نمی‌دهد. بهترین فرمول‌بندی پرسش-پیشنهاد است: «نظرت در مورد این رویکرد چیست؟»، «اینجا ممکن است NPE رخ دهد اگر user == nil. شاید guard اضافه کنیم؟». سؤالات فشار کمتری وارد می‌کنند و بحث را تحریک می‌کنند.

ساختار یک نظر خوب شامل سه بخش است: چه چیزی اشتباه است، چرا مشکل است و چگونه اصلاح شود. مثال: «در این حلقه به دلیل contains تو در تو از O(n²) استفاده شده که ممکن است با 10k+ رکورد کند شود. سعی کن با Set برای جستجوی O(1) جایگزین کنی». چنین فرمول‌بندی همزمان مشکل را نشان می‌دهد، اهمیت آن را توضیح می‌دهد و راه‌حل پیشنهاد می‌کند — نویسنده نیازی به حدس زدن ندارد.

GitHub و GitLab از suggestions پشتیبانی می‌کنند — پیشنهادهای داخلی تغییرات کد. بازبین می‌تواند بنویسد: «```suggestion قبل از پردازش خطوط خالی را فیلتر کن```» — و نویسنده تغییر را با یک کلیک اعمال می‌کند. این کار اصلاحات کوچک را سرعت می‌بخشد و تعداد دورهای ریویو را کاهش می‌دهد. برای اصلاحات بزرگ بهتر است نظر کلی بنویسید تا بلوک‌های بزرگ را در suggestion قرار دهید.

# الگوی نظر خوب برای code review

# بد: «این کد نادرست است»
# خوب: «ممکن است داده‌ها را در پاسخ خالی از دست بدهیم.
#         If response.data == nil, the guard returns nil,
#         and user sees empty screen without error.
#         Maybe add a fallback error message?"

# سینتکس پیشنهاد GitHub:
# ```suggestion
# let result = try? parse(response, fallback: .defaultValue)
# ```

Workflow code review در تیم

Workflow مؤثر ریویو بر چهار مرحله استوار است. اول — نویسنده PR را آماده می‌کند: نام قابل فهم می‌نویسد (مثلاً «feat: add password reset screen»)، توضیح تغییرات، پیوند به وظیفه در رهگیر و دستورالعمل‌های تست را اضافه می‌کند. دوم — نویسنده بازبین‌ها را از طریق auto-assign (بر اساس CODEOWNERS) یا دستی تعیین می‌کند.

مرحله سوم — بازبین کد را بررسی می‌کند و نظرات می‌گذارد. چهارم — نویسنده اصلاحات را اعمال می‌کند، به نظرات پاسخ می‌دهد و درخواست ریویوی مجدد می‌کند. چرخه تا دریافت تأیید تکرار می‌شود. پس از تأیید، نویسنده merge را انجام می‌دهد (یا bot merge را انجام می‌دهد). خودکارسازی از طریق Mergify یا GitHub Auto-merge مرحله نهایی را سرعت می‌بخشد.

عنصر مهم workflow — مدیریت PRهای راکد. اگر PR بیش از 3 روز بدون ریویو بماند، فرآیند مسدود می‌شود. راه‌حل‌ها: چرخش بازبین‌ها (اگر بازبین تعیین‌شده در دسترس نیست)، اعلان‌ها از طریق Slack/Teams، محدودیت زمان ریویو (SLA). در برخی تیم‌ها، PR بدون ریویو بیش از 7 روز به طور خودکار بسته می‌شود و نویسنده پس از همگام‌سازی با main یک PR جدید ایجاد می‌کند.

• ایجاد PR — نام قابل فهم، توضیح، پیوند به وظیفه، تصاویر صفحه برای تغییرات UI.
• تعیین — auto-assign از طریق CODEOWNERS یا انتخاب دستی 1-2 بازبین.
• ریویو — بررسی به ترتیب: معماری ← منطق ← تست‌ها ← امنیت ← سبک.
• اصلاحات — نویسنده به همه نظرات پاسخ می‌دهد، blocking issues را اصلاح می‌کند، درخواست re-review می‌کند.
• Merge — پس از تأیید و CI سبز، نویسنده یا bot ادغام را انجام می‌دهد.

اشتباهات رایج code review

اشتباه اول — ریویوی سطحی. بازبین به طور گذرا diff را نگاه می‌کند، بدون درک منطق، و Approve را می‌زند. دلایل: PR بزرگ، deadline، خستگی. عواقب: باگ‌ها وارد تولید می‌شوند. راه‌حل: اگر زمان برای ریویوی باکیفیت ندارید — صادقانه بنویسید «امروز نمی‌توانم بررسی کنم، به فردا موکول کن» به جای تأیید رسمی.

اشتباه دوم — انتقاد بیش از حد (nitpicking). بازبین ده‌ها نظر درباره سبک قالب‌بندی، نام‌گذاری متغیرها، جزئیات پیش‌پاافتاده می‌گذارد. این باعث بی‌انگیزگی نویسنده و طولانی شدن ریویو می‌شود. راه‌حل: StyleGuide و linterها باید سبک را به طور خودکار بررسی کنند. انسان در ریویو منطق، معماری و امنیت را بررسی می‌کند.

اشتباه سوم — ریویو بدون سؤال. اگر بازبین فقط Request Changes و Approve می‌گذارد اما سؤالی نمی‌پرسد، فرصت یادگیری چیز جدید را از دست می‌دهد. بهترین نشانگر سلامت code review وجود بحث‌هایی است که در آن هر دو طرف چیز جدیدی یاد می‌گیرند. اگر ریویو مونولوگ یکی از شرکت‌کنندگان است — فرآیند خراب است.

• ریویوی سطحی — Approve بدون درک عمیق. راه‌حل: اگر وقت ندارید ریویو نکنید.
• Nitpicking — انتقاد از سبکی که توسط linter بررسی می‌شود. راه‌حل: style checks را خودکار کنید.
• ادراک شخصی — «من طور دیگری می‌نوشتم». راه‌حل: کد باید کار کند، نه اینکه بازبین را خوشحال کند.
• طولانی شدن — ریویو بیش از 24 ساعت. راه‌حل: SLA برای ریویو، escalation در صورت نقض.
• نادیده گرفتن زمینه — ریویو کد بدون درک وظیفه. راه‌حل: قبل از diff توضیحات PR را بخوانید.