2.21 ٹائپ سسٹمز اور اسٹیٹک تجزیہ

جائزہ اور محرکات

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

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

بڑی ٹیموں کے لیے قدر مرکب ہوتی ہے۔ جب سینکڑوں انجینئر مشترک نظام کو چھوتے ہیں تو ٹائپ کا دستخط معاہدہ ہے جسے کمپائلر ان سب پر نافذ کرتا ہے، اور پائپ لائن میں چیکر ایسا ریویور ہے جو کبھی نہیں تھکتا اور کبھی جانبداری نہیں کرتا۔ انٹرپرائز ترتیبوں میں یہ آن بورڈنگ اور انضمام کی لاگت گھٹاتا ہے، کیونکہ ٹائپس نیت دستاویزی کرتی ہیں اور تجزیہ کار وہ غلطیاں پکڑتے ہیں جو نئے آنے والے کرتے ہیں۔ حکومت اور دیگر اعلیٰ داؤ کے نظاموں میں، جہاں غلط جواب کسی فائدے سے محروم کر سکتا ہے یا ڈیٹا بے نقاب کر سکتا ہے، مشین سے جانچی ضمانتیں شہادت ہیں: وہ آڈیٹر کو دکھاتی ہیں کہ نقائص کی پوری اقسام ساخت کے اعتبار سے ناممکن ہیں، محض غیر ٹیسٹ شدہ نہیں۔ یہ براہ راست سافٹ ویئر کے معیار (باب 2.11) اور ایپلیکیشن سلامتی (باب 4.2) سے جڑتا ہے۔

بنیادی اصول

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

سفارشات

اسٹیٹک یا متحرک ٹائپنگ کھلی آنکھوں سے چنیں

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

دوسرے، آزاد محور کے بارے میں درست رہیں: مضبوط بمقابلہ کمزور ٹائپنگ۔ مضبوط ٹائپ والی زبان ناموافق ٹائپس کو خاموشی سے بدلنے سے انکار کرتی ہے (عدد کو سٹرنگ میں جوڑنا خرابی اٹھاتا ہے)؛ کمزور ٹائپ والی خاموشی سے بدل دیتی ہے، ایسے سرپرائز پیدا کرتی ہے جیسے "3" + 4 سے ایسی چیز نکلنا جو آپ نے نہ چاہی تھی۔ آپ کے پاس اسٹیٹک اور کمزور، یا متحرک اور مضبوط ہو سکتی ہے۔ جب آپ زبان جانچیں تو دونوں سوال الگ پوچھیں، کیونکہ لوگ جب “ٹائپ شدہ” کہتے ہیں تو اکثر دراصل “مضبوط” چاہتے ہیں۔

ٹائپس کو سستا رکھنے کے لیے ٹائپ کے استنباط پر انحصار کریں

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

غیر قانونی حالتوں کو ناقابل اظہار بنائیں

عملی ٹائپ ڈیزائن میں سب سے طاقتور خیال یہ ہے کہ اپنی ٹائپس کو یوں شکل دیں کہ غلط حالت لکھی ہی نہ جا سکے۔ اگر آرڈر یا تو “مسودہ” ہے بغیر ادائیگی کے یا “دیا گیا” ادائیگی کے ساتھ، تو اسے ایک ایسے struct کے طور پر ماڈل نہ کریں جس میں nullable فیلڈز ہوں جہاں مسودہ غلطی سے ادائیگی لے سکے اور دیا گیا آرڈر بغیر لے سکے۔ اسے مجموعی قسم (جسے ٹیگ شدہ یونین، امتیازی یونین، یا ویریئنٹ بھی کہتے ہیں) کے طور پر ماڈل کریں: ایسی قدر جو شکلوں کے مقررہ سیٹ میں سے ٹھیک ایک ہو، ہر ایک اپنا ڈیٹا اٹھائے۔ اب غلط امتزاج موجود ہی نہیں، اور قدر سنبھالنے والے کوڈ کو ہر صورت کا حساب رکھنا ہوگا ورنہ کمپائلر شکایت کرتا ہے۔ یہ رن ٹائم “کبھی نہیں ہونا چاہیے” کو کمپائل ٹائم “نہیں ہو سکتا” میں بدلتا ہے، جو پورا مقصد ہے۔

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

