آپ یہ فیصلہ کیسے کرتے ہیں کہ کب کسی سسٹم کو refactor کریں بمقابلہ شروع سے دوبارہ لکھیں؟

Question

Accepted Answer

**refactoring** کو ڈیفالٹ بنائیں۔ ایک rewrite صرف اس وقت جائز ہے جب موجودہ سسٹم قابل قبول لاگت پر ضروریات کو پورا کرنے کے لیے مزید ترقی نہیں کر سکتا، اور آپ ایسا کرتے ہوئے قدر فراہم کرتے رہ سکتے ہیں۔ زیادہ تر "ہمیں rewrite کی ضرورت ہے" کی جبلتیں دراصل ایک غیر منظم tech-debt مسئلہ ہوتی ہیں جسے بتدریج refactoring بہت کم خطرے کے ساتھ حل کر دیتا ہے۔

## میں اس کے بارے میں کیسے سوچتا ہوں

- **کیا بنیادی architecture اب بھی قابل عمل ہے؟** اگر data model، حدود، اور runtime نئی ضروریات تک پھیل سکتے ہیں، تو refactor کریں۔ اگر بنیادی مفروضے غلط ہیں (غلط storage paradigm، scale کا کوئی طریقہ نہیں، language/platform کا end-of-life)، تو rewrite ایک حقیقی امیدوار بن جاتا ہے۔
- **تبدیلی کی تعدد کیا ہے؟** ایسا کوڈ جو شاذ و نادر ہی بدلتا ہے اسے خوبصورت ہونے کی ضرورت نہیں۔ کوشش وہاں مرکوز کریں جہاں ٹیم روزانہ کام کرتی ہے۔
- **کیا ہم موجودہ رویے کو سمجھتے ہیں؟** ایک rewrite برسوں کا انکوڈ شدہ edge-case علم پھینک دیتا ہے۔ اگر کوئی tests اور کوئی spec نہیں ہیں، تو rewrite پرانے bugs دوبارہ متعارف کرائے گا۔

## ایک فیصلہ سازی framework

| اشارہ | refactor کی طرف جھکیں | rewrite کی طرف جھکیں |
| --- | --- | --- |
| Architecture ضروریات کے مطابق ہے | ہاں | نہیں |
| Test/spec coverage | کم یا زیادہ | parity کی تصدیق کے لیے کافی زیادہ |
| بتدریج ship کر سکتے ہیں | ہاں | مشکل، big-bang |
| ٹیم کوڈ کو سمجھتی ہے | ہاں | نہیں، اور اصل مصنفین جا چکے |

## Trade-offs

- **Refactor:** کم خطرہ، مسلسل ڈلیوری، لیکن واقعی سڑی ہوئی بنیاد پر سست۔
- **Rewrite:** صاف سلیٹ، لیکن آپ **feature-freeze ٹیکس** ادا کرتے ہیں، **dual-maintenance لاگت** اٹھاتے ہیں، اور کلاسک second-system over-engineering کے جال کا خطرہ مول لیتے ہیں۔
- **strangler-fig** درمیانی راستے کو ترجیح دیں: نئے سسٹم کو پرانے کے ساتھ کھڑا کریں، traffic کو بتدریج route کریں، پرانے کو ٹکڑے ٹکڑے کر کے حذف کریں۔ یہ refactor-سطح کے خطرے کے ساتھ rewrite کے فوائد دیتا ہے۔

## نقصانات

- **جمالیات یا resume پر مبنی** وجوہات کے لیے rewrite کرنا، کاروباری لاگت کے لیے نہیں۔
- پوشیدہ رویے کو کم سمجھنا؛ ہمیشہ پہلے tests کے ساتھ موجودہ رویے کو characterize کریں۔
- ایک کئی سہ ماہیوں کا big-bang rewrite جو کچھ بھی ship نہیں کرتا — رفتار اور اعتماد دونوں منہدم ہو جاتے ہیں۔

## یہ کیوں اہم ہے

refactor بمقابلہ rewrite کا فیصلہ ایک Tech Lead کے سب سے زیادہ طاقتور فیصلوں میں سے ایک ہے۔ اسے rewrite کی طرف غلط کریں اور آپ ایک سال کے لیے ڈلیوری منجمد کر سکتے ہیں اور پھر بھی ناکام ہو سکتے ہیں؛ اسے refactor کی طرف غلط کریں اور آپ آہستہ آہستہ velocity کھوتے ہیں۔ اسے ذائقے کا فیصلہ نہیں بلکہ لاگت اور خطرہ کا فیصلہ پیش کرنا ہی وہ چیز ہے جو senior فیصلے کو ترجیح سے الگ کرتی ہے۔

اشارہ	refactor کی طرف جھکیں	rewrite کی طرف جھکیں
Architecture ضروریات کے مطابق ہے	ہاں	نہیں
Test/spec coverage	کم یا زیادہ	parity کی تصدیق کے لیے کافی زیادہ
بتدریج ship کر سکتے ہیں	ہاں	مشکل، big-bang
ٹیم کوڈ کو سمجھتی ہے	ہاں	نہیں، اور اصل مصنفین جا چکے