2.19 ری فیکٹرنگ اور تکنیکی قرض

جائزہ اور محرکات

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

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

انٹرپرائز اور سرکاری ترتیبوں میں داؤ بڑھ جاتے ہیں۔ یہ نظام طویل العمر، اکثر دہائیوں پرانے، اور آڈٹ اور تبدیلی کے کنٹرول کے ایسے نظاموں کے تحت ہیں جو کوڈ کی کسی بھی تبدیلی کو منظم واقعہ سمجھتے ہیں۔ آپ شہریوں کے فوائد کے نظام کو لمبے ہفتہ وار تعطیل میں دوبارہ نہیں لکھ سکتے؛ آپ اسے چھوٹے، قابل واپسی، شواہد کی پشت پناہی والے قدموں میں جدید کرتے ہیں، جو ٹھیک وہی ہے جو نظم و ضبط والی ری فیکٹرنگ دیتی ہے۔ بہت سی ٹیموں اور طویل العمر نظاموں میں اس کام کی ہم آہنگی (باب 10.4) بڑے پیمانے کی انجینئرنگ کے تعریفی چیلنجوں میں سے ہے، اور اسے غلط کرنا ہی وہ طریقہ ہے جس سے ادارے منجمد ہو جاتے ہیں، اس سافٹ ویئر کو بدلنے سے قاصر جسے وہ اب نہیں سمجھتے۔

بنیادی اصول

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

سفارشات

ری فیکٹرنگ اور رویے کی تبدیلی کو سختی سے الگ رکھیں

شروع کرنے سے پہلے طے کریں کہ آپ کون سی کر رہے ہیں، اور ایک ہی کمٹ میں دونوں کو کبھی نہ ملائیں۔ جب آپ ری فیکٹر کرتے ہیں تو جو ٹیسٹ پہلے پاس ہوتے تھے وہ بعد میں، بغیر بدلے، پاس ہونے چاہییں، کیونکہ قابل مشاہدہ رویہ نہیں ہلا۔ جب آپ رویہ بدلتے ہیں تو وہ اپنے ٹیسٹوں کے ساتھ اپنے کمٹ میں کریں۔ وجہ عملی ہے: اگر ملی ہوئی تبدیلی کچھ توڑے تو آپ نہیں بتا سکتے کہ آپ کی تنظیم نو نے بگ پیدا کیا یا آپ کے رویے کی تبدیلی نے، اور کوڈ ریویو (باب 2.5) میں ریویور کسی بھی نصف پر صاف طور پر استدلال نہیں کر سکتا۔ جو عادت کام کرتی ہے وہ Martin Fowler کا دو ٹوپیوں کا اصول ہے: آپ ہمیشہ یا ری فیکٹرنگ کی ٹوپی پہنے ہوتے ہیں یا فیچر کی، آپ جانتے ہیں کون سی، اور آپ جان بوجھ کر بدلتے ہیں۔ الگ کمٹس ورژن کنٹرول کی تاریخ کو پڑھنے کے قابل بھی بناتے ہیں، تاکہ ناکامی کو دو حصے کر کے ڈھونڈنے والا انجینئر خالص ری فیکٹر کمٹس اعتماد سے چھوڑ سکے۔

تنظیم نو سے پہلے قابل بھروسہ حفاظتی جال قائم کریں

