پی آر (PR) کھولیں، آپ کا ریویو کرنے والا ابھی تک اس سے واقف نہیں ہوا
میں نے حال ہی میں ایک بڑا پل ریکوسٹ (pull request) ریویو کیا۔ اس میں کوڈ لکھنے کے لیے AI کا استعمال کیا گیا تھا۔ اس نے ایک ایسے ماڈیول کو تبدیل کیا جسے تین دیگر فیچرز استعمال کر رہے تھے۔ اس کی تفصیل صرف ایک جملے پر مشتمل تھی۔ اس نے فائل کا نام تو بتایا لیکن تبدیلی کی وجہ نہیں بتائی۔
کام شروع کرنے سے پہلے میں نے تبدیلیوں کا نقشہ سمجھنے میں پندرہ منٹ صرف کیے۔ مجھے مقصد (intent) تلاش کرنا پڑا۔ مجھے خطرات (risks) تلاش کرنے پڑے۔ مجھے اہم فائلوں کو غیر ضروری معلومات (noise) سے الگ کرنا پڑا۔
مجھے احساس ہوا کہ میں نے پہلے بھی کسی اور کے ساتھ ایسا ہی کیا تھا۔
جب آپ کوڈ لکھتے ہیں، تو آپ کے پاس تمام سیاق و سباق (context) موجود ہوتا ہے۔ آپ جانتے ہیں کہ آپ نے ماڈیول کو کیوں تقسیم کیا۔ آپ جانتے ہیں کہ آپ نے پہلے کیا کوشش کی۔ آپ جانتے ہیں کہ کن حصوں کے بارے میں آپ غیر یقینی ہیں۔
زیادہ تر لوگ تفصیلات اپنے لیے لکھتے ہیں۔ وہ لکھتے ہیں "Refactored service layer" یا "Fixed auth module"۔ یہ ایسی تفصیلات ہیں جو ان لوگوں کے لیے ہیں جو پہلے سے سیاق و سباق سے واقف ہیں۔
ایک اچھی تفصیل اس شخص کے لیے ہوتی ہے جو کچھ نہیں جانتا۔
تفصیل محض ایک خلاصہ نہیں ہے۔ یہ ایک امتحان ہے۔ اگر آپ اپنے کام کی وضاحت نہیں کر سکتے، تو آپ کا کام تیار نہیں ہے۔
اب میں ہر اہم (non-trivial) PR کے لیے چھ حصوں پر مشتمل ایک ڈھانچہ استعمال کرتا ہوں:
• مقصد (Intent): وضاحت کریں کہ یہ PR کیوں موجود ہے اور یہ کس مسئلے کو حل کرتا ہے۔ اگر آپ یہ نہیں لکھ سکتے، تو رک جائیں۔ PR تیار نہیں ہے۔ • بڑی تبدیلیاں (Major changes): ان فیصلوں کی فہرست بنائیں جو آرکیٹیکچر یا موجودہ طرزِ عمل (behavior) کو متاثر کرتے ہیں۔ • چھوٹی تبدیلیاں (Minor changes): صفائی (cleanups) اور ناموں کی تبدیلی (renames) کی فہرست بنائیں۔ انہیں ساختی تبدیلیوں سے الگ رکھیں۔ • اثر (Impact): ان سسٹمز کی فہرست بنائیں جن پر اس کا اثر پڑے گا۔ اس کے اثر کے دائرہ کار (blast radius) کا نقشہ فراہم کریں۔ • ثبوت (Evidence): ان چیزوں کی فہرست بنائیں جو آپ نے چلائیں اور وہ ٹیسٹ جو آپ نے پاس کیے۔ ثبوت دکھائیں کہ آپ نے کام کیا ہے۔ • غیر یقینی صورتحال (Uncertainties): بتائیں کہ آپ کن چیزوں کے بارے میں غیر یقینی ہیں۔
جب آپ غیر یقینی صورتحال کا اعتراف کرتے ہیں، تو آپ ریویو کرنے والے کی مدد کرتے ہیں۔ انہیں معلوم ہوتا ہے کہ کہاں غور سے دیکھنا ہے۔ وہ ان حصوں پر وقت ضائع نہیں کرتے جو ٹھیک کام کر رہے ہیں۔
اگر آپ اپنی غیر یقینی صورتحال کا نام نہیں لے سکتے، تو اس کا مطلب ہے کہ آپ نے اپنے کوڈ کے بارے میں کافی گہرائی سے نہیں سوچا ہے۔
تفصیل وہ آخری قدم ہے جو آپ یہ فیصلہ کرنے سے پہلے اٹھاتے ہیں کہ آیا ایک PR کھولنا چاہیے بھی یا نہیں۔
ایک ریویو کرنے والا جو آپ کے مقصد کو سمجھتا ہے، وہ مشکل سوالات پر وقت صرف کرتا ہے۔ ایک ریویو کرنے والا جسے آپ کا مقصد اندازہ لگانا پڑتا ہے، وہ آسان سوالات پر وقت ضائع کرتا ہے۔ وہ یہ پوچھنے کے بجائے کہ کیا چیزیں درست ہیں، یہ پوچھتے ہیں کہ چیزیں کیا ہیں۔
اس ریویو کرنے والے کے لیے لکھیں جو ابھی آپ کے کوڈ سے واقف نہیں ہوا۔ ایسے لکھیں جیسے آپ سوالات کے جواب دینے کے لیے وہاں موجود نہیں ہوں گے۔ ایسے لکھیں جیسے آپ تین دن بعد اسے پڑھ رہے ہوں اور آپ کو کام کی کوئی یاد نہ ہو۔
اگر تفصیل برقرار رہتی ہے، تو PR تیار ہے۔
PR کھول دیں، آپ کا ریویو کرنے والا ابھی تک آپ سے نہیں ملا
آپ کئی دنوں سے ایک فیچر پر کام کر رہے ہیں۔ آپ نے کوڈ کی ہر لائن کو نکھارا ہے۔ آپ نے ٹیسٹ چلا لیے ہیں۔ آپ نے تمام ممکنہ حالات (edge cases) کو چیک کر لیا ہے۔ اور پھر بھی، آپ 'Create Pull Request' بٹن دبانے سے ہچکچا رہے ہیں۔
کیوں؟ کیونکہ آپ اس بات سے ڈرتے ہیں کہ ریویو کرنے والا کیا کہے گا۔ آپ کو ڈر ہے کہ وہ کوئی غلطی نکال لیں گے، یا آپ کو بتائیں گے کہ آپ کا طریقہ غلط ہے، یا کوئی بہتر طریقہ تجویز کریں گے جس سے آپ کا کام غیر پیشہ ورانہ لگنے لگے۔
لیکن حقیقت یہ ہے: آپ کا ریویو کرنے والا آپ کا جج نہیں ہے۔ وہ آپ کے ساتھی (collaborator) ہیں۔
آپ جتنی جلدی PR کھولیں گے، اتنی ہی جلدی آپ کو فیڈ بیک ملے گا۔ جتنی جلدی آپ کو فیڈ بیک ملے گا، اتنی ہی جلدی آپ چیزوں کو درست کر سکیں گے۔ جتنی جلدی آپ چیزوں کو درست کریں گے، اتنی ہی جلدی آپ اپنا کوڈ مرج (merge) کر سکیں گے۔
پرفیکشن ازم (Perfectionism) کا جال
ہر چیز کے مکمل (perfect) ہونے کا انتظار کرنا تاخیر کا باعث بنتا ہے۔ سافٹ ویئر ڈویلپمنٹ میں، پرفیکشن ایک ایسا ہدف ہے جو مسلسل بدلتا رہتا ہے۔ اگر آپ تب تک انتظار کریں گے جب تک آپ کو لگے کہ کوڈ "مکمل" ہے، تو آپ کبھی بھی اسے سبمٹ نہیں کر پائیں گے۔
آپ کا کوڈ کبھی بھی مکمل نہیں ہوتا۔ ہمیشہ کچھ نہ کچھ ایسا ہوگا جسے بہتر بنایا جا سکتا ہے یا کسی دوسرے طریقے سے لکھا جا سکتا ہے۔ لیکن اس کا مطلب یہ نہیں کہ آپ کو اسے سبمٹ کرنے سے پہلے ہر چیز کو مکمل کرنے کی ضرورت ہے۔
فیڈ بیک ایک تحفہ ہے
ریویو کرنے والے کے تبصرے آپ کی مہارت پر تنقید نہیں ہیں؛ بلکہ یہ سیکھنے اور بہتر ہونے کا ایک موقع ہیں۔ ایک اچھا ریویو کرنے والا آپ کو نہ صرف غلطیاں بتاتا ہے بلکہ آپ کو بہتر کوڈ لکھنے کے طریقے بھی سکھاتا ہے۔
اس لیے، زیادہ سوچنا بند کریں۔ بار بار نکھارنے (polishing) سے پرہیز کریں۔ PR کھول دیں۔
Source: https://dev.to/jeelvankhede/open-the-pr-your-reviewer-has-not-met-yet-4gfe
Optional learning community: https://t.me/GyaanSetuAi