کوڈ ریویو — یہ کیا ہے، کوڈ ریویو اور PR جانچ کیسے کام کرتی ہے

کوڈ ریویو کیا ہے

کوڈ ریویو انضمام سے پہلے ساتھیوں کے ذریعہ کوڈ کی منظم جانچ ہے۔ Git کے سیاق و سباق میں، اس کا مطلب ہے: ایک ڈویلپر تبدیلیوں کے ساتھ ایک پل ریکویسٹ بناتا ہے، جائزہ لینے والوں کو مقرر کرتا ہے، اور وہ ڈیف کا مطالعہ کرتے ہیں، تبصرے چھوڑتے ہیں اور فیصلہ سناتے ہیں۔ ایک جائزہ لینے والا تبدیلی کی درخواست کر سکتا ہے، PR کی منظوری دے سکتا ہے یا عام تبصرہ چھوڑ سکتا ہے۔

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

کوڈ ریویو کے برعکس بلائنڈ کمٹ ہے: ایک ڈویلپر بغیر جائزہ کے مشترکہ شاخ میں تبدیلیاں دھکیلتا ہے۔ یہ نقطہ نظر صرف واحد ڈویلپر پروجیکٹس یا بعد میں جائزہ کے ساتھ فوری ہاٹ فکسس کے لیے قابل قبول ہے۔ پیشہ ورانہ ٹیم کی ترقی میں، کوڈ ریویو کسی بھی تبدیلی کے لیے لازمی مرحلہ ہے، بشمول دستاویزات اور کنفیگریشن اپ ڈیٹس۔

کوڈ ریویو میں کیا جانچنا ہے

کوڈ ریویو منظم ہونا چاہیے، افراتفری کا شکار نہیں۔ تجربہ کار جائزہ لینے والے ایک مخصوص ترتیب میں کوڈ کی جانچ کرتے ہیں: پہلے فن تعمیر اور منطق، پھر ٹیسٹ، پھر سیکیورٹی اور کارکردگی، اور صرف آخر میں — انداز اور نام رکھنا۔ یہ ترتیب اس بات کو یقینی بناتی ہے کہ جائزہ لینے والے کے تھکنے سے پہلے اہم مسائل دیکھے جائیں۔

فن تعمیر اور منطق: کیا کوڈ کام کو حل کرتا ہے، کیا ضرورت سے زیادہ تجرید ہیں، کیا SOLID اور DRY اصولوں پر عمل کیا گیا ہے؟ پیچیدہ کوڈ جو پہلی بار پڑھنے میں سمجھنا مشکل ہے اس بات کا اشارہ ہے کہ ری فیکٹرنگ کی ضرورت ہے۔ جائزہ لینے والے کو یقینی بنانا چاہیے کہ کوڈ بالکل وہی کرتا ہے جو کام بتاتا ہے اور اس کی ذمہ داری سے باہر کوئی ضمنی اثرات نہیں ہیں۔

ٹیسٹ: کیا نئے ٹیسٹ تمام منظرناموں کا احاطہ کرتے ہیں — مثبت، منفی، حدی معاملات۔ کیا تبدیلیوں کے بعد موجودہ ٹیسٹ پاس ہوتے ہیں؟ کیا کوئی غیر مستحکم ٹیسٹ ہیں جو متضاد طور پر ناکام ہوتے ہیں؟ سیکیورٹی: SQL انجیکشن، XSS، لاگز یا API جوابات کے ذریعے حساس ڈیٹا کے رساو کی عدم موجودگی۔ کارکردگی: الگورتھم کی کارکردگی، ضرورت سے زیادہ ڈیٹا بیس سوالات، وسائل کے رساو۔

• فن تعمیر — حل کی درستگی، SOLID کی تعمیل، اوور انجینئرنگ کی عدم موجودگی۔
• منطق — غلطیوں اور حدی معاملات سمیت تمام منظرناموں کی ہینڈلنگ۔
• ٹیسٹ — نئی تبدیلیوں کی کوریج، موجودہ ٹیسٹوں کا ٹوٹنا نہیں۔
• سیکیورٹی — انجیکشن، XSS، CSRF، لاگز کے ذریعے ڈیٹا کا رساو۔
• کارکردگی — الگورتھم کی پیچیدگی، N+1 سوالات، میموری کا رساو۔

ریویو کا سائز: کیوں 400 لائنیں زیادہ سے زیادہ ہیں

PR سائز کی حد کوڈ ریویو کی تاثیر کا سب سے اہم میٹرک ہے۔ Cisco (2015) کا ایک مطالعہ اور SmartBear اور Google کے بعد کے تجربات نے دکھایا کہ جب جائزے کا حجم 400 لائنوں سے تجاوز کر جاتا ہے، تو جائزہ لینے والے کی نقائص تلاش کرنے کی صلاحیت تیزی سے گر جاتی ہے۔ اگر PR 400 لائنوں سے تجاوز کرتا ہے، تو نقائص تصادفی امکان سے زیادہ نہیں پائے جاتے۔