ٹیسٹ کے بغیر ری فیکٹرنگ بس ترمیم اور امید ہے۔ کسی بھی نتیجہ خیز چیز کی تنظیم نو سے پہلے آپ کو ایسا سوٹ چاہیے جس پر آپ بھروسہ کریں کہ اگر آپ رویہ بدل دیں تو وہ پکڑ لے گا، جو ٹیسٹنگ کی حکمت عملی (باب 2.4) کی بنیادی دلیل ہے۔ ایسے کوڈ کے لیے جس کی کوریج پہلے ہی اچھی ہے، ٹیسٹ چلائیں، چھوٹے قدموں میں ری فیکٹر کریں، اور ہر قدم کے بعد انہیں دوبارہ چلائیں۔ ایسے پرانے کوڈ کے لیے جس کے کوئی ٹیسٹ نہیں، ایماندار قدم پہلے خصوصیات متعین کرنے والے ٹیسٹ لکھنا ہے۔ خصوصیات متعین کرنے والا ٹیسٹ یہ دعویٰ نہیں کرتا کہ کوڈ کو کیا کرنا چاہیے؛ یہ گرفت میں لیتا ہے کہ کوڈ ابھی دراصل کیا کرتا ہے، اپنی عجیب حرکتوں سمیت، تاکہ رویے کی کوئی بھی تبدیلی ناکام ٹیسٹ کے طور پر ظاہر ہو۔ Michael Feathers نے ٹھیک اسی صورت حال کے لیے یہ طریقہ مقبول کیا جس میں بڑے ادارے رہتے ہیں: کوڈ جو کام کرتا ہے، اہم ہے، اور جس کے ٹیسٹ نہیں۔ ایک بار موجودہ رویہ پن ہو جائے تو آپ اس کے نیچے محفوظ طریقے سے ری فیکٹر کر سکتے ہیں، اور صرف تب اوپر رویہ بدل سکتے ہیں۔

کوڈ کی بو پہچاننا سیکھیں اور چھوٹی نام زد ری فیکٹرنگز لاگو کریں

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

موقع کے مطابق ری فیکٹرنگ کو ترجیح دیں، اور مہمیں حقیقی ساختی ضرورت کے لیے رکھیں

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

بڑی ساختی تبدیلی کے لیے اسٹرینگلر فِگ کا نمونہ استعمال کریں

جب پورے ذیلی نظام کو بدلنا ہو تو بڑے دھماکے والی دوبارہ تحریر کی کوشش نہ کریں جو ایک سال چلے اور آخر میں ضم ہو؛ اسی طرح جدید کاری کے منصوبے مرتے ہیں۔ اسٹرینگلر فِگ کا نمونہ استعمال کریں، جسے Martin Fowler نے اس بیل کے نام پر رکھا جو درخت کے گرد اگتی اور بتدریج اس کی جگہ لیتی ہے۔ آپ پرانے نظام کے سامنے سامنے کا حصہ رکھتے ہیں، فعلیت کا ایک ٹکڑا ایک وقت میں اس کے پیچھے نئے کوڈ کی طرف روٹ کرتے ہیں، پروڈکشن میں توثیق کرتے ہیں، اور دہراتے ہیں جب تک پرانا نظام پوری طرح گھر نہ جائے اور ہٹایا جا سکے۔ ہر ٹکڑا چھوٹا، بھیجنے کے قابل اور قابل واپسی ہے، اس لیے خطرہ محدود رہتا ہے اور قدر مسلسل آتی ہے۔ قریبی رشتہ دار، تجرید کے ذریعے شاخ، ایک ہی کوڈ بیس کے اندر یہی کرتا ہے: آپ اس چیز پر تجرید کی تہہ متعارف کراتے ہیں جسے بدلنا چاہتے ہیں، دونوں کے ساتھ رہتے ہوئے اس کے پیچھے نیا نفاذ بناتے ہیں، صارفین کو بتدریج منتقل کرتے ہیں، اور پرانا نفاذ تب حذف کرتے ہیں جب کوئی چیز اس پر منحصر نہ رہے۔ دونوں پرانے نظام کو زندہ رہتے ہوئے ارتقا کرنے دیتے ہیں، جو واحد قسم کی جدید کاری ہے جو زیادہ تر بڑے ادارے دراصل برداشت کر سکتے ہیں۔

تکنیکی قرض کو پورٹ فولیو سمجھیں، اور اسے نظر آنے والا بنائیں

