موبائل ڈویلپمنٹ میں تکنیکی قرض — جوہر، اقسام اور انتظام کے اصول

تکنیکی قرض کیا ہے

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

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

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

تکنیکی قرض کی اقسام

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

جان بوجھ کر اور غیر ارادی قرض

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

غیر ارادی قرض — وہ کوڈ جس کا معیار علم کی کمی، کوڈ کے جائزے کی عدم موجودگی یا خراب عمل کی وجہ سے توقع سے کم ہو۔ مثال: ایک ڈویلپر Room DB کے ساتھ کام کرنے کے بہترین طریقوں سے ناواقف تھا اور اس نے UI تھریڈ میں سوالیے لکھے، جس سے ANR پیدا ہوا۔ اس قسم کا قرض سب سے زیادہ مکار ہے — ٹیم کو اس کا اس وقت تک احساس نہیں ہوتا جب تک کہ انہیں کارکردگی کے سنگین مسائل کا سامنا نہ ہو۔

فن تعمیر اور کوڈ کا قرض

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

کوڈ کا قرض — ایک کلاس یا طریقہ کار کے اندر مقامی غیر بہترین پہلو۔ مثال: 200 سطروں والا ایک لمبا طریقہ جہاں UI، کاروباری منطق اور ڈیٹا پروسیسنگ مخلوط ہیں۔ Extract Method سے 15 منٹ میں درست ہو جاتا ہے۔ کوڈ کا قرض کم اہم ہے، لیکن پروجیکٹ کے پیمانے پر اس کا جمع ہونا ڈویلپمنٹ کو فن تعمیر کے قرض سے کم سست نہیں کرتا۔

جانچ اور دستاویزات کا قرض

جانچ کا قرض — یونٹ ٹیسٹ، UI ٹیسٹ یا انضمام ٹیسٹ کی کمی۔ ہر دستی رجریشن رن اس قرض پر سود ہے۔ اگر کسی پروجیکٹ میں خودکار ٹیسٹ نہیں ہیں، تو کسی بھی تبدیلی کے لیے گھنٹوں دستی جانچ کی ضرورت ہوتی ہے۔ Google Testing Blog کے مطابق، >70% ٹیسٹ کوریج والے پروجیکٹ پروڈکشن میں 2 گنا کم بگز جاری کرتے ہیں۔

دستاویزات کا قرض — فن تعمیر کی دستاویزات، پیچیدہ کوڈ والے علاقوں پر تبصرے، شمولیت کے لیے readme کی عدم موجودگی یا فرسودگی۔ دستاویزات کے بغیر ایک نیا ڈویلپر واقف ہونے میں ہفتے گزارتا ہے۔ حل: آرکیٹیکچر ڈیسیژن ریکارڈز (ADR) کو برقرار رکھنا اور دستاویزات کو ہر کام کے لیے تکمیل کی تعریف (Definition of Done) کا حصہ بنانا۔

تکنیکی قرض کیوں خطرناک ہے

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

مارکیٹ میں آنے میں تاخیر قرض کا براہ راست نتیجہ ہے۔ ٹیم دیکھ بھال پر زیادہ سے زیادہ وقت اور نئی خصوصیات پر کم وقت صرف کرتی ہے۔ Stripe (2023) کے ایک مطالعے سے پتہ چلا کہ ڈویلپرز کاروباری قدر پیدا کرنے کے بجائے تکنیکی قرض سے نمٹنے میں اوسطاً 17 گھنٹے فی ہفتہ صرف کرتے ہیں۔ موبائل ڈویلپمنٹ میں، یہ دو پلیٹ فارمز — ہر ایک اپنی پلیٹ فارم اپ ڈیٹس کے ساتھ — کی حمایت کرنے کی ضرورت سے مزید بڑھ جاتا ہے۔

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

تکنیکی قرض کا انتظام کیسے کریں

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

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

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

// بوائے اسکاؤٹ رول حکمت عملی عمل میں
// پہلے: جادوئی نمبروں والا ناقابل مطالعہ طریقہ
fun calc(a: Int): Int = a * 60 * 1000

// بعد: مستقل کے ساتھ قابل مطالعہ طریقہ
private const val SECONDS_IN_MINUTE = 60
private const val MILLIS_IN_SECOND = 1000

fun minutesToMillis(minutes: Int): Int =
    minutes * SECONDS_IN_MINUTE * MILLIS_IN_SECOND

آٹومیشن قرض کا پتہ لگانا انتظام کا تیسرا ستون ہے۔ لمبے طریقہ کار (>30 سطریں)، کلاسز (>500 سطریں)، ضر سے زیادہ نیسٹنگ (>5 سطحیں) کا پتہ لگانے کے لیے الرٹ ترتیب دیں۔ پل ریکویسٹ پر خودکار تبصروں کے لیے Danger یا اسی طرح کے اوزار استعمال کریں: اگر کوئی طریقہ کار پیچیدگی کی حد سے تجاوز کرتا ہے، تو بوٹ لکھتا ہے “اس طریقہ کار کی سائکلو میٹک پیچیدگی 12 ہے — براہ کرم اسے تقسیم کرنے پر غور کریں۔” آٹومیشن کوڈ کے جائزے کا بوجھ کم کرتی ہے۔

قرض کے تجزیہ کے اوزار

SonarQube تکنیکی قرض کے تجزیے کے لیے سب سے مقبول پلیٹ فارم ہے۔ یہ “درست کرنے کے دن” کا حساب لگاتا ہے — ایک میٹرک جو منتظمین کے لیے قابل فہم ہے۔ SonarQube Kotlin، Swift، Java، Python اور دیگر زبانوں کو سپورٹ کرتا ہے۔ یہ CI/CD پائپ لائن میں ضم ہوتا ہے اور اگر قرض حد سے بڑھ جائے تو پل ریکویسٹ کو مسترد کرتا ہے۔ موبائل ٹیموں کے لیے، یہ حقیقت میں معیار ہے۔

Android ٹیموں کے لیے Detekt (Kotlin جامد تجزیہ) اور Android Lint بھی استعمال ہوتے ہیں۔ Detekt کوڈ میٹرکس کا حساب لگاتا ہے اور Code Smell پیٹرن تلاش کرتا ہے۔ SonarQube Android Gradle پلگ ان نتائج کو ایک رپورٹ میں یکجا کرتا ہے۔ iOS ٹیموں کے لیے — جامد تجزیہ کے لیے SwiftLint اور غیر استعمال شدہ کوڈ تلاش کرنے کے لیے Periphery۔ Xcode Organizer کارکردگی کے میٹرکس دکھاتا ہے جو اکثر فن تعمیر کے قرض سے منسلک ہوتے ہیں۔

CodeClimate اور CodeFactor کلاؤڈ حل ہیں جو GitHub/GitLab ذخیروں کا تجزیہ کرتے ہیں اور قرض کی حرکیات دکھاتے ہیں۔ وہ ہر کمٹ کا جائزہ لیتے ہیں، جس سے یہ ٹریک کرنا ممکن ہوتا ہے کہ قرض کب بڑھنا شروع ہوا۔ برق رکھنے کی صلاحیت کا گراف انتظامیہ کے ساتھ بات چیت کے لیے ایک قابل فہم آلہ ہے: “مارچ میں چوٹی دیکھ رہے ہیں؟ یہ وہ وقت تھا جب ہم نے ریلیز میں تیزی لائی اور 3 دن کی اصلاح کا قرض جمع کیا۔”