Nullability اور generics کو سنجیدگی سے لیں

Null پوائنٹر، جس کے موجد نے اسے اپنی “ارب ڈالر کی غلطی” کہا، سب سے عام طریقہ ہے جس سے اسٹیٹک ٹائپ سسٹم جھوٹ بولا کرتا تھا: سٹرنگ ٹائپ کی قدر خفیہ طور پر null ہو سکتی تھی، اور آپ کو کریش کر کے پتا چلتا۔ جدید ٹائپ سسٹم nullability کو واضح بنا کر اسے ٹھیک کرتے ہیں۔ قدر یا تو String ہے جو کبھی null نہیں، یا Option/Maybe/nullable قسم جسے آپ کو استعمال سے پہلے کھولنا ہوگا، اور کمپائلر آپ کو خالی صورت سنبھالنے پر مجبور کرتا ہے۔ اگر آپ کی زبان non-nullable ٹائپس یا optional قسم دے تو انہیں ہر جگہ استعمال کریں اور کھلے nullable کو بو سمجھیں۔ یہ پروڈکشن کریش کے پورے خاندان کو ہٹاتا ہے۔

جنرکس، جنہیں پیرامیٹرک پولی مارفزم بھی کہتے ہیں، آپ کو ٹائپ کی حفاظت چھوڑے بغیر بہت سی ٹائپس پر کام کرنے والا کوڈ لکھنے دیتے ہیں: List<T> کسی مخصوص ٹائپ T کی فہرست ہے، کمپائل کے وقت جانچی گئی، بغیر ٹائپ والی چیزوں کی فہرست کے جسے آپ کاسٹ کر کے دعا کریں۔ دوبارہ قابل استعمال کنٹینرز، فنکشنز، اور تجریدات بنانے کے لیے جنرکس تک پہنچیں جو مضبوطی سے ٹائپ شدہ رہیں۔ مجموعی اقسام، non-nullable ٹائپس، اور جنرکس کا جوڑ وہ ہے جو جدید ٹائپ سسٹم کو محض primitives کو ٹیگ کرنے کے بجائے حقیقی ڈومین کے اصول بیان کرنے دیتا ہے۔

موجودہ متحرک کوڈ میں ٹائپس بتدریج اپنائیں

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

لنٹرز، ٹائپ چیکرز، اور گہرے تجزیہ کار ساتھ چلائیں

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

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

انتباہات کو خرابیاں سمجھیں اور بنیادی خط کو رچیٹ کریں

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

ایڈیٹرز اور CI میں تجزیہ جوڑیں، تیز رائے کے ساتھ

اسٹیٹک تجزیہ سب سے زیادہ ثمر تب دیتا ہے جب رائے فوری ہو۔ وہی جانچیں ایڈیٹر میں Language Server Protocol یا مساوی کے ذریعے چلائیں تاکہ ڈویلپر خرابی ٹائپ کرتے ہی، محفوظ کرنے سے بھی پہلے، دیکھے۔ پھر یکساں اصولوں کا سیٹ مسلسل انضمام (CI) میں چلائیں تاکہ پاس ہوئے بغیر کچھ ضم نہ ہو، اسے باب 8.1 کی پائپ لائن سے جوڑتے ہوئے۔ دونوں کو متفق ہونا چاہیے: اگر ایڈیٹر نرم اور CI سخت ہو، یا الٹا، تو لوگ دونوں پر اعتماد کھو دیتے ہیں۔ تجزیہ کو اتنا تیز رکھیں کہ ہر تبدیلی پر چلے، نتائج کیش کریں، اور جہاں ممکن ہو صرف بدلے کا تجزیہ کریں تاکہ چیکر محصول کی جگہ مدد ہو۔ جب ایڈیٹر اور پائپ لائن وہی اصول اسی طرح نافذ کرتے ہیں تو معیار وہ دستاویز نہیں رہتا جسے لوگ بھول جائیں بلکہ ماحول کی خاصیت بن جاتا ہے۔