قرض کا استعارہ، جو Ward Cunningham نے وضع کیا، دو چیزیں الگ کرتا ہے: اصل رقم (گندا کوڈ یا شارٹ کٹ خود) اور سود (وہ اضافی محنت جو ہر آئندہ تبدیلی اس کی وجہ سے ادا کرتی ہے)۔ تمام قرض برابر نہیں۔ Fowler کا چوکور اسے دو محوروں پر ترتیب دیتا ہے: جان بوجھ کر بمقابلہ اتفاقی، اور سمجھدار بمقابلہ لاپرواہ۔ سمجھدار-جان بوجھ کر قرض (“ہم ابھی ریلیز کرتے ہیں اور اگلے اسپرنٹ میں صفائی کرتے ہیں، اور ہمیں لاگت معلوم ہے”) جائز کاروباری فیصلہ ہے۔ لاپرواہ-اتفاقی قرض (“ڈیزائن پیٹرن کیا ہے؟”) محض نقصان ہے۔ انتظام کا کام، جو فیصلہ سازی اور نظم و نسق (باب 1.5) اور قرض کو پورٹ فولیو کے طور پر اس کے برتاؤ سے جڑتا ہے، قرض کو نظر آنے والا بنانا ہے تاکہ اس پر استدلال ہو سکے: جہاں کام رہتا ہے وہاں نمایاں مدیں ٹریک کریں، کوڈ ٹیگ کریں، اور وہ سود ریکارڈ کریں جو آپ ادا کر رہے ہیں تاکہ چکانا صلاحیت کے لیے سب سے اونچی آواز سے شکایت کرنے والے کی بجائے شواہد پر مقابلہ کرے۔ جس قرض کو آپ دیکھ نہیں سکتے اسے سنبھال نہیں سکتے۔

چکانے کو ہیروانہ کوشش کے بجائے مستحکم صلاحیت سے فنڈ کریں

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

اندرونی معیار ناپیں، مگر پیمانے کو ہدف نہ بننے دیں

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

جانیں کب ری فیکٹر نہیں کرنا

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

سمجھوتے: فوائد اور نقصانات

طریقہ	فوائد	نقصانات
موقع کے مطابق ری فیکٹرنگ (بوائے اسکاؤٹ کا اصول)	سستی، مسلسل، الگ بجٹ نہیں، وقت کے ساتھ مرکب ہوتی ہے	ناہموار کوریج؛ گرم فائلیں بہتر ہوتی ہیں جبکہ ٹھنڈی سڑتی ہیں
منصوبہ بند ری فیکٹرنگ مہم	وہ ساختی مسائل ٹھیک کرتی ہے جن تک صفائی نہیں پہنچ سکتی	مہنگی؛ فیچرز سے مقابلہ کرتی ہے؛ اچھے ٹیسٹ کے بغیر خطرناک
اسٹرینگلر فِگ / تجرید کے ذریعے شاخ	بتدریج، قابل واپسی، نظام کو زندہ رکھتی ہے، خطرہ محدود کرتی ہے	کاغذ پر دوبارہ تحریر سے سست؛ ختم کرنے کا نظم و ضبط چاہیے
بڑے دھماکے والی دوبارہ تحریر	صاف تختہ؛ کوئی پرانی پابندیاں نہیں	اعلیٰ ناکامی کی شرح؛ قدر تک پہنچنے میں لمبا وقت؛ رویے کے خلا
جان بوجھ کر سمجھدار قرض	قدر اب پہنچاتا ہے؛ واضح، منصوبہ بند ادائیگی	ادائیگی کبھی شیڈول نہ ہو تو لاپرواہ بن جاتا ہے
اشاریوں سے گیٹ شدہ معیار	معروضی، نظر آنے والا، بھٹکاؤ جلد پکڑتا ہے	کھیلنے کو دعوت دیتا ہے؛ باریکی کو سزا دیتا ہے؛ حقیقی معیار گھٹا سکتا ہے

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

اپنی ٹیم کے ساتھ بحث کے سوالات

