Code Review — ماهیت، قوانین و نحوه انجام بازبینی در تیم

Code Review چیست؟

Code Review — فرآیند بررسی کد منبع توسط یک یا چند توسعه‌دهنده قبل از ادغام آن در شاخه اصلی پروژه است. هدف بازبینی نه تنها یافتن خطاها، بلکه بهبود معماری، مطابقت با استانداردهای تیم و اشاعه دانش است. برخلاف تحلیل خودکار (لینترها)، بازبینی کد توسط انسان انجام می‌شود و خوانایی، منطق و تصمیمات معماری را ارزیابی می‌کند.

بر اساس Google Engineering Practices، 2024، Code Review به دو هدف هم‌ارز تقسیم می‌شود: حفاظت از پایگاه کد در برابر نقص‌ها و آموزش توسعه‌دهندگان از طریق بازخورد. در پروژه‌های موبایل، بازبینی الزاماً شامل بررسی فریم‌ورک‌ها (UIKit، SwiftUI، Jetpack Compose)، مدیریت حافظه و کار با درخواست‌های شبکه است.

Code Review در GitLab و GitHub از طریق Merge Request و Pull Request سازماندهی می‌شود. هر MR/PR شامل diff، نظرات روی خطوط، بحث‌ها و وضعیت بررسی‌ها است. طبق تحقیقات Microsoft Research (2023)، تیم‌هایی که بازبینی منظم انجام می‌دهند، 40% باگ‌های بحرانی کمتری به تولید منتشر می‌کنند.

تاریخچه Code Review: از بازرسی‌های رسمی تا PRهای ناهمگام

اولین Code Review رسمی در IBM در دهه 1970 به عنوان «بازرسی‌های ساختاریافته» با فهرست‌های گام‌به‌گام و پروتکل ظاهر شد. در دهه 2000 با گسترش Git و تیم‌های توزیع‌شده، بازبینی به فرمت ناهمگام از طریق Pull Request تکامل یافت. GitHub (2008) PR را به پدیده‌ای گسترده تبدیل کرد. Code Review مدرن فرآیندی غیررسمی و ناهمگام با تأکید بر سرعت و یادگیری است، نه بوروکراسی.

انواع Code Review: رویکردهای رسمی و غیررسمی

Code Review بسته به فرآیند و میزان مشارکت شرکت‌کنندگان به چهار نوع اصلی تقسیم می‌شود. رسمی (Asynchronous Review) — بررسی از طریق MR/PR بدون ارتباط همزمان، رایج‌ترین در تیم‌های توزیع‌شده. غیررسمی — quick CR، زمانی که یک توسعه‌دهنده به دیگری مراجعه کرده و درخواست بررسی کد در ۵ دقیقه می‌کند.

بر اساس Microsoft Research، 2023، برنامه‌نویسی جفتی (Pair Programming) — دو توسعه‌دهنده پشت یک صفحه کار می‌کنند، هر کد در زمان واقعی با بازبینی «در لحظه» نوشته می‌شود. Over-the-shoulder — یک توسعه‌دهنده به صفحه دیگری نگاه کرده و بدون فرآیند رسمی کد را نظر می‌دهد. Walkthrough — نویسنده کد گروهی از توسعه‌دهندگان را در تغییرات راهنمایی کرده و هر تصمیم را توضیح می‌دهد.

فهرست بازبینی Code Review: چه مواردی را در کد بررسی کنیم

فهرست بازبینی Code Review به بازبین کمک می‌کند جنبه‌های حیاتی را از دست ندهد. دسته اول — صحت و معماری: آیا راه‌حل با وظیفه محوله مطابقت دارد، آیا پیچیدگی اضافی وجود دارد، آیا الگوها (MVP، MVVM، Clean Architecture) به درستی انتخاب شده‌اند. دسته دوم — سبک و قالب‌بندی: آیا سبک کدنویسی تیم (Kotlin Code Style، Swift Style Guide) رعایت شده است.

بر اساس Thoughtbot Code Review Guide، 2024، بلوک سوم — تست: آیا تست‌های واحد نوشته شده‌اند، آیا موارد مرزی را پوشش می‌دهند، آیا تست‌های موجود را خراب نکرده‌اند. چهارم — امنیت: آیا توکن‌های هاردکد شده، کلیدهای API، تزریق SQL، نشت حافظه وجود دارد. پنجم — عملکرد: آیا کوروتین‌ها/RxJava به درستی استفاده شده‌اند، آیا مسدودسازی رشته UI، تخصیص‌های اضافی وجود دارد.

