2.14 پراجیکٹ اور ریپوزٹری کی ساخت

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

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

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

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

بنیادی اصول

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

سفارشات

مستقل اعلیٰ سطحی ترتیب اپنائیں

اعلیٰ سطحی فولڈرز کا معیاری سیٹ متعین کریں جو ہر ریپوزٹری جہاں قابل اطلاق ہو استعمال کرے، اور دستاویزی کریں کہ ہر ایک کس لیے ہے۔ عام، فروخت کنندہ سے غیر جانبدار اصول میں شامل ہیں: پروڈکشن کوڈ کے لیے سورس فولڈر (اکثر src)؛ خودکار ٹیسٹوں کے لیے ٹیسٹ فولڈر (اکثر test یا tests)؛ دستاویزات کے لیے docs فولڈر؛ بلڈ کی تعریفوں اور آؤٹ پٹس کے لیے build فولڈر؛ تعیناتی اور کوڈ کی صورت میں انفراسٹرکچر (سرورز، نیٹ ورکس اور سروسز کی مشین سے پڑھنے والی تعریفیں، جن کا احاطہ باب 8.2 میں ہے) کے لیے deploy فولڈر؛ خودکاری اور ڈویلپر ٹولنگ کے لیے scripts فولڈر؛ چلانے کے قابل نمونوں کے لیے examples فولڈر؛ اور تقاضوں اور ڈیزائن کی تصریحات کے لیے spec یا specification فولڈر۔ ہر ریپو کو ہر فولڈر نہیں چاہیے، مگر جہاں کوئی تشویش موجود ہو، اسے متوقع جگہ پر متوقع نام کے ساتھ رہنا چاہیے۔

README کو داخلے کا نکتہ بنائیں

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

ایڈیٹر اور کنفیگریشن فائلوں کو معیاری بنائیں

مشترک ایڈیٹر اور ٹولنگ کی کنفیگریشن ریپوزٹری میں جمع کریں تاکہ ہر شراکت کار کو مستقل رویہ خود بخود ملے۔ .editorconfig فائل (سادہ، ایڈیٹر سے غیر جانبدار فائل جو خالی جگہ، انڈینٹیشن اور لائن کے اختتام کے اصول متعین کرتی ہے) مختلف ایڈیٹرز اور آپریٹنگ سسٹمز میں بنیادی فارمیٹنگ کو یکساں رکھتی ہے۔ ورژن کنٹرول سسٹم کے لیے نظر انداز کرنے والی فائل جوڑیں (تاکہ بلڈ آؤٹ پٹس اور مقامی آرٹیفیکٹس کبھی کمٹ نہ ہوں)، ساتھ باب 2.1 میں بیان کردہ مشترک فارمیٹر اور لنٹر کنفیگریشنز۔ یہ فائلیں ریپوزٹری کے اصولوں کو صرف دستاویزی نہیں، فعال بناتی ہیں۔

نام رکھنے اور فولڈر کے اصول متعین کریں

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

تہوں اور انحصارات کو سوچ سمجھ کر ترتیب دیں

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

ابتدائی ڈھانچے اور سانچوں سے ساخت نافذ کریں

ابتدائی ڈھانچہ فراہم کریں، یعنی آغاز کرنے والے پراجیکٹ کی خودکار پیدائش، تاکہ نئی ریپوزٹریاں پہلے سے درست شروع ہوں۔ سانچہ یا کوکی کٹر (پیرامیٹر شدہ پراجیکٹ کا ڈھانچہ جو چند سوالات کے جواب سے تیار ریپوزٹری بناتا ہے) معیاری ترتیب، README، کنفیگ فائلیں، اور CI کی ترتیب ایک جگہ انکوڈ کرتا ہے۔ جب انجینئر مشترک سانچے سے نئی سروسز بناتے ہیں تو یکسانیت امنگ کے بجائے ڈیفالٹ بن جاتی ہے، اور سانچے میں بہتریاں آئندہ پراجیکٹس تک بہتی ہیں۔

بہت سی ریپوزٹریوں میں بڑے پیمانے پر ساخت کو مستقل رکھیں

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