ہم ری فیکٹرنگ اور رویے کی تبدیلی کو ایک ہی کمٹ میں گڈمڈ ہونے سے کیسے روکتے ہیں، اور کیا ہمارا ریویو واقعی اسے نافذ کرتا ہے؟ یہ پورے باب کا بنیادی نظم و ضبط ہے، اور وہ جسے ڈیڈ لائن کے دباؤ میں سب سے زیادہ توڑا جاتا ہے، کیونکہ “جب میں یہاں ہوں تو اسے صاف کر دوں” اور سب ساتھ ریلیز کر دینا کارآمد لگتا ہے۔ لاگت بعد میں آتی ہے: جب ملا ہوا کمٹ پروڈکشن توڑے تو کوئی نہیں بتا سکتا کہ تنظیم نو نے وجہ بنی یا فیچر نے، اور آپ کی تاریخ میں دو حصے کر کے ڈھونڈنا قابل بھروسہ نہیں رہتا۔ حالیہ چند پل ریکوئسٹس لائیں اور ایمانداری سے جانچیں کہ کتنی نے دونوں ٹوپیاں ملائیں۔ متصادم غور رگڑ ہے، کیونکہ کام کو الگ کمٹس میں تقسیم کرنا آگے تھوڑی زیادہ محنت ہے۔ جواب آپ کے کمٹ کے اصولوں اور ریویو کی چیک لسٹ کو شکل دے۔
ہمارا تکنیکی قرض کہاں ہے، ہم اس پر کتنا سود ادا کر رہے ہیں، اور کیا چکانا ہے یہ کون طے کرتا ہے؟ زیادہ تر ٹیمیں اس کا جواب نہیں دے سکتیں، جو اصل مسئلہ ہے، کیونکہ جس قرض کو آپ دیکھ نہیں سکتے وہ اس کی بنیاد پر سنبھالا جاتا ہے کہ کون سب سے زور سے شکایت کرتا ہے نہ کہ جہاں لاگت واقعی ہے۔ اسے نظر آنے والا بنانے کا مطلب نمایاں مدیں ٹریک کرنا، کوڈ ٹیگ کرنا، اور اس بارے میں شواہد جمع کرنا ہے کہ کون سے علاقے تبدیلیاں سست اور ناکامی کی طرف مائل بناتے ہیں۔ متصادم کھنچاؤ یہ ہے کہ چکانے پر خرچ ہوا ہر گھنٹہ فیچرز پر نہ خرچ ہونے والا گھنٹہ ہے، اس لیے فیصلہ قیادت کے ساتھ پورٹ فولیو کا فیصلہ ہونا چاہیے، جو آپ کے انجینئرنگ کے کام کو منظم کرنے کے طریقے (باب 1.5) سے جڑتا ہے۔ اپنی تبدیلی کی ناکامی کا ڈیٹا اور ان فائلوں کی فہرست لائیں جنہیں چھونے سے ہر کوئی ڈرتا ہے۔ جواب کو محفوظ، مستحکم چکانے کی صلاحیت بننا چاہیے، “جب حالات پرسکون ہوں تو صفائی کریں گے” کا مبہم ارادہ نہیں۔
ہمارے کوڈ بیس کے کن حصوں کو ہمیں جان بوجھ کر ری فیکٹر نہیں کرنا چاہیے، اور ہمیں کیسے معلوم ہوگا؟ ہر چیز کو ری فیکٹر کرنا اتنی ہی ناکامی ہے جتنا کچھ نہ کرنا، کیونکہ مستحکم، شاذ چھوئے، یا جلد ریٹائر ہونے والے کوڈ کی صفائی میں خرچ شدہ محنت ایسے قرض کا سود ہے جو آپ پر تھا ہی نہیں۔ فیصلے کا کام حقیقی ہے: ماڈیول بدصورت لگ سکتا ہے اور پھر بھی سرمایہ کاری کی غلط جگہ ہو سکتا ہے اگر اسے کبھی کوئی نہ بدلے۔ اپنی پیچیدگی کے اشاروں کے ساتھ تبدیلی کی تعدد کا ڈیٹا لائیں، کیونکہ اعلیٰ ہلچل اور اعلیٰ پیچیدگی کا سنگم وہ جگہ ہے جہاں صفائی مرکب ہوتی ہے، جبکہ کم ہلچل والا کوڈ عموماً چھوڑنا بہتر ہے۔ مقابل خطرہ یہ ہے کہ “ہم اسے چھوڑ دیں گے” مشکل کسی چیز کو کبھی نہ چھونے کا بہانہ بن جائے۔ جواب آپ کو سرمایہ کاری کے لائق گرم مقامات کی واضح مختصر فہرست اور پرسکون کونے نظر انداز کرنے کی اجازت دے۔
کیا ہم اپنے ٹیسٹ سوٹ پر اتنا بھروسہ کرتے ہیں کہ وہ کوڈ ری فیکٹر کریں جسے ہمیں سب سے زیادہ بدلنے کی ضرورت ہے، اور ہمیں پہلے کہاں خصوصیات متعین کرنے والے ٹیسٹ لکھنے پڑیں گے؟ جس حفاظتی جال پر آپ بھروسہ نہ کر سکیں وہ ری فیکٹرنگ کو ترمیم اور امید میں بدل دیتا ہے، اور بڑی ٹیم پر سب سے ڈراؤنا کوڈ عموماً سب سے کم ٹیسٹ شدہ ہوتا ہے، جو ٹھیک وہ جگہ ہے جہاں صفائی سب سے زیادہ ثمر دیتی۔ اپنے گرم مقامات کی کوریج اور تبدیلی کی ناکامی کا ڈیٹا لائیں، اور ایماندار رہیں کہ کون سے اہم ماڈیول آپ کو کوئی انتباہ نہ دیتے اگر تنظیم نو نے رویہ بدل دیا۔ متصادم غور یہ ہے کہ پرانے کوڈ کے لیے خصوصیات متعین کرنے والے ٹیسٹ لکھنا سست، بے رونق کام ہے جو کوئی فیچر نہیں بھیجتا، اس لیے اسے ہمیشہ کے لیے ٹالنا آسان ہے۔ آڈٹ اور تبدیلی کے کنٹرول کے تحت انٹرپرائز اور سرکاری نظاموں میں وہ پن شدہ ٹیسٹ اس بات کا ثبوت بھی ہیں کہ تبدیلی نے رویہ محفوظ رکھا، اس لیے انہیں فنڈ کرنا ایک ہی وقت میں حفاظت اور تعمیل کا اقدام ہے؛ جواب میں نام ہونا چاہیے کہ کن علاقوں کو کسی کے چھونے سے پہلے ٹیسٹ ہارنیس ملے گا۔
جب ذیلی نظام واقعی بدلنا ہو تو ہم بتدریج اسٹرینگلر فِگ طریقے اور دوبارہ تحریر کے درمیان کیسے فیصلہ کرتے ہیں، اور دوبارہ تحریر کو نہ کہنے کا اختیار کس کو ہے؟ بڑے دھماکے والی دوبارہ تحریر میز پر سب سے لبھانے والا اور سب سے ناکامی کی طرف مائل اختیار ہے، کیونکہ صاف تختہ ہمیشہ کاغذ پر پرانی پابندیوں کے ساتھ جینے سے سستا لگتا ہے۔ بڑے ادارے کے لیے بتدریج راستہ (سامنے کا حصہ، ایک وقت میں ایک ٹکڑا، پروڈکشن میں توثیق شدہ) نظام کو زندہ رکھتا اور خطرہ محدود کرتا ہے، مگر سست ہے، ختم کرنے کا نظم و ضبط مانگتا ہے، اور نئی شروعات کی بھوک سے مقابلہ کرتا ہے۔ ذیلی نظام کی تبدیلی کی تعدد کا نقشہ، اس کا ایماندار اندازہ کہ دوبارہ تحریر قدر پہنچانے سے پہلے کتنی چلے گی، اور رویے کے وہ خلا جو متوازی دوبارہ تحریر کو بند کرنے ہوں گے لائیں۔ حکومت اور ضابطے کے پابند ترتیبوں میں کئی سالہ دوبارہ تحریر جو آخر میں ضم ہو آڈٹ کے تحت شاذ ہی بچتی ہے، اس لیے جواب کو اسٹرینگلر فِگ یا تجرید کے ذریعے شاخ کی طرف ڈیفالٹ ہونا چاہیے اور کسی بھی دوبارہ تحریر کو ایسا استثنا سمجھنا چاہیے جس کے حق میں شواہد سے دلیل دینی ہو۔
ہم اندرونی معیار کے اشاریے قرض کے مرتکز ہونے کی جگہ ڈھونڈنے کے لیے کیسے استعمال کرتے ہیں بغیر اس کے کہ عدد ایسا ہدف بنے جس سے لوگ کھیلیں؟ پیچیدگی، نقل، کوریج، اور تبدیلی کی ناکامی کی شرح جیسے اشاریے بڑے ادارے کے لیے ایسے کوڈ کے پار دیکھنے کا واحد طریقہ ہیں جسے کوئی ایک شخص نہیں پڑھتا، پھر بھی جس لمحے کوئی ایک دروازے یا کارکردگی کے جائزے سے جڑ جائے، گڈہارٹ کا قانون سنبھال لیتا ہے اور عدد کچھ حقیقی ناپنا چھوڑ دیتا ہے۔ وہ مثالیں لائیں جہاں کوئی اشاریہ پہلے ہی رویے کو چلاتا ہے، اور پوچھیں کہ کیا وہ گفتگو شروع کر رہا ہے یا خاموشی سے ایسے ٹیسٹوں کو انعام دے رہا ہے جو کچھ دعویٰ نہیں کرتے اور حد سے بچنے کے لیے فنکشنز میں پھیلی منطق۔ متصادم کھنچاؤ یہ ہے کہ قیادت کو سادہ ڈیش بورڈ کا عدد چاہیے، اور “فہم استعمال کریں” سبز بار سے بیچنا مشکل ہے۔ انٹرپرائز اور سرکاری سیاق میں جہاں اشاریے نظم و نسق کی رپورٹنگ کو کھلاتے ہیں، واضح رہیں کہ معیار کے اشارے سرمایہ کاری کو آگاہ کرتے اور گرم مقامات ڈھونڈتے ہیں مگر افراد کو کبھی گیٹ نہیں کرتے؛ جواب کو سیکھنے کے لیے ناپنے اور پرکھنے کے لیے ناپنے کے بیچ پکی لکیر کھینچنی چاہیے۔

