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 1970 کی دہائی میں IBM میں مرحلہ وار چیک لسٹ اور پروٹوکول کے ساتھ "ساختی معائنہ" کے طور پر سامنے آیا۔ 2000 کی دہائی میں، Git اور تقسیم شدہ ٹیموں کے پھیلاؤ کے ساتھ، جائزہ Pull Request کے ذریعے غیر متزامن شکل میں تبدیل ہوا۔ GitHub (2008) نے PR کو ایک مرکزی دھارے کی مشق بنا دیا۔ جدید Code Review ایک غیر رسمی، غیر متزامن عمل ہے جو بیوروکریسی کے بجائے رفتار اور سیکھنے پر مرکوز ہے۔

Code Review کی اقسام: رسمی اور غیر رسمی طریقے

Code Review کو عمل اور شرکت کی بنیاد پر چار اہم اقسام میں تقسیم کیا گیا ہے۔ رسمی (غیر متزامن جائزہ) — بغیر ہم وقت مواصلت کے MR/PR کے ذریعے جانچ، تقسیم شدہ ٹیموں میں سب سے عام۔ غیر رسمی — فوری CR، جب ایک ڈیولپر دوسرے کے پاس جاتا ہے اور 5 منٹ کے لیے کوڈ دیکھنے کو کہتا ہے۔

Microsoft Research، 2023 کے مطابق، جوڑی پروگرامنگ (Pair Programming) کا مطلب ہے کہ دو ڈیولپر ایک اسکرین پر کام کرتے ہیں، کوڈ کی ہر سطر حقیقی وقت میں "موقع پر" جائزے کے ساتھ لکھی جاتی ہے۔ اوور-دی-شولڈر — ایک ڈیولپر دوسرے کی اسکرین دیکھتا ہے اور بغیر کسی رسمی عمل کے کوڈ پر تبصرہ کرتا ہے۔ واک تھرو — کوڈ کا مصنف ڈیولپرز کے ایک گروپ کو تبدیلیوں کے ذریعے لے جاتا ہے، ہر فیصلے کی وضاحت کرتا ہے۔

Code Review چیک لسٹ: کوڈ میں کیا جانچیں

Code Review چیک لسٹ جائزہ لینے والے کو اہم پہلوؤں کو نظر انداز نہ کرنے میں مدد دیتی ہے۔ پہلا زمرہ — درستگی اور فن تعمیر: کیا حل کام سے مطابقت رکھتا ہے، کیا غیر ضروری پیچیدگی ہے، کیا پیٹرن صحیح طریقے سے منتخب کیے گئے ہیں (MVP، MVVM، Clean Architecture)؟ دوسرا زمرہ — اسٹائل اور فارمیٹنگ: کیا کوڈ ٹیم کے کوڈ اسٹائل (Kotlin Code Style، Swift Style Guide) پر عمل کرتا ہے؟

Thoughtbot Code Review Guide، 2024 کے مطابق، تیسرا بلاک — ٹیسٹ: کیا یونٹ ٹیسٹ لکھے گئے ہیں، کیا وہ حدودی معاملات کا احاطہ کرتے ہیں، کیا موجودہ ٹیسٹ پاس ہوتے ہیں؟ چوتھا — حفاظت: کیا کوئی ہارڈ کوڈڈ ٹوکن، API کلید، SQL انجکشن، میموری لیک نہیں ہیں؟ پانچواں — کارکردگی: کیا coroutines/RxJava صحیح استعمال ہوئے ہیں، کیا UI تھریڈ بلاک نہیں ہے، کیا ضرورت سے زیادہ مختص نہیں ہیں؟

• منطق — الگورتھم کی درستگی، حدودی معاملات اور غلطیوں کا انتظام
• فن تعمیر — Clean Architecture، MVVM کی پیروی، ذمہ داریوں کی علیحدگی
• کوڈ اسٹائل — نام بندی، فارمیٹنگ، پروجیکٹ کے ساتھ ہم آہنگی
• ٹیسٹ — یونٹ ٹیسٹ کی موجودگی، ان کی مکمل اور سبز حالت

Code Review کیسے کریں: جائزہ لینے والے کے لیے اصول

