ایپ ڈویلپمنٹ میں میراث — یہ کیا ہے، خطرات اور حکمت عملی

ایپ ڈویلپمنٹ میں میراث کیا ہے

میراث — کوڈ یا نظام جو پروڈکشن میں چلتا رہتا ہے لیکن اب جدید معیار کے معیارات پر پورا نہیں اترتا۔ میراث کسی پرانی زبان میں لکھا جا سکتا ہے (مثال کے طور پر، Objective-C Swift کے بجائے)، غیر معاون لائبریریاں یا آرکیٹیکچرل پیٹرن استعمال کر سکتا ہے جو طویل عرصے سے اینٹی پیٹرن سمجھے جاتے ہیں۔

میراث کی اہم خصوصیت ٹیسٹوں کی عدم موجودگی ہے۔ Michael Feathers (2004) کی تعریف کے مطابق، میراث کوڈ وہ کوڈ ہے جس میں ٹیسٹ نہ ہوں۔ اگر آپ محفوظ طریقے سے رویہ تبدیل نہیں کر سکتے، تو نظام عمر سے قطع نظر میراث کی حالت میں ہے۔ یونٹ ٹیسٹ کے بغیر نیا کوڈ پہلے دن سے میراث ہے۔

میراث ضروری نہیں کہ برا ہو۔ Java 8 میں ایک اچھی طرح سے ڈیزائن کیا گیا نظام، coroutines کے ساتھ Kotlin میں بے ترتیب کوڈ سے زیادہ قابل اعتماد اور قابل فہم ہو سکتا ہے۔ کوڈ کی عمر معیار کا اشارہ نہیں ہے — اہم یہ ہے کہ نظام کو کتنی آسانی سے تبدیل اور بڑھایا جا سکتا ہے۔

میراث کوڈ کیوں معمول ہے

ہر کامیاب نظام وقت کے ساتھ میراث بن جاتا ہے۔ یہ ایک قدرتی عمل ہے: ٹیکنالوجی کوڈ کے دوبارہ لکھے جانے سے زیادہ تیزی سے ترقی کرتی ہے۔ 5 سال پہلے Swift 2 میں لکھی گئی ایپ آج میراث ہے، حالانکہ یہ تخلیق کے وقت جدید تھی۔

میراث کی کاروباری قدر کو اکثر کم سمجھا جاتا ہے۔ نظام قابل اعتماد طریقے سے کام کرتا ہے، لین دین پر کارروائی کرتا ہے، ڈیٹا ذخیرہ کرتا ہے — دوبارہ لکھنا خطرات رکھتا ہے۔ Standish Group (2024) کے مطابق، مکمل طور پر دوبارہ لکھنے کے 35% منصوبے ناکامی پر ختم ہوتے ہیں۔ معاشی طور پر میراث سے چھٹکارا حاصل کرنا نہیں، بلکہ اس کے ساتھ کام کرنا سیکھنا جائز ہے۔

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

میراث نظام کی اہم علامات

خودکار ٹیسٹوں کی کمی — اہم اشارہ۔ اگر ایک سطر تبدیل کرنے کے بعد ڈویلپر ٹیسٹ نہیں چلا سکتا اور تصدیق نہیں کر سکتا کہ کچھ نہیں ٹوٹا — آپ میراث کا سامنا کر رہے ہیں۔ اضافی علامت: تعیناتی کا عمل گھنٹے لیتا ہے اور دستی اقدامات کی ضرورت ہوتی ہے۔

دستاویزات کوڈ سے مماثل نہیں ہے — ایک اور علامت۔ آرکیٹیکچرل ڈایاگرام پرانے ہیں، تبصرے اس رویے کو بیان کرتے ہیں جو پہلے ہی بدل چکا ہے۔ نئے ڈویلپر کے لیے سیکھنے کا وقت ایک ماہ سے تجاوز کرتا ہے — اعلی پیچیدگی اور کم برقرار رکھنے کی صلاحیت کی علامت۔

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

نازک کوڈ کا رجحان — ایک جگہ تبدیلی تین دوسری جگہوں کو توڑ دیتی ہے۔ یہ مضبوط ربط کا نتیجہ ہے، جب ماڈیول ایک دوسرے کے بارے میں بہت زیادہ جانتے ہیں۔ ربط جتنا زیادہ ہوگا، نظام اتنی ہی تیزی سے میراث کے زمرے میں آتا ہے۔

پرانی کوڈ کے ساتھ کام کرنے کے خطرات