شعبہ جاتی نقطۂ نظر

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

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

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

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

مثالیں

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

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

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

کاروباری جواز: محرکات، ROI اور TCO

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

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

ضد نمونے اور خامیاں

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

پختگی کا ماڈل

سطح 1، آغاز: ری فیکٹرنگ فی البدیہہ اور ردعملی ہے، اکثر ایک ہی کمٹ میں رویے کی تبدیلی سے ملی ہوئی۔ کوئی قابل بھروسہ حفاظتی جال نہیں، تکنیکی قرض غیر مرئی اور غیر ٹریک شدہ ہے، اور صفائی صرف کبھی کبھار کے ہیروانہ جھونکوں میں ہوتی ہے یا بالکل نہیں۔
سطح 2، ترقی: کچھ ٹیمیں ری فیکٹرنگ کو رویے کی تبدیلی سے الگ کرتی ہیں اور جہاں موجود ہوں ٹیسٹوں پر انحصار کرتی ہیں، اور نام زد ری فیکٹرنگز اور خصوصیات متعین کرنے والے ٹیسٹ گوشوں میں ظاہر ہوتے ہیں۔ عمل ٹیموں میں غیر مستقل ہے، قرض پر بات ہوتی اور کبھی لاگ ہوتا ہے، اور چکانا فیچرز کے مقابل فی البدیہہ مقابلہ کرتا اور عموماً ہارتا ہے۔
سطح 3، معیار بندی: دو ٹوپیوں کا نظم و ضبط، پرانے کوڈ کے لیے خصوصیات متعین کرنے والے ٹیسٹ، اور چھوٹی نام زد ری فیکٹرنگز دستاویزی اور پورے ادارے میں متوقع ہیں۔ قرض مشترک رجسٹر میں ٹریک ہوتا ہے جو اصل رقم کو سود سے الگ کرتا ہے، اور چکانے کے لیے محفوظ صلاحیت ہر چکر میں منصوبہ بند اور ریویو میں نافذ ہوتی ہے۔
سطح 4، انتظام: قرض اور صفائی ڈیٹا سے بنیادی خطوط کے مقابل ناپے اور کنٹرول کیے جاتے ہیں۔ آپ گرم مقامات ڈھونڈنے کے لیے تبدیلی کی تعدد اور پیچیدگی ٹریک کرتے ہیں، ری فیکٹر شدہ علاقوں میں تبدیلی کی ناکامی کی شرح اور تبدیلی کے لیڈ ٹائم کو دیکھتے ہیں، اور ہر نمایاں مد کی لاگت کا سود ریکارڈ کرتے ہیں، اس لیے چکانے کے فیصلے شواہد پر ٹکے ہیں اور ختم کرنے یا سرمایہ لگانے کے فیصلے شکایت کے حجم کے بجائے رجحانات پر ہوتے ہیں۔ معیار کے اشارے سرمایہ کاری کو آگاہ کرتے ہیں بغیر ایسے دروازوں سے جڑے جن سے لوگ کھیل سکتے ہیں۔
سطح 5، ہم آہنگی: قرض کو پورے ادارے میں مصنوعات اور دیکھ بھال کی منصوبہ بندی سے مربوط مسلسل دوبارہ متوازن پورٹ فولیو کے طور پر سنبھالا جاتا ہے۔ ساختی تبدیلی معمول سے ٹیموں کے پار ہم آہنگ اسٹرینگلر فِگ اور تجرید کے ذریعے شاخ استعمال کرتی ہے، چکانا مسلسل ہے اور وہاں سے ملایا جاتا ہے جہاں تبدیلی بار بار اور تکلیف دہ ہے، اور نظام اور اس کے خطرے کی تصویر بدلنے کے ساتھ عمل ڈھلتا ہے، اس لیے طویل العمر کوڈ دہائیوں تک قابل تبدیل رہتا ہے۔

