پروگرامنگ میں بیساکھیاں — یہ کیا ہیں، اسباب اور کب جائز ہیں

پروگرامنگ میں «بیساکھی» کیا ہے

بیساکھی (crutch) ایک سافٹ ویئر حل ہے جو کام کرتا ہے لیکن «جلد بازی میں» بنایا گیا ہے: یہ ایک مخصوص مسئلے کو حل کرتا ہے لیکن اس کی وجہ کو ختم نہیں کرتا، پروجیکٹ کے فن تعمیر کی پیروی نہیں کرتا، اور ماحول میں معمولی تبدیلیوں پر ٹوٹ سکتا ہے۔ تشبیہ درست ہے — حقیقی بیساکھی کی طرح، ایسا کوڈ «چلنے» میں مدد دیتا ہے لیکن «ٹانگ» کو ٹھیک نہیں کرتا۔

ڈیولپرز بگز، ورژن کی عدم مطابقت، پلیٹ فارم کی خصوصیات اور کلائنٹ کی فوری ضروریات کو «عارضی طور پر سہارا دیتے ہیں»۔ ایک عام بیساکھی مشروط بیساکھی ہے: اگر iOS 15 ہے تو پیڈنگ شامل کریں، اگر Huawei ہے تو بٹن چھپائیں۔ اس طرح کی جانچیں بڑھتی جاتی ہیں اور کوڈ کو پلیٹ فارم اور ورژن شاخوں کا «پرتوں والا کیک» بنا دیتی ہیں۔

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

بیساکھیاں کیوں ظاہر ہوتی ہیں: اسباب اور سیاق و سباق

بنیادی سبب بیساکھیوں کے ظاہر ہونے کا مثالی حل اور پروجیکٹ کی حقیقی رکاوٹوں کے درمیان تصادم ہے۔ ڈیولپر جانتا ہے کہ صحیح طریقے سے کیسے کرنا ہے، لیکن وقت، پیسہ یا تکنیکی حدود اسے روکتی ہیں۔ نتیجتاً، ایک سمجھوتہ حل پیدا ہوتا ہے جو «بس کام کرتا ہے»۔

آئیے چار اہم اسباب پر نظر ڈالتے ہیں جن کی وجہ سے ڈیولپرز شعوری طور پر بیساکھیوں کا سہارا لیتے ہیں۔ ان اسباب کو سمجھنے سے بیساکھیوں کو غلطی کے طور پر نہیں بلکہ ایک عملی آلے کے طور پر دیکھنے میں مدد ملتی ہے جسے منظم کرنے کی ضرورت ہے۔

ڈیڈلائنز

سب سے عام سبب۔ ریلیز کل ہے، بگ صرف ایک مخصوص ماڈل پر ظاہر ہوتا ہے، اور اسے معمارانہ طور پر ٹھیک کرنے میں دو ہفتے لگیں گے۔ ایک مشروط بیساکھی میں ایک گھنٹہ لگتا ہے اور مسئلہ حل ہو جاتا ہے۔ ریلیز کے بعد، ٹیم واپس آ کر صحیح طریقے سے دوبارہ لکھنے کا وعدہ کرتی ہے۔ «عارضی حل سے زیادہ مستقل کچھ نہیں» — یہ بالکل ایسی بیساکھیوں کے بارے میں ہے۔

ورژن کی عدم مطابقت

لائبریری A کو Android 12 کی ضرورت ہے، لیکن آپ کی ایپ Android 10 کو سپورٹ کرتی ہے۔ حل ایک ریپر لکھنا ہے جو OS ورژن چیک کرتا ہے اور عملدرآمد کا راستہ منتخب کرتا ہے۔ یہ ایک بیساکھی ہے کیونکہ لائبریری اپ ڈیٹ ہونے پر ریپر کو دوبارہ لکھنا ہوگا۔ لیکن متبادل — لائبریری یا پرانے آلات کی سپورٹ چھوڑنا — بدتر ہو سکتا ہے۔

// API 29 مطابقت کے لیے بیساکھی
if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.R) {
    useModernApi()
} else {
    useLegacyFallback()
}

بگ والے تیسرے فریق کے انحصار

ایک لائبریری جس پر پروجیکٹ منحصر ہے اس میں بگ ہے، لیکن اسے اپ ڈیٹ کرنے میں ہفتے لگ سکتے ہیں (PR، کوڈ ریویو، اشاعت درکار)۔ انتظار کرنے کے بجائے، ٹیم ایک ریپر لکھتی ہے جو لائبریری کے رویے کو فوری طور پر پیچ کرتا ہے۔ جب لائبریری کا تصحیح شدہ ورژن جاری ہوتا ہے، تو ریپر ہٹا دیا جاتا ہے۔ اگر نہ ہٹایا جائے تو یہ پہلے سے ہی ایک معمارانہ مسئلہ ہے۔