رسمی توثیق اس کوڈ کے لیے رکھیں جو اس کا جواز دے

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

دباؤ کو ایماندار رکھیں

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

سمجھوتے: فوائد اور نقصانات

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

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

اپنی ٹیم کے ساتھ بحث کے سوالات

ہمارے کوڈ بیس میں کہاں ٹائپ سسٹم ہمارے پچھلے کئی پروڈکشن واقعات روک دیتا، اور کیا ہم جانتے ہیں؟ زیادہ تر ٹیمیں ٹائپنگ پر تجریدی بحث کرتی ہیں جب شہادت ان کی اپنی واقعات کی تاریخ میں بیٹھی ہوتی ہے۔ پچھلے دس یا بیس پروڈکشن نقائص نکالیں اور ترتیب دیں: کتنے وہ null تھے جہاں قدر متوقع تھی، حد کے پار گزری غلط شکل، غیر سنبھالی صورت، تار کی طرح ٹائپ شدہ قدر جو بھٹک گئی؟ یہ ٹھیک وہ نقائص ہیں جو ٹائپ چیکر اور لنٹر مفت پکڑتے ہیں۔ اگر آپ کے واقعات کا بڑا حصہ اس خانے میں ہے تو آپ کے پاس ان ماڈیولز میں مضبوط ٹائپنگ کا ٹھوس، ڈالر میں ناپا دلیل ہے جہاں وہ ہوئے۔ اگر تقریباً کوئی نہیں تو آپ کے بگز کہیں اور ہیں (منطق، ہم زمانیت، تقاضے) اور بھاری ٹائپنگ آپ کا سب سے قیمتی قدم نہیں ہو سکتا۔ دونوں صورتوں میں آپ رائے کو ڈیٹا سے بدل دیتے ہیں۔
اگر ہم بتدریج ٹائپنگ اپناتے تو کہاں سے شروع کرتے، اور “کافی ہو گیا” کا کیا مطلب ہوتا؟ بڑے متحرک کوڈ بیس میں چیکر چالو کرنا پروگرام ہے، سوئچ پلٹنا نہیں، اور ترتیب طے کرتی ہے کہ یہ کامیاب ہوتا ہے یا رک جاتا ہے۔ بحث کریں کہ کن ماڈیولز میں سب سے زیادہ خطرہ ہے (پیسہ، تصدیق، بنیادی ڈیٹا ماڈل) اور اس لیے پہلے ٹائپس کے مستحق ہیں، بمقابلہ کون سے اتنے مستحکم اور کم داؤ کے ہیں کہ ابھی بغیر ٹائپ چھوڑے جا سکتے ہیں۔ نئے کوڈ کے لیے اصول پر اتفاق کریں (پہلے دن سے ٹائپ شدہ) تاکہ بغیر ٹائپ والی سطح بڑھنا بند کرے جبکہ آپ بیک لاگ کو تراشتے ہیں۔ ہدف متعین کریں: شاید ہر عوامی فنکشن کا دستخط ٹائپ شدہ، ہر حد ٹائپ میں توثیق شدہ، چیکر نازک پیکیجز پر سخت موڈ میں چلتا ہو۔ متعین ختم ہونے کی لکیر کے بغیر بتدریج ٹائپنگ دائمی اور آدھی ڈھکی ہو جاتی ہے، جو دونوں کا بدترین ہے۔
جب اسٹیٹک تجزیہ کار غلط ہو تو ہماری پالیسی کیا ہے، اور کیا وہ ٹول کو قابل بھروسہ رکھتی ہے؟ ہر تجزیہ کار جھوٹے مثبت پیدا کرتا ہے، اور آپ انہیں کیسے سنبھالتے ہیں یہ طے کرتا ہے کہ ٹول مفید رہتا ہے یا مایوسی میں بند کر دیا جاتا ہے۔ ٹھوس مثالوں پر بات کریں: جب نتیجہ حقیقی جھوٹا مثبت ہو تو کیا دباؤ تنگ، وجہ کے ساتھ تبصرہ شدہ، اور ریویو میں نظر آتا ہے، یا کوئی پوری ریپوزٹری کے لیے پورا اصول بند کر دیتا ہے؟ اپنے موجودہ دباؤ دیکھیں: کتنے ہیں، کیا ان کے جواز ہیں، اور آخری بار کب کسی نے ان کا آڈٹ کیا؟ بغیر وضاحت کے، وسیع دباؤ کا ڈھیر کا مطلب ہے کہ آپ کی کوریج خاموشی سے کھوکھلی ہے۔ ہدف مشترک، نافذ شدہ نظم و ضبط ہے جو تجزیہ کار کو معتبر رکھے، تاکہ اس کے نتائج پر بھروسہ ہو اور عمل کیا جائے بجائے اضطراری طور پر خاموش کیے جانے کے۔
ہم کن زبانوں اور تجزیہ کاروں کو معیاری بناتے ہیں، اور جب ہمارا اسٹیک ٹیموں کے پار بکھرے تو ایک اصولوں کا سیٹ کیسے رکھتے ہیں؟ جب سینکڑوں انجینئر کئی زبانوں میں کام کرتے ہیں تو ہر ٹیم کا اپنے چیکر، اپنے لنٹ کے اصول، اور اپنی سختی کی ترتیب کی طرف بہنا خاموشی سے ضمانت تباہ کرتا ہے، کیونکہ ایک ریپوزٹری میں نافذ معاہدہ اگلی میں محض مشورہ ہے۔ مقابل کھنچاؤ حقیقی ہے: مرکزی معیار بندی آپ کو قابل منتقلی انجینئر اور یکساں آڈٹ شہادت دیتی ہے، پھر بھی مرکز سے مسلط اصولوں کا سیٹ زبان کے محاوروں سے لڑ سکتا ہے یا اس ٹیم کو سست کر سکتا ہے جس کے پاس اپنی ترتیب کے اچھے اسباب تھے۔ پروڈکشن میں زبانوں کی فہرست، ہر ٹیم کے چلائے تجزیہ کار اور ورژنز، اور ان کے اصولوں کے سیٹوں کا فرق لائیں تاکہ بھٹکاؤ فرض کرنے کے بجائے نظر آئے۔ انٹرپرائز یا سرکاری ترتیب میں جواب کو خریداری اور آڈٹ سے جوڑیں: ایک ورژن کنٹرول شدہ ترتیب جو ہر ریپوزٹری وراثت میں پاتی ہے وہ ہے جو آڈیٹر کو تصدیق کرنے دیتی ہے کہ وہی جانچیں ہر جگہ چلیں، اور وہ ہے جو فراہم کنندہ کو آپ کے اپنے عملے کے لیے لازم اصولوں سے کمزور اصولوں کے تحت کوڈ بھیجنے سے روکتی ہے۔
ہمارا تجزیہ کتنا تیز ہے، اور کس مقام پر لوگ اس کے گرد راستہ ڈھونڈنے لگتے ہیں؟ چیکر تبھی ضمانت ہے جب وہ ہر تبدیلی پر چلے، اور جس لمحے وہ ترمیم-بلڈ کے چکر کو تکلیف دہ بنائے انجینئر اسے چھوڑنا، مقامی طور پر بند کرنا، یا سرخ حالت میں ضم کرنا اور بعد میں ٹھیک کرنے کا وعدہ کرنا سیکھ جاتے ہیں۔ کھنچاؤ گہرائی بمقابلہ رفتار ہے: گہرا ڈیٹا فلو یا سلامتی کا پاس وہ بگز ڈھونڈتا ہے جو تیز لنٹر چھوڑ دیتا ہے، مگر اگر پورا سوٹ بیس منٹ لے تو لوگ اس کا انتظار چھوڑ دیتے ہیں، اور جس جانچ کا کوئی انتظار نہ کرے وہ کچھ نہیں بچاتی۔ بحث میں حقیقی اعداد لائیں: ایڈیٹر کی رائے کی تاخیر، تجزیے کے مرحلے کے لیے CI کا دیوار گھڑی کا وقت، کیش کے ہٹ کی شرحیں، کتنی بار بلڈ جانچیں چھوڑ کر یا اووررائیڈ کر کے ضم ہوتے ہیں، اور رن کا کتنا حصہ اضافی بمقابلہ مکمل ہے۔ بڑے یا عوامی ادارے کے لیے کمپیوٹ کا بل اور تھرو پٹ کی لاگت شامل کریں، کیونکہ بیڑے کے پیمانے پر سست لازمی تجزیے کا مرحلہ بجٹ کی مد اور قطار دونوں ہے جو ہر ریلیز میں تاخیر کرتی ہے، اور ایماندار حل عموماً اصول خاموشی سے نرم کرنے کے بجائے اضافی تجزیہ اور کیشنگ ہے۔
ہم آڈیٹر کے لیے کون سی مشین سے جانچی شہادت پیش کر سکتے ہیں، اور ہمارے کون سے نازک عدم تغیرات کو یہ ڈھکتی ہے؟ ضابطے کے پابند اور اعلیٰ داؤ کے نظاموں میں ٹائپنگ اور اسٹیٹک تجزیے کا مقصد، روزمرہ کے بگز کو روکنے سے آگے، قابل مظاہرہ ثبوت ہے کہ نقائص کی پوری اقسام ساخت کے اعتبار سے ناممکن ہیں، اور یہ دعویٰ بے وقعت ہے اگر آپ نہ دکھا سکیں کہ کون سے عدم تغیرات نافذ ہیں اور کہاں۔ تجارت دائرہ کار بمقابلہ لاگت ہے: زیادہ ثابت کرنا (ہر جگہ non-nullability، ہر قانونی حالت کے لیے مجموعی اقسام، بنیادی حساب کی رسمی توثیق) مضبوط شہادت خریدتا ہے، پھر بھی سختی میں ہر قدم اوپر تشریح کی محنت، ماہر کا وقت، اور بلڈ کی پیچیدگی لاگت کرتا ہے جو شاید کم داؤ کے کوڈ پر آپ کو نہ چاہیے۔ اپنے حفاظت کے لیے نازک ماڈیولز کا نقشہ لائیں کہ ہر ایک کے پاس فی الحال کون سی ضمانتیں ہیں، کھلے دباؤ ان کے جوازوں کے ساتھ، اور وہ خلا جہاں نازک اصول کمپائلر کے بجائے رواج سے نافذ ہے۔ سرکاری یا ضابطے کے پابند انٹرپرائز کے لیے اسے تصدیق کی شہادت کے طور پر پیش کریں: آڈیٹر کو مطلوبہ خاصیت کا سراغ مشین سے جانچی ٹائپ یا ثبوت تک لگانے اور دباؤ کا لاگ دیکھنے کے قابل ہونا چاہیے جو ہر استثنا دستاویزی کرتا ہے، تاکہ تعمیل بعد از وقت دستی ریویو کے بجائے ٹول چین کے پیدا کردہ آرٹیفیکٹس پر ٹکے۔

