Merge branch 'master' into patch-1

pull/205/head
Kyle Quest 4 months ago committed by GitHub
commit 9b253ad196
No known key found for this signature in database
GPG Key ID: B5690EEEBB952194

1
.gitattributes vendored

@ -0,0 +1 @@
* -text

@ -8,15 +8,21 @@ Translations:
* [简体中文](README_zh-CN.md) - ???
* [Français](README_fr.md)
* [日本語](README_ja.md)
* [Portuguese](README_ptBR.md)
* [Português](README_ptBR.md)
* [Español](README_es.md)
* [Română](README_ro.md)
* [Русский](README_ru.md)
* [Türkçe](README_tr.md)
* [Italiano](README_it.md)
* [Vietnamese](README_vi.md)
* [Українська](README_ua.md)
* [Indonesian](README_id.md)
## Overview
This is a basic layout for Go application projects. It's **`not an official standard defined by the core Go dev team`**; however, it is a set of common historical and emerging project layout patterns in the Go ecosystem. Some of these patterns are more popular than others. It also has a number of small enhancements along with several supporting directories common to any large enough real world application.
This is a basic layout for Go application projects. Note that it's basic in terms of content because it's focusing only on the general layout and not what you have inside. It's also basic because it's very high level and it doesn't go into great details in terms of how you can structure your project even further. For example, it doesn't try to cover the project structure you'd have with something like Clean Architecture.
This is **`NOT an official standard defined by the core Go dev team`**; however, it is a set of common historical and emerging project layout patterns in the Go ecosystem. Some of these patterns are more popular than others. It also has a number of small enhancements along with several supporting directories common to any large enough real world application. Note that the **core Go team provides a great set of general guidelines about structuring Go projects** and what it means for your project when it's imported and when it's installed. See the [`Organizing a Go module`](https://go.dev/doc/modules/layout) page in the official Go docs for more details. It includes the `internal` and `cmd` directory patterns (described below) and other useful information.
**`If you are trying to learn Go or if you are building a PoC or a simple project for yourself this project layout is an overkill. Start with something really simple instead (a single `main.go` file and `go.mod` is more than enough).`** As your project grows keep in mind that it'll be important to make sure your code is well structured otherwise you'll end up with a messy code with lots of hidden dependencies and global state. When you have more people working on the project you'll need even more structure. That's when it's important to introduce a common way to manage packages/libraries. When you have an open source project or when you know other projects import the code from your project repository that's when it's important to have private (aka `internal`) packages and code. Clone the repository, keep what you need and delete everything else! Just because it's there it doesn't mean you have to use it all. None of these patterns are used in every single project. Even the `vendor` pattern is not universal.
@ -26,7 +32,7 @@ This project layout is intentionally generic and it doesn't try to impose a spec
This is a community effort. Open an issue if you see a new pattern or if you think one of the existing patterns needs to be updated.
If you need help with naming, formatting and style start by running [`gofmt`](https://golang.org/cmd/gofmt/) and [`golint`](https://github.com/golang/lint). Also make sure to read these Go code style guidelines and recommendations:
If you need help with naming, formatting and style start by running [`gofmt`](https://golang.org/cmd/gofmt/) and [`staticcheck`](https://github.com/dominikh/go-tools/tree/master/cmd/staticcheck). The previous standard linter, golint, is now deprecated and not maintained; use of a maintained linter such as staticcheck is recommended. Also make sure to read these Go code style guidelines and recommendations:
* https://talks.golang.org/2014/names.slide
* https://golang.org/doc/effective_go.html#names
* https://blog.golang.org/package-names
@ -114,7 +120,7 @@ System init (systemd, upstart, sysv) and process manager/supervisor (runit, supe
Scripts to perform various build, install, analysis, etc operations.
These scripts keep the root level Makefile small and simple (e.g., [`https://github.com/hashicorp/terraform/blob/master/Makefile`](https://github.com/hashicorp/terraform/blob/master/Makefile)).
These scripts keep the root level Makefile small and simple (e.g., [`https://github.com/hashicorp/terraform/blob/main/Makefile`](https://github.com/hashicorp/terraform/blob/main/Makefile)).
See the [`/scripts`](scripts/README.md) directory for examples.
@ -128,7 +134,7 @@ Put your CI (travis, circle, drone) configurations and scripts in the `/build/ci
### `/deployments`
IaaS, PaaS, system and container orchestration deployment configurations and templates (docker-compose, kubernetes/helm, mesos, terraform, bosh). Note that in some repos (especially apps deployed with kubernetes) this directory is called `/deploy`.
IaaS, PaaS, system and container orchestration deployment configurations and templates (docker-compose, kubernetes/helm, terraform). Note that in some repos (especially apps deployed with kubernetes) this directory is called `/deploy`.
### `/test`

@ -14,6 +14,10 @@ Traducciones:
* [Română](README_ro.md)
* [Русский](README_ru.md)
* [Türkçe](README_tr.md)
* [Italiano](README_it.md)
* [Vietnamese](README_vi.md)
* [Українська](README_ua.md)
* [Indonesian](README_id.md)
## Resumen
@ -114,7 +118,7 @@ Configuraciones de inicio del sistema (systemd, upstart, sysv) y administración
Scripts para realizar varias operaciones de construcción, instalación, análisis, etc.
Estos scripts mantienen el Makefile de nivel raíz pequeño y simple (p.ej, [`https://github.com/hashicorp/terraform/blob/master/Makefile`](https://github.com/hashicorp/terraform/blob/master/Makefile)).
Estos scripts mantienen el Makefile de nivel raíz pequeño y simple (p.ej, [`https://github.com/hashicorp/terraform/blob/main/Makefile`](https://github.com/hashicorp/terraform/blob/main/Makefile)).
Consulte el directorio `/scripts` para ver ejemplos.

@ -14,6 +14,10 @@ Traductions:
* [Română](README_ro.md)
* [Русский](README_ru.md)
* [Türkçe](README_tr.md)
* [Italiano](README_it.md)
* [Vietnamese](README_vi.md)
* [Українська](README_ua.md)
* [Indonesian](README_id.md)
## Introduction
@ -67,7 +71,7 @@ Vous pouvez également ajouter un peu de structure dans vos packages internes po
### `/pkg`
Placez-y le code qui peut être réutilisé par les applications externes (p. ex., `/pkg/mypubliclib`). D'autres projets peuvent importer ces bibliothèques et s'attendent donc à ce qu'elles soient fonctionnelles, pensez y donc à deux fois avant de mettre du code dans ce dossier :-) Utiliser le dossier `internal` est une manière plus adéquate de garder vos packages privés et non importables car c'est intégré au compilateur Go. Le dossier `/pkg` est nénanmoins une bonne manière d'indiquer que le code contenu dans ce dossier peut être utilisé par les autres utilisateurs sans problème. L'article de blog de Travis Jeffery [`I'll take pkg over internal`](https://travisjeffery.com/b/2019/11/i-ll-take-pkg-over-internal/) explique plus en détail les différences entre les dossier `pkg` et `internal` et quand il fait sens de les utiliser.
Placez-y le code qui peut être réutilisé par les applications externes (p. ex., `/pkg/mypubliclib`). D'autres projets peuvent importer ces bibliothèques et s'attendent donc à ce qu'elles soient fonctionnelles, pensez y donc à deux fois avant de mettre du code dans ce dossier :-) Utiliser le dossier `internal` est une manière plus adéquate de garder vos packages privés et non importables car c'est intégré au compilateur Go. Le dossier `/pkg` est néanmoins une bonne manière d'indiquer que le code contenu dans ce dossier peut être utilisé par les autres utilisateurs sans problème. L'article de blog de Travis Jeffery [`I'll take pkg over internal`](https://travisjeffery.com/b/2019/11/i-ll-take-pkg-over-internal/) explique plus en détail les différences entre les dossier `pkg` et `internal` et quand il fait sens de les utiliser.
C'est également une manière de regrouper tout votre code Go au même endroit lorsque votre dossier racine comporte de nombreux composants et dossiers non-Go, permettant plus facilement de lancer les différents outils Go, tel que mentionné dans les conférences suivantes : [`Best Practices for Industrial Programming`](https://www.youtube.com/watch?v=PTE4VJIdHPg) lors de GopherCon EU 2018, [GopherCon 2018: Kat Zien - How Do You Structure Your Go Apps](https://www.youtube.com/watch?v=oL6JBUk6tj0) et [GoLab 2018 - Massimiliano Pippi - Project layout patterns in Go](https://www.youtube.com/watch?v=3gQa1LWwuzk)).
@ -113,7 +117,7 @@ Initialisation du système (systemd, upstart, sysv) et configurations des admini
Scripts permettant différentes opérations telles que le build, l'installation, des analyses, ...
Ces scripts permettent de garder le Makefile du dossier racine réduit et simple (p. ex., [`https://github.com/hashicorp/terraform/blob/master/Makefile`](https://github.com/hashicorp/terraform/blob/master/Makefile)).
Ces scripts permettent de garder le Makefile du dossier racine réduit et simple (p. ex., [`https://github.com/hashicorp/terraform/blob/main/Makefile`](https://github.com/hashicorp/terraform/blob/main/Makefile)).
Voir le dossier [`/scripts`](scripts/README.md) pour des exemples.

@ -0,0 +1,206 @@
# Standar Tata Letak Proyek Go
Terjemahan:
* [한국어 문서](README_ko.md)
* [简体中文](README_zh.md)
* [正體中文](README_zh-TW.md)
* [简体中文](README_zh-CN.md) - ???
* [Français](README_fr.md)
* [日本語](README_ja.md)
* [Portuguese](README_ptBR.md)
* [Español](README_es.md)
* [Română](README_ro.md)
* [Русский](README_ru.md)
* [Türkçe](README_tr.md)
* [Українська](README_ua.md)
* [Indonesian](README_id.md)
## Ringkasan
Berikut ini merupakan tata letak dasar untuk proyek aplikasi Go. Ini **`bukan standar resmi yang ditetapkan oleh tim pengembang inti Go`**; namun, ini merupakan sejumlah pola tata letak proyek historis dan terkini yang umumnya digunakan dalam ekosistem Go. Beberapa pola ini lebih populer daripada yang lain. Selain itu, terdapat beberapa pembaharuan kecil bersama dengan beberapa direktori pendukung yang umum ditemukan dalam aplikasi dunia nyata yang cukup besar.
Jika kamu sedang belajar Go atau sedang membangun PoC atau proyek sederhana untuk dirimu sendiri, tata letak proyek ini terlalu berlebihan. Mulailah dengan sesuatu yang sederhana saja (sebuah file `main.go` tunggal dan `go.mod` sudah cukup). Ketika proyekmu berkembang, penting untuk memastikan kodemu terstruktur dengan baik, jika tidak, kamu akan berakhir dengan kode yang berantakan dengan banyak dependensi tersembunyi dan state global. Ketika ada lebih banyak orang yang bekerja pada proyekmu, kamu akan membutuhkan struktur yang lebih terorganisir. Itulah saat yang penting untuk memperkenalkan cara umum dalam mengelola paket/pustaka. Ketika kamu memiliki proyek open source atau ketika kamu tahu proyek lain mengimpor kode dari repositori proyekmu, saat itulah penting untuk memiliki paket dan kode pribadi (dikenal juga sebagai `internal`). Klon repositori tersebut, ambil yang kamu butuhkan, dan hapus sisanya! Hanya karena ada di sana, tidak berarti kamu harus menggunakan semuanya. Tidak satu pun dari pola-pola ini digunakan dalam setiap proyek. Bahkan pola `vendor` tidaklah universal.
Dengan Go 1.14, [`Go Modules`](https://github.com/golang/go/wiki/Modules) akhirnya siap digunakan untuk produksi. Gunakan [`Go Modules`](https://blog.golang.org/using-go-modules) kecuali kamu memiliki alasan khusus untuk tidak menggunakannya. Jika kamu tidak menggunakan Go Modules, maka kamu tidak perlu khawatir tentang `$GOPATH` dan di mana kamu meletakkan proyekmu. File `go.mod` di dalam repositori ini mengasumsikan bahwa proyekmu di-host di GitHub, tetapi itu bukan menjadi persyaratan. Path modul dapat menjadi apa saja, meskipun komponen path modul pertama sebaiknya memiliki tanda titik dalam namanya (versi Go saat ini tidak lagi memaksakannya, tetapi jika kamu menggunakan versi yang sedikit lebih lama, jangan heran jika proses build tidak akan berhasil). Lihat isu [`37554`](https://github.com/golang/go/issues/37554) dan [`32819`](https://github.com/golang/go/issues/32819) jika kamu ingin tahu lebih banyak mengenai hal ini.
Tata letak proyek ini sengaja dirancang secara generik dan tidak mencoba memaksakan struktur paket Go yang spesifik.
Ini merupakan usaha komunitas. Buka sebuah isu jika kamu melihat pola baru atau jika kamu berpikir bahwa salah satu pola yang sudah ada perlu diperbarui.
Jika kamu membutuhkan bantuan dalam hal penamaan, pemformatan, dan gaya penulisan, mulailah dengan menjalankan [`gofmt`](https://golang.org/cmd/gofmt/) dan [`golint`](https://github.com/golang/lint). Pastikan juga untuk membaca panduan dan rekomendasi gaya penulisan kode Go berikut ini:
* https://talks.golang.org/2014/names.slide
* https://golang.org/doc/effective_go.html#names
* https://blog.golang.org/package-names
* https://github.com/golang/go/wiki/CodeReviewComments
* [Style guideline for Go packages](https://rakyll.org/style-packages) (rakyll/JBD)
Lihatlah [`Go Project Layout`](https://medium.com/golang-learn/go-project-layout-e5213cdcfaa2) untuk informasi latar belakang tambahan.
Lebih lanjut tentang penamaan dan pengorganisasian paket serta rekomendasi struktur kode lainnya:
* [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)
Sebuah postingan dalam bahasa Cina tentang pedoman Package-Oriented Design dan Architecture layer:
* [面向包的设计和架构分层](https://github.com/danceyoung/paper-code/blob/master/package-oriented-design/packageorienteddesign.md)
## Direktori Go
### `/cmd`
Aplikasi utama untuk proyek ini.
Nama direktori untuk setiap aplikasi harus sesuai dengan nama file eksekusi yang diinginkan (misalnya, `/cmd/myapp`).
Jangan menempatkan banyak kode di dalam direktori aplikasi. Jika anda berpikir bahwa kode tersebut dapat diimpor dan digunakan dalam proyek lain, maka kode tersebut harus ditempatkan di dalam direktori `/pkg`. Jika kode tersebut tidak dapat digunakan kembali atau jika anda tidak ingin orang lain menggunakannya kembali, letakkan kode tersebut di dalam direktori `/internal`. Anda akan terkejut dengan apa yang orang lain lakukan, jadi tetap jelaskan niat anda!
Biasanya, terdapat fungsi `main` kecil yang mengimpor dan memanggil kode dari direktori `/internal` dan `/pkg`, dan tidak ada yang lain.
Lihat direktori [`/cmd`](cmd/README.md) untuk contoh-contoh lebih lanjut.
### `/internal`
Kode aplikasi dan library privat. Ini adalah kode anda yang tidak ingin diimpor oleh aplikasi atau library lain. Perlu dicatat bahwa pola tata letak ini dipaksakan atau dijaga oleh kompiler Go itu sendiri. Lihat catatan rilis Go 1.4 [`di sini`](https://golang.org/doc/go1.4#internalpackages) untuk detailnya. Perhatikan bahwa anda tidak dibatasi pada direktori top level `internal` saja. Anda dapat memiliki lebih dari satu direktori `internal` di setiap tingkatan proyek anda.
Secara opsional anda dapat menambahkan struktur tambahan ke paket internal anda, untuk memisahkan kode internal yang bersifat shared dan non-shared. Hal ini tidak diwajibkan (terutama untuk proyek-proyek kecil), tetapi bagus untuk memiliki petunjuk visual yang menunjukkan penggunaan paket yang dimaksudkan. Sebenarnya kode aplikasi dapat ditempatkan di direktori `/internal/app` (misalnya, `/internal/app/myapp`) dan kode yang dibagikan oleh aplikasi tersebut dapat ditempatkan di direktori `/internal/pkg` (misalnya, `/internal/pkg/myprivlib`).
### `/pkg`
Kode library yang boleh digunakan oleh aplikasi eksternal (misalnya, `/pkg/mypubliclib`). Proyek lain akan mengimpor library ini dengan harapan dapat berfungsi, jadi berpikirlah dua kali sebelum anda meletakkan sesuatu di sini :-) Perlu dicatat bahwa direktori `internal` adalah cara yang lebih baik untuk memastikan paket pribadi anda tidak dapat diimpor karena dijaga oleh Go. Namun, direktori `/pkg` tetap cara yang baik untuk mengkomunikasikan secara eksplisit bahwa kode di dalam direktori tersebut aman digunakan oleh orang lain. Postingan [`I'll take pkg over internal`](https://travisjeffery.com/b/2019/11/i-ll-take-pkg-over-internal/) oleh Travis Jeffery memberikan gambaran yang baik tentang direktori `pkg` dan `internal` serta kapan waktu yang tepat untuk menggunakannya.
Hal ini merupakan cara untuk mengelompokkan kode Go di satu tempat ketika direktori root anda berisi banyak komponen dan direktori non-Go, sehingga memudahkan dalam menjalankan berbagai tools Go (seperti yang disebutkan dalam presentasi-presentasi ini: [`Best Practices for Industrial Programming`](https://www.youtube.com/watch?v=PTE4VJIdHPg) dari GopherCon EU 2018, [GopherCon 2018: Kat Zien - How Do You Structure Your Go Apps](https://www.youtube.com/watch?v=oL6JBUk6tj0), dan [GoLab 2018 - Massimiliano Pippi - Project layout patterns in Go](https://www.youtube.com/watch?v=3gQa1LWwuzk)).
Lihat direktori [`/pkg`](pkg/README.md) jika anda ingin melihat repositori Go populer yang menggunakan pola tata letak proyek seperti ini. Ini adalah pola tata letak yang umum digunakan, akan tetapi tidak diterima secara universal dan beberapa anggota komunitas Go tidak merekomendasikannya.
Tidak masalah jika anda tidak menggunakannya, apabila proyek aplikasi anda benar-benar kecil dan tingkatan level tambahan tidak begitu penting (kecuali jika anda benar-benar menginginkannya :-)). Pikirkanlah hal tersebut ketika proyek anda cukup besar dan direktori root anda sudah cukup sibuk (terutama jika anda memiliki banyak komponen aplikasi non-Go).
Asal-usul direktori `pkg`: Source code Go yang lama menggunakan `pkg` untuk paket-paketnya, dan kemudian berbagai proyek Go dalam komunitas mulai meniru pola tersebut (Lihat [`tweet Brad Fitzpatrick ini`](https://twitter.com/bradfitz/status/1039512487538970624) untuk konteks lebih lanjut).
### `/vendor`
Dependensi aplikasi (dikelola secara manual atau dengan dependency management tool favorit anda seperti fitur baru bawaan [`Go Modules`](https://github.com/golang/go/wiki/Modules). Perintah `go mod vendor` akan membuat direktori `/vendor `untuk anda. Perlu dicatat bahwa anda mungkin perlu menambahkan flag `-mod=vendor` ke perintah `go build` jika anda tidak menggunakan Go 1.14 di mana fitur tersebut sudah diaktifkan secara default.
Jangan meng-commit dependency aplikasi anda jika anda sedang membangun sebuah library.
Perlu dicatat bahwa sejak versi [`1.13`](https://golang.org/doc/go1.13#modules), Go telah mengaktifkan fitur module proxy (menggunakan [`https://proxy.golang.org`](https://proxy.golang.org) sebagai server proxy modul default). Baca lebih lanjut tentang fitur ini [`di sini`](https://blog.golang.org/module-mirror-launch) untuk melihat apakah sesuai dengan semua persyaratan dan batasan anda. Jika sesuai, maka anda sama sekali tidak perlu menggunakan direktori `vendor`.
## Direktori Servis Aplikasi
### `/api`
Spesifikasi OpenAPI/Swagger, file skema JSON, file definisi protokol.
Lihat direktori [`/api`](api/README.md) untuk contoh-contohnya.
### `/web`
Komponen-komponen spesifik aplikasi web: aset web statis, template di sisi server, dan SPAs.
## Direktori Umum Aplikasi
### `/configs`
Template file konfigurasi atau konfigurasi default.
Letakkan file template anda di `confd` atau `consul-template`..
### `/init`
Konfigurasi sistem init (systemd, upstart, sysv) dan manajer proses/supervisor (runit, supervisord).
### `/scripts`
Skrip-skrip untuk melakukan berbagai operasi seperti build, instalasi, analisis, dll.
Skrip-skrip ini menjaga Makefile tingkat root agar tetap kecil dan sederhana (misalnya, [`https://github.com/hashicorp/terraform/blob/master/Makefile`](https://github.com/hashicorp/terraform/blob/master/Makefile)).
Lihat direktori [`/scripts`](scripts/README.md) untuk melihat contoh-contohnya.
### `/build`
Pemaketan (Packaging) dan Integrasi Berkelanjutan (Continuous Integration).
Letakkan skrip paket dan konfigurasi untuk cloud (AMI), container (Docker), sistem operasi (deb, rpm, pkg) anda di direktori `/build/package`.
Letakkan skrip dan konfigurasi CI (travis, circle, drone) anda di direktori `/build/ci`. Perhatikan bahwa beberapa tools CI (misalnya, Travis CI) sangat ketat mengenai lokasi file konfigurasi mereka. Coba letakkan file konfigurasi di direktori `/build/ci` dan buat tautan ke lokasi yang diharapkan oleh tools CI (jika memungkinkan).
### `/deployments`
Konfigurasi dan template untuk IaaS, PaaS, orkestrasi sistem, dan container (docker-compose, kubernetes/helm, mesos, terraform, bosh). Perhatikan bahwa dalam beberapa repositori (terutama aplikasi yang diimplementasikan dengan kubernetes), direktori ini disebut `/deploy`.
### `/test`
Tambahan eksternal untuk menguji aplikasi dan data. Aturlah struktur direktori `/test` sesuai keinginan anda. Untuk proyek yang lebih besar, disarankan memiliki subdirektori data. Misalnya, anda dapat memiliki `/test/data` atau `/test/testdata` jika anda ingin Go mengabaikan apa yang ada dalam direktori tersebut. Perhatikan bahwa Go juga akan mengabaikan direktori atau file yang dimulai dengan "." atau "_", sehingga anda memiliki fleksibilitas lebih dalam penamaan direktori data pengujian.
Lihat direktori [`/test`](test/README.md) untuk contoh-contohnya.
## Direktori Lainya
### `/docs`
Dokumentasi desain dan pengguna (selain dokumentasi yang dihasilkan oleh godoc).
Lihat direktori [`/docs`](docs/README.md) untuk contoh-contohnya.
### `/tools`
Tools pendukung untuk proyek ini. Perhatikan bahwa tools ini dapat mengimpor kode dari direktori `/pkg` dan `/internal`.
Lihat direktori [`/tools`](tools/README.md) untuk contoh-contohnya.
### `/examples`
Contoh-contoh aplikasi atau library publik anda.
Lihat direktori [`/examples`](examples/README.md) untuk melihat contoh-contohnya.
### `/third_party`
Tools eksternal, kode yang di-fork, dan utilitas pihak ketiga (third party) lainnya (misalnya, Swagger UI).
### `/githooks`
Git hooks.
### `/assets`
Aset lainnya yang ada di repositori anda (gambar, logo, dll).
### `/website`
Tempat untuk meletakkan data situs web proyek anda jika anda tidak menggunakan halaman GitHub.
Lihat direktori [`/website`](website/README.md) untuk contoh-contohnya.
## Direktori yang Sebaiknya Tidak Dimiliki
### `/src`
Beberapa proyek Go memiliki folder `src`, akan tetapi ini biasanya terjadi ketika pengembang berasal dari dunia Java di mana itu adalah pola umum. Jika memungkinkan, hindari mengadopsi pola Java ini. Anda benar-benar tidak ingin kode Go atau proyek Go anda terlihat seperti Java :-)
Jangan bingung antara direktori proyek `/src` dengan direktori `/src` yang digunakan Go untuk workspace-nya seperti yang dijelaskan dalam [`How to Write Go Code`](https://golang.org/doc/code.html). Variabel environtment `$GOPATH` menunjuk ke workspace anda saat ini (secara default menunjuk ke `$HOME/go` pada sistem non-Windows). Workspace ini mencakup direktori top level `/pkg`, `/bin`, dan `/src`. Proyek aktual anda berada di bawah direktori `/src`, jadi jika anda memiliki direktori `/src` di proyek anda, path proyek akan terlihat seperti ini: `/some/path/to/workspace/src/your_project/src/your_code.go`. Perlu diingat bahwa dengan Go 1.11, memungkinkan untuk memiliki proyek di luar `GOPATH`, tetapi bukan berarti itu adalah ide yang baik untuk menggunakan pola tata letak ini.
## Badges
* [Go Report Card](https://goreportcard.com/) - Akan memindai kode anda menggunakan `gofmt`, `go vet`, `gocyclo`, `golint`, `ineffassign`, `license` dan `misspell`. Ubah `github.com/golang-standards/project-layout` dengan referensi proyek anda.
[![Go Report Card](https://goreportcard.com/badge/github.com/golang-standards/project-layout?style=flat-square)](https://goreportcard.com/report/github.com/golang-standards/project-layout)
* ~~[GoDoc](http://godoc.org) -Ini akan menyediakan versi online dari dokumentasi yang dihasilkan oleh GoDoc anda. Ubah tautan tersebut agar mengarah ke proyek anda.~~
[![Go Doc](https://img.shields.io/badge/godoc-reference-blue.svg?style=flat-square)](http://godoc.org/github.com/golang-standards/project-layout)
* [Pkg.go.dev](https://pkg.go.dev) - Pkg.go.dev adalah tempat baru untuk menemukan dan mendokumentasikan Go. Anda dapat membuat badge menggunakan [badge generation tool](https://pkg.go.dev/badge).
[![PkgGoDev](https://pkg.go.dev/badge/github.com/golang-standards/project-layout)](https://pkg.go.dev/github.com/golang-standards/project-layout)
* Release - Ini akan menampilkan nomor rilisan terbaru untuk proyek anda. Ubah tautan GitHub menjadi menunjuk ke proyek anda.
[![Release](https://img.shields.io/github/release/golang-standards/project-layout.svg?style=flat-square)](https://github.com/golang-standards/project-layout/releases/latest)
## Catatan
Opsi template lainya disertai contoh konfigurasi, skrip, dan kode yang dapat digunakan kembali sedang dalam pengembangan (WIP).

@ -13,12 +13,14 @@ Traduzioni:
* [Română](README_ro.md)
* [Русский](README_ru.md)
* [Türkçe](README_tr.md)
* [Українська](README_ua.md)
* [Indonesian](README_id.md)
## Panoramica
Questa è un'impostazione di base per applicativi Go. **Non è uno standard ufficiale definito dal team principale di Go**; Invece è un insieme di pattern archittetturali provenienti da progetti ben consolidati nell'ecosistema Go. Alcuni di questi patterns sono più popolari di altri. Sono presenti anche diversi piccoli miglioramenti con alcune cartelle di supporto comuni a qualsiasi grande applicativo in contesto reale.
Questa è un'impostazione di base per applicativi Go. **Non è uno standard ufficiale definito dal team principale di Go**; Invece è un insieme di pattern archittetturali provenienti da progetti ben consolidati nell'ecosistema Go. Alcuni di questi pattern sono più popolari di altri. Sono presenti anche diversi piccoli miglioramenti con alcune cartelle di supporto comuni a qualsiasi grande applicativo in contesto reale.
**`Se stai imparando Go o se stai sviluppando una PoC o un semplice progetto personale, questa struttura è una complicazione non necessaria. Invece inizia con qualcosa di veramente semplice (un unico file `main.go` e `go.mod` è abbastanza).`** Con la crescita del tuo progetto tieni a mente che sarà sempre più importante la corretta impostazione del tuo codice, altrimenti finirai con codice disordinato con molte dipendenze nascoste e uno stato globale. Quando più persone lavorano su un progetto, avrai bisogno di un'impostazione ancora più strutturata. Questo è il momento in cui è importante introdurre un modo comune di gestire pacchetti e librerie. Quando hai un progetto open source o quando sai che altri progetti importano il codice del tuo repository, questo è il momento in cui è importante avere pacchetti e codice privato (`internal`). Clona il repository, mantieni ciò di cui hai bisogno e cancella qualsiasi altra cosa! Solo perchè è presente non significa che vada usato. Nessuno di questi patterns sono usati in ogni singolo progetto. Perfino il `vendor` pattern non è universale.
**`Se stai imparando Go o se stai sviluppando una PoC o un semplice progetto personale, questa struttura è una complicazione non necessaria. Invece inizia con qualcosa di veramente semplice (un unico file `main.go` e `go.mod` è abbastanza).`** Con la crescita del tuo progetto tieni a mente che sarà sempre più importante la corretta impostazione del tuo codice, altrimenti finirai con codice disordinato con molte dipendenze nascoste e uno stato globale. Quando più persone lavorano su un progetto, avrai bisogno di un'impostazione ancora più strutturata. Questo è il momento in cui è importante introdurre un modo comune di gestire pacchetti e librerie. Quando hai un progetto open source o quando sai che altri progetti importano il codice del tuo repository, questo è il momento in cui è importante avere pacchetti e codice privato (`internal`). Clona il repository, mantieni ciò di cui hai bisogno e cancella qualsiasi altra cosa! Solo perchè è presente non significa che vada usato. Nessuno di questi pattern sono usati in ogni singolo progetto. Perfino il `vendor` pattern non è universale.
Con Go 1.14 i [`Go Modules`](https://github.com/golang/go/wiki/Modules) sono finalmente pronti per la produzione. Usa [`Go Modules`](https://blog.golang.org/using-go-modules) fino a quando hai una specifica ragione per non usarli e se lo farai non dovrai preoccuparti riguardo $GOPATH e dove mettere il tuo progetto. Il file `go.mod` di base nel repo presuppone che il tuo progetto sia pubblicato su GitHub, ma non è obbligatorio. Il path del modulo può essere uno qualsiasi, anche se la prima parte del path del modulo dovrebbe avere un punto nel nome (l'attuale versione di Go non lo forza più, ma se stai usando una delle versioni leggermente più vecchie, non essere sorpreso se le tue builds falliranno). Guarda le Issues [`37554`](https://github.com/golang/go/issues/37554) e [`32819`](https://github.com/golang/go/issues/32819) se vuoi saperne di più a riguardo.
@ -63,17 +65,17 @@ Vedi cartella [`/cmd`](cmd/README.md) per esempi.
Applicativo privato e codice di libreria. Quì c'è il codice che non vuoi gli altri importino nei loro progetti o librerie. Nota che questo pattern archittetturale è forzato dallo stesso compilatore Go. Vedi Go 1.4 [`release notes`](https://golang.org/doc/go1.4#internalpackages) per maggiori dettagli. Nota che non sei obbligato ad avere unicamente la cartella padre `internal`. Puoi avere più di una singola cartella `internal` a qualsiasi livello della tua ramificazione di progetto.
Puoi opzionalmente aggiungere una struttura aggiuntiva ai tuoi pacchetti interni, per separare il tuo codice interno condiviso e non condiviso. Non è obbligatorio (specialmente per piccoli progetti), ma è meglio avere indicazioni per mostrare l'utilizzo raccomandato del pacchetto. Il tuo effettivo codice applicativo, può essere inserito nella cartella `/internal/app` (es: `/internal/app/myapp`) e il codice condiviso da queste apps nella cartella `/internal/pkg` (es: `/internal/pkg/myprivlib`).
Puoi opzionalmente aggiungere una struttura aggiuntiva ai tuoi pacchetti interni, per separare il tuo codice interno condiviso e non condiviso. Non è obbligatorio (specialmente per piccoli progetti), ma è meglio avere indicazioni per mostrare l'utilizzo raccomandato del pacchetto. Il tuo effettivo codice applicativo può essere inserito nella cartella `/internal/app` (es: `/internal/app/myapp`) e il codice condiviso da queste app nella cartella `/internal/pkg` (es: `/internal/pkg/myprivlib`).
### `/pkg`
Codice di libreria che può essere utilizzato da applicazioni esterne (es:, `/pkg/mypubliclib`). Altri progetti importeranno queste librerie aspettandosi che funzionino, quindi pensaci bene prima di metterci dentro qualcosa :-) Nota che la cartella `internal` è un modo migliore di assicurarsi che i tuoi pacchetti privati non sono importabili, perchè ciò è forzato in Go. La cartella `/pkg` è anche un buon modo di esplicitare che il codice contenuto al suo interno è utilizzabile da parte di altri. Il post [`I'll take pkg over internal`](https://travisjeffery.com/b/2019/11/i-ll-take-pkg-over-internal/) scritto da Travis Jeffery fornisce una buona panoramica delle cartelle `pkg` e `internal` indicando quando ha senso usarle.
Codice di libreria che può essere utilizzato da applicazioni esterne (es:, `/pkg/mypubliclib`). Altri progetti importeranno queste librerie aspettandosi che funzionino, quindi pensaci bene prima di metterci dentro qualcosa :-) Nota che la cartella `internal` è un modo migliore di assicurarsi che i tuoi pacchetti privati non sono importabili, perché ciò è forzato in Go. La cartella `/pkg` è anche un buon modo di esplicitare che il codice contenuto al suo interno è utilizzabile da parte di altri. Il post [`I'll take pkg over internal`](https://travisjeffery.com/b/2019/11/i-ll-take-pkg-over-internal/) scritto da Travis Jeffery fornisce una buona panoramica delle cartelle `pkg` e `internal` indicando quando abbia senso usarle.
C'è anche un modo di raggruppare il codice Go in unico posto quando la tua cartella di root contiene molti componenti non-Go e cartelle semplificando l'utilizzo di vari strumenti Go (come menzionato in questi talks: [`Best Practices for Industrial Programming`](https://www.youtube.com/watch?v=PTE4VJIdHPg) dal GopherCon EU 2018, [GopherCon 2018: Kat Zien - How Do You Structure Your Go Apps](https://www.youtube.com/watch?v=oL6JBUk6tj0) e [GoLab 2018 - Massimiliano Pippi - Project layout patterns in Go](https://www.youtube.com/watch?v=3gQa1LWwuzk)).
C'è anche un modo di raggruppare il codice Go in unico posto quando la tua cartella di root contiene molti componenti non-Go e cartelle semplificando l'utilizzo di vari strumenti Go (come menzionato in questi talk: [`Best Practices for Industrial Programming`](https://www.youtube.com/watch?v=PTE4VJIdHPg) dal GopherCon EU 2018, [GopherCon 2018: Kat Zien - How Do You Structure Your Go Apps](https://www.youtube.com/watch?v=oL6JBUk6tj0) e [GoLab 2018 - Massimiliano Pippi - Project layout patterns in Go](https://www.youtube.com/watch?v=3gQa1LWwuzk)).
Guarda la cartella [`/pkg`](pkg/README.md) se vuoi vedere quali popolari repos utilizzano questa struttura di progetto. Questo è un pattern di layout comune, tuttavia non è universalmente accettato e qualcuno nella community Go non lo raccomanda.
Guarda la cartella [`/pkg`](pkg/README.md) se vuoi vedere quali popolari repo utilizzano questa struttura di progetto. Questo è un pattern di layout comune, tuttavia non è universalmente accettato e qualcuno nella community Go non lo raccomanda.
E' ok non utilizzarla se il tuo progetto è molto piccolo e aggiungere un ulteriore strato di nesting non dà un valore aggiunto (a meno che tu non lo voglia davvero molto :-)). Pensa di prevederla quando sta diventando grande abbastanza e la tua cartella root si sta riempendo troppo (specialmente quando hai molti componenti non Go nell'applicativo).
È ok non utilizzarla se il tuo progetto è molto piccolo e aggiungere un ulteriore strato di annidamento non dà un valore aggiunto (a meno che tu non lo voglia davvero molto :-)). Pensa di prevederla quando sta diventando grande abbastanza e la tua cartella root si sta riempendo troppo (specialmente quando hai molti componenti non Go nell'applicativo).
Origini della cartella `pkg`: Il vecchio codice sorgente di Go usava la cartella `pkg` per i suoi pacchetti e così diversi progetti Go nella community hanno iniziato a copiare questo pattern (vedi [`questo`](https://twitter.com/bradfitz/status/1039512487538970624) tweet di Brad Fitzpatrick per avere un contesto più dettagliato).
@ -113,9 +115,9 @@ Inizializzazione del sistema (systemd, upstart, sysv) e configurazioni per proce
### `/scripts`
Scripts per effettuare varie operazioni per la build, installazione, analisi, ecc...
Script per effettuare varie operazioni per la build, installazione, analisi, ecc...
Questi scripts mantengono a livello di root un Makefile piccolo e immediato (es: [`https://github.com/hashicorp/terraform/blob/master/Makefile`](https://github.com/hashicorp/terraform/blob/master/Makefile)).
Questi script mantengono a livello di root un Makefile piccolo e immediato (es: [`https://github.com/hashicorp/terraform/blob/master/Makefile`](https://github.com/hashicorp/terraform/blob/master/Makefile)).
Vedi la cartella [`/scripts`](scripts/README.md) per esempi.
@ -123,17 +125,17 @@ Vedi la cartella [`/scripts`](scripts/README.md) per esempi.
Packaging e Continuous Integration.
Metti le configurazioni dei tuoi pacchetti: cloud (AMI), container (Docker), OS (deb, rpm, pkg) e scripts nella cartella `/build/package`.
Metti le configurazioni dei tuoi pacchetti: cloud (AMI), container (Docker), OS (deb, rpm, pkg) e script nella cartella `/build/package`.
Metti le tue configurazioni della CI (travis, circle, drone) e scripts nella cartella `/build/ci`. Nota che qualche tool di CI (es: Travis CI) sono molto stringenti riguardo la posizione dei propri files di configurazione. Prova mettendo le configurazioni nella cartella `/build/ci` collegandole al percorso dove i strumenti di CI se le aspettano (quando possibile).
Metti le tue configurazioni della CI (travis, circle, drone) e script nella cartella `/build/ci`. Nota che qualche tool di CI (es: Travis CI) sono molto stringenti riguardo la posizione dei propri file di configurazione. Prova mettendo le configurazioni nella cartella `/build/ci` collegandole al percorso dove gli strumenti di CI se le aspettano (quando possibile).
### `/deployments`
Configurazioni e templates per distribuzioni IaaS, PaaS, di sistema e basati su sistemi di orchestrazione (docker-compose, kubernetes/helm, mesos, terraform, bosh). Nota che in alcuni repos (specialmente per gli applicativi pubblicati con kubernetes) questa cartella è chiamata `/deploy`.
Configurazioni e template per distribuzioni IaaS, PaaS, di sistema e basati su sistemi di orchestrazione (docker-compose, kubernetes/helm, mesos, terraform, bosh). Nota che in alcuni repo (specialmente per gli applicativi pubblicati con kubernetes) questa cartella è chiamata `/deploy`.
### `/test`
Ulteriori app di test esterne e dati di test. Sentiti libero di strutturare la cartella `/test` come preferisci. Per progetti più grandi ha senso avere una sotto cartella data. Per esempio potresti avere `/test/data` o `/test/testdata` se hai bisogno che Go ignori il contenuto di questa cartella. Nota che Go ignorerà anche le cartelle o files che iniziano con "." o "_", così si ha più flessibilità in termini di come intendi chiamare la cartella dei tuoi dati test.
Ulteriori app di test esterne e dati di test. Sentiti libero di strutturare la cartella `/test` come preferisci. Per progetti più grandi ha senso avere una sotto cartella data. Per esempio potresti avere `/test/data` o `/test/testdata` se hai bisogno che Go ignori il contenuto di questa cartella. Nota che Go ignorerà anche le cartelle o file che iniziano con "." o "_", così si ha più flessibilità in termini di come intendi chiamare la cartella dei tuoi dati test.
Vedi la cartella [`/test`](test/README.md) per esempi.
@ -159,15 +161,15 @@ Vedi la cartella [`/examples`](examples/README.md) per esempi.
### `/third_party`
Strumenti esterni di aiuto, codice forcato e altre utilities di terze parti (es: Swagger UI).
Strumenti esterni di aiuto, codice forcato e altre utility di terze parti (es: Swagger UI).
### `/githooks`
Git hooks.
Hook di Git.
### `/assets`
Altri assets del tuo repository (immagini, loghi, etc).
Altri asset del tuo repository (immagini, loghi, etc).
### `/website`
@ -181,7 +183,7 @@ Vedi la cartella [`/website`](website/README.md) per esempi.
Qualche progetto Go ha una cartella `src`, ma comunemente succede quando gli sviluppatori provengono dal mondo Java, dove è una pratica comune. Se vuoi aiutarti prova a non adottare questo pattern Java. Non vuoi davvero che il tuo codice Go o i tuoi progetti Go assomiglino a quelli Java :-)
Non confondere la cartella `/src` a livello di progetto con la cartella `/src` che Go utilizza per i suoi workspaces come descritto in [`How to Write Go Code`](https://golang.org/doc/code.html). La variabile di ambiente `$GOPATH` punta al tuo (attuale) workspace (di default punta a `$HOME/go` su sistemi non-windows). Questo workspace include includes le cartelle di livello superiore `/pkg`, `/bin` e `/src`. Il tuo progetto attuale finisce per essere una sotto cartella di `/src`, quindi se hai la cartella `/src` nel tuo progetto, il tuo path di progetto assomiglierà a questo: `/some/path/to/workspace/src/your_project/src/your_code.go`. Nota che da Go 1.11 è possibile avere il proprio progetto al di fuori del `GOPATH`, ma ciò non significa che sia una buona idea utilizzare questo pattern di layout.
Non confondere la cartella `/src` a livello di progetto con la cartella `/src` che Go utilizza per i suoi workspace come descritto in [`How to Write Go Code`](https://golang.org/doc/code.html). La variabile di ambiente `$GOPATH` punta al tuo (attuale) workspace (di default punta a `$HOME/go` su sistemi non Windows). Questo workspace include le cartelle di livello superiore `/pkg`, `/bin` e `/src`. Il tuo progetto attuale finisce per essere una sotto cartella di `/src`, quindi se hai la cartella `/src` nel tuo progetto, il tuo path di progetto assomiglierà a questo: `/some/path/to/workspace/src/your_project/src/your_code.go`. Nota che da Go 1.11 è possibile avere il proprio progetto al di fuori del `GOPATH`, ma ciò non significa che sia una buona idea utilizzare questo pattern di layout.
## Badges
@ -204,4 +206,4 @@ Non confondere la cartella `/src` a livello di progetto con la cartella `/src` c
## Note
Un template di progetto standardizzato con configurazioni semplici e riutilizzabili, gli aggiornamenti per gli scripts e il codice sono in corso.
Un template di progetto standardizzato con configurazioni semplici e riutilizzabili, gli aggiornamenti per gli script e il codice sono in corso.

@ -14,6 +14,10 @@
* [Română](README_ro.md)
* [Русский](README_ru.md)
* [Türkçe](README_tr.md)
* [Italiano](README_it.md)
* [Vietnamese](README_vi.md)
* [Українська](README_ua.md)
* [Indonesian](README_id.md)
## 概要
@ -113,7 +117,7 @@ OpenAPI/Swaggerの仕様、JSONスキーマファイル、プロトコル定義
様々なビルド、インストール、解析などの操作を行うためのスクリプトです。
これらのスクリプトはルートレベルの Makefile を小さくシンプルに保ちます (例: [`https://github.com/hashicorp/terraform/blob/master/Makefile`](https://github.com/hashicorp/terraform/blob/master/Makefile))。
これらのスクリプトはルートレベルの Makefile を小さくシンプルに保ちます (例: [`https://github.com/hashicorp/terraform/blob/main/Makefile`](https://github.com/hashicorp/terraform/blob/main/Makefile))。
例に関しては、[`/scripts`](scripts/README.md)ディレクトリを参照してください。

@ -14,6 +14,10 @@
* [Română](README_ro.md)
* [Русский](README_ru.md)
* [Türkçe](README_tr.md)
* [Italiano](README_it.md)
* [Vietnamese](README_vi.md)
* [Українська](README_ua.md)
* [Indonesian](README_id.md)
## 개요
@ -69,7 +73,7 @@ Internal 패키지에서 공유되는 내부 코드와 공유되지 않는 내
### `/pkg`
외부 애플리케이션에서 사용되어도 괜찮은 라이브러리 코드입니다 (e.g., `/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` 디렉터리와 언제 쓰는게 맞을지에 대해 좋은 개요를 제공합니다.
외부 애플리케이션에서 사용되어도 괜찮은 라이브러리 코드입니다 (e.g., `/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가 아닌 컴포넌트와 디렉터리를 포함하고 있다면 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)).
@ -115,7 +119,7 @@ OpenAPI/Swagger 스펙들, JSON schema 파일들, 프로토콜 정의 파일들.
빌드, 설치, 분석, 기타 작업을 위한 스크립트들.
이 스크립트들은 루트의 Makefile을 작고 간단하게 유지해줍니다 (e.g., [`https://github.com/hashicorp/terraform/blob/master/Makefile`](https://github.com/hashicorp/terraform/blob/master/Makefile)).
이 스크립트들은 루트의 Makefile을 작고 간단하게 유지해줍니다 (e.g., [`https://github.com/hashicorp/terraform/blob/main/Makefile`](https://github.com/hashicorp/terraform/blob/main/Makefile)).
예시로 [`/scripts`](scripts/README.md) 디렉터리를 확인하세요.

@ -14,6 +14,10 @@ Traduções:
* [Română](README_ro.md)
* [Русский](README_ru.md)
* [Türkçe](README_tr.md)
* [Italiano](README_it.md)
* [Vietnamese](README_vi.md)
* [Українська](README_ua.md)
* [Indonesian](README_id.md)
## Visão geral
@ -113,7 +117,7 @@ Configurações de inicialização do sistema (systemd, upstart, sysv) e gerenci
Scripts para executar várias operações de construção, instalação, análise, etc.
Esses scripts mantêm o Makefile de nível raiz pequeno e simples (ex. [`https://github.com/hashicorp/terraform/blob/master/Makefile`](https://github.com/hashicorp/terraform/blob/master/Makefile)).
Esses scripts mantêm o Makefile de nível raiz pequeno e simples (ex. [`https://github.com/hashicorp/terraform/blob/main/Makefile`](https://github.com/hashicorp/terraform/blob/main/Makefile)).
Veja o diretório [`/scripts`](scripts/README.md) para mais exemplos.

@ -14,6 +14,10 @@ Traduceri:
* [Română](README_ro.md)
* [Русский](README_ru.md)
* [Türkçe](README_tr.md)
* [Italiano](README_it.md)
* [Vietnamese](README_vi.md)
* [Українська](README_ua.md)
* [Indonesian](README_id.md)
## General
@ -111,7 +115,7 @@ Configurări de inițializare system (systemd, upstart, sysv) și gestiune/super
Scripturi pentru rularea diferitelor operații.
Ele țin nivelul rădăcinii Makefile mic și simplu (e.g., [`https://github.com/hashicorp/terraform/blob/master/Makefile`](https://github.com/hashicorp/terraform/blob/master/Makefile)).
Ele țin nivelul rădăcinii Makefile mic și simplu (e.g., [`https://github.com/hashicorp/terraform/blob/main/Makefile`](https://github.com/hashicorp/terraform/blob/main/Makefile)).
Vezi directorul [`/scripts`](scripts/README.md) pentru examples.

@ -1,6 +1,6 @@
# Standard Go Project Layout
# Стандартный макет Go проекта
Translations:
Переводы:
* [English](README.md)
* [한국어 문서](README_ko.md)
@ -14,20 +14,24 @@ Translations:
* [Română](README_ro.md)
* [Русский](README_ru.md)
* [Türkçe](README_tr.md)
* [Italiano](README_it.md)
* [Vietnamese](README_vi.md)
* [Українська](README_ua.md)
* [Indonesian](README_id.md)
## Overview
## Обзор
Это базовый макет организации проектов, разработанных на Golang. Это не официально определенный командой разработчиков Golang стандарт, однако он удовлетворяет исторически сложившимся шаблонам организации проекта в экосистеме Golang. Некоторые из шаблонов могут быть известнее остальных. В макете также присутствуют несколько улучшений, включая дополнительные директории, используемые в любом достаточно большом реальном приложении.
Это базовый макет организации проектов, разработанных на Go. Это **не официально определенный командой разработчиков Go стандарт**, однако он удовлетворяет исторически сложившимся шаблонам организации проекта в экосистеме Go. Некоторые из шаблонов могут быть известнее остальных. В макете также присутствуют несколько улучшений, включая дополнительные директории, используемые в любом достаточно большом реальном приложении.
Если вы пытаетесь изучить Golang или собрать маленький обучающий проект для личного пользования, данный макет будет явным перебором. Стоит начать с чего-нибудь действительно простого (одного файла `main.go` будет достаточно). Как только ваш проект начнет расти, стоит задуматься о важности содержания кода в структурированном состоянии, чтобы в конечном итоге не получить грязный код с множеством скрытых зависимостей и global state. А когда над проектом начнут работать другие люди - понадобится еще большая структуризация. В этот момент важно определить стандартный путь организации пакетов/библиотек. Если вы разрабатываете проект с открытым исходным кодом или знаете, что вашим кодом будут пользоваться при разработке других проектов, необходимо понимать важность создания личных, внутренних (или `internal`) пакетов и кода. Клонируйте репозиторий, пользуйтесь тем, что действительно нужно, и удалите всё остальное! Наличие этого "всего остального" вовсе не означает, что это обязательно использовать. Заметьте, что ни один из этих шаблонов не обязан быть использован в абсолютно каждом проекте. Даже `vendor` не может быть универсален во всех случаях.
Если вы пытаетесь изучить Go или собрать маленький обучающий проект для личного пользования, данный макет будет явным перебором. Стоит начать с чего-нибудь действительно простого (одного файла `main.go` будет достаточно). Как только ваш проект начнет расти, стоит задуматься о важности содержания кода в структурированном состоянии, чтобы в конечном итоге не получить грязный код с множеством скрытых зависимостей и global state. А когда над проектом начнут работать другие люди - понадобится еще большая структуризация. В этот момент важно определить стандартный путь организации пакетов/библиотек. Если вы разрабатываете проект с открытым исходным кодом или знаете, что вашим кодом будут пользоваться при разработке других проектов, необходимо понимать важность создания личных, внутренних (или `internal`) пакетов и кода. Клонируйте репозиторий, пользуйтесь тем, что действительно нужно, и удалите всё остальное! Наличие этого "всего остального" вовсе не означает, что это обязательно использовать. Заметьте, что ни один из этих шаблонов не обязан быть использован в абсолютно каждом проекте. Даже `vendor` не может быть универсален во всех случаях.
С выходом обновления Golang 1.14, [`Go Modules`](https://github.com/golang/go/wiki/Modules) стали наконец-то доступны для использования. Применяйте [`Go Modules`](https://blog.golang.org/using-go-modules) везде, пока не столкнётесь с веской причиной отказаться от них, и если такой момент всё же настанет - вам больше не придётся волноваться о значении переменной окружения $GOPATH и месте, где вы размещаете свой проект. Базовый `go.mod` файл в репозитории показывает, что ваш проект размещён на GitHub, однако он не является обязательным. Путь к модулю может быть любым, при условии, что первый компонент пути должен содержать точку в имени (текущая версия Golang больше не требует этого, но если вы используете достаточно устаревшие версии - не стоит удивляться, что ваши сборки могу перестать работать). Ознакомьтесь с проблемами: [`37554`](https://github.com/golang/go/issues/37554) и [`32819`](https://github.com/golang/go/issues/32819) если хотите узнать об этом больше.
С выходом обновления Go 1.14, [`Go Modules`](https://github.com/golang/go/wiki/Modules) стали наконец-то доступны для использования. Применяйте [`Go Modules`](https://blog.golang.org/using-go-modules) везде, пока не столкнётесь с веской причиной отказаться от них, и если такой момент всё же настанет - вам больше не придётся волноваться о значении переменной окружения $GOPATH и месте, где вы размещаете свой проект. Базовый `go.mod` файл в репозитории показывает, что ваш проект размещён на GitHub, однако он не является обязательным. Путь к модулю может быть любым, при условии, что первый компонент пути должен содержать точку в имени (текущая версия Go больше не требует этого, но если вы используете достаточно устаревшие версии - не стоит удивляться, что ваши сборки могу перестать работать). Ознакомьтесь с проблемами: [`37554`](https://github.com/golang/go/issues/37554) и [`32819`](https://github.com/golang/go/issues/32819) если хотите узнать об этом больше.
Этот шаблон организации проекта намеренно сделан обобщенным, и не является примером структуры какого-то конкретного пакета Golang.
Этот шаблон организации проекта намеренно сделан обобщенным, и не является примером структуры какого-то конкретного пакета Go.
Этот репозиторий открыт к усилиям сообщества. Создайте заявку о проблеме, если вы нашли новый шаблон или считаете, что один из существующих шаблонов необходимо обновить.
Этот проект открыт сообществу для улучшения. Создайте заявку о проблеме, если вы нашли новый шаблон или считаете, что один из существующих шаблонов необходимо обновить.
Если вам нужна помощь в наименовании, форматировании или стилизации кода - начните с [`gofmt`](https://golang.org/cmd/gofmt/) и [`golint`](https://github.com/golang/lint). Также обязательно прочтите эти руководства по стилизации кода Golang и рекомендации:
Если вам нужна помощь в наименовании, форматировании или стилизации кода - начните с [`gofmt`](https://golang.org/cmd/gofmt/) и [`golint`](https://github.com/golang/lint). Также обязательно прочтите эти руководства по стилю для кода на Go и рекомендации:
* https://talks.golang.org/2014/names.slide
* https://golang.org/doc/effective_go.html#names
* https://blog.golang.org/package-names
@ -42,54 +46,55 @@ Translations:
* [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)
Пост о руководствах по пакетноориентированному дизайну и макетам архитектур
Пост о руководствах по пакетно-ориентированному дизайну и архитектурным слоям
* [面向包的设计和架构分层](https://github.com/danceyoung/paper-code/blob/master/package-oriented-design/packageorienteddesign.md)
## Директории Go
### `/cmd`
Основные приложения проекта.
Основные приложения для текущего проекта.
Имя директории для каждого приложения должно совпадать с именем исполняемого файла, который вы хотите собрать (например, `/cmd/myapp`).
Не стоит располагать в этой директории большие объёмы кода. Если вы предполагаете дальнейшее использование кода в других проектах, вам стоит хранить его в директории `/pkg` в корне проекта. Если же код не должен быть переиспользован где-то еще - ему самое место в директории `/internal` в корне проекта. Вы будете удивлены тем, что другие люди могут сделать, поэтому будьте уверены в своих намерениях!
Не стоит располагать в этой директории большие объёмы кода. Если вы предполагаете дальнейшее использование кода в других проектах, вам стоит хранить его в директории `/pkg` в корне проекта. Если же код не должен быть переиспользован где-то еще - ему самое место в директории `/internal` в корне проекта. Вы будете удивлены тем, что могут сделать другие люди, по
тому выражайте свои намерения явно!
Самой распространнёной практикой является использование маленькой `main` функции, которая импортирует и вызывает весь необходимый код из директорий `/internal` и `/pkg` и никаких других.
Самой распространённой практикой является использование маленькой `main` функции, которая импортирует и вызывает весь необходимый код из директорий `/internal` и `/pkg`, но не из других.
Ознакомьтесь с директорией [`/cmd`](cmd/README.md) для примера.
Примеры смотрите в директории [`/cmd`](cmd/README.md).
### `/internal`
Внутренний код приложения и библиотек. Это код, который не должен быть применен в других приложениях и библиотеках. Стоит отметить, что этот шаблон навязан самим компилятором Golang. Ознакомьтесь с [`release notes`](https://golang.org/doc/go1.4#internalpackages) Go 1.4. Также, вы вольны использовать `internal` директорию на разных уровнях своего проекта.
Внутренний код приложения и библиотек. Это код, который не должен использоваться в других приложениях и библиотеках. Стоит отметить, что этот шаблон применяется самим компилятором Golang. Ознакомьтесь с [`release notes`](https://golang.org/doc/go1.4#internalpackages) Go 1.4 для более детальной информации. Также, вы вольны использовать более одной директории `internal` на разных уровнях структуры своего проекта.
Вы можете добавить дополнительное структурирование, чтобы разделить открытую и закрытую части вашего внутреннего кода. Такой подход не является необходимым, особенно для маленьких проектов, но позволяет сразу визуально оценить применение кода. Код самого приложения может находиться в директории `/internal/app` (например, `/internal/app/myapp`), а код, который это приложение использует - в директории `/internal/pkg` (например, `/internal/pkg/myprivlib`).
### `/pkg`
Код библиотек, пригодных для использования в сторонних приложениях. (например, `/pkg/mypubliclib`). Другие проекты будут импортировать эти библиотеки, ожидая их автономной работы, поэтому стоит подумать дважды, прежде чем класть сюда какой-нибудь код :-) Заметьте, что использование директории `internal` - более оптимальный способ не дать импортировать внутренние пакеты, потому что это обеспечит сам Golang. Директория `/pkg` - всё еще хороший путь дать понять, что код в этой директории могут безопасно использовать другие. Пост [`I'll take pkg over internal`](https://travisjeffery.com/b/2019/11/i-ll-take-pkg-over-internal/) в блоге Трэвиса Джеффери предоставляет хороший обзор директорий `pkg` и `internal` и когда есть смысл их использовать.
Код библиотек, пригодных для использования в сторонних приложениях (например, `/pkg/mypubliclib`). Другие проекты будут импортировать эти библиотеки, ожидая их автономной работы, поэтому стоит подумать дважды, прежде чем класть сюда какой-нибудь код. Обратите внимание, что использование директории `internal` - более оптимальный способ гарантировать что ваши внутренние пакеты, не будут импортированы, потому что это обеспечивает сам Go. Директория `/pkg` - всё еще хороший путь дать понять, что код в этой директории могут безопасно использовать другие. Статья [`I'll take pkg over internal`](https://travisjeffery.com/b/2019/11/i-ll-take-pkg-over-internal/) в блоге Трэвиса Джеффери (Travis Jeffery) предоставляет хороший обзор директорий `pkg` и `internal` и когда есть смысл их использовать.
Существует возможность группировать код на Golang в одном месте, когда ваша корневая директория содержит множество не относящихся к Go компонентов и директорий, что позволит облегчить работу с разными инструментами Go (как упомянуто в этих разговорах: [`Best Practices for Industrial Programming`](https://www.youtube.com/watch?v=PTE4VJIdHPg) с GopherCon EU 2018, [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 в одном месте, когда ваша корневая директория содержит множество не относящихся к Go компонентов и директорий, что позволит облегчить работу с разными инструментами Go (как упомянуто в этих выступлениях: [`Best Practices for Industrial Programming`](https://www.youtube.com/watch?v=PTE4VJIdHPg) с GopherCon EU 2018, [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)).
Ознакомьтесь с директорией [`/pkg`](pkg/README.md), если хотите увидеть, какие популярные репозитории используют такой шаблон организации проекта. Несмотря на его распространенность, он не был принят всеми, а некоторые в сообществе Go и вовсе не рекомендует его использовать.
Ознакомьтесь с директорией [`/pkg`](pkg/README.md), если хотите увидеть, какие популярные репозитории используют этот макет для организации проекта. Это часто используемый макет, но он не общепринятый, а некоторые в сообществе Go и вовсе не рекомендует его использовать.
Вы можете не использовать эту директорию, если проект совсем небольшой и добавление нового уровня вложенности не имеет практического смысла (разве что вы сами этого не хотите :-)). Подумайте об этом, когда ваша корневая директория начинает слишком сильно разрастаться, особенно, если у вас много компонентов, написанных не на Go.
Вы можете не использовать эту директорию, если проект совсем небольшой и добавление нового уровня вложенности не несет практического смысла (разве что вы сами этого не хотите). Подумайте об этом, когда ваша корневая директория начинает слишком сильно разрастаться, особенно, если у вас много компонентов, написанных не на Go.
### `/vendor`
Зависимости приложений, управляемые вручную или с использованием вашей любимой системы управления зависимостями, вроде новых встроенных [`Go Modules`](https://github.com/golang/go/wiki/Modules)). Команда `go mod vendor` создаст для вас директорию `/vendor`. Заметьте, что вам возможно придётся добавить флаг `-mod=vendor` к команде `go build`, если вы используете версию, отличную от Go 1.14, где такой флаг выставлен по-умолчанию.
Зависимости приложений, управляемые вручную или с использованием вашей любимой системы управления зависимостями, вроде доступного из коробки [`Go Modules`](https://github.com/golang/go/wiki/Modules). Команда `go mod vendor` создаст для вас директорию `/vendor`. Обратите внимание, что вам возможно придётся добавить флаг `-mod=vendor` к команде `go build`, если вы используете версию, отличную от Go 1.14, где такой флаг выставлен по-умолчанию.
Не стоит отправлять зависимости вашего приложения в репозиторий, если собираетесь создавать библиотеку.
Стоит отметить, что с версии [`1.13`](https://golang.org/doc/go1.13#modules) Go добавил возможность проксирования модулей (с использованием [`https://proxy.golang.org`](https://proxy.golang.org) как прокси-сервера по-умолчанию). [`Здесь`](https://blog.golang.org/module-mirror-launch) можно побольше узнать про эту возможность, чтобы убедиться, что она удовлетворяет вашим необходимостям и ограничениям. Если это так - использование директории `vendor` не требуется вовсе.
Стоит отметить, что начиная с версии [`1.13`](https://golang.org/doc/go1.13#modules) Go добавил возможность проксирования модулей (с использованием [`https://proxy.golang.org`](https://proxy.golang.org) как прокси-сервера по-умолчанию). [`Здесь`](https://blog.golang.org/module-mirror-launch) можно побольше узнать про эту возможность, чтобы убедиться, что она удовлетворяет вашим требованиям и ограничениям. Если это так - использование директории `vendor` не требуется вовсе.
## Директории приложений-сервисов
### `/api`
Спецификации OpenAPI/Swagger, файлы JSON schema, файлы определения протоколов.
Спецификации OpenAPI/Swagger, JSON schema файлы, файлы определения протоколов.
Ознакомьтесь с директорией [`/api`](api/README.md) для примеров.
Примеры смотрите в директории [`/api`](api/README.md).
## Директории Веб-приложений
@ -103,19 +108,19 @@ Translations:
Шаблоны файлов конфигураций и файлы настроек по-умолчанию.
Положите файлы конфигураций `confd` или `consul-template` сюда.
Поместите файлы конфигураций `confd` или `consul-template` сюда.
### `/init`
Файлы конфигураций для процессов инициализации системы (systemd, upstart, sysv) и менеджеров процессов (runit, supervisord).
Файлы конфигураций для инициализации системы (systemd, upstart, sysv) и менеджеров процессов (runit, supervisord).
### `/scripts`
Скрипты для сборки, установки, анализа и прочих операций над проектом.
Скрипты для выполнения различных операций сборки, установки, анализа и т.п. операций.
Эти скрипты позволяют оставить основной Makefile небольшим и простым (например, [`https://github.com/hashicorp/terraform/blob/master/Makefile`](https://github.com/hashicorp/terraform/blob/master/Makefile)).
Эти скрипты позволяют оставить основной Makefile небольшим и простым (например, [`https://github.com/hashicorp/terraform/blob/main/Makefile`](https://github.com/hashicorp/terraform/blob/main/Makefile)).
Ознакомьтесь с директорией [`/scripts`](scripts/README.md) для примеров.
Примеры смотрите в директории [`/scripts`](scripts/README.md).
### `/build`
@ -123,37 +128,37 @@ Translations:
Поместите файлы конфигурации и скрипты облака (AMI), контейнера (Docker), пакетов (deb, rpm, pkg) в директорию `/build/package`.
Поместите ваши файлы конфигурации CI (travis, circle, drone) и скрипты в директорию `/build/ci`. Заметьте, что некоторые инструменты CI (например, Travis CI) очень требовательны к расположению их конфигурационных файлов. Попробуйте поместить их в директорию `/build/ci` создав ссылку на них в месте, где их ожидают найти инструменты Go (если возможно).
Поместите ваши файлы конфигурации CI (travis, circle, drone) и скрипты в директорию `/build/ci`. Обратите внимание, что некоторые инструменты CI (например, Travis CI) очень требовательны к расположению их конфигурационных файлов. Попробуйте поместить конфигурационные файлы в директорию `/build/ci` создав ссылку на них в месте, где их ожидают найти CI инструменты (если возможно).
### `/deployments`
Шаблоны и файлы конфигураций систем оркестраций IaaS, PaaS, операционных систем и контейнеров (docker-compose, kubernetes/helm, mesos, terraform, bosh). Отметьте, что в некоторых репозиториях, особенно в приложениях, развернутых с использованием Kubernetes, эта директория называется `/deploy`.
Шаблоны и файлы конфигураций разворачивания IaaS, PaaS, системной и контейнерной оркестрации (docker-compose, kubernetes/helm, mesos, terraform, bosh). Стоит заметить, что в некоторых репозиториях (особенно в приложениях, развернутых с использованием Kubernetes) эта директория называется `/deploy`.
### `/test`
Дополнительные внешние приложения и данные для тестирования. Вы вольны организовывать структуру директории `/test` так, как вам угодно. Для больших проектов имеет смысл создавать вложенную директорию с данными для тестов. Например,`/test/data` или `/test/testdata`, если вы хотите, чтобы Go игнорировал находящиеся там файлы. Отметьте, что Go будет также игнорировать файлы, путь к которым начинается с "." или "_", что предоставляет вам гибкость в наименовании вашей папки с тестами.
Дополнительные внешние тестовые приложения и данные для тестирования. Вы вольны организовывать структуру директории `/test` так, как вам угодно. Для больших проектов имеет смысл создавать вложенную директорию с данными для тестов. Например,`/test/data` или `/test/testdata`, если вы хотите, чтобы Go игнорировал находящиеся там файлы. Стоит заметить, что Go будет также игнорировать файлы, путь к которым начинается с "." или "_", что предоставляет вам гибкость в наименовании вашей директории с тестовыми данными.
Ознакомьтесь с директорией [`/test`](test/README.md) для примеров.
Примеры смотрите в директории [`/test`](test/README.md).
## Другие Директории
### `/docs`
Документы пользователей и дизайна (в дополнение к автоматической документации godoc).
Проектная и пользовательская документация (в дополнение к документации сгенерированной godoc).
Ознакомьтесь с директорией [`/docs`](docs/README.md) для примеров.
Примеры смотрите в директории [`/docs`](docs/README.md).
### `/tools`
Инструменты поддержки проекта. Отметьте, что эти инструменты могут импортировать код из директорий `/pkg` и `/internal`.
Инструменты поддержки проекта. Обратите внимание, что эти инструменты могут импортировать код из директорий `/pkg` и `/internal`.
Ознакомьтесь с директорией [`/tools`](tools/README.md) для примеров.
Примеры смотрите в директории [`/tools`](tools/README.md).
### `/examples`
Примеры ваших приложений и/или библиотек.
Ознакомьтесь с директорией [`/examples`](examples/README.md) для примеров.
Примеры смотрите в директории [`/examples`](examples/README.md).
### `/third_party`
@ -165,21 +170,21 @@ Git hooks.
### `/assets`
Другие ресурсы, необходимые для работы (картинки, логотипы и т.д.)
Другие ресурсы, необходимые для использования вашего репозитория (изображения, логотипы и т.д.)
### `/website`
Здесь можно разделить файлы для вебсайта вашего проекта, если вы не используете `GitHub pages`.
Здесь можно разделить файлы для сайта вашего проекта, если вы не используете `GitHub pages`.
Ознакомьтесь с директорией [`/website`](website/README.md) для примеров.
Примеры смотрите в директории [`/website`](website/README.md).
## Директории, которые не стоит размещать у себя в проекте
### `/src`
Некоторые проекты на Go имеют директорию `src`, но это обычно происходит, когда разработкой занялся человек, пришедший из мира Java, где такой подход весьма распространен. Постарайтесь не использовать его в разработке на Golang, если не хотите, чтобы ваш код или проект выглядел, будто написан на Java :-).
Некоторые проекты на Go имеют директорию `src`, но это обычно происходит, когда разработкой занялся человек, пришедший из мира Java, где такой подход весьма распространен. Постарайтесь не использовать этот Java паттерн. Вы же не хотите, чтобы ваш код на Go или Go проект выглядел, будто написан на Java.
Не путайте директорию уровня проекта `/src` с директорией `/src`, которую Go использует для своих рабочих пространств, как это описано в [`How to Write Go Code`](https://golang.org/doc/code.html). Переменная окружения `$GOPATH` указывает на ваше текущее рабочее пространство (по-умолчанию - `$HOME/go` на системах под управлением ОС, отличной от Windows). Это рабочее пространство включает высокоуровневые директории `/pkg`, `/bin` и `/src`. Ваш проект в свою очередь находится во вложенной в `/src` директории, поэтому если вы имеете директорию `/src` внутри вашего проекта, путь к нему будет выглядеть примерно так: `/some/path/to/workspace/src/your_project/src/your_code.go`. Отметьте, что в версиях после Go 1.11 возможно хранить проект отдельно от локации, описанной в `GOPATH`, но это всё еще не значит, что применять этот Java-шаблон - хорошая идея.
Не путайте директорию уровня проекта `/src` с директорией `/src`, которую Go использует для своих рабочих пространств, как это описано в [`How to Write Go Code`](https://golang.org/doc/code.html). Переменная окружения `$GOPATH` указывает на ваше (текущее) рабочее пространство (по-умолчанию она указывает на `$HOME/go` на системах под управлением ОС, отличной от Windows). Это рабочее пространство включает высокоуровневые директории `/pkg`, `/bin` и `/src`. Ваш проект в свою очередь находится в директории вложенной в директорию `/src`, поэтому если у вас есть директория `/src` внутри вашего проекта, путь к проекту будет выглядеть примерно так: `/some/path/to/workspace/src/your_project/src/your_code.go`. Стоит заметить, что в версиях Go начиная с 1.11 ваш проект может хранить за пределами вашего `GOPATH`, но это всё еще не значит, что применять этот шаблон компоновки - это хорошая идея.
## Badges
@ -188,14 +193,18 @@ Git hooks.
[![Go Report Card](https://goreportcard.com/badge/github.com/golang-standards/project-layout?style=flat-square)](https://goreportcard.com/report/github.com/golang-standards/project-layout)
* [GoDoc](http://godoc.org) - Предоставит онлайн версию вашей сгенерированной GoDoc документации
* ~~[GoDoc](http://godoc.org) - Предоставит онлайн версию вашей сгенерированной GoDoc документации. Измените ссылку, чтобы она указывала на ваш проект.~~
[![Go Doc](https://img.shields.io/badge/godoc-reference-blue.svg?style=flat-square)](http://godoc.org/github.com/golang-standards/project-layout)
* [Pkg.go.dev](https://pkg.go.dev) - Pkg.go.dev is a new destination for Go discovery & docs. You can create a badge using the [badge generation tool](https://pkg.go.dev/badge).
* [Pkg.go.dev](https://pkg.go.dev) - Pkg.go.dev это новое место для исследования Go и документации. Вы можете создать бейдж с помощью [badge generation tool](https://pkg.go.dev/badge).
[![PkgGoDev](https://pkg.go.dev/badge/github.com/golang-standards/project-layout)](https://pkg.go.dev/github.com/golang-standards/project-layout)
* Release - Покажет версию последнего релиза вашего проекта.
* Release - Покажет версию последнего релиза вашего проекта. Измените ссылку на github, чтобы она указывала на ваш проект.
[![Release](https://img.shields.io/github/release/golang-standards/project-layout.svg?style=flat-square)](https://github.com/golang-standards/project-layout/releases/latest)
## Примечания
Более продуманный шаблон проекта с образцами/повторно используемыми конфигурациями, скриптами и кодом — это WIP.

@ -14,6 +14,10 @@
* [Română](README_ro.md)
* [Русский](README_ru.md)
* [Türkçe](README_tr.md)
* [Italiano](README_it.md)
* [Vietnamese](README_vi.md)
* [Українська](README_ua.md)
* [Indonesian](README_id.md)
## Genel Bakış:
@ -113,7 +117,7 @@ Sistem başlangıcı (systemd, upstart, sysv) ve işlem yöneticisi (runit, supe
Çeşitli derleme, yükleme, analiz ve benzeri işlemleri gerçekleştirmek için olan komut dosyaları.
Bu dosyalar ana katmandaki Makefile dosyasını küçük ve basit tutar. (örneğin, [`https://github.com/hashicorp/terraform/blob/master/Makefile`](https://github.com/hashicorp/terraform/blob/master/Makefile)).
Bu dosyalar ana katmandaki Makefile dosyasını küçük ve basit tutar. (örneğin, [`https://github.com/hashicorp/terraform/blob/main/Makefile`](https://github.com/hashicorp/terraform/blob/main/Makefile)).
Örnekler için [`/scripts`](scripts/README.md) klasörüne bakabilirsiniz.

@ -0,0 +1,208 @@
# Стандартний макет проєкту Go
Translations:
* [한국어 문서](README_ko.md)
* [简体中文](README_zh.md)
* [正體中文](README_zh-TW.md)
* [简体中文](README_zh-CN.md) - ???
* [Français](README_fr.md)
* [日本語](README_ja.md)
* [Portuguese](README_ptBR.md)
* [Español](README_es.md)
* [Română](README_ro.md)
* [Русский](README_ru.md)
* [Türkçe](README_tr.md)
* [Українська](README_ua.md)
* [Indonesian](README_id.md)
## Огляд
Це базовий макет для проєктів Go-додатків. Це **`не є офіційним стандартом, визначеним командою розробників Go`**; тим не менш, це звід паттернів програмування в екосистемі Go, що склалися історично. Деякі з цих паттернів більш популярні та відомі ніж інші. Також в цьому макеті є декілька покращень, в тому числі декілька додаткових дерикторій, що використовуються в будь-якому достатньо великому реальному застосунку.
**`Якщо ви тільки вивчаєте Go або створюєте якийсь демонстраційний чи простий проєкт для себе цей макет буде занадто складним. Почність з чогось дійсно простого (одного файлу `main.go` та `go.mod` буде достатньо).`** Коли проєкт почне рости не забувайте, важливо щоб код залишався добре структурованим, інакше ви отримаєте брудний код з великою кількістю прихованих залежностей та глобальних станів. Якщо над проєктом працює більше людей, необхідно ще більше структури. Саме тоді важливо запровадити єдиний спосіб управління пакетами/бібліотеками. Коли ви маєте проєкт з відкритим вихідним кодом або коли ви знаєте, що інші проєкти імпортують код з вашого репозиторію проєкту, саме тоді важливо мати приватні (`internal`) пакети та код. Клонуйте сховище, зберігайте те, що вам потрібно, а все інше видаляйте! Те, що це є, не означає, що ви повинні використовувати все це. Жодна з цих моделей не використовується в кожному окремому проєкті. Навіть паттерн `vendor` не є універсальним.
Починаючи з Go 1.14 [`Go модулі`](https://github.com/golang/go/wiki/Modules) нарешті готові до використання. Використовуйте [`Go модулі`](https://blog.golang.org/using-go-modules) якщо у вас немає конкретної причини не використовувати їх, а якщо є, то вам не потрібно турбуватися про $GOPATH і про те, куди ви помістили свій проєкт. Базовий файл `go.mod` в репозиторії передбачає, що ваш проєкт розміщено на GitHub, однак це не є обов'язковою вимогою. Шлях до модуля може бути будь-яким, але перший компонент шляху до модуля повинен містити крапку в назві (поточна версія Go більше не вимагає цього, але якщо ви використовуєте трохи старіші версії, не дивуйтеся, якщо ваші збірки не працюватимуть без цього). Якщо ви хочете дізнатися більше про це, дивіться: [`37554`](https://github.com/golang/go/issues/37554) та [`32819`](https://github.com/golang/go/issues/32819).
Ця схема проєкту є навмисно загальною і не намагається нав'язати конкретну структуру пакета Go.
Це зусилля спільноти. Відкрийте тему, якщо ви бачите новий шаблон або якщо ви вважаєте, що один з існуючих шаблонів потребує оновлення.
Якщо вам потрібна допомога з іменуванням, форматуванням та стилем, почніть з запуску [`gofmt`](https://golang.org/cmd/gofmt/) та [`golint`](https://github.com/golang/lint). Також обов'язково ознайомтеся з цими керівними принципами та рекомендаціями щодо стилю коду Go:
* https://talks.golang.org/2014/names.slide
* https://golang.org/doc/effective_go.html#names
* https://blog.golang.org/package-names
* https://github.com/golang/go/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)
Китайська публікація про керівні принципи пакетно-орієнтованого проєктування та рівень архітектури
* [面向包的设计和架构分层](https://github.com/danceyoung/paper-code/blob/master/package-oriented-design/packageorienteddesign.md)
## Go каталоги
### `/cmd`
Головні застосунки цього проєкту
Ім'я каталогу для кожного додатка повинно збігатися з ім'ям виконуваного файлу, який ви хочете мати (наприклад `/cmd/myapp`).
Не розміщуйте багато коду в каталозі програми. Якщо ви вважаєте, що код може бути імпортований і використаний в інших проєктах, то він повинен знаходитися в каталозі `/pkg`. Якщо код не може бути використаний повторно або якщо ви не хочете, щоб інші використовували його повторно, помістіть цей код в каталог `/internal`. Ви будете здивовані тим, що будуть робити інші, тому будьте відверті у своїх намірах!
Зазвичай є невелика функція `main`, яка імпортує та викликає код з каталогів `/internal` та `/pkg` і нічого більше.
Дивіться [`/cmd`](cmd/README.md) для прикладів.
### `/internal`
Приватний код додатків та бібліотек. Це код, який ви не хочете, щоб інші імпортували у свої програми або бібліотеки. Зауважте, що цей шаблон компонування забезпечується самим компілятором Go. Дивіться Go 1.4 [`release notes`](https://golang.org/doc/go1.4#internalpackages) для додаткових деталей. Зверніть увагу, що ви не обмежені директорією `internal` верхнього рівня. Ви можете мати більше одного каталогу `internal` на будь-якому рівні дерева вашого проєкту.
За бажанням ви можете додати трохи додаткової структури до ваших внутрішніх пакунків, щоб відокремити ваш спільний і не спільний внутрішній код. Це не є обов'язковим (особливо для невеликих проєктів), але приємно мати візуальні підказки, що показують передбачуване використання пакунків. Ваш власне код програми може знаходитися у каталозі `/internal/app` (наприклад, `/internal/app/myapp`), а код, який використовується спільно з іншими програмами, у каталозі `/internal/pkg` (наприклад, `/internal/pkg/myprivlib`).
### `/pkg`
Код бібліотеки, який можна використовувати зовнішніми програмами (наприклад, `/pkg/mypubliclib`). Інші проєкти імпортуватимуть ці бібліотеки, очікуючи, що вони будуть працювати, тому подумайте двічі, перш ніж щось сюди класти :-) Зауважте, що каталог `internal` є кращим способом гарантувати, що ваші приватні пакунки не будуть імпортовані, оскільки це забезпечується Go. Каталог `/pkg` все ще є гарним способом явно повідомити, що код у цьому каталозі є безпечним для використання іншими. Допис у блозі [`I'll take pkg over internal`](https://travisjeffery.com/b/2019/11/i-ll-take-pkg-over-internal/) Тревіса Джеффрі (Travis Jeffery) надає гарний огляд каталогів `pkg` та `internal` і того, коли може мати сенс їх використання.
Це також спосіб згрупувати код Go в одному місці, коли ваш кореневий каталог містить багато не-Go компонентів і каталогів, що полегшує запуск різних інструментів Go (як згадувалося в цих доповідях: [`Best Practices for Industrial Programming`](https://www.youtube.com/watch?v=PTE4VJIdHPg) з GopherCon EU 2018, [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`](pkg/README.md). Це загальноприйнятий шаблон, але він не є загальноприйнятим, і дехто у спільноті Go не рекомендує його використовувати.
Можна не використовувати його, якщо ваш проєкт програми дійсно невеликий і де додатковий рівень вкладеності не додає особливої цінності (якщо тільки ви дійсно цього не хочете :-)). Подумайте про це, коли він стане досить великим і ваш кореневий каталог буде досить зайнятий (особливо якщо у вас багато компонентів програми, які не є Go).
Походження каталогу `pkg`: старий вихідний код Go використовував `pkg` для своїх пакунків, а потім різні проєкти Go у спільноті почали копіювати цей шаблон (див. [`це`](https://twitter.com/bradfitz/status/1039512487538970624) твіт Бреда Фіцпатріка для більш детального контексту).
### `/vendor`
Залежності додатків (управляються вручну або за допомогою вашого улюбленого інструменту управління залежностями, наприклад, нової вбудованої функції [`Go модулі`](https://github.com/golang/go/wiki/Modules)). Команда `go mod vendor` створить для вас каталог `/vendor`. Зауважте, що вам може знадобитися додати прапорець `-mod=vendor` до команди `go build`, якщо ви не використовуєте Go 1.14, де він увімкнений за замовчуванням.
Не фіксуйте залежності програми, якщо ви створюєте бібліотеку.
Зверніть увагу, що починаючи з [`1.13`](https://golang.org/doc/go1.13#modules) Go також включив функцію модульного проксі (використовуючи [`https://proxy.golang.org`](https://proxy.golang.org) в якості свого модульного проксі-сервера за замовчуванням). Прочитайте більше про нього [`тут`](https://blog.golang.org/module-mirror-launch), щоб дізнатися, чи відповідає він усім вашим вимогам і обмеженням. Якщо так, то каталог `vendor` вам взагалі не знадобиться.
## Каталоги сервісних додатків
### `/api`
Специфікації OpenAPI/Swagger, файли схем JSON, файли визначення протоколів.
Приклади дивіться у каталозі [`/api`](api/README.md).
## Каталоги веб-додатків
### `/web`
Специфічні компоненти веб-додатків: статичні веб-активи, шаблони на стороні сервера та односторінкові застосунки.
## Загальні директорії додатків
### `/configs`
Шаблони файлів конфігурації або конфігурації за замовчуванням.
Сюди викладіть файли шаблонів `confd` або `consul-template`.
### `/init`
Конфігурації системного запуску (systemd, upstart, sysv) та диспетчера/супервізора процесів (runit, supervisord).
### `/scripts`
Скрипти для виконання різних операцій по збірці, установці, аналізу і т.д.
Ці скрипти роблять Makefile кореневого рівня невеликим і простим (наприклад, [`https://github.com/hashicorp/terraform/blob/master/Makefile`](https://github.com/hashicorp/terraform/blob/master/Makefile)).
Приклади див. у каталозі [`/scripts`](scripts/README.md).
### `/build`
Упаковка та безперервна інтеграція (CI).
Конфігурації хмарних (AMI), контейнерних (Docker), ОС (deb, rpm, pkg) пакетів та скрипти покладіть в каталог `/build/package`.
Помістіть конфігурації та скрипти CI (travis, circle, drone) в каталог `/build/ci`. Зверніть увагу, що деякі інструменти CI (наприклад, Travis CI) дуже прискіпливі до розташування своїх конфігураційних файлів. Спробуйте помістити конфігураційні файли в каталог `/build/ci`, пов'язавши їх з тим місцем, де їх очікують інструменти CI (коли це можливо).
### `/deployments`
Конфігурації та шаблони розгортання IaaS, PaaS, системної та контейнерної оркестрації (docker-compose, kubernetes/helm, mesos, terraform, bosh). Зверніть увагу, що в деяких репозиторіях (особливо для додатків, що розгортаються за допомогою kubernetes) цей каталог називається `/deploy`.
### `/test`
Додаткові зовнішні тестові програми та тестові дані. Не соромтеся структурувати каталог `/test` як завгодно. Для великих проєктів має сенс мати підкаталог даних. Наприклад, ви можете мати `/test/data` або `/test/testdata`, якщо вам потрібно, щоб команда Go ігнорувала те, що знаходиться в цьому каталозі. Зауважте, що Go також ігноруватиме каталоги або файли, які починаються з "." або "_", тому у вас є більше гнучкості в плані того, як ви можете назвати свій каталог тестових даних.
Приклади дивіться у каталозі [`/test`](test/README.md).
## Інші директорії
### `/docs`
Проєктна та користувацька документація (на додаток до вашої документації, згенерованої в godoc).
Приклади дивіться у каталозі [`/docs`](docs/README.md).
### `/tools`
Допоміжні інструменти для цього проєкту. Зверніть увагу, що ці інструменти можуть імпортувати код з каталогів `/pkg` та `/internal`.
Приклади дивіться у каталозі [`/tools`](tools/README.md).
### `/examples`
Приклади для ваших додатків та/або публічних бібліотек.
Приклади дивіться у каталозі [`/examples`](examples/README.md).
### `/third_party`
Зовнішні допоміжні інструменти, форкований код та інші утиліти сторонніх розробників (наприклад, Swagger UI).
### `/githooks`
Скріпти (хуки) Git.
### `/assets`
Інші ресурси, які будуть супроводжувати ваш репозиторій (зображення, логотипи тощо).
### `/website`
Це місце для розміщення даних сайту вашого проєкту, якщо ви не використовуєте GitHub Pages.
Приклади дивіться у каталозі [`/website`](website/README.md).
## Директорії, яких у вас не має бути
### `/src`
Деякі проєкти Go мають папку `src`, але це зазвичай трапляється, коли розробники прийшли зі світу Java, де це є поширеним шаблоном. Намагайтеся не використовувати цей патерн Java. Ви ж не хочете, щоб ваш Go код або Go проєкти виглядали як Java :-)
Не плутайте каталог `/src` на рівні проєкту з каталогом `/src`, який Go використовує для своїх робочих областей, як описано в [`How to Write Go Code`](https://golang.org/doc/code.html). Змінна оточення `$GOPATH` вказує на вашу (поточну) робочу область (за замовчуванням вона вказує на `$HOME/go` на системах, відмінних від Windows). Ця робоча область включає в себе каталоги верхнього рівня `/pkg`, `/bin` та `/src`. Ваш фактичний проєкт закінчується підкаталогом у каталозі `/src`, тому, якщо у вашому проєкті є каталог `/src`, шлях до проєкту буде виглядати наступним чином: `/some/path/to/workspace/src/ваш_проєкт/src/ваш_код.go`. Зауважте, що з Go 1.11 можна мати проєкт поза `GOPATH`, але це ще не означає, що це гарна ідея використовувати цей шаблон компонування.
## Бейджі
* [Go Report Card](https://goreportcard.com/) - відсканує ваш код за допомогою `gofmt`, `go vet`, `gocyclo`, `golint`, `ineffassign`, `license` та `misspell`. Замініть `github.com/golang-standards/project-layout` посиланням на ваш проєкт.
[![Go Report Card](https://goreportcard.com/badge/github.com/golang-standards/project-layout?style=flat-square)](https://goreportcard.com/report/github.com/golang-standards/project-layout)
* ~~[GoDoc](http://godoc.org) - надає онлайн-версію вашої документації, створеної у форматі GoDoc. Змініть посилання, щоб воно вказувало на ваш проєкт.~~
[![Go Doc](https://img.shields.io/badge/godoc-reference-blue.svg?style=flat-square)](http://godoc.org/github.com/golang-standards/project-layout)
* [Pkg.go.dev](https://pkg.go.dev) - Pkg.go.dev це нове місцезнаходження для дослідження Go та документації. Ви можете створити бейдж використовуючи [badge generation tool](https://pkg.go.dev/badge).
[![PkgGoDev](https://pkg.go.dev/badge/github.com/golang-standards/project-layout)](https://pkg.go.dev/github.com/golang-standards/project-layout)
* Реліз - покаже номер останнього релізу для вашого проєкту. Змініть посилання на github, щоб воно вказувало на ваш проєкт.
[![Release](https://img.shields.io/github/release/golang-standards/project-layout.svg?style=flat-square)](https://github.com/golang-standards/project-layout/releases/latest)
## Нотатки
Більш розгорнутий шаблон проєкту зі зразками/багаторазовими конфігураціями, скриптами та кодом - це WIP.

@ -0,0 +1,204 @@
# Bố cục tiêu chuẩn của một dự án Go
Các bản dịch:
* [English](README.md)
* [한국어 문서](README_ko.md)
* [简体中文](README_zh.md)
* [正體中文](README_zh-TW.md)
* [简体中文](README_zh-CN.md) - ???
* [Français](README_fr.md)
* [日本語](README_ja.md)
* [Portuguese](README_ptBR.md)
* [Español](README_es.md)
* [Română](README_ro.md)
* [Русский](README_ru.md)
* [Türkçe](README_tr.md)
* [Vietnamese](README_vi.md)
## Tổng quan
Đây là một bố cục cơ bản cho nhiều ứng dụng Go. Dù **`không phải là tiêu chuẩn chính thức được đưa ra từ đội ngũ cốt lõi của Go`**, đây là một tập hợp mẫu bố cục trong hệ sinh thái Go. Những cải tiến nhỏ cùng với một số thư mục hỗ trợ đều có thể được dùng phổ biến cho bất kỳ ứng dụng lớn nào trong thực tế.
**`Nếu bạn đang muốn học Go hoặc đang xây dựng một PoC hoặc một dự án cá nhân đơn giản thì bố cục này là thừa. Bạn nên bắt đầu bằng những thứ đơn giản hơn (chẳng hạn một tập tin `main.go`và một tập tin`go.mod` là đủ).`** Hãy nhớ một điều là khi dự án của bạn phát triển, điều quan trọng là dự án của bạn có cấu trúc tốt, nếu không thì bạn sẽ gặp nhiều vấn đề với mã nguồn lộn xộn cùng các phụ thuộc ẩn và trạng thái toàn cục. Khi bạn có nhiều người làm việc trên một dự án, bạn còn cần cấu trúc nhiều hơn. Vì thế, việc quan trọng là giới thiệu cách phổ biến để quản lý các gói/thư viện. Khi bạn có một dự án mã nguồn mở hoặc khi bạn biết các dự án khác, hãy nhập mã từ kho lưu trữ dự án của bạn, đó là lúc điều quan trọng là phải có các gói và mã riêng tư (hay còn gọi là `nội bộ`). Sao y kho lưu trữ, giữ lại những thứ bạn cần và xóa hết phần còn lại! Chỉ vì nó ở đó không có nghĩa là bạn phải sử dụng tất cả. Không có mẫu nào trong số này được sử dụng trong mọi dự án. Ngay cả mô hình `vendor` cũng không phải là phổ biến.
Ở phiên bản Go 1.14, [`Go Modules`](https://github.com/golang/go/wiki/Modules) đã sẵn sàng để dùng trên môi trường production. Trừ khi bạn có một lý do cục thể nào đấy, còn không thì bạn nên dùng [`Go Modules`](https://blog.golang.org/using-go-modules) vì bạn sẽ không cần để tâm tới $GOPATH và nơi bạn đặt dự án của mình. Tập tin cơ bản `go.mod` trong repo giả định rằng dự án của bạn được lưu trữ trên GitHub, nhưng nó không phải là một yêu cầu. Đường dẫn module có thể là bất kỳ thứ gì mặc dù phần đầu thành phần đường dẫn module phải có dấu chấm trong tên của nó (phiên bản Go hiện tại không bắt buộc điều này, nhưng nếu bạn đang sử dụng các phiên bản cũ hơn, đừng ngạc nhiên nếu bản dựng của bạn thất bại khi thiếu nó). Xem các lỗi [`37554`](https://github.com/golang/go/issues/37554) và [`32819`](https://github.com/golang/go/issues/32819) nếu bạn muốn tìm hiểu thêm.
Bố cục dự án này có chủ đích chung chung và nó không cố gắng áp đặt một vài trúc gói Go cụ thể.
Dự án này là nỗ lực của cộng đồng. Hãy mở một issue nếu bạn gặp một mẫu thiết kế nào mới hoặc bạn nghĩ những mẫu thiết kế có sẵn cần được cập nhật.
Bắt đầu với [`gofmt`](https://golang.org/cmd/gofmt/) và [`golint`](https://github.com/golang/lint) nếu bạn cần hỗ trợ về cách đặt tên, định dạng và phong cách. Đồng thời, đảm bảo rằng bạn đã đọc các hướng dẫn và khuyến nghị của Go dưới đây:
* https://talks.golang.org/2014/names.slide
* https://golang.org/doc/effective_go.html#names
* https://blog.golang.org/package-names
* https://github.com/golang/go/wiki/CodeReviewComments
* [Hướng dẫn thiết kế các gói trong Go](https://rakyll.org/style-packages) (rakyll/JBD)
Đọc thêm [`Mẫu dự án Go`](https://medium.com/golang-learn/go-project-layout-e5213cdcfaa2) để biết thêm thông tin cơ bản.
Tìm hiểu thêm về cách đặt tên và tổ chức các gói cũng như các đề xuất về cấu trúc mã khác:
* [GopherCon EU 2018: Peter Bourgon - Thực tiễn tốt nhất cho lập trình công nghiệp](https://www.youtube.com/watch?v=PTE4VJIdHPg)
* [GopherCon Russia 2018: Ashley McNamara + Brian Ketelsen - Thực tiễn tốt trong Go.](https://www.youtube.com/watch?v=MzTcsI6tn-0)
* [GopherCon 2017: Edward Muller - Các chống mẫu trong Go](https://www.youtube.com/watch?v=ltqV6pDKZD8)
* [GopherCon 2018: Kat Zien - Bạn cấu trúc ứng dụng Go của mình như thế nào](https://www.youtube.com/watch?v=oL6JBUk6tj0)
Một bài đăng của Trung Quốc về hướng dẫn thiết kế theo hướng gói và lớp kiến trúc
* [Thiết kế theo hướng gói và phân lớp kiến trúc](https://github.com/danceyoung/paper-code/blob/master/package-oriented-design/packageorienteddesign.md)
## Các thư mục trong Go
### `/cmd`
Thư mục chứa các ứng dụng chính cho dự án này.
Tên thư mục cho mỗi ứng dụng phải khớp với tên của tập tin thực thi mà bạn muốn có (ví dụ: `/cmd/myapp`).
Đừng đặt nhiều mã trong thư mục ứng dụng. Nếu bạn nghĩ rằng mã có thể được nhập và sử dụng trong các dự án khác, thì nó sẽ nằm trong thư mục `/pkg`. Nếu mã không thể sử dụng lại được hoặc nếu bạn không muốn người khác sử dụng lại, hãy đặt mã đó vào thư mục `/internal`. Bạn sẽ ngạc nhiên về những gì người khác sẽ làm, vì vậy hãy rõ ràng về ý định của bạn!
Thông thường có một hàm `main` nhỏ nhập và gọi mã từ các thư mục `/internal``/pkg` và không có gì khác.
Xem thêm ví dụ ở thư mục [`/cmd`](cmd/README.md).
### `/internal`
Thư mục chứa ứng dụng riêng và mã thư viện. Đây là mã mà bạn không muốn người khác sử dụng trong các ứng dụng hoặc thư viện của họ. Lưu ý, mẫu bố cục này được thực thi bởi chính trình biên dịch Go. Xem Go 1.4 [`ghi chú phát hành`](https://golang.org/doc/go1.4#internalpackages) để biết thêm chi tiết. Lưu ý rằng bạn không bị giới hạn ở thư mục `internal` cấp cao nhất. Bạn có thể có nhiều hơn một thư mục `internal` ở bất kỳ cấp nào trong cây dự án của bạn.
Bạn có thể tùy chọn thêm một chút cấu trúc bổ sung vào các gói bên trong của mình để tách mã nội bộ được chia sẻ và không được chia sẻ. Nó không bắt buộc (đặc biệt đối với các dự án nhỏ), nhưng thật tuyệt khi có manh mối trực quan cho thấy mục đích sử dụng gói dự kiến. Mã ứng dụng thực tế của bạn có thể nằm trong thư mục `/internal/app` (ví dụ: `/internal/app/myapp`) và mã được các ứng dụng đó chia sẻ trong thư mục `/internal/pkg` (ví dụ: `/internal/pkg/myprivlib`).
### `/pkg`
Thư mục chứa code thư viện cho phép các ứng dụng bên ngoài sử dụng (ví dụ: `/pkg/mypubliclib`). Các dự án khác sẽ nhập các thư viện này và kỳ vọng là chúng sẽ hoạt động, vì vậy hãy nghĩ cẩn thận trước khi bạn để thứ gì vào đây :-). Lưu ý rằng thư mục `nội bộ` là cách tốt hơn để đảm bảo các gói riêng tư của bạn không thể nhập được vì nó được Go thực thi. Thư mục `/pkg` vẫn là một cách tốt để thông báo rõ ràng rằng mã trong thư mục đó an toàn cho người khác sử dụng. Bài [`Tôi sẽ dùng pkg thay vì gói nội bộ`](https://travisjeffery.com/b/2019/11/i-ll-take-pkg-over-internal/) đăng bởi Travis Jeffery cung cấp một góc nhìn tổng quan về các thư mục `pkg``internal` và khi nào nên dùng chúng.
Đó cũng là một cách để nhóm mã Go vào một nơi khi thư mục gốc của bạn chứa nhiều thành phần và thư mục không phải Go, giúp chạy các công cụ Go khác nhau dễ dàng hơn (như đã đề cập trong các bài nói này: [`Thực tiễn tốt nhất cho lập trình công nghiệp`](https://www.youtube.com/watch?v=PTE4VJIdHPg) từ GopherCon EU 2018, [GopherCon 2018: Kat Zien - Làm thế nào để tổ chức các ứng dụng Go](https://www.youtube.com/watch?v=oL6JBUk6tj0) và [GoLab 2018 - Massimiliano Pippi - Mẫu bố cục dự án trong Go](https://www.youtube.com/watch?v=3gQa1LWwuzk)).
Xem thư mục [`/pkg`](pkg/README.md) nếu bạn muốn xem repos Go phổ biến nào dùng bố cục này. Đây là một mẫu bố cục phổ biến, nhưng nó không được chấp nhận rộng rãi và một số người trong cộng đồng Go không khuyến khích nó.
Bạn không nên sử dụng nó nếu dự án ứng dụng của bạn thực sự nhỏ và ở đó mức độ lồng ghép bổ sung không mang lại nhiều giá trị (trừ khi bạn thực sự muốn :-)). Hãy nghĩ về nó khi nó đủ lớn và thư mục gốc của bạn trở nên khá bận rộn (đặc biệt nếu bạn có nhiều thành phần ứng dụng không phải của Go).
Nguồn gốc thư mục `pkg`: Mã nguồn Go cũ dùng `pkg` cho các gói của nó và sau đó các dự án Go khác trong cộng đồng bắt đầu sao chép mẫu này (xem [`Tweet`](https://twitter.com/bradfitz/status/1039512487538970624) của Brad Fitzpatrick để biết thêm ngữ cảnh).
### `/vendor`
Thư mục chứa các phụ thuộc của ứng dụng (được quản lý thủ công hoặc bằng công cụ quản lý phụ thuộc ưa thích của bạn tương tự như tính năng tích hợp mới là [`Go Modules`](https://github.com/golang/go/wiki/Modules)). Câu lệnh `go mod vendor` sẽ tạo ra cho bạn một thư mục `/vendor`. Lưu ý rằng bạn có thể sẽ cần phải thêm cờ hiệu `-mod=vendor` cho câu lệnh `go build` nếu bạn không dùng Go 1.14, phiên bản được thêm cờ hiệu mặc định.
Không nên commit các phụ thuộc ứng dụng nếu bạn đang muốn xây dựng một thư viện.
Lưu ý rằng kể từ phiên bản [`1.13`](https://golang.org/doc/go1.13#modules), Go bật tính năng module proxy (mặc định dùng máy chủ module proxy [`https://proxy.golang.org`](https://proxy.golang.org)). Đọc thêm để xem liệu nó có phù hợp với tất cả các yêu cầu và ràng buộc của bạn hay không ở [`đây`](https://blog.golang.org/module-mirror-launch). Nếu có thì bạn không cần tới thư mục `vendor`.
## Thư mục ứng dụng dịch vụ
### `/api`
Thư mục chứa bản mô tả OpenAPI/Swagger, tập tin lược đồ JSON, tập tin định nghĩa giao thức.
Xem thêm ví dụ ở thư mục [`/api`](api/README.md).
## Thư mục ứng dụng Web
### `/web`
Thư mục chứa các thành phần cụ thể của ứng dụng web: tài nguyên web tĩnh, mẫu bên máy chủ và SPAs.
Để các tập mẫu `confd``consul-template` ở đây.
### `/init`
Thư mục chứa phần khởi tạo hệ thống (systemd, upstart, sysv) và cấu hình quản lý/giám sát tiến trình (runit, supervisord).
### `/scripts`
Thư mục chứa tập lệnh để thực hiện các hoạt động xây dựng, cài đặt, phân tích ...
Các tập lệnh này làm cho tập Makefile ở cấp cao nhất nhỏ gọn và đơn giản. (Ví dụ: [`https://github.com/hashicorp/terraform/blob/master/Makefile`](https://github.com/hashicorp/terraform/blob/master/Makefile))
Xem ví dụ ở thư mục [`/scripts`](scripts/README.md).
### `/build`
Thư mục chứa gói và tích hợp liên tục.
Đặt các cấu hình và tập lệnh các gói đám mây (AMI), container (Docker), OS (deb, rpm, pkg) của bạn vào thư mục `/build/package`.
Đặt cấu hình và tập lệnh CI (travis, circle, drone) trong thư mục `/build/ci`. Lưu ý rằng một vài công cụ CI (ví dụ: Travis CI) rất kén chọn vị trí của tập tin cấu hình. Thử đặt các tập tin cấu hình ở thư mục `/build/ci`, lên kết chúng với vị trí mà công cụ CI mong đợi (khi có thể).
### `/deployments`
Thư mục chứa IaaS, PaaS, các cấu hình và mẫu triển khai điều phối hệ thống và vùng chứa (docker-compose, kubernetes/helm, mesos, terraform, bosh). Lưu ý rằng trong một số repo (đặc biệt là các ứng dụng được triển khai với kubernetes) thư mục này được gọi là `/deploy`.
### `/test`
Thư mục chứa các ứng dụng thử nghiệm bên ngoài bổ sung và dữ liệu thử nghiệm. Hãy thoải mái cấu trúc thư mục `/test` theo cách bạn muốn. Đối với các dự án lớn hơn, điều hợp lý là có một thư mục con dữ liệu. Ví dụ: bạn có thể có `/test/data` hoặc `/test/testdata` nếu bạn cần Go bỏ qua những gì trong thư mục đó. Lưu ý rằng Go cũng sẽ bỏ qua các thư mục hoặc tệp bắt đầu bằng "." hoặc "_", vì vậy bạn có thể linh hoạt hơn về cách đặt tên cho thư mục dữ liệu thử nghiệm của mình.
Xem ví dụ ở thư mục [`/test`](test/README.md).
## Thư mục khác
### `/docs`
Thư mục chứa tài liệu người dùng và bản thiết kế (bên cạnh tài liệu do godoc tạo ra).
Xem ví dụ ở thư mục [`/docs`](docs/README.md).
### `/tools`
Thư mục chứa công cụ hỗ trợ cho dự án này. Lưu ý rằng các công cụ này có thể nhập mã từ thư mục `/pkg``/internal`.
Xem ví dụ ở thư mục [`/tools`](tools/README.md).
### `/examples`
Thư mục chứa mẫu cho ứng dụng và/hoặc các thư viện công cộng của bạn.
Xem ví dụ ở thư mục [`/examples`](examples/README.md)
### `/third_party`
Thư mục chứa các công cụ trợ giúp bên ngoài, mã phân nhánh và các tiện ích bên thứ ba khác (ví dụ: giao diện người dùng Swagger).
### `/githooks`
Thư mục chứa git hooks.
### `/assets`
Các tài sản khác đi cùng với kho lưu trữ của bạn (hình ảnh, logo ...).
### `/website`
Đây là nơi để dữ liệu trang web của bạn nếu bạn không sử dụng các trang của GitHub.
Xem ví dụ ở thư mục [`/website`](website/README.md).
## Thư mục bạn không nên có
### `/src`
Một vài dự án Go có thư mục `src` nhưng nó thường xảy ra khi các nhà phát triển đến từ thế giới Java, nơi đó là một mẫu phổ biến. Bạn không nên học mẫu này từ Java. Bạn thực sự không muốn mã Go hoặc các dự án Go của mình trông giống như Java :-)
Đừng nhầm lẫn giữa thư mục `/src` cấp dự án với thư mục `/src` mà Go sử dụng cho các không gian làm việc của nó như được mô tả trong [`Cách viết mã Go`](https://golang.org/doc/code.html). Biến môi trường `$GOPATH` trỏ tới không gian làm việc hiện tại của bạn (với những hệ thống không phải là Windows, nó mặc định trỏ tới `$HOME/go`). Không gian làm việc này bao gồm các thư mục `/pkg`, `/bin`, `/src` cấp cao nhất. Dự án thực tế của bạn kết thúc là một thư mục con trong `/src`, vì vậy nếu bạn có thư mục `/src` trong dự án của mình, đường dẫn dự án sẽ giống như sau: `/some/path/to/workspace/src/your_project/src/your_code.go`. Lưu ý rằng với Go 1.11, bạn có thể đặt dự án của mình bên ngoài `GOPATH`, nhưng điều đó không có nghĩa là bạn nên sử dụng mẫu bố cục này.
## Danh hiệu
* [Go Report Card](https://goreportcard.com/) - Nó sẽ quét toàn bộ mã của bạn bằng `gofmt`, `go vet`, `gocyclo`, `golint`, `ineffassign`, `license` and `misspell`. Thay `github.com/golang-standards/project-layout` bằng tuỳ chọn trong dự án của bạn.
[![Go Report Card](https://goreportcard.com/badge/github.com/golang-standards/project-layout?style=flat-square)](https://goreportcard.com/report/github.com/golang-standards/project-layout)
* ~~[GoDoc](http://godoc.org) - Nó sẽ cung cấp phiên bản trực tuyến của tài liệu do GoDoc tự tạo. Đổi đường dẫn để trỏ tới dự án của bạn.~~
[![Go Doc](https://img.shields.io/badge/godoc-reference-blue.svg?style=flat-square)](http://godoc.org/github.com/golang-standards/project-layout)
* [Pkg.go.dev](https://pkg.go.dev) - Pkg.go.dev là điểm đến mới cho khám phá và tài liệu về Go. Bạn có thể tạo huy hiệu bằng [badge generation tool](https://pkg.go.dev/badge).
[![PkgGoDev](https://pkg.go.dev/badge/github.com/golang-standards/project-layout)](https://pkg.go.dev/github.com/golang-standards/project-layout)
* Bản phát hành - Nó sẽ hiển thị số phát hành mới nhất cho dự án của bạn. Thay đổi liên kết github để trỏ đến dự án của bạn.
[![Release](https://img.shields.io/github/release/golang-standards/project-layout.svg?style=flat-square)](https://github.com/golang-standards/project-layout/releases/latest)
## Ghi chú
Một mẫu dự án "có định kiến" (opinionated) hơn đang được xây dựng với các cấu hình, tập lệnh và mã có thể tái sử dụng.

@ -12,33 +12,39 @@
* [Română](README_ro.md)
* [Русский](README_ru.md)
* [Türkçe](README_tr.md)
* [Italiano](README_it.md)
* [Vietnamese](README_vi.md)
* [Українська](README_ua.md)
* [Indonesian](README_id.md)
这是Go应用程序项目的基础布局。这不是Go核心开发团队定义的官方标准无论是在经典项目还是在新兴的项目中这都是Go生态系统中一组常见的项目布局模式。这其中有一些模式比另外的一些更受欢迎。它通过几个支撑目录为任何足够大规模的实际应用程序提供一些增强功能。
如果你正准备学习Go、正在构建PoC项目或编写玩具项目那么按照这个项目进行布局就大材小用了。从一些正真简单是的事情开始一个`main.go`文件就足够了)。随着项目的增长,确保代码结构的合理是非常重要的,否则最终会出现很多隐藏的依赖关系和全局状态而到这项目代码混乱。当一个项目多人同时进行时,就更需要有清晰的结构,此时引入一种通用的项目包/标准库管理工具就显得尤为重要。当你维护一个开源项目或者有其他项目导入了你的代码,那么有一个私有的包(如`internal`)就很重要了。克隆这个项目,保留你项目中需要的部分,并删除其他部分。通常来说不需要也没必要使用这个项目中的全部内容。因为,从没有在一个单一的项目中使用本项目中定义的全部模式,甚至如`vendor`模式。
如果你正准备学习Go、正在构建PoC项目或编写玩具项目那么按照这个项目进行布局就大材小用了。从一些真简单的事情开始(一个`main.go`文件就足够了)。随着项目的增长,确保代码结构的合理是非常重要的,否则最终会出现很多隐藏的依赖关系和全局状态而导致这个项目的代码混乱。当一个项目多人同时进行时,就更需要有清晰的结构,此时引入一种通用的项目包/标准库管理工具就显得尤为重要。当你维护一个开源项目或者有其他项目导入了你的代码,那么有一个私有的包(如`internal`)就很重要了。克隆这个项目,保留你项目中需要的部分,并删除其他部分。通常来说不需要也没必要使用这个项目中的全部内容。因为,从没有在一个单一的项目中使用本项目中定义的全部模式,甚至如`vendor`模式。
Go 1.14 `Go Modules`已经可以用于生产环境。没有什么特殊原因的话,请使用`Go Modules`,使用它之后,你就也不用担心`$GOPATH`的配置和项目实际的存放位置,项目想放在哪里就放在哪里。本项目中`go.mod`文件的内容假设你的项目是托管在GitHub上的当然这不是必选项因为`Module`中的路径可以是任意的值,一般`Module`路径的第一部分中应该包含一个点最新版的Go中不再强制要求这一点如果使用的是稍微旧一些的版本那么可能遇到编译失败的问题。了解更多请看Issues [37554](https://github.com/golang/go/issues/37554)和 [32819](https://github.com/golang/go/issues/32819)。
Go 1.14 `Go Modules`已经可以用于生产环境。没有什么特殊原因的话,请使用`Go Modules`,使用它之后,你就也不用担心`$GOPATH`的配置和项目实际的存放位置,项目想放在哪里就放在哪里。本项目中`go.mod`文件的内容假设你的项目是托管在GitHub上的当然这不是必选项因为`Module`中的路径可以是任意的值,一般`Module`路径的第一部分中应该包含一个点最新版的Go中不再强制要求这一点如果使用的是稍微旧一些的版本那么可能遇到编译失败的问题。了解更多请看Issues [37554](https://github.com/golang/go/issues/37554)和 [32819](https://github.com/golang/go/issues/32819)。
本项目布局有意设计的更通用一些而不会尝试去引入一些特定的Go包结构。
这是社区共同的努力。如果发现了一种新的模式或者项目中已经存在的某些模式需要更新请新建一个issue。
这是社区共同的努力。如果发现了一种新的模式或者项目中已经存在的某些模式需要更新请新建一个issue。
如果需要一些关于命名、格式化或者样式方面的帮助,请先运行[`gofmt`](https://golang.org/cmd/gofmt/)和[`golint`](https://github.com/golang/lint)。另外请务必阅读以下Go代码样式指南和建议
- https://talks.golang.org/2014/names.slide
- https://golang.org/doc/effective_go.html#names
- https://blog.golang.org/package-names
- https://github.com/golang/go/wiki/CodeReviewComments
- Style guideline for Go packages (rakyll/JBD)
* <https://talks.golang.org/2014/names.slide>
* <https://golang.org/doc/effective_go.html#names>
* <https://blog.golang.org/package-names>
* <https://github.com/golang/go/wiki/CodeReviewComments>
* Style guideline for Go 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)
* [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)
## Go目录
@ -46,9 +52,9 @@ Go 1.14 `Go Modules`已经可以用于生产环境。没有什么特殊原因的
项目主要的应用程序。
对于每个应用程序来说这个目录的名字应该和项目可执行文件的名字匹配(例如,`/cmd/myapp`)。
对于每个应用程序来说这个目录的名字应该和项目可执行文件的名字匹配(例如,`/cmd/myapp`)。
不要在这个目录中放太多的代码。如果目录中的代码可以被其他项目导入并使用,那么应该把他们放在`/pkg`目录。如果目录中的代码不可重用,或者不希望被他人使用,应该将代码放在`/internal`目录。显示的表明意图比较好!
不要在这个目录中放太多的代码。如果目录中的代码可以被其他项目导入并使用,那么应该把他们放在`/pkg`目录。如果目录中的代码不可重用,或者不希望被他人使用,应该将代码放在`/internal`目录。显式地表明意图比较好!
通常来说,项目都应该拥有一个小的`main`函数,并在`main`函数中导入或者调用`/internal`和`/pkg`目录中的代码。
@ -108,7 +114,7 @@ Web应用程序特定的组件静态Web资源服务器端模板和单页
用于执行各种构建,安装,分析等操作的脚本。
这些脚本使根级别的Makefile变得更小更简单例如 https://github.com/hashicorp/terraform/blob/master/Makefile )。
这些脚本使根级别的Makefile变得更小更简单例如<https://github.com/hashicorp/terraform/blob/main/Makefile>)。
更多样例查看[`/scripts`](https://github.com/golang-standards/project-layout/blob/master/scripts/README.md)。
@ -174,13 +180,13 @@ Git的钩子。
有一些Go项目确实包含`src`文件夹但通常只有在开发者是从Java这是Java中一个通用的模式转过来的情况下才会有。如果可以的话请不要使用这种Java模式。你肯定不希望你的Go代码和项目看起来像Java。
不要将项目级别的`/src`目录与Go用于其工作空间的`/src`目录混淆,就像[How to Write Go Code](https://golang.org/doc/code.html)中描述的那样。`$GOPATH`环境变量指向当前的工作空间默认情况下指向非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用于其工作空间的`/src`目录混淆,就像[How to Write Go Code](https://golang.org/doc/code.html)中描述的那样。`$GOPATH`环境变量指向当前的工作空间默认情况下指向非Windows系统中的`$HOME/go`)。此工作空间包括顶级`/pkg``/bin`和`/src`目录。实际的项目最终变成`/src`下的子目录,因此,如果项目中有`/src`目录,则项目路径将会变成:`/some/path/to/workspace/src/your_project/src/your_code.go`。请注意使用Go 1.11可以将项目放在GOPATH之外但这并不意味着使用此布局模式是个好主意。
## 徽章
- [Go Report Card](https://goreportcard.com/):它将使用`gofmt``vet``gocyclo``golint``ineffassign``license`和`mispell`扫描项目中的代码。将`github.com/golang-standards/project-layout`替换为你的项目的引用。
- [GoDoc](http://godoc.org/)它将提供GoDoc生成的文档的在线版本。更改链接以指向你的项目。
- Release它将显示你项目的最新版本号。更改github链接以指向你的项目。
* [Go Report Card](https://goreportcard.com/):它将使用`gofmt``vet``gocyclo``golint``ineffassign``license`和`mispell`扫描项目中的代码。将`github.com/golang-standards/project-layout`替换为你的项目的引用。
* [GoDoc](http://godoc.org/)它将提供GoDoc生成的文档的在线版本。更改链接以指向你的项目。
* Release它将显示你项目的最新版本号。更改github链接以指向你的项目。
[![Go Report Card](https://goreportcard.com/badge/github.com/golang-standards/project-layout?style=flat-square)](https://goreportcard.com/report/github.com/golang-standards/project-layout)
[![Go Doc](https://img.shields.io/badge/godoc-reference-blue.svg?style=flat-square)](http://godoc.org/github.com/golang-standards/project-layout)

@ -14,6 +14,10 @@
* [Română](README_ro.md)
* [Русский](README_ru.md)
* [Türkçe](README_tr.md)
* [Italiano](README_it.md)
* [Vietnamese](README_vi.md)
* [Українська](README_ua.md)
* [Indonesian](README_id.md)
這是 Go 應用程式專案的基本目錄結構。它不是核心 Go 開發團隊定義的官方標準;然而,它是 Go 生態系統中一組常見的老專案和新專案的目錄結構。其中一些目錄結構比其他目錄結構更受歡迎。這個專案目錄結構還有一些細微的改進,可以支援任何大型且實用的應用程式目錄結構。
@ -111,7 +115,7 @@ Web 應用程式相關的元件:靜態 Web 檔案、伺服器端範本與 SPAs
放置要執行各種建置、安裝、分析等操作的命令腳本!
這些腳本可以讓你在根目錄的 `Makefile` 更小、更簡單(例如:[`https://github.com/hashicorp/terraform/blob/master/Makefile`](https://github.com/hashicorp/terraform/blob/master/Makefile))。
這些腳本可以讓你在根目錄的 `Makefile` 更小、更簡單(例如:[`https://github.com/hashicorp/terraform/blob/main/Makefile`](https://github.com/hashicorp/terraform/blob/main/Makefile))。
請查看 [`/scripts`](scripts/README.md) 目錄獲得更多範例。

@ -14,10 +14,14 @@
* [Română](README_ro.md)
* [Русский](README_ru.md)
* [Türkçe](README_tr.md)
* [Italiano](README_it.md)
* [Vietnamese](README_vi.md)
* [Українська](README_ua.md)
* [Indonesian](README_id.md)
这是 Go 应用程序项目的基本布局。它不是核心 Go 开发团队定义的官方标准;然而,它是 Go 生态系统中一组常见的老项目和新项目的布局模式。其中一些模式比其他模式更受欢迎。它还具有许多小的增强,以及对任何足够大的实际应用程序通用的几个支持目录。
如果你尝试学习 Go或者你正在为自己建立一个 PoC 或一个玩具项目,这个项目布局是没啥必要的。从一些非常简单的事情开始(一个 `main.go` 文件绰绰有余)。随着项目的增长,请记住保持代码结构良好非常重要,否则你最终会得到一个凌乱的代码,这其中就包含大量隐藏的依赖项和全局状态。当有更多的人参与这个项目时,你将需要更多的结构。这时候,介绍一种管理包/库的通用方法是很重要的。当你有一个开源项目时,或者当你知道其他项目从你的项目存储库中导入代码时,这时候拥有私有(又名 `internal`)包和代码就很重要。克隆存储库,保留你需要的内容,删除其他所有的内容!仅仅因为它在那里并不意味着你必须全部使用它。这些模式都没有在每个项目中使用。甚至 `vendor` 模式也不是通用的。
如果你尝试学习 Go或者你正在为自己建立一个 PoC 或一个玩具项目,这个项目布局是没啥必要的。从一些非常简单的事情开始(一个 `main.go` 文件绰绰有余)。随着项目的增长,请记住保持代码结构良好非常重要,否则你最终会得到一个凌乱的代码,这其中就包含大量隐藏的依赖项和全局状态。当有更多的人参与这个项目时,你将需要更多的结构。这时候,介绍一种管理包/库的通用方法是很重要的。当你有一个开源项目时,或者当你知道其他项目从你的项目存储库中导入代码时,这时候拥有私有(又名 `internal`)包和代码就很重要。克隆存储库,保留你需要的内容,删除其他所有的内容仅仅因为它在那里并不意味着你必须全部使用它。这些模式都没有在每个项目中使用。甚至 `vendor` 模式也不是通用的。
Go 1.14 [`Go Modules`](https://github.com/golang/go/wiki/Modules) 终于可以投入生产了。除非你有特定的理由不使用它们,否则使用 [`Go Modules`](https://blog.golang.org/using-go-modules) 。如果你使用,就无需担心 $GOPATH 以及项目放置的位置。存储库中的 `go.mod` 文件基本假定你的项目托管在 Github 上,但这不是要求。模块路径可以是任何地方,尽管第一个模块路径组件的名称中应该有一个点(当前版本的 Go 不再强制使用该模块,但如果使用稍旧的版本,如果没有 `mod` 文件构建失败的话 ,不要惊讶)。如果你想知道更多信息,请参阅 Issues [`37554`](https://github.com/golang/go/issues/37554) 和 [`32819`](https://github.com/golang/go/issues/32819) 。
@ -58,7 +62,7 @@ Go 1.14 [`Go Modules`](https://github.com/golang/go/wiki/Modules) 终于可以
私有应用程序和库代码。这是你不希望其他人在其应用程序或库中导入代码。请注意,这个布局模式是由 Go 编译器本身执行的。有关更多细节请参阅Go 1.4 [`release notes`](https://golang.org/doc/go1.4#internalpackages) 。注意,你并不局限于顶级 `internal` 目录。在项目树的任何级别上都可以有多个内部目录。
你可以选择向 internal 包中添加一些额外的结构,以分隔共享和非共享的内部代码。这不是必需的(特别是对于较小的项目),但是最好有可视化的线索来显示预期的包的用途。你的实际应用程序代码可以放在 `/internal/app` 目录下(例如 `/internal/app/myapp`),这些应用程序共享的代码可以放在 `/internal/pkg` 目录下(例如 `/internal/pkg/myprivlib`)。
你可以选择向 internal 包中添加一些额外的结构,以分隔共享和非共享的内部代码。这不是必需的(特别是对于较小的项目),但是最好有可视化的线索来显示预期的包的用途。你的实际应用程序代码可以放在 `/internal/app` 目录下(例如 `/internal/app/myapp`),这些应用程序共享的代码可以放在 `/internal/pkg` 目录下(例如 `/internal/pkg/myprivlib`)。
### `/pkg`
@ -112,7 +116,7 @@ System initsystemdupstartsysv和 process manager/supervisorrunit
执行各种构建、安装、分析等操作的脚本。
这些脚本保持了根级别的 Makefile 变得小而简单(例如, [`https://github.com/hashicorp/terraform/blob/master/Makefile`](https://github.com/hashicorp/terraform/blob/master/Makefile) )。
这些脚本保持了根级别的 Makefile 变得小而简单(例如, [`https://github.com/hashicorp/terraform/blob/main/Makefile`](https://github.com/hashicorp/terraform/blob/main/Makefile) )。
有关示例,请参见  [`/scripts`](scripts/README.md) 目录。

@ -1,3 +1,3 @@
module github.com/YOUR-USER-OR-ORG-NAME/YOUR-REPO-NAME
go 1.14
go 1.19

@ -12,6 +12,7 @@ Examples:
* https://github.com/jaegertracing/jaeger/tree/main/internal
* https://github.com/moby/moby/tree/master/internal
* https://github.com/satellity/satellity/tree/main/internal
* https://github.com/minio/minio/tree/master/internal
## `/internal/pkg`

@ -13,17 +13,21 @@ The `pkg` directory origins: The old Go source code used to use `pkg` for its pa
Examples:
* https://github.com/containerd/containerd/tree/main/pkg
* https://github.com/slimtoolkit/slim/tree/master/pkg
* https://github.com/telepresenceio/telepresence/tree/release/v2/pkg
* https://github.com/jaegertracing/jaeger/tree/master/pkg
* https://github.com/istio/istio/tree/master/pkg
* https://github.com/GoogleContainerTools/kaniko/tree/master/pkg
* https://github.com/google/gvisor/tree/master/pkg
* https://github.com/google/syzkaller/tree/master/pkg
* https://github.com/perkeep/perkeep/tree/master/pkg
* https://github.com/minio/minio/tree/master/pkg
* https://github.com/heptio/ark/tree/master/pkg
* https://github.com/argoproj/argo/tree/master/pkg
* https://github.com/argoproj/argo-workflows/tree/master/pkg
* https://github.com/argoproj/argo-cd/tree/master/pkg
* https://github.com/heptio/sonobuoy/tree/master/pkg
* https://github.com/helm/helm/tree/master/pkg
* https://github.com/k3s-io/k3s/tree/master/pkg
* https://github.com/kubernetes/kubernetes/tree/master/pkg
* https://github.com/kubernetes/kops/tree/master/pkg
* https://github.com/moby/moby/tree/master/pkg
@ -56,3 +60,53 @@ Examples:
* https://github.com/kata-containers/runtime/tree/master/pkg
* https://github.com/okteto/okteto/tree/master/pkg
* https://github.com/solo-io/squash/tree/master/pkg
* https://github.com/google/exposure-notifications-server/tree/main/pkg
* https://github.com/spiffe/spire/tree/main/pkg
* https://github.com/rook/rook/tree/master/pkg
* https://github.com/buildpacks/pack/tree/main/pkg
* https://github.com/cilium/cilium/tree/main/pkg
* https://github.com/containernetworking/cni/tree/main/pkg
* https://github.com/crossplane/crossplane/tree/master/pkg
* https://github.com/dragonflyoss/Dragonfly2/tree/main/pkg
* https://github.com/kubeedge/kubeedge/tree/master/pkg
* https://github.com/kubevela/kubevela/tree/master/pkg
* https://github.com/kubevirt/kubevirt/tree/main/pkg
* https://github.com/kyverno/kyverno/tree/main/pkg
* https://github.com/thanos-io/thanos/tree/main/pkg
* https://github.com/cri-o/cri-o/tree/main/pkg
* https://github.com/fluxcd/flux2/tree/main/pkg
* https://github.com/kedacore/keda/tree/main/pkg
* https://github.com/linkerd/linkerd2/tree/main/pkg
* https://github.com/opencost/opencost/tree/develop/pkg
* https://github.com/antrea-io/antrea/tree/main/pkg
* https://github.com/karmada-io/karmada/tree/master/pkg
* https://github.com/kuberhealthy/kuberhealthy/tree/master/pkg
* https://github.com/submariner-io/submariner/tree/devel/pkg
* https://github.com/trickstercache/trickster/tree/main/pkg
* https://github.com/tellerops/teller/tree/master/pkg
* https://github.com/OpenFunction/OpenFunction/tree/main/pkg
* https://github.com/external-secrets/external-secrets/tree/main/pkg
* https://github.com/ko-build/ko/tree/main/pkg
* https://github.com/lima-vm/lima/tree/master/pkg
* https://github.com/clastix/capsule/tree/master/pkg
* https://github.com/carvel-dev/ytt/tree/develop/pkg
* https://github.com/clusternet/clusternet/tree/main/pkg
* https://github.com/fluid-cloudnative/fluid/tree/master/pkg
* https://github.com/inspektor-gadget/inspektor-gadget/tree/main/pkg
* https://github.com/sustainable-computing-io/kepler/tree/main/pkg
* https://github.com/GoogleContainerTools/kpt/tree/main/pkg
* https://github.com/guacsec/guac/tree/main/pkg
* https://github.com/kubeovn/kube-ovn/tree/master/pkg
* https://github.com/kube-vip/kube-vip/tree/main/pkg
* https://github.com/kubescape/kubescape/tree/master/pkg
* https://github.com/kudobuilder/kudo/tree/main/pkg
* https://github.com/kumahq/kuma/tree/master/pkg
* https://github.com/kubereboot/kured/tree/main/pkg
* https://github.com/nocalhost/nocalhost/tree/main/pkg
* https://github.com/openelb/openelb/tree/master/pkg
* https://github.com/openfga/openfga/tree/main/pkg
* https://github.com/openyurtio/openyurt/tree/master/pkg
* https://github.com/getporter/porter/tree/main/pkg
* https://github.com/sealerio/sealer/tree/main/pkg
* https://github.com/werf/werf/tree/main/pkg

2
vendor/README.md vendored

@ -1,6 +1,6 @@
# `/vendor`
Application dependencies (managed manually or by your favorite dependency management tool like the new built-in, but still experimental, [`modules`](https://github.com/golang/go/wiki/Modules) feature).
Application dependencies (managed manually or by your favorite dependency management tool or the built-in [`modules`](https://github.com/golang/go/wiki/Modules) feature).
Don't commit your application dependencies if you are building a library.

Loading…
Cancel
Save