ہم کب ریفیکٹر (Refactor) کریں اور کب دوبارہ لکھیں (Rewrite)، اس کا فیصلہ کیسے کرتے ہیں
ہر ڈویلپر کو اس لمحے کا سامنا کرنا پڑتا ہے۔
کوڈ بیس (codebase) سست ہے۔ فیچرز شامل کرنے میں بہت زیادہ وقت لگتا ہے۔ نئے آنے والے ملازمین کو سسٹم سمجھنے میں دشواری ہوتی ہے۔ آخر کار کوئی مکمل ری رائٹ (rewrite) کا مشورہ دیتا ہے۔
ٹیم عام طور پر دو گروہوں میں تقسیم ہو جاتی ہے۔ ایک گروہ نئے سرے سے شروع کرنا چاہتا ہے۔ دوسرا گروہ ماضی میں کیے گئے ری رائٹس کی ناکامی سے ڈرتا ہے۔ دونوں اطراف کے پاس ٹھوس دلائل ہوتے ہیں۔
ری رائٹ کوئی جادوئی حل نہیں ہے۔ اس میں اکثر منصوبہ بندی سے زیادہ وقت لگتا ہے۔ آپ کو ایک ہی وقت میں دو سسٹمز کو برقرار رکھنا پڑتا ہے۔ ہو سکتا ہے کہ آپ نئے ورژن میں بھی وہی غلطیاں دہرا دیں۔
ری رائٹ ان مخصوص حالات میں منطقی ہے:
• ڈیٹا ماڈل کاروبار کے لیے بنیادی طور پر غلط ہے۔ • ٹیکنالوجی پرانی ہو چکی ہے اور اس کے لیے کوئی سیکیورٹی اپ ڈیٹس نہیں ملتیں۔ • کاروباری ضروریات اتنی بدل چکی ہیں کہ اصل سسٹم اب غیر متعلقہ (obsolete) ہو چکا ہے۔ • موجودہ ٹیم میں کوئی بھی یہ نہیں سمجھتا کہ سسٹم کیسے کام کرتا ہے۔
اس کے باوجود، ایک دم سے سب کچھ تبدیل نہ کریں۔ 'strangler fig pattern' کا استعمال کریں۔ پرانے سسٹم کے ساتھ ساتھ نئے سسٹم کو ٹکڑوں میں تیار کریں۔
زیادہ تر وقت، آپ کو دراصل ریفیکٹرنگ (refactoring) کی ضرورت ہوتی ہے۔
ریفیکٹرنگ تب صحیح انتخاب ہے جب:
• آپ اب بھی فیچرز شامل کر سکتے ہیں، چاہے اس میں وقت زیادہ لگے۔ • ٹیم موجودہ کوڈ کو سمجھتی ہے۔ • پیچیدگی صرف مخصوص ماڈیولز تک محدود ہے۔ • کاروبار نئے فیچرز فراہم کرنا بند نہیں کر سکتا۔
انتخاب کرنے سے پہلے، یہ پوچھیں کہ کوڈ خراب کیوں ہوا۔
اگر مسئلہ ٹیکنیکل ڈیٹ (technical debt) ہے، تو بدترین حصوں کو ریفیکٹر کریں۔ اگر مسئلہ کوڈ ریویوز کی کمی یا ناقص کلچر ہے، تو ری رائٹ سے کوئی مدد نہیں ملے گی۔ آپ صرف پرانی عادات کے ساتھ ایک نیا گڑبڑ والا سسٹم بنا لیں گے۔
فیصلہ کرنے سے پہلے یہ سوالات پوچھیں:
• کیا ہم بدترین حصوں کو الگ سے ٹھیک کر سکتے ہیں؟ • کیا ڈیٹا ماڈل موجودہ کاروباری ضروریات کے مطابق ناکارہ ہے؟ • اگر ہم نئے سرے سے شروع کریں گے تو ہم کتنا علم یا تجربہ کھو دیں گے؟ • کیا کاروبار میں ایک طویل تبدیلی کے عمل کو سنبھالنے کے لیے استحکام ہے؟
نئے سرے سے شروع کرنا اچھا لگتا ہے۔ ری رائٹ کو مکمل کرنا مشکل حصہ ہے۔ زیادہ تر وقت، ایک منظم ریفیکٹرنگ پلان زیادہ محفوظ اور مؤثر ہوتا ہے۔
ماخذ: https://dev.to/daviefano/how-we-decide-when-to-refactor-and-when-to-rewrite-40pk