شعبہ جاتی نقطۂ نظر

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

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

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

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

مثالیں

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

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

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

کاروباری جواز: محرکات، ROI اور TCO

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

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

ضد نمونے اور خامیاں

فرار کا دروازہ بطور عادت: چیکر کو چپ کرانے کے لیے any، dynamic، یا بغیر ٹائپ والے مساوی میں کاسٹ کرنا، جو ضمانت ٹھیک وہاں مٹاتا ہے جہاں آپ کو سب سے زیادہ چاہیے تھی۔
ہر چیز تار کی طرح ٹائپ شدہ: حدود کے پار کھلی سٹرنگز اور بغیر ٹائپ والے نقشے گزارنا بجائے حالتوں کو حقیقی ٹائپس کے طور پر ماڈل کرنے کے، اس لیے کمپائلر مدد نہیں کر سکتا۔
بذریعہ ڈیفالٹ nullable: جب زبان non-nullable اور optional ٹائپس دے تو قدریں nullable چھوڑنا، ارب ڈالر کی غلطی برقرار رکھتے ہوئے۔
انتباہات جو کبھی ناکام نہیں کرتے: ہزاروں برداشت شدہ انتباہات جن میں اہم والا غیر مرئی ہے، کیونکہ کچھ بلڈ نہیں توڑتا۔
ایڈیٹر اور CI اختلاف کرتے ہیں: مقامی طور پر نرم اور پائپ لائن میں سخت، یا الٹا، اس لیے ڈویلپر دونوں پر عدم اعتماد کرتے ہیں اور انضمام لوگوں کو حیران کرتے ہیں۔
وسیع دباؤ: ایک جائز نتیجے کے بجائے پورا اصول یا فائل بند کرنا، کوریج کو خاموشی سے کھوکھلا کرتے ہوئے۔
تجزیے کا تماشا: ایسے ٹول چلانا جن کے نتائج کوئی نہیں پڑھتا یا ان پر عمل نہیں کرتا، اس لیے رپورٹیں جمع ہوتی ہیں اور قدر صفر ہے۔
سب یا کچھ نہیں ٹائپنگ: شروع کرنے سے انکار کیونکہ آپ سب کچھ ایک ساتھ ٹائپ نہیں کر سکتے، نازک کوڈ پہلے ٹائپ کرنے کے بڑے فوائد سے محروم رہنا۔
ہر جگہ توثیق: عام کوڈ پر رسمی طریقوں تک پہنچنا، کم یاب ماہر کی محنت وہاں خرچ کرنا جہاں مضبوط ٹائپس کافی ہوتیں۔