بہترین سائز: فی PR 200–400 لائنیں. اس حجم کا جائزہ 30–60 منٹ میں توجہ برقرار رکھتے ہوئے لیا جا سکتا ہے۔ Google مکمل توجہ کے ساتھ فی جائزہ دور میں 200 لائنوں سے زیادہ نہ کرنے کی سفارش کرتا ہے۔ اگر تبدیلیاں بڑی ہیں، تو کام کو کئی ترتیب وار PRs میں تقسیم کیا جانا چاہیے، ہر ایک منطقی طور پر مکمل تبدیلی پیش کرتا ہے۔

جائزے کا وقت: PR بنانے کے 24 گھنٹوں کے اندر۔ اگر جائزہ کئی دنوں تک کھینچتا ہے، تو کام کا سیاق و سباق کھو جاتا ہے، اور مصنف کو تبصروں کا جواب دیتے وقت سیاق و سباق بحال کرنے میں وقت گزارنا پڑتا ہے۔ مضبوط کوڈ ریویو کلچر والی ٹیمیں جائزے پر SLAs مقرر کرتی ہیں: مثال کے طور پر، اہم تبدیلیوں کے لیے 4 گھنٹے اور عام تبدیلیوں کے لیے 24 گھنٹے۔

اچھے ریویو تبصرے کیسے لکھیں

تبصروں کا لہجہ کوڈ ریویو کی تاثیر کے لیے انتہائی اہم ہے۔ “یہ غلط ہے” جیسا تبصرہ دفاعی ردعمل کا سبب بنتا ہے اور مصنف کو مفید معلومات فراہم نہیں کرتا۔ ایک بہتر تشکیل سوال-تجویز ہے: “آپ اس نقطہ نظر کے بارے میں کیا سوچتے ہیں؟”، “یہ user == nil ہونے پر NPE کا سبب بن سکتا ہے۔ شاید گارڈ شامل کریں؟”۔ سوالات کم تصادم والے ہوتے ہیں اور بحث کو تحریک دیتے ہیں۔

ایک اچھے تبصرے میں تین حصے شامل ہوتے ہیں: کیا غلط ہے، یہ مسئلہ کیوں ہے اور اسے کیسے ٹھیک کیا جائے۔ مثال: “یہ لوپ نیسٹڈ contains کی وجہ سے O(n²) استعمال کرتا ہے، جو 10k+ ریکارڈز کے ساتھ سست ہو سکتا ہے۔ O(1) تلاش کے لیے Set سے تبدیل کرنے کی کوشش کریں۔” یہ تشکیل بیک وقت مسئلے کی نشاندہی کرتی ہے، اس کی اہمیت کی وضاحت کرتی ہے اور حل تجویز کرتی ہے — مصنف کو اندازہ لگانے کی ضرورت نہیں۔

GitHub اور GitLab تجاویز کو سپورٹ کرتے ہیں — ان لائن کوڈ تبدیلی کی تجاویز۔ ایک جائزہ لینے والا لکھ سکتا ہے: “```suggestion Filter empty strings before processing```” اور مصنف ایک کلک سے تبدیلی لاگو کر سکتا ہے۔ یہ چھوٹی اصلاحات کو تیز کرتا ہے اور جائزے کے دوروں کی تعداد کو کم کرتا ہے۔ بڑی تبدیلیوں کے لیے، تجویز میں بڑے بلاکس شامل کرنے کے بجائے عام تبصرہ لکھنا بہتر ہے۔

# اچھے کوڈ ریویو تبصرے کا ٹیمپلیٹ

# برا: "This code is wrong"
# اچھا: "We may lose data on empty response.
#         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)
# ```

ٹیم میں کوڈ ریویو کا ورک فلو

ایک موثر جائزہ ورک فلو چار مراحل پر بنایا گیا ہے۔ پہلا — مصنف PR تیار کرتا ہے: ایک واضح عنوان لکھتا ہے (مثال کے طور پر، “feat: add password reset screen”)، تبدیلیوں کی تفصیل، ٹریکر میں کام کے لنکس اور جانچ کی ہدایات شامل کرتا ہے۔ دوسرا — مصنف آٹو اسائن (CODEOWNERS کی بنیاد پر) یا دستی طور پر جائزہ لینے والوں کو مقرر کرتا ہے۔