رفتار میں کمی — اہم خطرہ۔ ایک سادہ فیچر شامل کرنے میں کوڈ کے مطالعہ میں گھنٹے اور جانچ میں دن لگتے ہیں۔ Stripe (2024) کے مطابق، ڈویلپر اپنے 33% وقت تکنیکی قرض پر قابو پانے میں صرف کرتے ہیں، جس کا براہ راست تعلق پروجیکٹ میں میراث ماڈیولز کی موجودگی سے ہے۔

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

سیکیورٹی — پرانی لائبریریوں میں معلوم کمزوریاں ہوتی ہیں۔ Java پروجیکٹس میں OpenSSL 1.0.2 یا Jackson کے پرانے ورژن استعمال کرنا سیکیورٹی واقعات کا براہ راست راستہ ہے جو کاروبار کو ساکھ اور گاہکوں کی قیمت چکا سکتا ہے۔

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

میراث ری فیکٹرنگ کی حکمت عملی

Characterization tests — میراث کوڈ میں کسی بھی تبدیلی سے پہلے پہلا قدم۔ کوڈ کو معروف ان پٹ ڈیٹا پر چلائیں اور متوقع آؤٹ پٹ ریکارڈ کریں۔ یہ ٹیسٹ موجودہ رویے کو ایک وضاحت کے طور پر قید کرتے ہیں۔ Golden master testing ایک قسم ہے جہاں آؤٹ پٹ کا حوالہ فائل سے موازنہ کیا جاتا ہے۔

Seam تجزیہ — ان نکات کو تلاش کرنا جہاں رویہ تبدیل کیے بغیر ربط توڑا جا سکتا ہے۔ Michael Feathers کئی اقسام کے seams کی نشاندہی کرتا ہے: preprocessor seam، object seam، link seam۔ Object seam سب سے عام ہے: انٹرفیس کے ذریعے حقیقی آبجیکٹ کو ٹیسٹ سٹب سے تبدیل کرنا۔

Sprout method اور Sprout class — پرانے کوڈ کے اندر نہیں بلکہ اس کے ساتھ نیا کوڈ شامل کرنے کی تکنیکیں۔ موجودہ طریقہ کار میں ترمیم کرنے کے بجائے، مطلوبہ منطق کے ساتھ ایک نیا طریقہ بنائیں اور اسے پرانے سے کال کریں۔ اس سے کام کرنے والے کوڈ کے ٹوٹنے کا خطرہ کم سے کم ہوتا ہے۔

مثال: میراث میں لاگنگ شامل کرنا

class LegacyPaymentProcessor {
    def process(payment) {
        // میراث کوڈ کی 200 سطریں جنہیں نہیں چھونا چاہیے
        logPayment(payment) // sprout طریقہ
    }
    def logPayment(payment) {
        // میراث کے ساتھ شامل کیا گیا نیا کوڈ
    }
}

جدید ٹیکنالوجی اسٹیک کی طرف منتقلی

Strangler Fig پیٹرن — میراث کی منتقلی کے لیے تجویز کردہ طریقہ۔ ایک نیا ماڈیول متوازی طور پر بنایا جاتا ہے، ٹریفک آہستہ آہستہ پرانے سے نئے کی طرف منتقل کیا جاتا ہے۔ پرانا ماڈیول قدرتی طور پر ختم ہو جاتا ہے جب وہ درخواستیں وصول کرنا بند کر دیتا ہے۔ پیٹرن خطرات کو کم کرتا ہے اور مسائل کی صورت میں واپسی کی اجازت دیتا ہے۔

Branch by Abstraction — ایک تکنیک جہاں پرانے اور نئے نفاذ کے اوپر ایک تجرید بنایا جاتا ہے۔ کلائنٹ کوڈ تجرید پر منتقل ہو جاتا ہے اور پرانا نفاذ آہستہ آہستہ تبدیل کر دیا جاتا ہے۔ مثال: ایک متحد NetworkService پروٹوکول کے ذریعے نیٹ ورکنگ پرت کو AFNetworking سے Alamofire میں تبدیل کرنا۔

مرحلہ وار منتقلی — تبدیلی کو چھوٹے مراحل میں تقسیم کرنا: پرانے ماڈیول کو چھپائیں → ٹیسٹ لکھیں → نیا ماڈیول بنائیں → متوازی چلائیں → پرانا ماڈیول ہٹائیں۔ ہر مرحلہ ایک مستحکم نظام کی حالت پر ختم ہوتا ہے، جو کسی بھی وقت تعیناتی کی اجازت دیتا ہے۔