ساخت کو مونو ریپو بمقابلہ ملٹی ریپو کے انتخاب کو آگاہ کرنے دیں

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

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

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

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

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

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

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

اسٹارٹ اپ۔ رفتار جیتتی ہے، اس لیے اپنی پہلی ریپو کے لیے ایک سادہ، کافی چپٹی ترتیب پر اتفاق کریں (src، test، docs، scripts، بھرپور README، .editorconfig، اور نظر انداز کرنے والی فائلیں) اور اسی دوپہر اسے ہلکے سانچے کے طور پر محفوظ کریں۔ دوسری سروس اس سے بنائیں تاکہ دونوں ریپوز مانوس لگیں اور نیا ٹھیکیدار برف کے گولے کی الٹی انجینئرنگ کے بجائے گھنٹوں میں آغاز کار کر سکے۔ گہری درجہ بندیوں اور بھاری نظم و نسق کی مزاحمت کریں جس کی آپ کو ابھی ضرورت نہیں؛ یہاں پوری واپسی یہ ہے کہ دو بانی اور ایک ٹھیکیدار ایک نقشہ بانٹتے ہیں۔

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

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

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

مثالیں

اسٹارٹ اپ۔ تین افراد کا اسٹارٹ اپ اپنی پہلی ریپو کے لیے سادہ معیاری ترتیب پر اتفاق کرتا ہے (src، test، docs، scripts، بھرپور README، .editorconfig، اور نظر انداز کرنے والی فائلیں) اور اسے ہلکے سانچے کے طور پر محفوظ کرتا ہے۔ جب وہ ایک ماہ بعد دوسری سروس شروع کرتے ہیں تو اسے اسی سانچے سے بناتے ہیں، اس لیے دونوں ریپوز پہلے سے مانوس لگتی ہیں اور نیا ٹھیکیدار ایک دوپہر میں آغاز کار کر لیتا ہے۔ وہ گہری فولڈر کی درجہ بندیوں کی مزاحمت کرتے ہیں جن کی انہیں ابھی ضرورت نہیں، ٹری کو اتنا چپٹا رکھتے ہوئے کہ ایک نظر میں اسکین ہو۔ لاگت ایک دوپہر کی تیاری تھی، اور یہ انہیں اس برف کے گولوں کے پھیلاؤ سے بچاتی ہے جو ورنہ ہر آئندہ ریپو کو چھوٹا تحقیقی منصوبہ بنا دیتا۔

بڑا ادارہ۔ ایک کثیر قومی خوردہ فروش کئی زبانوں میں سینکڑوں سروسز چلاتا ہے۔ اس کی پلیٹ فارم ٹیم ورژن شدہ ریپوزٹری ساخت کا معیار اور اسے نافذ کرنے والے پراجیکٹ کے سانچوں کا سیٹ شائع کرتی ہے۔ ہر نئی سروس سانچے سے بنتی ہے، اس لیے وہ معیاری src، test، docs، deploy، اور scripts فولڈرز، بھرپور README، .editorconfig، نظر انداز کرنے والی فائلوں، اور کام کرتی CI پائپ لائن کے ساتھ آتی ہے۔ چونکہ ہر ریپوزٹری ایک جیسی لگتی ہے، نئی ٹیم میں منتقل انجینئر گھنٹوں میں کارآمد ہوتا ہے، اور ادارے بھر کے سلامتی اور انحصار کے اسکینرز یکساں چلتے ہیں کیونکہ انہیں فائلیں ہمیشہ وہیں ملتی ہیں جہاں وہ توقع رکھتے ہیں۔

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

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

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

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

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

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

پختگی کا ماڈل

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

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

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

اہم نکات

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

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

Robert C. Martin, Clean Architecture: A Craftsman’s Guide to Software Structure and Design
Steve McConnell, Code Complete: A Practical Handbook of Software Construction
Andrew Hunt and David Thomas, The Pragmatic Programmer
Titus Winters, Tom Manshreck, and Hyrum Wright (eds.), Software Engineering at Google
Scott Chacon and Ben Straub, Pro Git
EditorConfig project documentation (as a reference standard for editor configuration)