پختگی کا ماڈل

سطح 1، آغاز: ٹائپنگ اور تجزیہ فی البدیہہ اور فی ڈویلپر ہیں۔ متحرک کوڈ کا کوئی چیکر نہیں، یا اسٹیٹک زبان انتباہات نظر انداز کر کے چلتی ہے۔ ٹائپ کی شکل کے بگز (nulls، غلط شکلیں، غیر سنبھالی صورتیں) باقاعدگی سے پروڈکشن تک پہنچتے ہیں، اور ری فیکٹرنگ سے ڈرا جاتا ہے کیونکہ کچھ درستگی کی توثیق نہیں کرتا۔
سطح 2، ترقی: لنٹر اور، جہاں متعلقہ ہو، ٹائپ چیکر کچھ پراجیکٹس پر چلتے ہیں، مگر اصول ٹیموں کے بیچ مختلف ہیں، انتباہات بلڈ ناکام نہیں کرتے، اور فرار کے دروازے اور وسیع دباؤ عام ہیں۔ کچھ فائدہ حاصل ہے، پھر بھی کوریج غیر مستقل اور ٹولز پر اعتماد ناہموار ہے۔
سطح 3، معیار بندی: مشترک، ورژن کنٹرول شدہ ترتیب پورے ادارے میں یکساں اصولوں کے ساتھ ایڈیٹر اور CI میں ٹائپ کی جانچ اور لنٹنگ نافذ کرتی ہے۔ انتباہات رچیٹ شدہ بنیادی خط کے ساتھ خرابیاں ہیں، nullability اور مجموعی اقسام حدود پر غیر قانونی حالتوں کو ناقابل اظہار بنانے کے لیے استعمال ہوتی ہیں، اور ہر دباؤ کو دستاویزی، قابل ریویو وجہ چاہیے۔
سطح 4، انتظام: تجزیہ بنیادی خطوط کے مقابل ناپا اور کنٹرول کیا جاتا ہے۔ نازک ماڈیولز پر ٹائپ کی کوریج، انتباہات کی گنتی، جھوٹے مثبت کی شرحیں، دباؤ کی گنتی، اور پروڈکشن کے واقعات کا حصہ جو چیکر پکڑ لیتا، سب واضح اہداف کے مقابل ٹریک ہوتے ہیں۔ اشاریے تبدیلی کو گیٹ کرتے ہیں: پیسے اور تصدیق کے کوڈ پر کوریج گر نہیں سکتی، جھوٹے مثبت کی بڑھتی شرح اصول کی دوبارہ کیلیبریشن چلاتی ہے، اور ڈیش بورڈ دکھاتے ہیں کہ ضمانتیں واقعی قائم ہیں نہ کہ محض ترتیب شدہ۔
سطح 5، ہم آہنگی: تجزیہ پورے ادارے میں مسلسل بہتر اور مربوط ہے۔ بتدریج ٹائپنگ نازک ماڈیولز تک پہنچ چکی ہے، ڈیٹا فلو اور سلامتی کے تجزیہ کار معمول سے چلتے ہیں، زبانوں اور خطرات کے ارتقا کے ساتھ اصول ڈھلتے ہیں، اور رسمی توثیق ان چند اجزا پر جان بوجھ کر لاگو ہوتی ہے جن کی ناکامی تباہ کن ہو۔ ٹولنگ، اشاریے، اور اصولوں کا سیٹ ڈیزائن، بھرتی، اور خریداری میں واپس کھلتے ہیں، اس لیے پورا ادارہ مسلسل بدلنے کے لیے محفوظ تر ہوتا ہے۔