بحث کے لیے خیالات

ری فیکٹرنگ کو رویے کی تبدیلی سے الگ رکھنے کا آپ کی ٹیم کا اصل، نافذ شدہ اصول کیا ہے، اور ڈیڈ لائن کے دباؤ میں یہ کہاں ٹوٹتا ہے؟
آپ شواہد کے ساتھ کیسے طے کرتے ہیں کہ کون سا کوڈ صفائی کا مستحق ہے اور کون سا چھوڑنا بہتر ہے؟
خصوصیات متعین کرنے والے ٹیسٹ آپ کو کس پرانے علاقے کو محفوظ طریقے سے ری فیکٹر کرنے دیں گے جس سے آپ ابھی بچتے ہیں؟
اپنی اگلی بڑی جدید کاری کے لیے اسٹرینگلر فِگ طریقہ کیسا نظر آئے گا، اور آپ پہلے کون سا سامنے کا حصہ یا تجرید متعارف کرائیں گے؟
تکنیکی قرض کے رجسٹر کا مالک کون ہے، اور چکانا فیچر کے کام کے مقابل صلاحیت کیسے جیتتا ہے؟

اہم نکات

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

حوالہ جات اور مزید مطالعہ

Martin Fowler, Refactoring: Improving the Design of Existing Code, second edition
Michael Feathers, Working Effectively with Legacy Code
Ward Cunningham, The WyCash Portfolio Management System (OOPSLA 1992 experience report, origin of the debt metaphor)
Martin Fowler, “TechnicalDebtQuadrant” and “StranglerFigApplication” (martinfowler.com)
Kent Beck, Tidy First? A Personal Exercise in Empirical Software Design
Steve McConnell, Code Complete: A Practical Handbook of Software Construction
Robert C. Martin, Clean Code: A Handbook of Agile Software Craftsmanship