• منطق — صحت الگوریتم، مدیریت موارد مرزی و خطاها
• معماری — رعایت Clean Architecture، MVVM، جداسازی مسئولیت‌ها
• سبک کدنویسی — نام‌گذاری، قالب‌بندی، سازگاری با پروژه
• تست‌ها — وجود تست‌های واحد، کامل بودن و وضعیت سبز

نحوه انجام Code Review: قوانین برای بازبین

Code Review از بازبین تعادل بین دقت و سرعت را می‌طلبد. قانون اصلی — بررسی کد در بخش‌های کوچک. حجم بهینه — ۲۰۰–۴۰۰ خط تغییر در یک جلسه. بر اساس Google Research (2022)، بازبینی بیش از ۵۰۰ خط کارایی خود را از دست می‌دهد: تعداد نقص‌های نادیده گرفته شده با حجم تغییرات به صورت خطی افزایش می‌یابد. قانون دوم — از معماری شروع کنید، سپس منطق، سپس جزئیات.

بر اساس SmartBear، 2025، نظرات باید مشخص باشند: نه «این بد است»، بلکه «این متد SRP را نقض می‌کند — منطق اعتبارسنجی را به کلاس جداگانه منتقل کنید». هر نظر یک پیشنهاد برای بهبود است، نه انتقاد. اگر کد درست است اما سبک با ترجیحات بازبین مطابقت ندارد — بدون نظر بگذارید. بازبین باید راه‌حل صحیح را تأیید کند، حتی اگر خودش طور دیگری می‌نوشت.

نحوه پذیرش Code Review: نکاتی برای نویسنده

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

بر اساس LeadDev، 2024، قبل از ارسال برای بازبینی، نویسنده باید خود کد خود را بررسی کند: تست‌ها را اجرا کند، فهرست بازبینی را مرور کند، از نبود لاگ‌های اشکال‌زدایی و کد کامنت‌شده اطمینان حاصل کند. MR/PR باید شامل توضیحات قابل فهم با زمینه تغییرات باشد. هر چه توضیح بهتر باشد، بازبینی سریع‌تر و مؤثرتر انجام می‌شود.

ایمنی روانی در Code Review

جنبه کلیدی Code Review — ایمنی روانی در تیم است. اگر توسعه‌دهنده از دریافت انتقاد تند یا تمسخر بترسد، مشکلات را پنهان می‌کند به جای بحث درباره آنها. Google Project Aristotle (2017) نشان داد: تیم‌های با ایمنی روانی بالا ۲۵% مولدتر هستند. قوانین: کد را نقد کنید، نه نویسنده را؛ به جای اتهام سؤال بپرسید؛ برای راه‌حل‌های خوب تشکر کنید.

قانون کلیدی برای نویسنده — در بستن نظرات عجله نکنید. اگر بازبین تغییراتی درخواست کرده، باید اعمال شوند، نه اینکه پاسخ «باشه» بدهید و بدون اصلاح رها کنید. پس از اعمال اصلاحات — دوباره درخواست بازبینی کنید. GitLab و GitHub از Re-request Review برای اطلاع‌رسانی به بازبین پشتیبانی می‌کنند.

اتوماسیون Code Review: لینترها و تحلیل ایستا

اتوماسیون Code Review بار توسعه‌دهندگان را با حذف بررسی قوانین رسمی کاهش می‌دهد. لینترها (ktlint، SwiftLint، ESLint) سبک کدنویسی، قالب‌بندی و خطاهای پایه را بررسی می‌کنند. تحلیلگران ایستا (Detekt، SonarQube، Infer) باگ‌های بالقوه، نشت حافظه و مشکلات امنیتی را قبل از اینکه کد به بازبینی انسانی برسد، پیدا می‌کنند.