Code Review کے لیے جائزہ لینے والے کو باریک بینی اور رفتار کے درمیان توازن رکھنا ہوتا ہے۔ بنیادی اصول کوڈ کو چھوٹے حصوں میں جانچنا ہے۔ بہترین حجم — ایک سیشن میں 200–400 سطروں کی تبدیلیاں۔ Google Research (2022) کے مطابق، 500 سطروں سے زیادہ کا جائزہ تاثیر کھو دیتا ہے: چھوٹے ہوئے نقائص کی تعداد تبدیلی کے حجم کے ساتھ خطی طور پر بڑھتی ہے۔ دوسرا اصول — فن تعمیر سے شروع کریں، پھر منطق، پھر تفصیلات۔

SmartBear، 2025 کے مطابق، تبصرے مخصوص ہونے چاہئیں: "یہ برا ہے" نہیں بلکہ "یہ طریقہ SRP کی خلاف ورزی کرتا ہے — توثیق کی منطق کو علیحدہ کلاس میں نکالیں"۔ ہر تبصرہ بہتری کی تجویز ہے، تنقید نہیں۔ اگر کوڈ درست ہے لیکن اسٹائل جائزہ لینے والے کی ترجیحات سے مطابقت نہیں رکھتا — بغیر تبصرے کے چھوڑ دیں۔ جائزہ لینے والے کو درست حل کی منظوری دینی چاہیے چاہے وہ خود اسے مختلف طریقے سے لکھتا۔

Code Review کیسے حاصل کریں: مصنف کے لیے مشورے

Code Review حاصل کرنا کوڈ کا جائزہ لینے سے کم اہم مہارت نہیں ہے۔ مصنف کو تبصروں کے لیے کھلا ہونا چاہیے اور انہیں حل بہتر بنانے کے موقع کے طور پر دیکھنا چاہیے۔ پہلا اصول — تبصروں کو ذاتی تنقید نہ سمجھیں۔ Code Review کوڈ کی جانچ کرتا ہے، ڈیولپر کی نہیں۔ دوسرا — اگر تبصرہ واضح نہیں ہے تو فوری طور پر درست کرنے کے بجائے وضاحت طلب کریں۔

LeadDev، 2024 کے مطابق، جائزے کے لیے بھیجنے سے پہلے، مصنف کو اپنے کوڈ کی جانچ کرنی چاہیے: ٹیسٹ چلائیں، چیک لسٹ دیکھیں، یقینی بنائیں کہ کوئی ڈی بگ لاگ یا تبصرہ شدہ کوڈ نہیں ہے۔ MR/PR میں تبدیلیوں کے سیاق و سباق کے ساتھ واضح وضاحت ہونی چاہیے۔ وضاحت جتنی بہتر ہوگی، جائزہ اتنا ہی تیز اور نتیجہ خیز ہوگا۔

Code Review میں نفسیاتی حفاظت

Code Review کا ایک اہم پہلو ٹیم میں نفسیاتی حفاظت ہے۔ اگر ایک ڈیولپر سخت تنقید یا طنز سے ڈرتا ہے تو وہ مسائل پر بحث کرنے کے بجائے چھپائے گا۔ Google Project Aristotle (2017) نے دکھایا: اعلی نفسیاتی حفاظت والی ٹیمیں 25% زیادہ پیداواری ہوتی ہیں۔ اصول: کوڈ پر تنقید کریں، مصنف پر نہیں؛ الزام لگانے کے بجائے سوال پوچھیں؛ اچھے حلوں کے لیے شکریہ ادا کریں۔

مصنف کے لیے اہم اصول — تبصروں کو بند کرنے میں جلدی نہ کریں۔ اگر جائزہ لینے والے نے تبدیلیاں مانگی ہیں تو ان پر عمل کرنا چاہیے، نہ کہ صرف "ٹھیک ہے" کہہ کر بغیر درست کیے چھوڑ دینا۔ تصحیح کرنے کے بعد — دوبارہ جائزہ کی درخواست کریں۔ GitLab اور GitHub جائزہ لینے والے کو مطلع کرنے کے لیے Re-request Review کی حمایت کرتے ہیں۔

Code Review آٹومیشن: لنٹرز اور جامد تجزیہ

Code Review آٹومیشن رسمی اصولوں کی جانچ کو ختم کرکے ڈیولپرز پر بوجھ کم کرتا ہے۔ لنٹرز (ktlint، SwiftLint، ESLint) کوڈ اسٹائل، فارمیٹنگ اور بنیادی غلطیوں کی جانچ کرتے ہیں۔ جامد تجزیہ کار (Detekt، SonarQube، Infer) کوڈ کے انسانی جائزے تک پہنچنے سے پہلے ممکنہ بگز، میموری لیک اور حفاظتی مسائل تلاش کرتے ہیں۔