بحث کے لیے خیالات

آپ کے حالیہ پروڈکشن بگز میں سے کون سے ٹائپ چیکر یا لنٹر پکڑ لیتا، اور وہ کل کا کتنا حصہ ہیں؟
آپ کے ڈومین ماڈل میں کہاں مجموعی قسم یا توثیق شدہ لپیٹنے والی قسم رن ٹائم “کبھی نہیں ہونا چاہیے” کو کمپائل ٹائم “نہیں ہو سکتا” میں بدل سکتی ہے؟
اگر آپ کل انتباہات کو خرابیاں بنا دیں تو کتنے بلڈ توڑیں گے، اور کون سا بنیادی خط اور رچیٹ آپ کو صفائی کی مہم کے بغیر پالیسی اپنانے دے گا؟
کیا آپ کا ایڈیٹر اور آپ کی پائپ لائن ٹھیک وہی اصول چلاتے ہیں، اور ڈویلپر کو کیسے پتا چلے گا کہ وہ الگ ہو گئے ہیں؟
ابھی آپ کے کوڈ بیس میں کتنے دباؤ ہیں، کتنوں کا جواز ہے، اور آخری بار ان کا آڈٹ کب ہوا؟
کیا آپ کے نظام میں کوئی جزو ہے جس کی ناکامی رسمی توثیق کا جواز دینے کے لیے کافی تباہ کن ہو، اور آپ کو کیسے پتا چلے گا؟

اہم نکات

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

حوالہ جات اور مزید مطالعہ

Benjamin C. Pierce, Types and Programming Languages
Simon Peyton Jones (ed.), The Implementation of Functional Programming Languages
Flemming Nielson, Hanne Riis Nielson, and Chris Hankin, Principles of Program Analysis
Patrick Cousot and Radhia Cousot, “Abstract Interpretation: A Unified Lattice Model for Static Analysis of Programs by Construction or Approximation of Fixpoints”
Scott Wlaschin, Domain Modelling Made Functional
Steve McConnell, Code Complete: A Practical Handbook of Software Construction
Michael Barr and the MISRA Consortium, MISRA C: Guidelines for the Use of the C Language in Critical Systems
Al Bessey et al., “A Few Billion Lines of Code Later: Using Static Analysis to Find Bugs in the Real World,” Communications of the ACM