تیسرا مرحلہ — جائزہ لینے والا کوڈ چیک کرتا ہے اور تبصرے چھوڑتا ہے۔ چوتھا — مصنف اصلاحات کرتا ہے، تبصروں کا جواب دیتا ہے اور دوبارہ جائزے کی درخواست کرتا ہے۔ منظوری ملنے تک سائیکل دہرایا جاتا ہے۔ منظوری کے بعد، مصنف انضمام کرتا ہے (یا بوٹ کرتا ہے)۔ Mergify یا GitHub Auto-merge کے ذریعے آٹومیشن حتمی مرحلے کو تیز کرتا ہے۔

ورک فلو کا ایک اہم عنصر — پرانے PR کا نظم و نسق ہے۔ اگر PR 3 دن سے زیادہ جائزے کے بغیر رہتا ہے، تو عمل بلاک ہو جاتا ہے۔ حل: جائزہ لینے والوں کی گردش (اگر مقرر کردہ جائزہ لینے والا دستیاب نہیں ہے)، Slack/Teams کے ذریعے اطلاعات، جائزے کی وقت کی حد (SLA)۔ کچھ ٹیموں میں، 7 دن سے زیادہ جائزے کے بغیر PR خود بخود بند ہو جاتا ہے، اور مصنف main کے ساتھ مطابقت پذیری کے بعد نیا بناتا ہے۔

• PR بنانا — واضح عنوان، تفصیل، کام کے لنکس، UI تبدیلیوں کے لیے اسکرین شاٹس۔
• تقرری — CODEOWNERS کے ذریعے آٹو اسائن یا 1–2 جائزہ لینے والوں کا دستی انتخاب۔
• جائزہ — ترتیب میں جانچ: فن تعمیر → منطق → ٹیسٹ → سیکیورٹی → انداز۔
• اصلاحات — مصنف تمام تبصروں کا جواب دیتا ہے، مسائل کو حل کرتا ہے، دوبارہ جائزے کی درخواست کرتا ہے۔
• انضمام — منظوری اور سبز CI کے بعد، مصنف یا بوٹ انضمام کرتا ہے۔

کوڈ ریویو کی عام غلطیاں

پہلی غلطی — سطحی جائزہ۔ جائزہ لینے والا منطق میں گہرائی میں جانے کے بغیر ڈیف کو تیزی سے اسکین کرتا ہے اور منظوری پر کلک کرتا ہے۔ وجوہات: بڑا PR، آخری تاریخ، تھکاوٹ۔ نتائج: بگ پروڈکشن تک پہنچ جاتے ہیں۔ حل: اگر معیاری جائزے کے لیے وقت نہیں ہے تو — رسمی منظوری کے بجائے ایمانداری سے لکھیں “میں آج جائزہ نہیں لے سکتا، اسے کل تک ملتوی کریں”۔

دوسری غلطی — ضرورت سے زیادہ تنقید (نٹپکنگ)۔ جائزہ لینے والا فارمیٹنگ اسٹائل، متغیر کے ناموں، معمولی تفصیلات پر درجنوں تبصرے چھوڑتا ہے۔ یہ مصنف کی حوصلہ شکنی کرتا ہے اور جائزے کو طول دیتا ہے۔ حل: StyleGuide اور لنٹرز کو خود بخود اسٹائل چیک کرنا چاہیے۔ جائزے میں انسان منطق، فن تعمیر اور سیکیورٹی چیک کرتا ہے۔

تیسری غلطی — سوالوں کے بغیر جائزہ۔ اگر جائزہ لینے والا صرف Request Changes اور Approve پوسٹ کرتا ہے لیکن سوال نہیں پوچھتا، تو وہ کچھ نیا سیکھنے کا موقع کھو دیتا ہے۔ صحت مند کوڈ ریویو کا بہترین اشارہ گفتگو کی موجودگی ہے جس میں دونوں فریق کچھ نیا سیکھتے ہیں۔ اگر جائزہ ایک شریک کا یک گوئی ہے، تو عمل ٹوٹ گیا ہے۔

• سطحی جائزہ — گہرے تجزیے کے بغیر منظوری۔ حل: اگر وقت نہیں ہے تو جائزہ نہ لیں۔
• نٹپکنگ — اسٹائل کی تنقید جسے لنٹر سے چیک کیا جانا چاہیے۔ حل: اسٹائل چیک خودکار کریں۔
• ذاتی ترجیح — “میں اسے مختلف طریقے سے لکھتا”۔ حل: کوڈ کو کام کرنا چاہیے، جائزہ لینے والے کو خوش نہیں کرنا چاہیے۔
• تاخیر — 24 گھنٹے سے زیادہ جائزہ۔ حل: جائزے پر SLA، خلاف ورزی پر ایسکلیشن۔
• سیاق و سباق کو نظر انداز کرنا — کام کو سمجھے بغیر کوڈ کا جائزہ لینا۔ حل: ڈیف سے پہلے PR کی تفصیل پڑھیں۔