گو پروجیکٹ ڈائریکٹری ساخت کے لئے بہترین طریقے

معلومات عامہ

یہ گولانے کے ایپلیکیشن پروجیکٹس کے لئے ایک بنیادی لے آؤٹ ہے۔ یہ `گو کور ڈویلپمنٹ ٹیم کی طرف سے رسمی طور پر مقرر کردہ معیار نہیں ہے۔ بلکہ یہ عوامی گولانے پروجیکٹس کے لئے ایک عام استعمال ہونے والے ڈائرکٹری لے آؤٹ ہے۔

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

یہ پروجیکٹ لے آؤٹ اصولی طور پر بہت عمومی طور پر ڈیزائن کیا گیا ہے اور ایک مخصوص گو پیکیج سکھاؤ کے سکیم کو عائد کرنے کی کوشش نہیں کی گئی ہے۔

گو پروجیکٹ ڈائرکٹری معیار

نیچے تجویز کی گؤ پروجیکٹ ڈائرکٹری معیار دی گئی ہے۔

.
├── go.mod
├── api
├── assets
├── build
├── cmd
├── configs
├── deployments
├── docs
├── examples
├── githooks
├── go.mod
├── init
├── internal
├── pkg
├── scripts
├── test
├── third_party
├── tools
├── vendor
├── web
└── website

ہر ڈائرکٹری کا مطلب نیچے بیان کیا گیا ہے۔

/cmd

پروجیکٹ کے مین ایپلیکیشنز، یعنی، پروگرام کے داخلے کی جگہ۔ یہ ڈائرکٹری میں گو فائل عام طور پر قابل اجراء فائلیں پیدا کرتی ہیں۔ ایک سادہ پروجیکٹ میں، ایک فائل جیسے کہ /test/main.go مندرجہ ذیل ہو سکتی ہے۔

ہر ایپلیکیشن کی ڈائرکٹری کا نام وہی ہونا چاہیے جو آپ کوائف ہیں (مثلاً cmd/myapp).

اپلیکیشن ڈائرکٹری میں زیادہ کوڈ نہ ڈالیں۔ اگر آپ کوڈ کو دوسرے پروجیکٹس میں درآمد کرکے اور استعمال کرنے کا خیال ہو تو اسے /pkg ڈائرکٹری میں ڈالیں۔ اگر کوڈ قابل استعمال نہیں ہے یا آپ چاہتے ہیں کہ دوسرے اسے استعمال نہ کریں تو اسے /internal ڈائرکٹری میں ڈالیں۔ آپ کو دیگر لوگوں کے رویے سے حیران ہو سکتے ہیں، لہذا اپنی نیت واضح کریں!

عام طور پر ایک چھوٹی سی main فعل ہوتی ہے جو /internal اور /pkg ڈائرکٹریوں سے کوڈ کو درآمد کرتی ہے اور کچھ نہیں۔

/internal

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

آپ لے آؤٹ پیکیجز کو شئیرڈ اور غیر شئیرڈ داخلی کوڈ میں فرق کرنے کیلئے کچھ اضافی ساخت ڈالنے کا انتخاب کرسکتے ہیں۔ یہ ضروری نہیں ہے (خاص طور پر چھوٹے پروجیکٹس کے لیے)، لیکن منظری جاتا رہنا منظور مقصد کی قابل دیکھائی ہے۔ آپ کا واقعی ایپلیکیشن کوڈ /internal/app ڈائرکٹری میں رکھا جا سکتا ہے (مثلاً /internal/app/myapp)، اور اس کے لئے شیئرڈ کوڈ ان ایپلیکیشنز کی /internal/pkg ڈائرکٹری میں رکھا جا سکتا ہے (مثلاً /internal/pkg/myprivlib)۔

/pkg

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

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

/vendor

درخواست کردہ ایپلیکیشن کی تابعیتی پردہ کاتے (مینوئلی منزوں یا آپ کی ترجیح کے تابعیتی پردہ کی منجمد کاتے، مثال کے طور پر Go Modules فیچر)۔ go mod vendor کمانڈ آپ کے لئے /vendor ڈائرکٹری بنائیں گے۔ نوٹ کریں کہ اگر آپ ڈیفالٹ سیٹ گو 1.14 ورژن استعمال نہیں کر رہے ہیں تو، آپ کو go build کمانڈ کے لیے -mod=vendor پرچم شامل کرنا پڑ سکتا ہے۔

اگر آپ ایک لائبریری بنا رہے ہیں تو براہ کرم اپنی ایپلیکیشن کی تابعیتی پردہات کو کمٹ نہ کریں۔

سروس ایپلیکیشن ڈائرکٹریز

/api

OpenAPI/Swagger specifications, JSON schema files, protocol definition files, and API protocol directories.

ویب ایپلیکیشن ڈائرکٹریز

/web

Web ایپلیکیشن کے لئے خصوصی اجزاء: اسٹیٹک ویب سائٹ اسٹس، سرور سائیڈ ٹمپلیٹس، اور سنگل پیج ایپلیکیشنز (SPAs)۔

عام ایپلیکیشن ڈائرکٹریز

/configs

تشکیل فائل ٹمپلیٹ یا ابتدائی تشکیلات۔

اپنے confd یا consul-template ٹیمپلیٹ فائلز یہاں رکھیں۔

/init

نظام کی ابتدائی کارروائی (systemd، upstart، sysv) اور پروسیس منیجر/ڈیمن (runit، supervisord) کنفیگریشن۔

/scripts

مختلف بلڈ، انسٹالیشن، تجزیہ، اور دیگر عملات کے لئے اسکرپٹس۔

/build

پیکیجنگ اور مسلسل انٹیگریشن۔

Cloud (AMI)، کنٹینر (Docker)، آپریٹنگ سسٹم (deb، rpm، pkg) پیکیج تشکیلات اور اسکرپٹس کو /build/package ڈائرکٹری میں رکھیں۔

مسلسل انٹیگریشن (travis، circle، drone) کنفیگریشن اور اسکرپٹس کو /build/ci ڈائرکٹری میں رکھیں۔براہ کرم نوٹ کریں کہ کچھ مسلسل انٹیگریشن ٹولز (مثلاً Travis CI) ان کنفیگریشن فائلز کے مقام کے بارے میں بہت ہی مخصوص ہوتے ہیں۔ ان کنفیگریشن فائلز کو /build/ci ڈائرکٹری میں رکھنے کی کوشش کریں اور انہیں مسلسل انٹیگریشن ٹولز کی توقع کے مقامات سے منسلک کرنے کے لئے لنکس استعمال کریں (اگر ممکن ہو)۔

/deployments

IaaS، PaaS، سسٹم، اور کنٹینر ارکسٹریشن (docker-compose، kubernetes/helm، terraform) کے ڈیپلوئمنٹ کنفیگریشن اور ٹیمپلیٹس۔ براہ کرم نوٹ کریں کہ کچھ ریپوزیٹریز میں (خصوصاً جہاں کنٹینرز کا استعمال ہوتا ہے)، یہ ڈائرکٹری /deploy کہلاتی ہے۔

/test

دیگر بیرونی ٹیسٹنگ ایپلیکیشنزاور ٹیسٹ ڈیٹا۔ براہ کرم آپ کی ضرورتوں کے مطابق /test ڈائرکٹری کو منظم کرنے کی اجازت حاصل ہے۔ بڑے پراجیکٹس کے لئے، ڈیٹا کو ذیلی ڈائرکٹریوں میں منظم کرنا معقول ہوتا ہے۔ مثال کے طور پر، آپ /test/data یا /test/testdata ڈائرکٹریاں بنا سکتے ہیں تاکہ Go مواد کو نظرانداز نہ کرے۔ براہ کرم نوٹ کریں کہ Go بھی داقھ میں چلنے والی ڈائرکٹریوں یا فائلوں کو نظرانداز کرتا ہے جو "." یا "_" سے شروع ہوتی ہیں، جو ٹیسٹ ڈیٹا ڈائرکٹریاں کے نام دینے کے وقت بہتر ممکن بناتا ہے۔

دیگر ڈائرکٹریز

/docs

ڈیزائن اور صارف کی ہدایات (جو آپ کی جنریٹ کردہ godoc دستاویزات کے علاوہ ہیں)۔

/tools

اس پروجیکٹ کے لئے سپورٹنگ ٹولز۔ براہ کرم نوٹ کریں کہ ان ٹولز کو /pkg اور /internal ڈائرکٹریز سے کوڈ امپورٹ کر سکتے ہیں۔

/examples

ایپلیکیشن اور/یا عوامی لائبریریز کے لئے مثالیں۔

/third_party

بیرونی معاون ٹولز، فورک کوڈ، اور دوسرے تیسری پارٹی خدمتی ٹولز (مثلاً Swagger UI)۔

/githooks

گٹ ہکس۔

/assets

ضمنی اموال (تصاویر، لوگوز، وغیرہ) جو ریپوزٹری کے ساتھ فراہم کی جاتی ہیں۔

/website

پروجیکٹ ویب سائٹ ڈیٹا کی جگہ، اگر آپ GitHub Pages نہیں استعمال کر رہے ہیں تو۔

/src

کچھ Go پروجیکٹس میں src فولڈر ہوتا ہے، لیکن یہ عام طور پر جاوا دنیا سے آنے والے ڈویلپرز کی وجہ سے ہوتا ہے، جہاں یہ ایک عام پیٹرن ہے۔ اگر ممکن ہو تو، براہ کرم اس جاوا جیسے پیٹرن کا اپنانا تجاویز نہیں ہے۔ واقع میں آپ نہیں چاہتے کہ آپ کا Go کوڈ یا پروجیکٹ جاوا کی طرح لگے :-)

براہ کرم پروجیکٹ سطح پر /src ڈائرکٹری کو Go ورک اسپیس میں استعمال شدہ /src ڈائرکٹری سے غلطی سے متاثر نہ کریں۔ جو Go ورک اسپیس کی تفصیلات کو موصول کرتا ہے، جیسا کہ How to Write Go Code میں بیان کیا گیا ہے۔ $GOPATH ماحولیاتی متغیر آپ کے (فعلی) ورک اسپیس کو اشارہ کرتا ہے (غیر ونڈوز نظاموں پر، یہ افتراضی طور پر $HOME/go ڈائریکٹری میں ہوتا ہے)۔ یہ ورک اسپیس ٹاپ لیول /pkg، /bin، اور /src ڈائریکٹریاں شامل ہوتا ہے۔ آپ کا واقعی پروجیکٹ، /src ڈائرکٹری کے نیچے کی داخلی ہو گی، لہذا اگر آپ کا پروجیکٹ کے پاس /src ڈائرکٹری ہے تو پروجیکٹ کا راستہ ایسا لگے گا: /some/path/to/workspace/src/your_project/src/your_code.go۔ براہ کرم نوٹ کریں کہ گو 1.11 سے، آپ کا پروجیکٹ GOPATH کے باہر بھی ہو سکتا ہے، لیکن یہ یہ کہنا نہیں ہے کہ یہ لے آؤٹ پیٹرن کا ایک اچھا آئیڈیا ہے۔