2.1 کوڈنگ معیارات اور اسلوب
جائزہ اور محرکات
کوڈنگ معیارات وہ مشترک اصول ہیں جو بہت سے لوگوں کو یوں کوڈ لکھنے دیتے ہیں گویا ایک محتاط مصنف نے لکھا ہو۔ وہ نام رکھنے، فارمیٹنگ، فائل کی ترتیب، محاورات، خرابی سے نمٹنے، اور ٹیم کے پسندیدہ نمونوں کا احاطہ کرتے ہیں۔ چھوٹی ٹیم میں انفرادی پسند فیصلہ کر سکتی ہے۔ بڑی ٹیم میں (سینکڑوں یا ہزاروں انجینئر، بہت سے ٹھیکیدار، اعلیٰ تبدیلی) بے ربطی ایسا محصول بن جاتی ہے جو آپ ہر پڑھت، ہر ریویو اور ہر آغاز کار پر ادا کرتے ہیں۔ معیارات بے شمار چھوٹی اسلوبی بحثوں کو ایک بار کے فیصلے میں بدل دیتے ہیں جسے پھر مشین آپ کے لیے نافذ کرتی ہے۔
بڑے اداروں کے لیے داؤ ٹھوس ہیں۔ کوڈ لکھے جانے سے کہیں زیادہ پڑھا جاتا ہے۔ انٹرپرائز اور سرکاری ماحول میں، کوڈ کی ایک لائن اپنے مصنف کے چلے جانے کے برسوں بعد آڈیٹرز، سلامتی کے ریویورز اور نگہبانوں کے ہاتھوں پڑھی جا سکتی ہے۔ مستقل اسلوب اس پڑھت کی ذہنی لاگت کم کرتا ہے، نقائص کی گنجائش گھٹاتا ہے، اور لنٹرز (ایسے ٹولز جو ممکنہ نقائص اور اسلوب کی خلاف ورزیوں کو خود بخود نشان زد کرتے ہیں)، سلامتی اسکینرز اور ری فیکٹرنگ ٹولز میں خودکار تجزیہ کو قابل اعتماد بناتا ہے۔ جہاں ضابطہ لاگو ہو، جیسے مالیاتی خدمات، صحت، دفاع اور سرکاری شعبے کے نظاموں میں، معیارات اس ثبوت کا بھی حصہ بنتے ہیں کہ کوڈ بیس قابل دیکھ بھال اور کنٹرول شدہ ہے۔
جدید طریقہ اسلوب کو جاری انسانی فیصلے کا معاملہ سمجھنے کے بجائے حل شدہ، خودکار تشویش سمجھنا ہے۔ فارمیٹرز اور لنٹرز ایڈیٹر میں، پری کمٹ ہکس میں، اور مسلسل انضمام (CI) میں چلتے ہیں، یعنی وہ خودکار بلڈ اور ٹیسٹ کا عمل جو ہر تبدیلی پر چلتا ہے۔ مشینیں اسلوب نافذ کرتی ہیں، تاکہ آپ ریویو کی توجہ ڈیزائن اور درستگی پر لگا سکیں۔ مقصد یکسانیت برائے یکسانیت نہیں۔ یہ رگڑ کا خاتمہ ہے: آپ کو بنیادی باتیں دوبارہ سیکھے بغیر سروسز اور ٹیموں کے درمیان منتقل ہو سکنا چاہیے۔
بنیادی اصول
- یکسانیت انفرادی ترجیح کو ہرا دیتی ہے؛ ہر جگہ لاگو ایک متفقہ اسلوب ناہموار لاگو “بہترین” اسلوب سے زیادہ قیمتی ہے۔
- نفاذ کو خودکار کریں۔ فارمیٹرز اور لنٹرز سچائی کا ماخذ ہیں، خالی جگہ کے بارے میں کوڈ ریویو کے تبصرے نہیں۔
- اصل مصنف کے بجائے قاری اور نگہبان کے لیے بہتری لائیں۔
- وسیع زبان کی برادری پہلے سے جو اصول استعمال کرتی ہے انہیں مخصوص گھر کے اصولوں پر ترجیح دیں۔
- معیار کو اپنانا آسان بنائیں: ایسی PDF کے بجائے جو کوئی نہ پڑھے مشترک کنفیگریشنز، سانچے اور ٹولنگ فراہم کریں۔
- اسلوب کے اصول کم، قابل دفاع اور بلا ابہام ہوں؛ ہر اصول کا نفاذ کا طریقہ ہے ورنہ وہ محض تجویز ہے۔
- نام رکھنا پڑھنے کی اہلیت کا سب سے زیادہ لیوریج والا فیصلہ ہے اور واضح رہنمائی کا مستحق ہے۔
سفارشات
ہر زبان کے لیے ایک مستند اسلوب گائیڈ اپنائیں
آپ جو زبان بھی استعمال کریں اس کے لیے بنیادی خط کے طور پر وسیع طور پر تسلیم شدہ اسلوب گائیڈ اپنائیں (مثال کے طور پر اس زبان کے لیے برادری یا فروخت کنندہ کی گائیڈ) اور صرف وہ فرق دستاویزی کریں جو آپ کے ادارے کو چاہییں۔ شروع سے گھر کا اسلوب ایجاد نہ کریں۔ اپنا انتخاب مرکزی، قابل دریافت جگہ پر شائع کریں، اور کوڈ کی طرح اس کے ورژن رکھیں۔
فارمیٹرز کو ناقابل مذاکرات ڈیفالٹس بنائیں
ہر اس زبان کے لیے رائے رکھنے والا خودکار فارمیٹر استعمال کریں جس کے پاس ہو، ریپوزٹری میں جمع کی گئی ایک مشترک کنفیگریشن کے ساتھ۔ فارمیٹنگ کا ریویو میں کبھی ذکر نہیں آنا چاہیے، کیونکہ وہ محفوظ کرنے پر خود بخود لاگو ہوتی ہے اور CI میں تصدیق ہوتی ہے۔ جہاں کسی زبان میں مضبوط فارمیٹر نہ ہو تو ایک لنٹر کنفیگریشن چنیں اور اسے اسی طرح سمجھیں۔
لنٹرز کو مشورے کے بجائے نافذ دروازوں کے طور پر چلائیں
لنٹرز کو متفقہ اصولوں کے سیٹ سے ترتیب دیں، خلاف ورزی پر بلڈ ناکام کریں، اور اصولوں کا سیٹ ورژن کنٹرول میں رکھیں تاکہ تبدیلیاں ریویو سے گزریں۔ خود بخود ٹھیک ہونے والے اصولوں (انہیں خود لاگو کریں) کو ان اصولوں سے الگ کریں جنہیں انسانی فیصلہ چاہیے (نشان زد کریں اور روکیں)۔ نئے اصول “warn” موڈ میں متعارف کریں، پرانا بقایا صاف کریں، پھر انہیں “error” میں ترقی دیں۔
متعدد تہوں پر نافذ کریں
فوری فیڈبیک کے لیے ایڈیٹر کا انضمام، مقامی نفاذ کے لیے پری کمٹ ہکس، اور مستند دروازے کے طور پر CI کی جانچیں فراہم کریں۔ آپ خلاف ورزی جتنی جلد پکڑیں گے اتنا ہی سستا ہے۔ CI کو آخری پشت پناہ ہونا چاہیے، کیونکہ مقامی ہکس کو بائی پاس کیا جا سکتا ہے۔
نام رکھنے کو واضح اصول دیں
ہر زبان کے لیے حروف کی شکل کے اصول معیاری بنائیں، مقصد ظاہر کرنے والے نام لازمی کریں، گمراہ کن مخففات پر پابندی لگائیں، اور بولینز، مجموعوں، اکائیوں اور غیر ہم وقت عملیات کے لیے اصول متعین کریں۔ اپنی شعبے کی لغت مشترک گلوسری میں لکھیں تاکہ ایک ہی تصور کا ہر جگہ ایک ہی نام ہو۔
کثیر لسانی یکسانیت کو سوچ سمجھ کر سنبھالیں
ایسے کوڈ بیس میں جو کئی زبانوں پر پھیلا ہو، حتیٰ کہ جہاں نحو مختلف ہو، مستقل تصورات (خرابی سے نمٹنے کے نمونے، لاگنگ کی ساخت، پراجیکٹ کی ترتیب) کا ہدف رکھیں۔ مرکزی ریپوزٹری سے فی زبان کنفیگریشنز فراہم کریں تاکہ نئی سروس سانچوں یا ابتدائی ڈھانچے کے ذریعے معیارات خود بخود وراثت میں پائے۔
محاورات اور نمونوں کو مدون کریں
فارمیٹنگ سے آگے جائیں۔ اپنے پسندیدہ محاورات لکھیں، جیسے خرابیاں کیسے سنبھالیں، ماڈیولز کی ساخت کیسے بنائیں، اور استثنا بمقابلہ نتیجے کی اقسام کب استعمال کریں، ان نمونوں کے ساتھ جو آپ کی ٹیمیں پسند کرتی ہیں۔ یہی وہ جگہ ہے جہاں حقیقی پڑھنے کی اہلیت اور دیکھ بھال کی اہلیت رہتی ہے۔
سمجھوتے: فوائد اور نقصانات
| طریقہ | فوائد | نقصانات |
|---|---|---|
| سخت خودکار فارمیٹر، بلا کنفیگ | فارمیٹنگ کی تمام بحث ختم؛ فوری یکسانیت؛ آسان آغاز کار | کچھ ناپسندیدہ انتخابات ناقابل مذاکرات؛ پہلی بار لاگو کرنے پر بڑا فرق |
| گھر کے اصولوں کے ساتھ ترتیب دینے کے قابل لنٹر | ادارے کی ضروریات کے مطابق؛ حقیقی نقائص روکنے والے اصول مدون کر سکتا ہے | کنفیگ کا بھٹکاؤ؛ اصولوں کی بحث؛ دیکھ بھال کا بوجھ |
| برادری کا معیار جوں کا توں اپنانا | نئے بھرتیوں کے لیے مانوس؛ مضبوط ٹولنگ ماحولیاتی نظام؛ کم دیکھ بھال | مخصوص ادارہ جاتی پابندیوں کے مطابق نہ ہو؛ کبھی کبھار بے ڈھنگے اصول |
| مخصوص اندرونی معیار | ادارے کے عین مطابق | لکھنے اور برقرار رکھنے میں مہنگا؛ بھرتیوں کے لیے غیر مانوس؛ کمزور ٹولنگ |
| فی ٹیم خود مختاری | بلند مقامی حوصلہ؛ سیاق کے مطابق | بکھراؤ؛ ٹیموں کے درمیان منتقلی تکلیف دہ؛ بے ربط ٹولنگ |
نافذ شدہ ڈیفالٹس تھوڑی سی انفرادی خود مختاری کے بدلے بڑے اجتماعی فوائد دیتے ہیں: کم ریویو رگڑ، تیز آغاز کار، اور قابل اعتماد خودکاری۔ بنیادی خطرہ معیار کو سینکڑوں اصولوں میں حد سے زیادہ انجینئر کرنا ہے جو حقیقی نقائص روکے بغیر سب کو سست کرتے ہیں۔ اصولوں کا سیٹ چھوٹا اور شواہد پر مبنی رکھیں، اور موجودہ معیار اپنانے کی طرف جھکیں تاکہ دیکھ بھال سستی رہے۔
اپنی ٹیم کے ساتھ بحث کے سوالات
کون سے لنٹر کے اصول بلڈ ناکام کریں، اور آپ کسی اصول کو سب کو روکے بغیر انتباہ سے خرابی تک کیسے ترقی دیں؟ یہ باب دلیل دیتا ہے کہ ہر اصول کا نفاذ کا طریقہ ہو، اور نئے اصول warn موڈ میں آئیں، ان کا بقایا صاف ہو، پھر error میں پلٹیں۔ بڑی ٹیم میں گندے کوڈ بیس کے خلاف اصول کو error میں پلٹنا رات بھر سینکڑوں غیر متعلقہ تبدیلیاں روک دیتا ہے۔ اجلاس میں ٹھوس شواہد لائیں: ہر امیدوار اصول کی موجودہ خلاف ورزیوں کی تعداد، اور یہ کہ وہ خود بخود ٹھیک ہونے والا ہے یا انسانی فیصلہ مانگتا ہے۔ انٹرپرائز اور سرکاری ماحول میں پاس/فیل کی لکیر آڈٹ کے دروازوں کو بھی کھلاتی ہے، اس لیے مبہم اصولوں کا سیٹ آپ کی تعمیل کی کہانی کمزور کرتا ہے۔ مرحلہ وار رول آؤٹ طے کریں: جو ہو سکے خود ٹھیک کریں، صفائی کا بجٹ رکھیں، پھر دروازہ لگائیں۔
جب آپ پہلی بار اپنے پرانے کوڈ پر فارمیٹر لاگو کریں تو اس دوبارہ فارمیٹ کو git blame تباہ کرنے اور ریویو ڈبونے سے کیسے روکیں گے؟ سمجھوتوں کا جدول بڑے ابتدائی فرق سے خبردار کرتا ہے، اور ضد نمونوں کا حصہ دوبارہ فارمیٹ کے کمٹ کو منطق کی تبدیلیوں سے ملانے کی نشاندہی کرتا ہے۔ ایک وسیع دوبارہ فارمیٹ ہزاروں لائنیں دوبارہ لکھتا ہے اور blame کو حقیقی مصنف کے بجائے دوبارہ فارمیٹ کی طرف اشارہ کرواتا ہے، جو برسوں بعد ڈی بگ کرنے والے ہر شخص کو نقصان پہنچاتا ہے۔ دوبارہ فارمیٹ کو ایک الگ، واضح لیبل والے کمٹ کے طور پر کریں اور اسے blame-ignore فائل میں رجسٹر کریں تاکہ تاریخ مفید رہے۔ آڈیٹرز کے لیے جو سراغ لگاتے ہیں کہ کس نے کیا بدلا، یہ علیحدگی صاف ثبوت اور شور کے درمیان فرق ہے۔ کوڈ کو چھونے سے پہلے ترتیب پر اتفاق کریں، بعد میں نہیں۔
آپ کی نام رکھنے کی گلوسری اور شعبے کی لغت کا مالک کون ہے، اور نیا اصطلاحی لفظ کیسے شامل ہوتا ہے؟ باب نام رکھنے کو پڑھنے کی اہلیت کا سب سے زیادہ لیوریج والا فیصلہ کہتا ہے اور شعبے کی لغت مشترک گلوسری میں لکھنے کو کہتا ہے۔ نام زد مالک کے بغیر، ایک ہی تصور ٹیموں میں تین مختلف نام اپنا لیتا ہے، اور اسٹیٹک تجزیہ اور تلاش کے ٹولز کی قابل اعتمادی گھٹتی ہے۔ ٹھوس اشارے کے طور پر اپنے کوڈ بیس میں وہ تصورات لائیں جن کے پہلے ہی متضاد نام ہیں۔ ایک مالک اور ہلکا تجویز کا راستہ مقرر کریں، تاکہ اصطلاح شامل یا تبدیل کرنا ہر پل ریکوئسٹ میں بحث کے بجائے چھوٹی، ریویو شدہ تبدیلی ہو۔ جواب آغاز کار بدل دیتا ہے: نیا بھرتی غیر مستقل کوڈ سے ارادہ الٹی انجینئرنگ کرنے کے بجائے ایک گلوسری پڑھتا ہے۔
ہر زبان کے لیے، کیا آپ تسلیم شدہ برادری یا فروخت کنندہ کی اسلوب گائیڈ جوں کی توں اپناتے ہیں، اور گھر کے فرق کہاں واقعی جائز ہیں؟ یہ باب دلیل دیتا ہے کہ موجودہ معیار کو بنیادی خط بنائیں اور صرف وہ فرق دستاویزی کریں جو آپ کے ادارے کو چاہییں، کیونکہ مخصوص معیار لکھنا مہنگا ہے اور بھرتیوں کے لیے غیر مانوس۔ مقابل کھنچاؤ حقیقی ہے: اندرونی پابندی (سلامتی کا اصول، پرانا فریم ورک، رسائی پذیری کا حکم) کبھی کبھی برادری کے ڈیفالٹ سے واقعی ٹکراتی ہے، اور ہر فرق جو آپ رکھتے ہیں وہ اصول ہے جس کے مالک آپ اب ہمیشہ کے لیے بن گئے۔ تجویز کردہ فرق کی فہرست اجلاس میں لائیں، ہر ایک اس ٹھوس پابندی کے ساتھ جو اسے محرک کرتی ہے، اور کوئی بھی فرق کاٹنے کو تیار رہیں جو محض پسند ہو۔ انٹرپرائز اور سرکاری ماحول میں، وسیع زبان کی برادری سے ملتا بنیادی خط یہ بھی کہتا ہے کہ ٹھیکیدار اور نئے فروخت کنندگان پہلے سے رواں آتے ہیں، جو آغاز کار مختصر کرتا اور وہ دیکھ بھال کی اہلیت کا ثبوت مضبوط کرتا ہے جو آڈیٹرز تلاش کرتے ہیں۔
کثیر لسانی کوڈ بیس میں کون سے اصول واقعی آفاقی ہیں اور کون سے زبان کے مقامی رہتے ہیں، اور آپ فی ریپو کنفیگز کو بھٹکنے سے کیسے روکیں گے؟ باب زبانوں میں مستقل تصورات (خرابی سے نمٹنا، لاگنگ کی ساخت، پراجیکٹ کی ترتیب) مانگتا ہے چاہے نحو مختلف ہو، اور مرکزی ریپوزٹری سے فی زبان کنفیگز مانگتا ہے تاکہ نئی سروسز خود بخود معیارات وراثت میں پائیں۔ کھنچاؤ یہ ہے کہ ایک زبان کے محاورے دوسری پر زبردستی لگانا بے ڈھنگا، غیر محاوراتی کوڈ پیدا کرتا ہے، جبکہ ہر ٹیم کو اپنا کنفیگ فورک کرنے دینا اس پر ختم ہوتا ہے کہ “معیار” کا کوئی مطلب نہیں رہتا۔ ٹھوس اشارے کے طور پر اپنے موجودہ فی ریپو لنٹر اور فارمیٹر کنفیگز کی فہرست اور وہ فرق لائیں جو دکھائے کہ وہ پہلے ہی کتنا بھٹک چکے ہیں۔ درجنوں سروسز چلانے والے بڑے ادارے کے لیے ترسیل کا طریقہ طے کریں (سانچے، ابتدائی ڈھانچہ، مشترک کنفیگ پیکیج) تاکہ اصول کی تبدیلی ہر ریپوزٹری میں ہاتھ سے نقل ہونے کے بجائے ایک بار پھیلے۔
اصول کو بند کرنا کب جائز ہے، معطلی کا ریویو کون کرتا ہے، اور آپ کیسے روکتے ہیں کہ بلینکٹ ڈس ایبلز معیار کو کھوکھلا نہ کریں؟ ضد نمونوں کا حصہ وسیع اندرونی معطلیوں کو اس علامت کے طور پر نشان زد کرتا ہے کہ اصول غلط ہے یا ٹیم نے ہار مان لی، پھر بھی بلا استثنا سخت پالیسی لوگوں کو لنٹر کو مطمئن کرنے کے لیے بدتر کوڈ لکھنے پر دھکیلتی ہے۔ ہلکے راستے پر اتفاق کریں: معطلی کی وجہ ہو، وہ ممکنہ طور پر تنگ ترین دائرے پر ہو، اور وہ عالمی نظر انداز فائل میں دفن ہونے کے بجائے ریویو میں نظر آئے۔ فی اصول اور فی ریپوزٹری معطلیوں کی موجودہ تعداد لائیں، کیونکہ جو اصول سینکڑوں بار معطل ہو وہ کوڈ کے بارے میں نہیں بلکہ اصول کے بارے میں آپ کو کچھ بتا رہا ہے۔ ضابطے کے پابند اور سرکاری کام میں بغیر وضاحت کی بلینکٹ معطلیاں آڈٹ کی کہانی براہ راست کمزور کرتی ہیں، کیونکہ پائپ لائن اب نہیں دکھا سکتی کہ ضم شدہ کوڈ واقعی متفقہ دروازوں سے گزرا۔
شعبہ جاتی نقطۂ نظر
اسٹارٹ اپ۔ رفتار جیتتی ہے، اس لیے اپنی ایک زبان کے لیے پہلے دن برادری کے فارمیٹر اور لنٹر کے ڈیفالٹس اپنائیں اور دوسرے انجینئر کے آنے سے پہلے انہیں پری کمٹ ہک اور CI میں جوڑ دیں۔ ایسا گھر کا اسلوب نہ لکھیں جسے برقرار رکھنے کا آپ کے پاس وقت نہیں: ریپو میں بھیجی گئی کنفیگریشن ہی پورا معیار ہے۔ جب آپ دوسری زبان شامل کریں تو اصول شروع سے ایجاد کرنے کے بجائے اس زبان کی مستند گائیڈ تک پہنچیں۔
چھوٹا کاروبار۔ ٹولنگ کے مخصوص ماہر کے بغیر اور تنگ بجٹ کے ساتھ، اپنی زبان کے ساتھ یا اس کے ساتھ آنے والے مفت، رائے رکھنے والے فارمیٹر پر مکمل انحصار کریں اور اس کے ڈیفالٹس کو ٹیون کرنے کے بجائے قبول کریں۔ یہ بنانے پر خریدنے کا واضح معاملہ ہے: مخصوص اصولوں کا سیٹ برقرار رکھنے میں وہ وقت لگتا ہے جو آپ کے پاس نہیں، جبکہ تیار شدہ فارمیٹر کچھ خرچ نہیں کرتا اور اسلوب کی بحث فوراً ختم کرتا ہے۔ کنفیگ ریپوزٹری میں رکھیں تاکہ اگلے سال جو ٹھیکیدار آپ بھرتی کریں وہ بغیر گفتگو کے اسے وراثت میں پائے۔
بڑا ادارہ۔ بڑے پیمانے پر کام بہت سی ٹیموں میں نظم و نسق ہے: مرکزی انجینئرنگ معیارات کی ریپوزٹری جس میں فی زبان مشترک فارمیٹر اور لنٹر کنفیگز ہوں، ان کنفیگز کو کھینچنے والے سانچوں سے بنی نئی سروسز، اور CI کے دروازے جو غیر تعمیلی انضمام روکیں۔ اصولوں کے سیٹ کے ورژن کوڈ کی طرح رکھیں اور تبدیلیاں وقفے وقفے کے ریویو سے گزاریں تاکہ معیارات بھٹکنے کے بجائے سوچ سمجھ کر ارتقا کریں۔ واپسی یہ ہے کہ انجینئر ٹیموں کے درمیان مانوس کوڈ میں منتقل ہوں، اور خودکار ٹولنگ قابل اعتماد اشارہ دے کیونکہ ہر ریپوزٹری یکساں ہے۔
حکومت۔ خریداری اور جوابدہی انتخاب کو شکل دیتی ہیں: عمل کرنے کی اجازت کے تقاضوں کے حصے کے طور پر مخصوص اسلوب اور سلامتی کے اصولوں کا سیٹ لازمی کریں، اور پائپ لائن سے ایسی رپورٹ نکلوائیں جو آڈٹ کے شواہد کے طور پر دکھائے کہ ہر ضم شدہ تبدیلی متفقہ دروازوں سے گزری۔ چونکہ فارمیٹر خود بخود لاگو ہوتا ہے، متعدد فروخت کنندگان اور ٹھیکیداروں کا کوڈ یکساں نظر آتا ہے، جو معاہدوں کے ختم ہونے کے بہت بعد عوامی دیکھ بھال کے کام کی حفاظت کرتا ہے۔ مخصوص اصولوں پر برادری کے مستند بنیادی خطوط کو ترجیح دیں تاکہ معیار شفاف ہو اور کوئی بھی آئندہ سپلائر ملکیتی لاک ان کے بغیر اسے اپنا سکے۔
مثالیں
اسٹارٹ اپ۔ چار افراد کا اسٹارٹ اپ اپنی ایک زبان کے لیے پہلے دن برادری کے فارمیٹر اور لنٹر کے ڈیفالٹس اپناتا ہے، انہیں پری کمٹ ہک اور CI میں جوڑ کر تاکہ ریویو میں کوئی خالی جگہ پر بحث نہ کرے۔ چونکہ کنفیگ ریپو کے اندر آتا ہے، پانچویں اور چھٹے بھرتی خود بخود اسے وراثت میں پاتے ہیں اور کبھی فارمیٹنگ کا تبصرہ نہیں دیکھتے۔ جب ٹیم بعد میں دوسری زبان شامل کرتی ہے تو وہ گھر کا اسلوب ایجاد کرنے کے بجائے، جسے برقرار رکھنے کا ان کے پاس وقت نہیں، اس زبان کی معیاری گائیڈ تک پہنچتی ہے۔
بڑا ادارہ۔ ایک بڑا بینک درجنوں ٹیموں میں Java، Python اور TypeScript میں سروسز چلاتا ہے۔ وہ مرکزی “انجینئرنگ معیارات” کی ریپوزٹری شائع کرتا ہے جس میں ہر زبان کے مشترک فارمیٹر اور لنٹر کنفیگز ہیں۔ نئی سروسز سانچے سے بنتی ہیں جو یہ کنفیگز کھینچتا ہے، تاکہ ہر ریپوزٹری شروع سے ہی تعمیلی ہو۔ CI ہر خلاف ورزی پر انضمام روکتا ہے، اور سہ ماہی جائزہ اصولوں کی تبدیلیوں پر حکومت کرتا ہے۔ ٹیموں کے درمیان منتقل ہونے والے انجینئروں کا آغاز کار کا وقت نمایاں طور پر گھٹتا ہے، کیونکہ ہر ریپوزٹری مانوس لگتی ہے۔
حکومت۔ پرانے نظام کو جدید بنانے والی سرکاری ایجنسی اپنے عمل کی اجازت (ATO) کے تقاضوں کے حصے کے طور پر رسائی پذیری اور سلامتی کے لنٹنگ اصولوں کا سیٹ لازمی کرتی ہے، یعنی پروڈکشن میں نظام چلانے کے لیے درکار رسمی منظوری۔ اسلوب کی تعمیل آڈٹ کے شواہد کا حصہ بن جاتی ہے: پائپ لائن ایسی رپورٹ تیار کرتی ہے جو دکھاتی ہے کہ تمام ضم شدہ کوڈ متفقہ اسٹیٹک تجزیہ کے دروازوں سے گزرا۔ چونکہ فارمیٹر خود بخود لاگو ہوتا ہے، متعدد فروخت کنندگان کے ٹھیکیدار بصری طور پر یکساں کوڈ بناتے ہیں، جو معاہدوں کے ختم ہونے کے بعد حکومت کے طویل مدتی دیکھ بھال کے کام کو آسان بناتا ہے۔
کاروباری جواز: محرکات، ROI اور TCO
معیارات اپنانے کی لاگت زیادہ تر ایک بار کی ہے: گائیڈز کا انتخاب، ٹولنگ جوڑنا، اور ایک بڑا ابتدائی دوبارہ فارمیٹنگ کا کمٹ۔ بار بار کی لاگت کم ہے، کیونکہ نفاذ خودکار ہے۔ معیارات نہ اپنانے کی لاگت بار بار اور مرکب ہے: ہر ریویو اسلوب پر منٹ لگاتا ہے، ہر آغاز کار سست ہے، اسٹیٹک تجزیہ کے ٹولز شور پیدا کرتے ہیں، اور بے ربط کوڈ نقائص چھپاتا ہے۔ بڑے ادارے میں وہ منٹ مل کر کل وقتی مساوی کے نقصان بنتے ہیں۔
واپسی کم ریویو کی تاخیر، اسلوب سے متعلق کم ریویو تبصروں، تیز آغاز کار، اور خودکار ٹولنگ سے اعلیٰ اشارے کی صورت میں نظر آتی ہے۔ ضابطے کے پابند ماحول میں آڈٹ کی تیاری کی صورت میں مزید واپسی ہے: دکھائے جانے کے قابل، نافذ شدہ کنٹرولز تعمیل کے جائزوں کی محنت اور خطرہ کم کرتے ہیں۔ قیادت کے سامنے دلیل رکھنے کے لیے معیارات کو ڈویلپر کی پیداواریت اور آڈٹ کی حیثیت پر کم لاگت، اعلیٰ لیوریج والے لیور کے طور پر پیش کریں، اور ریویو تبصروں کے تجزیے اور آغاز کار کے سروے کے ڈیٹا سے بے ربطی کی موجودہ لاگت پر عدد لگائیں۔
ضد نمونے اور خامیاں
- کوڈ ریویو میں اسلوب پر بحث: اس بات کی علامت کہ نفاذ خودکار نہیں؛ اصول کو ٹولنگ میں منتقل کریں۔
- ناپڑھا ہوا معیارات کا دستاویز: نفاذ کے بغیر وکی صفحہ سجاوٹ ہے؛ ہر اصول کو طریقہ کار چاہیے۔
- اصولوں کا پھیلاؤ: سینکڑوں معمولی اصول جو حقیقی نقائص روکے بغیر کام سست کرتے ہیں۔
- کنفیگ کا بھٹکاؤ: ہر ریپوزٹری اپنا لنٹر کنفیگ فورک کرتی ہے یہاں تک کہ “معیار” کا کوئی مطلب نہیں رہتا۔
- فیچر کے کام کے بیچ پوری ریپو کی فارمیٹنگ: دوبارہ فارمیٹ کے کمٹ کو منطق کی تبدیلیوں سے ملانا ریویو اور blame کو تباہ کرتا ہے؛ بڑی دوبارہ فارمیٹنگ الگ، واضح لیبل والے کمٹ میں کریں۔
- بلینکٹ معطلیوں سے لنٹر کو نظر انداز کرنا: وسیع اندرونی ڈس ایبلز غلط اصول یا ہار مان چکی ٹیم کا اشارہ ہیں۔
- ملکیت کے بغیر معیارات: واضح مالک کے بغیر اصول کبھی ارتقا نہیں کرتے اور سڑ جاتے ہیں۔
پختگی کا ماڈل
- سطح 1، آغاز: اسلوب فی مصنف اور ردعملی ہے؛ کوئی مشترک کنفیگ نہیں؛ فارمیٹنگ ریویو میں بحث ہوتی ہے اور اس دن جسے سب سے زیادہ پروا ہو وہ طے کرتا ہے۔
- سطح 2، ترقی: انفرادی ٹیمیں فارمیٹر اور لنٹر اپناتی ہیں، مگر کنفیگ اور اصولوں کے سیٹ ٹیم سے ٹیم اور ریپو سے ریپو بدلتے ہیں، اس لیے یکسانیت ہر ٹیم کی حد پر رک جاتی ہے۔
- سطح 3، معیار بندی: فی زبان مرکزی مشترک کنفیگز دستاویزی اور پورے ادارے میں نافذ ہیں؛ CI غیر تعمیلی انضمام روکتا ہے؛ نئی ریپوزٹریاں سانچوں یا ابتدائی ڈھانچے سے معیارات خود بخود وراثت میں پاتی ہیں۔
- سطح 4، انتظام: معیار کو ڈیٹا سے ناپا اور کنٹرول کیا جاتا ہے: خلاف ورزی کی شرحیں، معطلیوں کی تعداد، اسلوب سے متعلق ریویو تبصرے، اور آغاز کار کا وقت بنیادی خطوط کے مقابل ٹریک ہوتے ہیں، اور اصولوں کی تبدیلیاں رائے کے بجائے اس شواہد پر ترقی یا ریٹائر ہوتی ہیں۔
- سطح 5، ہم آہنگی: معیارات مسلسل بہتر اور پورے ادارے میں مربوط ہیں؛ کثیر لسانی محاورات اور شعبے کی لغت دستاویزی اور نافذ ہیں، نفاذ تقریباً بلا رگڑ ہے، اور زبانوں، ٹولنگ اور ادارہ جاتی ضروریات کے بدلنے کے ساتھ اصولوں کا سیٹ ڈھلتا ہے۔
بحث کے لیے خیالات
- نافذ شدہ اصول اور دستاویزی رہنما اصول کے درمیان لکیر کہاں ہے جو انجینئر کے فیصلے پر بھروسہ کرتا ہے؟
- ادارہ پسندیدہ برادری کے اصول کو کیسے سنبھالے جو حقیقی اندرونی پابندی سے ٹکراتا ہو؟
- معیارات کا مالک کون ہے، اور اصولوں کی تبدیلیاں بغیر خلل کے کیسے تجویز، بحث اور رول آؤٹ ہوتی ہیں؟
- کثیر لسانی کوڈ بیس میں کون سے اصول واقعی آفاقی ہونے چاہئیں اور کون سے زبان کے مقامی؟
- آپ بڑے پرانے کوڈ بیس پر بغیر خلل ڈالنے والی بڑی دھماکہ خیز دوبارہ فارمیٹنگ کے معیارات کیسے لگائیں؟
- مشینی فارمیٹنگ سے آگے محاورات تجویز یا نافذ کرنے میں AI کی معاونت والی ٹولنگ کا کیا کردار ہونا چاہیے؟
اہم نکات
- اسلوب کو خودکار، حل شدہ مسئلہ سمجھیں تاکہ انسان ڈیزائن اور درستگی کا جائزہ لیں۔
- موجودہ برادری کے معیارات اپنائیں اور صرف فرق دستاویزی کریں۔
- ایڈیٹر، پری کمٹ اور CI کی تہوں پر نافذ کریں، CI کو مستند دروازے کے طور پر۔
- اصولوں کا سیٹ چھوٹا، قابل دفاع اور مرکزی طور پر منظم رکھیں۔
- نام رکھنا اور محاورات، خالی جگہ نہیں، وہ جگہ ہیں جہاں پڑھنے کی اہلیت واقعی جیتی جاتی ہے۔
حوالہ جات اور مزید مطالعہ
- Robert C. Martin, Clean Code: A Handbook of Agile Software Craftsmanship
- Andrew Hunt and David Thomas, The Pragmatic Programmer
- Steve McConnell, Code Complete
- Dustin Boswell and Trevor Foucher, The Art of Readable Code
- Kevlin Henney (ed.), 97 Things Every Programmer Should Know
- Google, Google Engineering Practices and language style guides (as reference exemplars)