بر اساس مستندات detekt، 2024، در خط لوله CI/CD لینترها و تحلیلگران به طور خودکار هنگام ایجاد MR/PR اجرا می‌شوند. اگر بررسی ناموفق باشد — MR با دکمه Merge مسدود می‌شود. این تضمین می‌کند که کدی که به بازبینی انسانی می‌رسد، قبلاً بررسی پایه را گذرانده است. بازبین روی معماری، منطق و خوانایی تمرکز می‌کند، نه روی فاصله‌ها و تورفتگی‌ها.

// نمونه پیکربندی detekt برای پروژه Android
build.gradle.kts (app):

detekt {
    config = files("detekt-config.yml")
    buildUponDefaultConfig = true
    allRules = false
    autoCorrect = true
    debug = false
    parallel = true
}

tasks.named("preMerge") {
    dependsOn("detekt")
    dependsOn("ktlintCheck")
}

ابزارهای Code Review در پروژه‌های موبایل

ابزارهای Code Review در توسعه موبایل به دو دسته تقسیم می‌شوند: پلتفرمی (GitLab، GitHub، Bitbucket) و تخصصی (Gerrit، Reviewable، Crucible). GitLab و GitHub قابلیت داخلی ارائه می‌دهند: مقایسه diff، نظرات روی خطوط، بحث‌ها، وضعیت‌های Approve/Changes Requested، یکپارچگی با CI/CD. انتخاب ابزار به اندازه تیم و سیاست بازبینی بستگی دارد.

بر اساس مستندات GitLab، 2025، برای تیم‌های بزرگ (۵۰+ توسعه‌دهنده)، Gerrit کنترل سخت‌گیرانه‌تری فراهم می‌کند: تأیید اجباری از طریق CI قبل از ادغام، تأییدهای وزنی (Verified + Code-Review) و حقوق دسترسی دقیق. برای تیم‌های کوچک و متوسط GitLab و GitHub انتخاب بهینه هستند: پیکربندی Required Approvals، Code Owners و Merge Checks دقیقه‌ای انجام می‌شود.

• GitLab — Approvals، Code Owners، Merge Checks، MR Templates، CI/CD داخلی
• GitHub — Pull Requests، CODEOWNERS، Required Reviews، GitHub Actions
• Bitbucket — Pull Requests برای Mercurial/Git، Approvals با نظرات Diff
• Gerrit — فرآیند تأیید سخت‌گیرانه، ارزیابی‌های وزنی، یکپارچگی با Jenkins

اشتباهات رایج در Code Review

اشتباهات در Code Review کارایی آن را کاهش داده و تیم را بی‌انگیزه می‌کند. اولین — بررسی حجم بسیار زیاد تغییرات به یکباره. وقتی MR شامل ۲۰۰۰+ خط است، بازبین تا ۷۰% نقص‌ها را از دست می‌دهد. دوم — نظرات ذهنی که مبتنی بر سبک کدنویسی یا معماری نیستند. نظراتی مانند «من طور دیگری می‌نوشتم» بدون دلیل سودی ندارند.

بر اساس Google Engineering Practices، 2024، سومین اشتباه — نادیده گرفتن تست‌ها. اگر MR شامل تست‌های عملکرد جدید نباشد — بازبین باید آنها را درخواست کند، نه اینکه «برای بعد» تأیید کند. چهارم — بررسی در پایان روز یا اسپرینت، زمانی که توجه پراکنده است. بهترین زمان برای بازبینی — نیمه اول روز، با ۳۰–۶۰ دقیقه زمان اختصاصی بدون جابجایی بین وظایف.

ایمنی بازبینی — پنجمین اشتباه رایج: بازبینان بررسی نمی‌کنند که آیا در کد رازهای هاردکد شده، WebView با JavaScript باز، آسیب‌پذیری در کتابخانه‌ها وجود دارد. در پروژه‌های موبایل این حیاتی است: نشت کلید API می‌تواند به به خطر افتادن کل بک‌اند منجر شود.

Code Review در تیم‌های توزیع‌شده

برای تیم‌های دورکار، Code Review کانال اصلی انتقال دانش است. فرمت ناهمگام از طریق MR با مهلت‌های مشخص توصیه می‌شود: حداکثر ۲۴ ساعت برای بازبینی. برای بحث‌های معماری پیچیده از ضبط صفحه (Loom) استفاده کنید. در تیم‌های توزیع‌شده ثبت نوشتاری تصمیمات در نظرات MR بسیار مهم است تا زمینه با تغییر منطقه زمانی از دست نرود.