آپ کے PRs کے بڑا ہونے کی اصل وجہ
میں ایک ایسی کمپنی میں کام کرتا تھا جہاں عادت کے طور پر بہت بڑے pull requests بھیجے جاتے تھے۔ ایک PR ہفتوں تک کھلا رہ سکتا تھا۔ اس کا جائزہ لینے کے لیے پورے subsystem کو ذہن میں رکھنا ضروری ہوتا تھا۔ Bugs جمع ہوتے گئے۔ Deadlines نکلتی گئیں۔ آخر کار ہمیں سسٹم کا ایک بڑا حصہ دوبارہ بنانا پڑا کیونکہ اب کوئی بھی اسے حفاظت سے تبدیل نہیں کر سکتا تھا۔
انجینئرز برے نہیں تھے۔ وہ ذہین تھے اور سخت محنت کرتے تھے۔ PRs ایک بورنگ وجہ سے بڑے ہو جاتے تھے۔
کسی نے انہیں کام کو چھوٹے حصوں میں تقسیم کرنا نہیں سکھایا تھا۔
ہم اکثر بڑے PRs کو نظم و ضبط (discipline) کا مسئلہ سمجھتے ہیں۔ ہم کہتے ہیں، "بس چھوٹے PRs بنائیں۔" ہم ایسا برتاؤ کرتے ہیں جیسے 1,500 تبدیلیوں اور 150 تبدیلیوں کے درمیان واحد فرق صرف willpower ہو۔
یہ willpower کا معاملہ نہیں ہے۔ بڑے کام کو چھوٹے، آزادانہ حصوں میں تقسیم کرنا ایک مہارت ہے۔ زیادہ تر لوگوں کو یہ کبھی نہیں سکھایا جاتا۔ جب کوئی ticket کہتا ہے "add billing" تو یہ ایک واحد کام محسوس ہوتا ہے۔ یہ دیکھنا کہ ایک PR کہاں ختم ہوتا ہے اور اگلا کہاں سے شروع ہوتا ہے، اصل مشکل حصہ ہے۔
میں بھی بڑے PRs بھیجتا تھا۔ میں سمجھتا تھا کہ "done" کا مطلب ہے پورے مسئلے کو ایک ہی بار حل کرنا اور اسے review کے لیے بھیج دینا۔ یہ سیکھنے میں سال لگ گئے کہ چھوٹا ہونا بہتر ہے۔
چھوٹے PRs نے میرے لیے سب کچھ بدل دیا:
- Reviewers زیادہ bugs پکڑتے ہیں۔ ایک انسان 200 تبدیلیوں کا جائزہ لے سکتا ہے۔ وہ 2,000 تبدیلیوں کا جائزہ نہیں لے سکتا۔ وہ بس سرسری نظر ڈالتے ہیں اور approve کر دیتے ہیں۔
- Merges تیزی سے ہوتے ہیں۔ PRs queue میں پڑے نہیں رہتے۔
- میں نے خود کو بوجھ تلے دبا ہوا محسوس کرنا چھوڑ دیا۔ میں نے ایک وقت میں ایک ہی حصے پر توجہ دی۔
- میں ایک بہتر planner بن گیا۔ کام کو تقسیم کرنے کے لیے آپ کو اپنے کام کی نوعیت کو سمجھنا ضروری ہے۔
میں نے سسٹم کو Lego اینٹوں کے طور پر دیکھنا شروع کیا۔ یہ چھوٹے ٹکڑے ہیں جو آپس میں جڑ جاتے ہیں۔ ایک بار جب آپ ان اینٹوں کو دیکھ لیتے ہیں، تو کام کو تقسیم کرنا فطری محسوس ہوتا ہے۔
میری موجودہ ٹیم چھوٹے PRs بھیجتی ہے۔ نتائج واضح ہیں:
- ہمارا اوسط merge time 1.5 دن ہے۔
- ہم bugs کو تیزی سے تلاش اور ٹھیک کرتے ہیں کیونکہ تبدیلیاں واضح ہوتی ہیں۔
- ہماری delivery timing مستقل رہتی ہے۔
کام کو تقسیم کرنا ایک ایسی مہارت ہے جس کی تربیت (coach) کرنی چاہیے۔ آپ کسی اصول سے بڑے PRs کو ٹھیک نہیں کر سکتے۔ آپ انہیں لوگوں کو اینٹیں دیکھنا سکھا کر ٹھیک کرتے ہیں۔
AI اس مہارت کو مزید اہم بنا دیتا ہے۔
ماضی میں، 2,000 لائنوں کا کوڈ لکھنے میں بہت محنت لگتی تھی۔ اس friction نے PRs کو چھوٹا رکھا۔ AI نے اس friction کو ختم کر دیا ہے۔ آپ ایک ہی prompt سے بڑے پیمانے پر تبدیلیاں پیدا کر سکتے ہیں۔
محنت ختم نہیں ہوئی۔ یہ صرف reviewer کی طرف منتقل ہو گئی۔ لکھنے والا کچھ نہیں چکاتا، لیکن reviewer کو پوری قیمت ادا کرنی پڑتی ہے۔
اگر سائز اب اس بات کی علامت نہیں رہا کہ مصنف نے کتنا کام کیا ہے، تو سائز آپ کو خطرے کے بارے میں بہت کم معلومات فراہم کرتا ہے۔ آپ کو یہ فیصلہ کرنا ہوگا کہ کون سے حصے آپ کی سب سے زیادہ توجہ کے مستحق ہیں۔
اپنی ٹیم کو 'اینٹیں' دیکھنا سکھائیں۔ یہ انجینئرنگ میں سب سے زیادہ اثر انگیز عادت ہے۔
آپ کی ٹیم یہ کیسے فیصلہ کرتی ہے کہ کن PRs کو گہرائی سے ریویو کرنے کی ضرورت ہے اور کن کو جلدی منظور کیا جا سکتا ہے؟
Source: https://dev.to/pixel-wraith/the-real-reason-your-prs-get-big-5cm3
Optional learning community: https://t.me/GyaanSetuAi