Legacy Code وقت کے ساتھ ساتھ مزید خراب ہوتا جاتا ہے

لیگیسی کوڈ وقت کے ساتھ بہتر نہیں ہوتا، بلکہ یہ مزید خراب ہوتا جاتا ہے۔

گزشتہ ہفتے، میں نے ایک بگ (bug) کو ٹھیک کرنے میں تین گھنٹے صرف کیے۔ اسے صرف 20 منٹ لگنے چاہیے تھے۔ مسئلہ 2019 کا ایک ویلیڈیشن ماڈیول (validation module) تھا۔ ہر کسی نے اسے نظر انداز کر دیا کیونکہ "یہ کام کرتا ہے۔" لیکن یہ کام نہیں کر رہا تھا۔ مجھے فائل کے اندر 2020 کا ایک TODO کمنٹ ملا۔

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

یہ ایک برا چکر (cycle) پیدا کرتا ہے:

  • آپ کو ایک بکھرا ہوا پروجیکٹ ورثے میں ملتا ہے۔
  • آپ اپنے فیچر کو چلانے کے لیے ایک اور if statement شامل کر دیتے ہیں۔
  • چھ ماہ بعد، کوئی اور بھی یہی کرتا ہے۔
  • ایک سال بعد، فائل 800 لائنوں پر مشتمل ہوتی ہے اور اس میں کوئی ٹیسٹ نہیں ہوتا۔

اس "کام کرنے والے" کوڈ کے چھپے ہوئے نقصانات ہیں:

  • ڈویلپمنٹ کی رفتار کم ہو جاتی ہے۔ آپ کوڈ لکھنے کے بجائے سیاق و سباق (context) کو سمجھنے میں زیادہ وقت صرف کرتے ہیں۔
  • بگ (bugs) بڑھ جاتے ہیں۔ ایک چیز ٹھیک کرنے سے دوسری چیز خراب ہو جاتی ہے۔
  • آن بورڈنگ (onboarding) مشکل ہو جاتی ہے۔ نئے ڈویلپرز اس بات کو سمجھنے میں جدوجہد کرتے ہیں کہ منطق (logic) ہر جگہ کیوں دہرائی گئی ہے۔

ان خطرے کی علامات (red flags) پر نظر رکھیں:

  • بے کار یا غلط کمنٹس۔
  • مختلف فائلوں میں دہرائی گئی بزنس لاجک (business logic)۔
  • سرکولر ڈیپینڈنسیز (circular dependencies) اور ہائی کپلنگ (high coupling)۔

سب کچھ دوبارہ لکھنے کی کوشش نہ کریں۔ مکمل ری رائٹ (rewrite) 80% بار ناکام ہو جاتے ہیں۔ آپ ان چیزوں کو دوبارہ بنانے میں مہینوں صرف کر دیتے ہیں جو پہلے سے موجود ہیں، جبکہ بزنس نئے فیچرز کا انتظار کر رہا ہوتا ہے۔

کریکٹرائزیشن ٹیسٹ (characterization tests) کے ساتھ بتدریج ریفیکٹورنگ (incremental refactoring) کا استعمال کریں:

  • ٹیسٹ کے ذریعے موجودہ طرزِ عمل (behavior) کو محفوظ کریں، چاہے وہ عجیب ہی کیوں نہ ہو۔
  • اس طرزِ عمل کو تبدیل کیے بغیر ریفیکٹر (refactor) کریں۔
  • اسے اس وقت تک دہراتے رہیں جب تک کوڈ پڑھنے کے قابل نہ ہو جائے۔
  • اس کے بعد ہی اصل ٹیسٹ کے ذریعے طرزِ عمل کو تبدیل کریں۔

جال سے بچنے کے لیے ان اصولوں پر عمل کریں:

  • ٹیسٹ کے بغیر کبھی ریفیکٹر نہ کریں۔
  • ریفیکٹورنگ کے دوران طرزِ عمل تبدیل نہ کریں۔ ہو سکتا ہے کہ کوئی بگ کسی ایسی غیر دستاویزی فیچر (undocumented feature) کا حصہ ہو جس پر کلائنٹ انحصار کر رہا ہو۔
  • خاموش کوڈ کو ویسے ہی رہنے دیں۔ اگر کوئی ماڈیول تین سال سے نہیں بدلا اور کوئی مسئلہ پیدا نہیں کر رہا، تو اسے نہ چھیڑیں۔

اپنی توانائی اس کوڈ پر مرکوز کریں جسے آپ اکثر استعمال کرتے ہیں۔

Source: https://dev.to/taina_costa_f/legacy-code-nao-envelhece-como-vinho-quanto-mais-espera-pior-fica-132h