نظام کی نامکمل سمجھ

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

بیساکھی کب جائز ہے: عملی نقطہ نظر

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

جائز بیساکھی کے معیار: یہ کسی مخصوص مسئلے کو حل کرتی ہے، اس کا مالک ہے (اسے ہٹانے کا ذمہ دار کوئی)، اور ری فیکٹرنگ کا منصوبہ موجود ہے۔ اگر ان تین شرائط میں سے کم از کم ایک غائب ہو تو بیساکھی تکنیکی قرض میں بدل جاتی ہے۔ ٹریکر میں ٹکٹ کے ساتھ TODO تبصرے جیسے اوزار کم سے کم دستاویزکاری کا طریقہ ہیں۔

جائز بیساکھی کی مثال

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

// TODO: IT-1234 — AuthService ری فیکٹرنگ کے بعد یہ بیساکھی ہٹائیں
guard let userId = session.user?.id else {
    return Result.failure(.notAuthenticated)
}

عارضی بیساکھی کو معمارانہ مسئلے سے کیسے ممتاز کریں

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

بیساکھی کب مسئلہ بن جاتی ہے

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

بیساکھیوں کے بحران کی علامات

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

• ایک ہی بیساکھی تین یا زیادہ جگہوں پر دہرائی جاتی ہے — متحد حل بنانے کا وقت
• بیساکھی ہٹانے کے منصوبے کے بغیر تین سپرنٹ سے زیادہ زندہ رہتی ہے — یہ پہلے ہی تکنیکی قرض ہے
• نیا ڈیولپر نہیں سمجھتا کہ کوڈ اس طرح کیوں کام کرتا ہے — بیساکھی دستاویزی نہیں
• بیساکھی کو ہٹانے سے غلطیوں کا سلسلہ وار ردعمل پیدا ہوتا ہے — بیساکھی پر انحصار معمارانہ ہو گیا ہے

بیساکھیوں کا ری فیکٹرنگ: حکمت عملی اور عمل

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

ترجیحی حکمت عملی

اعلیٰ ترجیح — بار بار تبدیل ہونے والے ماڈیولز (کاروباری منطق، عام مقصد UI) میں بیساکھیاں جو ترقی کو سست کرتی ہیں اور رجعت کا سبب بنتی ہیں۔ درمیانی ترجیح — شاذ و نادر تبدیل ہونے والے ماڈیولز میں بیساکھیاں لیکن صارفین پر ممکنہ اثر کے ساتھ (ادائیگی کی پروسیسنگ، اجازت نامہ)۔ کم ترجیح — میراثی کوڈ میں بیساکھیاں جو مستحکم طور پر کام کرتا ہے اور ترمیم کے لیے منصوبہ بند نہیں ہے۔

قدم بہ قدم ہٹانے کا عمل

مرحلہ 1: انوینٹری — بیساکھیوں سے متعلق تمام TODO اور FIXME تلاش کریں۔ مرحلہ 2: تشخیص — طے کریں کہ کون سے اب بھی متعلقہ ہیں۔ مرحلہ 3: منصوبہ بندی — اعلیٰ ترجیح سے شروع کرتے ہوئے سپرنٹ میں بیساکھی ری فیکٹرنگ کا شیڈول بنائیں۔ مرحلہ 4: تبدیلی — صاف حل نافذ کریں، بیساکھی اور اس کا TODO تبصرہ ہٹائیں۔ مرحلہ 5: تصدیق — یقینی بنائیں کہ ٹیسٹ پاس ہوں اور کوئی رجعت نہ ہو۔

# پروجیکٹ میں تمام TODO بیساکھیاں تلاش کریں
grep -r "TODO\|FIXME\|HACK\|XXX" --include="*.kt" --include="*.swift" .

نئی بیساکھیوں کی روک تھام

بیساکھیوں سے لڑنے کا بہترین طریقہ انہیں غیر ضروری طور پر نہ بنانا ہے۔ بیساکھی لکھنے سے پہلے، اپنے آپ سے تین سوال پوچھیں: کیا میں معقول وقت میں صاف حل نافذ کر سکتا ہوں؟ کیا کوئی متبادل ہے جو بیساکھی نہ ہو؟ کیا ٹیم کے پاس واپس آ کر اسے دوبارہ لکھنے کا وقت ہوگا؟ اگر کم از کم ایک سوال کا جواب «نہیں» ہے — کوڈ کو «سہارا» دینے سے پہلے دوبارہ سوچیں۔