এটি একটি সাধারণ Go অ্যাপ্লিকেশন প্রজেক্টের লেআউট। মনে রাখবেন, এটি কন্টেন্টের দিক থেকে সাধারণ কারণ এটি শুধুমাত্র সাধারণ লেআউটের উপর গুরুত্ব দিচ্ছে, ভিতরের উপাদানগুলোর উপর নয়। এটি উচ্চস্তরের (high-level) একটি গাইড, যা প্রজেক্ট স্ট্রাকচার আরও গভীরভাবে কিভাবে সাজানো যায়, সে বিষয়ে বিস্তারিত আলোচনা করে না।
উদাহরণস্বরূপ, এটি সুশৃঙ্খল নির্মাণ কৌশল (Clean Architecture) -এর মতো কাঠামোতে কিভাবে প্রজেক্ট সাজানো হয়, সেটি কাভার করে না।
<b>`এটি Go মূল ডেভেলপমেন্ট টিম কর্তৃক নির্ধারিত কোনো অফিসিয়াল স্ট্যান্ডার্ড নয়`।</b> বরং এটি Go ইকোসিস্টেমে ব্যবহৃত কিছু প্রচলিত এবং নতুনভাবে গড়ে ওঠা প্রজেক্ট লেআউট প্যাটার্নের একটি সংকলন। এর মধ্যে কিছু প্যাটার্ন অন্যগুলোর তুলনায় বেশি জনপ্রিয়।
এতে আরও কিছু ছোটখাটো উন্নয়ন (enhancement) এবং এমন কিছু সাপোর্টিং ডিরেক্টরিও রয়েছে, যেগুলো বাস্তব জীবনের বড় ধরনের অ্যাপ্লিকেশনে সাধারণত ব্যবহৃত হয়।
মনে রাখবেন, <b>মূল Go টিম Go প্রজেক্ট স্ট্রাকচারের জন্য কিছু চমৎকার সাধারণ নির্দেশনা প্রদান করে</b> যেমন, একটি প্রজেক্ট যখন অন্য কোথাও থেকে ইমপোর্ট বা ইনস্টল করা হয়, তখন সেটির অর্থ কী হয়।
এ বিষয়ে আরও বিস্তারিত জানতে অফিসিয়াল Go ডকুমেন্টেশনের[ **Organizing a Go module**](https://go.dev/doc/modules/layout) পেজটি দেখুন।
এই নির্দেশনায় `internal` এবং `cmd` ডিরেক্টরির প্যাটার্ন (যা নিচে ব্যাখ্যা করা হয়েছে) সহ আরও গুরুত্বপূর্ণ তথ্য অন্তর্ভুক্ত রয়েছে।
<b>`যদি আপনি Go শিখছেন বা নিজের জন্য কোনো PoC (Proof of Concept) বা একটি সাধারণ প্রজেক্ট তৈরি করছেন, তাহলে এই প্রজেক্ট লেআউটটি আপনার জন্য খুব বেশি জটিল হবে। এর বদলে খুব সহজ কিছু দিয়ে শুরু করুন `(একটা মাত্র `main.go` ফাইল এবং `go.mod` ফাইল যথেষ্ট)।</b>কিন্তু আপনার প্রজেক্ট বড় হওয়া সাথে সাথে মনে রাখবেন, কোডটি সুশৃঙ্খলভাবে সাজানো থাকা খুব গুরুত্বপূর্ণ, না হলে কোডটা এলোমেলো হয়ে যাবে যেখানে অনেক লুকানো নির্ভরশীলতা (dependencies) এবং গ্লোবাল স্টেট থাকবে।
যখন আপনার প্রজেক্টে আরো মানুষ কাজ করবে, তখন আরও বেশি স্ট্রাকচার বা বিন্যাসের প্রয়োজন হবে।সেই সময়ই প্যাকেজ/লাইব্রেরি ব্যবস্থাপনার জন্য একটি সাধারণ পদ্ধতি নেয়া গুরুত্বপূর্ণ হয়ে ওঠে।যখন আপনার একটি ওপেন সোর্স প্রজেক্ট থাকে বা অন্য প্রজেক্টগুলো আপনার প্রজেক্টের কোড ইমপোর্ট করে, তখন প্রাইভেট (অর্থাৎ `internal`) প্যাকেজ এবং কোড থাকা খুব জরুরি হয়ে পড়ে।রিপোজিটরি ক্লোন করুন, যা প্রয়োজন তা রাখুন আর বাকিটা মুছে ফেলুন! শুধু সেটা সেখানে আছে বলে আপনাকে সবকিছু ব্যবহার করতেই হবে এমন নয়।এই প্যাটার্নগুলোর কোনোটা প্রতিটি প্রজেক্টে ব্যবহার হয় না। এমনকি `vendor` প্যাটার্নও সার্বজনীন নয়।
Go 1.14 এর সাথে [Go Modules](https://go.dev/wiki/Modules) অবশেষে প্রোডাকশনের জন্য প্রস্তুত।
আপনার যদি [Go Modules](https://go.dev/blog/using-go-modules) ব্যবহার না করার কোনো বিশেষ কারণ না থাকে, তাহলে অবশ্যই Go Modules ব্যবহার করুন।
এক্ষেত্রে আপনাকে `$GOPATH` বা আপনার প্রজেক্ট কোথায় রাখতে হবে তা নিয়ে চিন্তা করার দরকার নেই।
রিপোজিটরির বেসিক `go.mod` ফাইল ধরে নেয় যে আপনার প্রজেক্ট GitHub-এ হোস্ট করা আছে, কিন্তু এটি বাধ্যতামূলক নয়।
মডিউল পাথ যেকোনো হতে পারে, তবে প্রথম মডিউল পাথের অংশে একটি ডট (.) থাকা উচিত। (Go-এর বর্তমান ভার্সন এটা আর কঠোরভাবে প্রযোজ্য করে না, কিন্তু যদি আপনি কিছু পুরোনো ভার্সন ব্যবহার করেন তাহলে এটা না থাকলে বিল্ড ফেল হতে পারে।)
এ বিষয়ে আরো জানতে চাইলে Issues [37554](https://github.com/golang/go/issues/37554) এবং [32819](https://github.com/golang/go/issues/32819) দেখতে পারেন।
এই প্রজেক্ট লেআউটটি ইচ্ছাকৃতভাবে সাধারণ রাখা হয়েছে এবং এটি কোনো নির্দিষ্ট Go প্যাকেজ স্ট্রাকচার চাপিয়ে দেয় না।
এটি একটি কমিউনিটি উদ্যোগ।যদি আপনি কোনো নতুন প্যাটার্ন দেখতে পান বা মনে করেন বিদ্যমান প্যাটার্নগুলোর মধ্যে কোনোটা আপডেট হওয়া প্রয়োজন, তাহলে অনুগ্রহ করে একটি ইস্যু খুলুন।
নামকরণ (naming), ফরম্যাটিং এবং স্টাইল নিয়ে সাহায্যের প্রয়োজন হলে প্রথমে [gofmt](https://pkg.go.dev/cmd/gofmt) এবং [staticcheck](https://github.com/dominikh/go-tools/tree/master/cmd/staticcheck) চালিয়ে শুরু করুন।
পুরানো স্ট্যান্ডার্ড linter, golint এখন অব্যবহৃত (deprecated) এবং আর রক্ষণাবেক্ষণ করা হয় না; তাই staticcheck-এর মতো রক্ষণাবেক্ষিত লিন্টার ব্যবহার করার পরামর্শ দেওয়া হয়।সাথে সাথে নিচের Go কোড স্টাইল গাইডলাইন এবং সুপারিশগুলো পড়া নিশ্চিত করুন:
- https://talks.golang.org/2014/names.slide
- https://golang.org/doc/effective_go.html#names
- https://blog.golang.org/package-names
- https://go.dev/wiki/CodeReviewComments
- [Style guideline for Go packages](https://rakyll.org/style-packages/) (rakyll/JBD)
অতিরিক্ত তথ্যের জন্য [Go Project Layout](https://medium.com/golang-learn/go-project-layout-e5213cdcfaa2) পৃষ্ঠা দেখুন।
নামকরণ এবং প্যাকেজ সংগঠনের বিষয়াদি এবং অন্যান্য কোড স্ট্রাকচার সুপারিশ সম্পর্কিত আরও তথ্য:
- [GopherCon EU 2018: Peter Bourgon - Best Practices for Industrial Programming](https://www.youtube.com/watch?v=PTE4VJIdHPg)
- [GopherCon Russia 2018: Ashley McNamara + Brian Ketelsen - Go best practices.](https://www.youtube.com/watch?v=MzTcsI6tn-0)
- [GopherCon 2017: Edward Muller - Go Anti-Patterns](https://www.youtube.com/watch?v=ltqV6pDKZD8)
- [GopherCon 2018: Kat Zien - How Do You Structure Your Go Apps](https://www.youtube.com/watch?v=oL6JBUk6tj0)
প্যাকেজ-ভিত্তিক ডিজাইন নির্দেশিকা এবং আর্কিটেকচার স্তর সম্পর্কে একটি চীনা পোস্ট
প্রতিটি অ্যাপ্লিকেশনের জন্য ডিরেক্টরির নাম অবশ্যই সেই এক্সিকিউটেবলের(executable ) নামের সঙ্গে মিলতে হবে যা আপনি রাখতে চান (যেমন, `/cmd/myapp`)।
অ্যাপ্লিকেশন ডিরেক্টরিতে বেশি কোড রাখবেন না। যদি মনে করেন কোডটি অন্য প্রজেক্টে ইমপোর্ট করে ব্যবহার করা যেতে পারে, তাহলে কোডটি `/pkg` ডিরেক্টরিতে থাকা উচিত।
আর যদি কোডটি পুনঃব্যবহারযোগ্য না হয় অথবা আপনি চান না অন্যরা এটি ব্যবহার করুক, তাহলে কোডটি `/internal` ডিরেক্টরিতে রাখুন।অন্যরা কী করবে সেটা আপনি অবাক হয়ে দেখবেন, তাই আপনার ইচ্ছেটা স্পষ্ট করে রাখুন!
সাধারণত একটি ছোট `main` ফাংশন থাকে, যা `/internal` এবং `/pkg` ডিরেক্টরি থেকে কোড ইমপোর্ট করে চালায়, আর অন্য কিছু করে না।
উদাহরণ দেখতে [`/cmd`](https://github.com/golang-standards/project-layout/blob/master/cmd/README.md) ডিরেক্টরি দেখুন।
### /internal
প্রাইভেট অ্যাপ্লিকেশন এবং লাইব্রেরি কোডের জন্য।এই কোডগুলো আপনি চান না অন্যরা তাদের অ্যাপ্লিকেশন বা লাইব্রেরিতে ইমপোর্ট করুক।
মনে রাখবেন, এই লেআউট প্যাটার্নটি Go কম্পাইলার নিজেই প্রয়োগ করে। বিস্তারিত জানতে Go 1.4 [release notes](https://go.dev/doc/go1.4#internalpackages) দেখুন।আপনি শুধু টপ-লেভেল `/internal` ডিরেক্টরিতে সীমাবদ্ধ নন। আপনার প্রজেক্টের যেকোনো স্তরে একাধিক `/internal` ডিরেক্টরি থাকতে পারে।
ঐচ্ছিকভাবে, আপনি আপনার internal প্যাকেজগুলোতে আরও একটু স্ট্রাকচার যোগ করতে পারেন, যাতে শেয়ার করা এবং শেয়ার না করা কোড আলাদা করা যায়।ছোট প্রজেক্টগুলোর জন্য এটি বাধ্যতামূলক নয়, তবে কোড ব্যবহারের উদ্দেশ্য বোঝাতে ভিজ্যুয়াল clue হিসেবে ভালো।
আপনার প্রকৃত অ্যাপ্লিকেশন কোড `/internal/app` (যেমন, `/internal/app/myapp`) ডিরেক্টরিতে রাখতে পারেন, আর সেই অ্যাপগুলো দ্বারা শেয়ার করা কোড `/internal/pkg` (যেমন, `/internal/pkg/myprivlib`) এ রাখতে পারেন।
আপনি internal ডিরেক্টরি ব্যবহার করে প্যাকেজগুলো প্রাইভেট বানান।যদি কোনো প্যাকেজ internal ডিরেক্টরির মধ্যে থাকে, তবে অন্য প্যাকেজগুলো সেটি ইমপোর্ট করতে পারবে না যতক্ষণ না তারা একটি সাধারণ উপরের লেভেলের ডিরেক্টরির অধীনে থাকে।এছাড়া এটি একমাত্র ডিরেক্টরি যার নাম Go ডকুমেন্টেশনে উল্লেখ রয়েছে এবং যা কম্পাইলার দ্বারা বিশেষভাবে হ্যান্ডল করা হয়।
### /pkg
এখানে এমন লাইব্রেরি কোড রাখা হয় যেগুলো বাইরের অ্যাপ্লিকেশনগুলোর দ্বারা ব্যবহারযোগ্য (যেমন, `/pkg/mypubliclib`)।অন্য প্রজেক্টগুলো এই লাইব্রেরিগুলো ইমপোর্ট করবে এবং কাজ করবে বলে ধরে নেবে, তাই কিছু এখানে রাখার আগে দুইবার ভাবুন :)।মনে রাখবেন, `internal` ডিরেক্টরি ব্যবহার করাই সবচেয়ে ভালো উপায় কোনো প্যাকেজকে প্রাইভেট রাখতে, কারণ এটি Go কম্পাইলার দ্বারা জোরপূর্বক প্রয়োগ হয়।তবুও `/pkg` ডিরেক্টরি ব্যবহার করা ভালো একটি উপায় অন্যদেরকে স্পষ্টভাবে জানিয়ে দিতে যে, এখানকার কোড তারা নিরাপদে ব্যবহার করতে পারে।Travis Jeffery-এর [I'll take pkg over internal](https://travisjeffery.com/b/2019/11/i-ll-take-pkg-over-internal/) ব্লগ পোস্টে `pkg` এবং `internal` ডিরেক্টরি নিয়ে ভালো ব্যাখ্যা দেওয়া আছে — কবে কোনটি ব্যবহার করা উচিত তা নিয়ে।
এছাড়া এটি হলো Go কোডকে এক জায়গায় গুছিয়ে রাখার একটি উপায়, বিশেষ করে যখন আপনার রুট ডিরেক্টরিতে অনেক non-Go কম্পোনেন্ট বা ফোল্ডার থাকে। এতে বিভিন্ন Go টুল চালানো সহজ হয়।
(এই বিষয়ে আরও আলোচনা হয়েছে:
GopherCon EU 2018 [Best Practices for Industrial Programming](https://www.youtube.com/watch?v=PTE4VJIdHPg) , [GopherCon 2018:Kat Zien: How Do You Structure Your Go Apps](https://www.youtube.com/watch?v=oL6JBUk6tj0) এবং [GoLab 2018 – Massimiliano Pippi: Project layout patterns in Go](https://www.youtube.com/watch?v=3gQa1LWwuzk).
আপনি যদি দেখতে চান কোন কোন জনপ্রিয় Go রিপোজিটরি এই লেআউট প্যাটার্ন ব্যবহার করছে, তাহলে [`/pkg`](https://github.com/golang-standards/project-layout/blob/master/pkg/README.md) ডিরেক্টরিটি দেখুন।এই লেআউটটি অনেক সাধারণ, তবে সবার দ্বারা গৃহীত নয়, এবং Go কমিউনিটির কেউ কেউ এটি ব্যবহারের সুপারিশও করে না।
যদি আপনার অ্যাপ প্রজেক্টটি খুব ছোট হয় এবং অতিরিক্ত স্তর (nesting) বড় কোনো উপকার না করে, তাহলে এটি ব্যবহার না করলেও চলবে (অবশ্য আপনি চাইলে করতেই পারেন :-))।যখন আপনার প্রজেক্ট বড় হতে শুরু করবে এবং রুট ডিরেক্টরিটি বেশ ব্যস্ত হয়ে যাবে (বিশেষ করে অনেক non-Go উপাদান থাকলে), তখন এ নিয়ে ভাবা উচিত।
`pkg` ডিরেক্টরির উৎপত্তিঃপুরোনো Go সোর্স কোডে `pkg` ব্যবহার হতো প্যাকেজগুলোর জন্য। পরে কমিউনিটির বিভিন্ন Go প্রজেক্ট এটি অনুকরণ করতে শুরু করে।(বিস্তারিত জানতে Brad Fitzpatrick [এর](https://x.com/bradfitz/status/1039512487538970624) টুইটটি দেখুন)।
### /vendor
অ্যাপ্লিকেশনের ডিপেনডেন্সিগুলো (হাতে বা আপনার পছন্দের ডিপেনডেন্সি ম্যানেজমেন্ট টুল — যেমন Go-এর নতুন বিল্ট-ইন [Go Modules](https://go.dev/wiki/Modules) ফিচার) দ্বারা ম্যানেজ করা হয়।`go mod vendor` কমান্ড চালালে এটি আপনার জন্য `/vendor` ডিরেক্টরি তৈরি করবে।মনে রাখবেন, যদি আপনি Go 1.14 ব্যবহার না করেন, তাহলে `go build` কমান্ডে `-mod=vendor` ফ্ল্যাগ যুক্ত করতে হতে পারে, কারণ Go 1.14-এ এটি ডিফল্টভাবে চালু থাকে।
আপনি যদি একটি লাইব্রেরি তৈরি করছেন, তাহলে আপনার অ্যাপ্লিকেশনের ডিপেনডেন্সিগুলো `/vendor` ডিরেক্টরিতে কমিট করবেন না।
আরও একটি বিষয় [Go 1.13](https://go.dev/doc/go1.13#modules) থেকে Go module proxy ফিচার চালু করেছে, যেখানে ডিফল্টভাবে https://proxy.golang.org ব্যবহার করা হয় মডিউল প্রোক্সি সার্ভার হিসেবে।এটা আপনার সব চাহিদা ও সীমাবদ্ধতার সঙ্গে মানিয়ে যায় কিনা, তা জানতে [এই লিংকে](https://go.dev/blog/module-mirror-launch) আরও পড়ুন।যদি মানিয়ে যায়, তাহলে `/vendor` ডিরেক্টরির আর প্রয়োজন হবে না।
উদাহরণ দেখতে [`/scripts`](https://github.com/golang-standards/project-layout/blob/master/scripts/README.md) ডিরেক্টরি দেখুন।
### `/build`
প্যাকেজিং এবং Continuous Integration সংক্রান্ত ফাইল।
ক্লাউড (AMI), কনটেইনার (Docker), বা অপারেটিং সিস্টেম (deb, rpm, pkg) প্যাকেজের কনফিগারেশন ও স্ক্রিপ্টগুলো `/build/package` ডিরেক্টরিতে রাখুন।
CI টুলস(travis, circle, Drone) ইত্যাদির কনফিগারেশন ও স্ক্রিপ্টগুলো
`/build/ci` ডিরেক্টরিতে রাখুন।মনে রাখবেন, কিছু CI টুল (যেমন Travis CI) কনফিগারেশন ফাইলের অবস্থান নিয়ে খুব সংবেদনশীল।সম্ভব হলে `/build/ci` ডিরেক্টরিতে কনফিগ ফাইল রেখে সেগুলোকে সেই অবস্থানে লিংক করে দিন, যেখানে ওই টুলগুলো ফাইল খুঁজে পায়।
### `/deployments`
IaaS, PaaS, সিস্টেম ও কন্টেইনার অর্কেস্ট্রেশন ডিপ্লয়মেন্ট কনফিগারেশন ও টেমপ্লেট(যেমন: docker-compose, kubernetes/helm, terraform)।অনেক ক্ষেত্রে এই ডিরেক্টরির নাম `/deploy` হয়ে থাকে, বিশেষ করে Kubernetes ডিপ্লয়ড অ্যাপ্লিকেশনে।
### `/test`
অতিরিক্ত এক্সটার্নাল টেস্ট অ্যাপ ও টেস্ট ডেটা।আপনি যেভাবে ইচ্ছা `/test` ডিরেক্টরি সাজাতে পারেন।বড় প্রজেক্টের ক্ষেত্রে একটি আলাদা data সাবডিরেক্টরি রাখা যুক্তিযুক্ত।
উদাহরণস্বরূপ, আপনি চাইলে `/test/data` বা `/test/testdata` ব্যবহার করতে পারেন — বিশেষ করে যদি আপনি চান Go সেই ডিরেক্টরির ভিতরের জিনিসগুলো উপেক্ষা (ignore) করুক।Go এছাড়াও এমন ডিরেক্টরি বা ফাইল উপেক্ষা করে যেগুলোর নাম `.` বা `_` দিয়ে শুরু, তাই নামকরণের ক্ষেত্রে বেশ স্বাধীনতা আছে।
উদাহরণ দেখতে [`/test`](https://github.com/golang-standards/project-layout/blob/master/test/README.md) ডিরেক্টরি দেখুন।
## অন্যান্য ডিরেক্টরিগুলো
### `/docs`
ডিজাইন এবং ইউজার ডকুমেন্টেশন (godoc দিয়ে জেনারেট হওয়া ডকুমেন্টেশনের পাশাপাশি)।
উদাহরণ দেখতে [`/docs`](https://github.com/golang-standards/project-layout/blob/master/docs/README.md) ডিরেক্টরি দেখুন।
### `/tools`
প্রজেক্টে ব্যবহৃত সহায়ক টুলস।এই টুলসগুলো `/pkg` এবং `/internal` ডিরেক্টরি থেকে কোড ইমপোর্ট করতে পারে।
উদাহরণ দেখতে [`/tools`](https://github.com/golang-standards/project-layout/blob/master/tools/README.md) ডিরেক্টরি দেখুন।
### `/examples`
আপনার অ্যাপ্লিকেশন বা পাবলিক লাইব্রেরির উদাহরণ কোড।
উদাহরণ দেখতে [`/examples`](https://github.com/golang-standards/project-layout/blob/master/examples/README.md) ডিরেক্টরি দেখুন।
### `/third_party`
বাইরের হেল্পার টুলস, ফর্ক করা কোড, এবং অন্যান্য 3rd-party ইউটিলিটি (যেমনঃ Swagger UI)।
### `/githooks`
Git হুকস ।
### `/assets`
রিপোজিটরির সাথে সংযুক্ত অন্যান্য ফাইল (যেমন: ছবি, লোগো, মিডিয়া ফাইল ইত্যাদি)।
### `/website`
যদি আপনি GitHub Pages ব্যবহার না করেন, তাহলে আপনার প্রজেক্টের ওয়েবসাইট সংক্রান্ত ফাইল এখানে রাখা উচিত।
উদাহরণ দেখতে [`/website`](https://github.com/golang-standards/project-layout/blob/master/website/README.md) ডিরেক্টরি দেখুন।
## যে ডিরেক্টরিগুলো ব্যবহার করা উচিত নয়
#### `/src`
কিছু Go প্রজেক্টে `/src` ডিরেক্টরি দেখা যায়, তবে এটা সাধারণত তখন হয় যখন ডেভেলপাররা Java ব্যাকগ্রাউন্ড থেকে এসেছে, যেখানে এটি একটি প্রচলিত প্যাটার্ন।
Go-তে এটি ব্যবহার না করাই উত্তম। কারণ আপনি চাইবেন না যে আপনার Go কোড বা প্রজেক্ট দেখতে Java-এর মতো হোক। :)
আপনার প্রজেক্টে থাকা `/src` ডিরেক্টরিকে Go-এর ওয়ার্কস্পেসের `/src` ডিরেক্টরির সঙ্গে মিশিয়ে ফেলবেন না।এটা বোঝার জন্য Go-এর অফিসিয়াল গাইড [How to Write Go Code](https://go.dev/doc/code) দেখে নেওয়া উচিত।`$GOPATH` এনভায়রনমেন্ট ভ্যারিয়েবলটি আপনার (বর্তমান) Go ওয়ার্কস্পেস-কে নির্দেশ করে — ডিফল্টভাবে এটি নন-Windows সিস্টেমে `$HOME/go` ফোল্ডার।এই ওয়ার্কস্পেসে তিনটি শীর্ষ লেভেলের ডিরেক্টরি থাকে: `/pkg`,`/bin`,`/src` ।আপনার প্রকৃত প্রোজেক্টটি সাধারণত `/src` এর নিচে একটি সাব-ডিরেক্টরি হিসেবে থাকে,তাই, যদি আপনি নিজেই আপনার প্রোজেক্টে আরেকটি `/src` ডিরেক্টরি রাখেন, তাহলে আপনার কোডের পাথ দেখতে এমন হবে:
`/some/path/to/workspace/src/your_project/src/your_code.go`।যদিও Go 1.11 থেকে আপনার প্রোজেক্ট `GOPATH`-এর বাইরে রাখা সম্ভব হয়েছে,তবুও এই ধরণের লেআউট প্যাটার্ন (দ্বৈত /src) ব্যবহার করাটা ভালো আইডিয়া নয়।
## ব্যাজসমূহ
- [Go Report Card](https://goreportcard.com/) - এটি `gofmt`, `go vet`, `gocyclo`, `golint`, `ineffassign`, `license` এবং `misspell` দিয়ে আপনার কোড বিশ্লেষণ করে। `github.com/golang-standards/project-layout` এর পরিবর্তে আপনার প্রজেক্টের ইউআরএল দিন।
- [Pkg.go.dev](https://pkg.go.dev) - Go প্যাকেজের ডকুমেন্টেশন ও খোঁজার জন্য এটি একটি নতুন প্ল্যাটফর্ম। [ব্যাজ জেনারেটর টুল](https://pkg.go.dev/badge) ব্যবহার করে ব্যাজ তৈরি করুন।
这是 Go 应用程序项目的基本布局。它不是核心 Go 开发团队定义的官方标准；然而，它是 Go 生态系统中一组常见的老项目和新项目的布局模式。其中一些模式比其他模式更受欢迎。它还具有许多小的增强，以及对任何足够大的实际应用程序通用的几个支持目录。
这是 Go 应用程序项目的基本布局。它不是核心 Go 开发团队定义的官方标准；然而，它是 Go 生态系统中一组常见的老项目和新项目的布局模式。其中一些模式比其他模式更受欢迎。它还具有许多小的增强，以及对任何足够大的实际应用程序通用的几个支持目录。
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Alamgir Hosain