detekt Documentation، 2024 کے مطابق، CI/CD پائپ لائن میں، MR/PR بناتے وقت لنٹرز اور تجزیہ کار خود بخود چلتے ہیں۔ اگر جانچ ناکام ہوتی ہے تو MR ضم بٹن سے مسدود ہو جاتا ہے۔ یہ یقینی بناتا ہے کہ انسانی جائزے تک پہنچنے والا کوڈ پہلے ہی بنیادی جانچ پاس کر چکا ہے۔ جائزہ لینے والا فن تعمیر، منطق اور پڑھنے کی اہلیت پر توجہ دیتا ہے، خالی جگہوں اور حاشیہ بندی پر نہیں۔

// Android پروجیکٹ کے لیے detekt کنفیگریشن کی مثال
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 موازنہ، سطر کے تبصرے، تھریڈز، منظوری/تبدیلی کی درخواست کی حالتیں، CI/CD انضمام۔ ٹول کا انتخاب ٹیم کے سائز اور جائزہ پالیسی پر منحصر ہے۔

GitLab Docs، 2025 کے مطابق، بڑی ٹیموں (50+ ڈیولپرز) کے لیے، 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 — Mercurial/Git کے لیے Pull Requests، Diff تبصروں کے ساتھ Approvals
• Gerrit — سخت تصدیقی عمل، وزنی تشخیص، Jenkins انضمام

Code Review میں عام غلطیاں

Code Review میں غلطیاں اس کی تاثیر کو کم کرتی ہیں اور ٹیم کی حوصلہ شکنی کرتی ہیں۔ پہلی — ایک بار میں بہت بڑی مقدار میں تبدیلیوں کا جائزہ لینا۔ جب MR میں 2000+ سطریں ہوں تو جائزہ لینے والا 70% تک نقائص سے محروم رہ جاتا ہے۔ دوسری — کوڈ اسٹائل یا فن تعمیر پر مبنی نہ ہونے والے موضوعی تبصرے۔ "میں اسے مختلف طریقے سے لکھتا" جیسے بلا جواز تبصرے کوئی قدر نہیں رکھتے۔

Google Engineering Practices، 2024 کے مطابق، تیسری غلطی — ٹیسٹوں کو نظر انداز کرنا۔ اگر MR میں نئی فعالیت کے لیے ٹیسٹ شامل نہیں ہیں تو جائزہ لینے والے کو ان کی درخواست کرنی چاہیے، "بعد میں" کہہ کر منظور نہ کریں۔ چوتھی — دن یا سپرنٹ کے آخر میں جائزہ لینا جب توجہ بکھری ہوتی ہے۔ جائزے کے لیے بہترین وقت دن کا پہلا نصف ہے، جس میں بغیر کام تبدیل کیے 30–60 منٹ وقف کیے جائیں۔

جائزہ حفاظت — پانچویں عام غلطی: جائزہ لینے والے یہ نہیں چیک کرتے کہ کوڈ میں ہارڈ کوڈڈ راز، غیر محفوظ JavaScript WebView یا کمزور لائبریریاں تو نہیں ہیں۔ موبائل پروجیکٹس میں یہ اہم ہے: API کلید کا رساؤ پورے بیک اینڈ سے سمجھوتہ کر سکتا ہے۔

تقسیم شدہ ٹیموں میں Code Review

دور دراز ٹیموں کے لیے، Code Review علم کی منتقلی کا بنیادی ذریعہ ہے۔ واضح ڈیڈ لائن کے ساتھ MR کے ذریعے غیر متزامن فارمیٹ تجویز کیا جاتا ہے: جائزے کے لیے زیادہ سے زیادہ 24 گھنٹے۔ پیچیدہ تعمیری مباحثوں کے لیے اسکرین ریکارڈنگ (Loom) استعمال کریں۔ تقسیم شدہ ٹیموں میں، MR تبصروں میں فیصلوں کی تحریری دستاویزات خاص طور پر اہم ہے تاکہ ٹائم زون تبدیل ہونے پر سیاق و سباق ضائع نہ ہو۔