From 1f98fc6b59d89df6f8657ed14a3d1314b9e9f41c Mon Sep 17 00:00:00 2001 From: xis Date: Wed, 3 Feb 2021 22:06:34 +0300 Subject: [PATCH 01/76] turkish translation --- README_tr.md | 206 +++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 206 insertions(+) create mode 100644 README_tr.md diff --git a/README_tr.md b/README_tr.md new file mode 100644 index 0000000..9906368 --- /dev/null +++ b/README_tr.md @@ -0,0 +1,206 @@ +# Standart Go Projesi Düzeni + +Çeviriler: + +* [한국어 문서](README_ko.md) +* [简体中文](README_zh.md) +* [正體中文](README_zh-TW.md) +* [简体中文](README_zh-CN.md) - ??? +* [Français](README_fr.md) +* [日本語](README_ja.md) +* [Español](README_es.md) +* [Türkçe](README_tr.md) + +## Genel Bakış + +Bu proje Go projeleri için basit bir yerleşim düzenidir. Bu standart Go geliştirici takımının belirlediği bir resmi standart değildir ama Go ekosistemi zaman geçtikçe ortaya çıkmış şablonları içerir. Bu şablonlardan bazıları diğerlerinden daha popülerdir. Bir dizi iyileştirmenin yanı sıra yeterli büyüklükte herhangi bir gerçek dünya uygulamasına özgü birkaç destekli dizin de içerir. + +Eğer Go'yu öğrenmeye çalışıyorsanız veya PoC (Proof of Concept) yada kendinize oyuncak bir proje yapıyorsanız bu klasör düzeni aşırı olabilir. Çok basit bir şeyle başlayın (tek bir `main.go` dosyası fazlasıyla yeterli). Projeniz büyüdükçe projenin iyi yapılandırıldığından emin olmanın önemli olduğunu unutmayon yoksa bir sürü gizli bağımlılık (dependency) ve bir sürü her yerden erişebildiğin global değişkenlerle dolu dağınık bir kodla karşılaşabilirsiniz. Proje üstünde fazla kişi çalıştığında projeyi çok daha fazla yapılandırmanız gerekebilir. İşte tam da bu durumda paketleri/kütüphaneleri idare edebilmek için ortaya ortak bir yol koymak gerekir. Açık kaynak bir projeniz olduğunda yada başkalarının senin projeni kullandıklarını bildiğinizde projenizde özel paketlerin ve kodların (diğer adıyla, `internal` klasörü) olması önemlidir. Bu projeyi klonla, ihtiyacın olanları bırakın ve diğer bütün her şeyi silin. Bütün klasörlerin burada olması kullanmanız gerektiği anlamına gelmez. `vendor` klasörü bile herkes tarafından kullanılan bir şey değil. + +Go 1.14 ile birlikte [`Go Modules`](https://github.com/golang/go/wiki/Modules) özelliği sonunda `production` ortamında kullanılması için hazır oldu. Eğer karşı bir nedeniniz yoksa [`Go Modules`](https://blog.golang.org/using-go-modules) kullanın eğer kullanırsanız `$GOPATH` ile ve projenizin nereye koyulacağıyla alakalı endişeler duymazsınız. Projenizde bulunan basit `go.mod` dosyası projenizin GitHub'da barındırıldığını varsayar ama bu bir gereklilik değildir. Modül yolu her şey olabilir ama modül yolunun ilk parçasının içinde bir nokta olmalıdır (Go'nun şimdiki versiyonu artık bu konuda zorlamıyor ama eğer daha eski versiyonları kullanırsanız ve derleme işleminde hata alırsanız şaşırmayın). Daha fazla bilgi için [`37554`](https://github.com/golang/go/issues/37554) ve [`32819`](https://github.com/golang/go/issues/32819) hata bildirimlerine bakabilirsiniz. + +With Go 1.14 [`Go Modules`](https://github.com/golang/go/wiki/Modules) are finally ready for production. Use [`Go Modules`](https://blog.golang.org/using-go-modules) unless you have a specific reason not to use them and if you do then you don’t need to worry about $GOPATH and where you put your project. The basic `go.mod` file in the repo assumes your project is hosted on GitHub, but it's not a requirement. The module path can be anything though the first module path component should have a dot in its name (the current version of Go doesn't enforce it anymore, but if you are using slightly older versions don't be surprised if your builds fail without it). See Issues [`37554`](https://github.com/golang/go/issues/37554) and [`32819`](https://github.com/golang/go/issues/32819) if you want to know more about it. + +Bu proje düzeni genel bir düzendir ve belirli bir Go paketi yapısını empoze etmeye çalışmaz. + +Bu bir topluluk eseridir. Eğer yeni bir şablon, düzen ile karşılaşırsanız yada olan şablonların, düzenlerin güncellenmesi gerektiğini düşünyorsanız bir hata bildirimi açınız. + +This project layout is intentionally generic and it doesn't try to impose a specific Go package structure. + +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. + +Eğer isimlendirmekle, biçimlendirmeyle ve stilize etmeyle ilgili yardıma ihtiyacın varsa [`gofmt`](https://golang.org/cmd/gofmt/) ve [`golint`](https://github.com/golang/lint) yazılımlarını çalıştırmayı dene. Ayrıca aşağıdaki Go kod stili rehberlerini ve önerilerini okuduğunuzdan emin olun. +* 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) + +Ek bilgi için [`Go Project Layout`](https://medium.com/golang-learn/go-project-layout-e5213cdcfaa2) adlı yazıya bakabilirsin. + +Paketlerin adlandırılması ve düzenlenmesi ile diğer kod yapısı önerileri hakkında daha fazla bilgi: +* [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) + +Paket odaklı dizayn rehberi ve Mimari katmanı ile alakalı Çince bir yazı +* [面向包的设计和架构分层](https://github.com/danceyoung/paper-code/blob/master/package-oriented-design/packageorienteddesign.md) + +## Go Klasörleri + +### `/cmd` + +Projenin ana uygulamalarını içerir. + +Her uygulamanın klasör adı, eklemek istediğiniz uygulamanın adıyla eşleşmelidir. (örneğin, `/cmd/benimuygulamam`) + +Bu klasöre çok fazla kod koymanız iyi olmaz. Eğer kodların başka projeler tarafından kullanılabileceğini düşünüyorsanız, o kodları `/pkg` klasörüne koymalısınız. Eğer kod yeniden kullanılabilecek değilse yada diğerlerinin yeniden kullanmasını istemiyorsanız, bu kodları `/internal` klasörüne koymalısınız. Niyetiniz hakkında açık olun, diğer geliştiricilerin kodunuzu ne için kullanabileceğine şaşıracaksınız! + +`/internal` ve `/pkg` klasörlerinden kod çağıran küçük bir `main` fonksiyonunuzun olması yaygındır. + +Örnekler için [`/cmd`](cmd/README.md) klasörüne bakabilirsiniz. + +### `/internal` + +Özel uygulama ve kütüphane kodunu içerir. Buradaki kodlar diğer geliştiricilerin kendi projelerinde kullanmasını istemediğiniz kodlardır. Bu yerleşim düzeninin Go derleyicisinin kendisi tarafından uygulandığına dikkat edin. Ayrıntılar için Go 1.4 [`sürüm notları`](https://golang.org/doc/go1.4#internalpackages). Üst katmandaki `internal` klasörü ile sınırlı olmadığınızı unutmayın, projenizin herhangi bir katmanında birden fazla `internal` klasörüne sahip olabilirsiniz. + +Paylaşılan ve paylaşılmayan kodunuzu ayırmak için isteğe bağlı olarak ekstra yapılar ekleyebilirsiniz. Bu gerekli değildir (özellikle küçük projeler için) ancak amaçlanan paket kullanımını gösteren görsel ipuçlarına sahip olmak güzel bir şey. Asıl uygulama kodunuz `/internal/app` klasöründe yer alabilir (örneğin, `/internal/app/benimuygulamam`) ve bu kodlar `/internal/pkg` klasöründe yer alan kodlar (örneğin, `/internal/pkg/benimözelkütüphanem`) ile paylaşılabilir. + +### `/pkg` + +Diğerleriyle paylaşmak istediğiniz kodu içerir (örneğin, `/pkg/benimherkeseaçıkkütüphanem`). Diğer projeler bu kütüphaneleri çalışacağını tahmin ederek kullanırlar. Yani buraya bir şey koyarken iki kere düşünün :-) Unutmayın ki `internal` klasörü başka projeler tarafından kullanılmasını istemediğiniz kodlar için daha iyi bir yerdir çünkü bu Go tarafından zorunlu olarak uygulanır. `/pkg` klasörü içindeki kodun başkaları tarafından kullanılmasının güvenli olduğunu açıkça belirtmek için hala iyi bir yoldur. Travis Jeffery tarafından yazılan [`I'll take pkg over internal`](https://travisjeffery.com/b/2019/11/i-ll-take-pkg-over-internal/) blog yazısı `pkg` ve `internal` klasörleri ve onları ne zaman kullanmanın mantıklı olacağına dair genel bakış sağlar. + +Ayrıca ana klasörünüz çok sayıda Go kodu olmayan dosya ve klasör içerdiğinde Go kodunu tek bir yerde gruplamanın yoludur ve bazı Go araçlarını kullanmayı daha kolay hale getirir (bu konuşmalarda bahsedildiği gibi: [`Best Practices for Industrial Programming`](https://www.youtube.com/watch?v=PTE4VJIdHPg) from GopherCon EU 2018, [GopherCon 2018: Kat Zien - How Do You Structure Your Go Apps](https://www.youtube.com/watch?v=oL6JBUk6tj0) and [GoLab 2018 - Massimiliano Pippi - Project layout patterns in Go](https://www.youtube.com/watch?v=3gQa1LWwuzk)). + +Hangi popüler Go projelerinin bu düzeni kullandığını merak ediyorsanız [`/pkg`](pkg/README.md) klasörüne bakabilirsiniz. Bu genel bir yerleşim düzenidir ama herkes tarafından kabul edilmiyor ve bazı Go toplulukları bu yerleşim düzenini tavsiye etmeyebilir. + +Eğer projenizde ekstra bir katmana gerek yoksa yada projeniz çok küçükse burayı kullanmamanızda bir sakınca olmaz (çok istiyorsanız kullanın). Projeniz yeterince büyük olduğunda ve ana klasörünüz karışmaya başladığında (özellikle çok fazla Go kodu olmayan dosyanız olduğunda) bunu kullanmayı düşünebilirsiniz. + +### `/vendor` + +Uygulama bağımlılıkları (el ile yönetilen yada yeni bir özellik olan [`Go Modules`](https://github.com/golang/go/wiki/Modules) gibi favori bağımlılık yönetim aracınızla yönetilen). `go mod vendor` komutu size yeni bir `/vendor klasörü yaratır`. Unutmayın eğer Go 1.14 kullanmıyorsanız `go build` komutuna `-mod=vendor` parametresi vermeniz gerekebilir Go 1.14 bunu varsayılan olarak yapar. + +Eğer bir kütüphane yazıyorsanız bağımlılıklarınızı `commit` etmeyin. + +Not olarak [`1.13`](https://golang.org/doc/go1.13#modules) versiyonundan itibaren Go modüller için `proxy` özelliğini aktif hale getirdi (varsayılan olarak[`https://proxy.golang.org`](https://proxy.golang.org) adresini kullanır). [`Buradan`](https://blog.golang.org/module-mirror-launch) gereksinimlerinize ve kısıtlamalarınıza uyup uymadığı hakkında daha fazla bilgi edinebilirsiniz. Eğer bu size uyarsa `vendor` klasörüne çokta ihtiyacınız olmayacaktır. + +## Servis Uygulaması Klasörleri + +### `/api` + +OpenAPI/Swagger dosyaları, JSON şema dosyaları, protokol tanımlama dosyaları. + +Örnekler için [`/api`](api/README.md) klasörüne bakabilirsiniz. + +## Web Uygulaması Klasörleri + +### `/web` + +Spesifik web uygulaması parçaları: statik web varlıkları, sunucu taraflı şablonlar ve SPA'lar. + +## Genel Uygulama Klasörleri + +### `/configs` + +Konfigürasyon dosya şablonları veya varsayılan konfigürasyonlar. + +`confd` veya `consul-template` dosyalarını buraya koyabilirsiniz. + +### `/init` + +Sistem başlangıcı (systemd, upstart, sysv) ve işlem yöneticisi (runit, supervisord) konfigürasyonları. + +### `/scripts` + +Ç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. (örnek, [`https://github.com/hashicorp/terraform/blob/master/Makefile`](https://github.com/hashicorp/terraform/blob/master/Makefile)). + +Örnekler için [`/scripts`](scripts/README.md) klasörüne bakabilirsiniz. + +### `/build` + +Paketleme ve Sürekli Entegrasyon. + +`/build/package` klasörüne bulut (AMI), konteyner (Docker), işletim sistemi (deb, rpm, pkg) paket konfigürasyonlarını ve komut dosyalarını koyabilirsiniz. + +`/build/ci` klasörüne de Sürekli Entegrasyon (travis, circle, drone) konfigürasyonlarını ve komut dosyalarını koyabilirsiniz. Önemli olarak bazı sürekli entegrasyon araçları (örneğin, Travis CI) konfigürasyon dosyalarının klasörleriyle alakalı seçici olabiliyor. Konfigürasyon dosyalarını `/build/ci` klasörüne koymayı deneyin ve dosyaları sürekli entegrasyon araçlarının bekledikleri yere bağlayın (mümkün olduğunda). + +### `/deployments` + +IaaS, Paas, sistem ve konteyner orkestrasyon yayınlama konfigürasyonlarını ve şablonlarını (docker-compose, kubernetes/helm, mesos, terraform, bosh) bu klasöre koyabilirsiniz. Önemli olarak bazı projelerde (özellikle kubernetes ile yayınlanan projeler) bu klasörün adı `/deploy` olabilir. + +### `/test` + +Ek harici test uygulamaları ve test verileri. `/test` klasörünün içini istediğiniz gibi yapılandırmada özgür hissedin. Daha büyük projelerde test verileri için alt klasörler açmak mantıklı olabilir. Örneğin, eğer Go'nun test dosyalarını görmezden gelmesini istiyorsanız bu dosyalar için `/test/data` veya `/test/testdata` adlı klasörlere sahip olabilirsiniz. Not olarak Go "." veya "_" ile başlayan klasörleri ve dosyalarıda görmezden gelir, bu sayede test klasörlerinizi ve dosyalarınızı isimlendirmede daha esnek olabilirsiniz. + +Örnekler için [`/test`](test/README.md) klasörüne bakabilirsiniz. + +## Diğer Klasörler + +### `/docs` + +Tasarım ve kullanıcı dökümanları (godoc ile oluşturulmuş dökümanlara ek olarak) + +Örnekler için [`/docs`](docs/README.md) klasörüne bakabilirsiniz. + +### `/tools` + +Bu klasöre projen için destekleyici araçları koyabilirsin. Unutma bu araçlar `/pkg` ve `/internal` klasörlerindeki kodları kullanabilirler. + +Örnekler için [`/tools`](tools/README.md) klasörüne bakabilirsiniz. + +### `/examples` + +Bu klasöre yaptığın uygulamalar yada kütüphaneler için örnekleri koyabilirsin. + +Örnekler için [`/examples`](examples/README.md) klasörüne bakabilirsiniz. + +### `/third_party` + +Dış yardımcı araçlar, çatallanmış kod (forked code) ve diğer 3. parti yardımcı şeyler. (örnek, Swagger UI) + +### `/githooks` + +Git hooks. + +### `/assets` + +Bu klasöre resim, logo ve benzeri kaynakları koyabilirsiniz. + +### `/website` + +Eğer GitHub Pages kullanmıyorsan burası projenin websitesinin dosyalarının konulması için doğru adres. + +Örnekler için [`/website`](website/README.md) klasörüne bakabilirsiniziz. + +## Sahip olmamanız gereken klasörler + +### `/src` + +Bazı Go projelerinde `src` adlı bir klasör görebilirsiniz, ama bu çoğunlukla `src` klasörü kullanmanın genel bir kalıp olduğu Java dünyasından gelen geliştiricilerde olur. Eğer yapabilirseniz bu Java kalıbını benimsememeye çalışın. Gerçekten Go kodunuzun yada Go projenizin Java gibi gözükmesini istemezsiniz :-) + +Proje seviyesindeki `/src` klasörü ile [`How to Write Go Code`](https://golang.org/doc/code.html) adresinde belirtilen Go'nun çalışma alanları için kullandığı `/src` klasörünü karıştırmayın. `$GOPATH` ortam değişkeni senin çalışma alanına (şuanki) işaret eder (Windows olmayan sistemlerde varsayılan olarak `$HOME/go` klasörüne işaret eder). Bu çalışma alanı içerisinde en üst katmandaki `/pkg`, `/bin` ve `/src` klasörlerini barındırır. Asıl projen `/src` klasörü altında bir alt dizin olur. Eğer projende `/src` klasörüne sahipsen, projenin dosya yolu büyük ihtimal şöyle gözükecek `/calisma-alanin/src/senin_projen/src/senin_kodun.go`. Not olarak Go 1.11 ile `$GOPATH` klasörü dışında projeler açabilirsin ama bunu yapabilmen bu yerleşim düzeninin kullanılmasının iyi bir fikir olduğu anlamına gelmez. + +## Rozetler + +* [Go Report Card](https://goreportcard.com/) - Kodunu `gofmt`, `go vet`, `gocyclo`, `golint`, `ineffassign`, `license` ve `misspell` yazılımları ile tarar. `github.com/golang-standards/project-layout` linkini kendi proje linkiniz ile değiştirin. + + [![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) - Projenizin GoDoc tarafından yaratılmış online bir dökümantasyonunu çıkartır. İşaret ettiği linki kendi proje linkiniz ile değiştirin.~~ + + [![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) - Paket keşfi ve dökümantasyonları için yeni adres Pkg.go.dev. [Rozet yaratma aracı](https://pkg.go.dev/badge) ile projenize bir rozet yaratabilirsiniz. + + [![PkgGoDev](https://pkg.go.dev/badge/github.com/golang-standards/project-layout)](https://pkg.go.dev/github.com/golang-standards/project-layout) + +* Release - Projenin en son yayınlanmış versiyonunu gösterir. İşaret ettiği linki kendi proje linkiniz ile değiştirin. + + [![Release](https://img.shields.io/github/release/golang-standards/project-layout.svg?style=flat-square)](https://github.com/golang-standards/project-layout/releases/latest) + +## Notlar + +Örnek/yeniden kullanılabilir yapılandırmalar, komut dosyaları ve kodları içeren daha kararlı bir proje şablonu yapım aşamasındadır. \ No newline at end of file From f92995aa1b23e58790c00615baf8bfc54f746823 Mon Sep 17 00:00:00 2001 From: xis Date: Wed, 3 Feb 2021 22:08:38 +0300 Subject: [PATCH 02/76] edits --- README_tr.md | 6 ------ 1 file changed, 6 deletions(-) diff --git a/README_tr.md b/README_tr.md index 9906368..c94ed87 100644 --- a/README_tr.md +++ b/README_tr.md @@ -19,16 +19,10 @@ Eğer Go'yu öğrenmeye çalışıyorsanız veya PoC (Proof of Concept) yada ken Go 1.14 ile birlikte [`Go Modules`](https://github.com/golang/go/wiki/Modules) özelliği sonunda `production` ortamında kullanılması için hazır oldu. Eğer karşı bir nedeniniz yoksa [`Go Modules`](https://blog.golang.org/using-go-modules) kullanın eğer kullanırsanız `$GOPATH` ile ve projenizin nereye koyulacağıyla alakalı endişeler duymazsınız. Projenizde bulunan basit `go.mod` dosyası projenizin GitHub'da barındırıldığını varsayar ama bu bir gereklilik değildir. Modül yolu her şey olabilir ama modül yolunun ilk parçasının içinde bir nokta olmalıdır (Go'nun şimdiki versiyonu artık bu konuda zorlamıyor ama eğer daha eski versiyonları kullanırsanız ve derleme işleminde hata alırsanız şaşırmayın). Daha fazla bilgi için [`37554`](https://github.com/golang/go/issues/37554) ve [`32819`](https://github.com/golang/go/issues/32819) hata bildirimlerine bakabilirsiniz. -With Go 1.14 [`Go Modules`](https://github.com/golang/go/wiki/Modules) are finally ready for production. Use [`Go Modules`](https://blog.golang.org/using-go-modules) unless you have a specific reason not to use them and if you do then you don’t need to worry about $GOPATH and where you put your project. The basic `go.mod` file in the repo assumes your project is hosted on GitHub, but it's not a requirement. The module path can be anything though the first module path component should have a dot in its name (the current version of Go doesn't enforce it anymore, but if you are using slightly older versions don't be surprised if your builds fail without it). See Issues [`37554`](https://github.com/golang/go/issues/37554) and [`32819`](https://github.com/golang/go/issues/32819) if you want to know more about it. - Bu proje düzeni genel bir düzendir ve belirli bir Go paketi yapısını empoze etmeye çalışmaz. Bu bir topluluk eseridir. Eğer yeni bir şablon, düzen ile karşılaşırsanız yada olan şablonların, düzenlerin güncellenmesi gerektiğini düşünyorsanız bir hata bildirimi açınız. -This project layout is intentionally generic and it doesn't try to impose a specific Go package structure. - -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. - Eğer isimlendirmekle, biçimlendirmeyle ve stilize etmeyle ilgili yardıma ihtiyacın varsa [`gofmt`](https://golang.org/cmd/gofmt/) ve [`golint`](https://github.com/golang/lint) yazılımlarını çalıştırmayı dene. Ayrıca aşağıdaki Go kod stili rehberlerini ve önerilerini okuduğunuzdan emin olun. * https://talks.golang.org/2014/names.slide * https://golang.org/doc/effective_go.html#names From d734c2ab8017c0fc6b5012be955c9e85679d798c Mon Sep 17 00:00:00 2001 From: xis Date: Wed, 3 Feb 2021 22:47:23 +0300 Subject: [PATCH 03/76] edits --- README_tr.md | 20 ++++++++++---------- 1 file changed, 10 insertions(+), 10 deletions(-) diff --git a/README_tr.md b/README_tr.md index c94ed87..3194dd1 100644 --- a/README_tr.md +++ b/README_tr.md @@ -13,17 +13,17 @@ ## Genel Bakış -Bu proje Go projeleri için basit bir yerleşim düzenidir. Bu standart Go geliştirici takımının belirlediği bir resmi standart değildir ama Go ekosistemi zaman geçtikçe ortaya çıkmış şablonları içerir. Bu şablonlardan bazıları diğerlerinden daha popülerdir. Bir dizi iyileştirmenin yanı sıra yeterli büyüklükte herhangi bir gerçek dünya uygulamasına özgü birkaç destekli dizin de içerir. +Bu proje Go projeleri için basit bir yerleşim düzenidir. Go geliştirici takımının belirlediği resmi standartları değil, Go ekosistemindeki ortak geçmişi ve zaman içinde ortaya çıkmış şablonları içerir. Bu şablonlardan bazıları diğerlerinden daha popülerdir. Bir dizi iyileştirmenin yanı sıra yeterli büyüklükte herhangi bir gerçek dünya uygulamasına özgü birkaç destekli dizin de içerir. -Eğer Go'yu öğrenmeye çalışıyorsanız veya PoC (Proof of Concept) yada kendinize oyuncak bir proje yapıyorsanız bu klasör düzeni aşırı olabilir. Çok basit bir şeyle başlayın (tek bir `main.go` dosyası fazlasıyla yeterli). Projeniz büyüdükçe projenin iyi yapılandırıldığından emin olmanın önemli olduğunu unutmayon yoksa bir sürü gizli bağımlılık (dependency) ve bir sürü her yerden erişebildiğin global değişkenlerle dolu dağınık bir kodla karşılaşabilirsiniz. Proje üstünde fazla kişi çalıştığında projeyi çok daha fazla yapılandırmanız gerekebilir. İşte tam da bu durumda paketleri/kütüphaneleri idare edebilmek için ortaya ortak bir yol koymak gerekir. Açık kaynak bir projeniz olduğunda yada başkalarının senin projeni kullandıklarını bildiğinizde projenizde özel paketlerin ve kodların (diğer adıyla, `internal` klasörü) olması önemlidir. Bu projeyi klonla, ihtiyacın olanları bırakın ve diğer bütün her şeyi silin. Bütün klasörlerin burada olması kullanmanız gerektiği anlamına gelmez. `vendor` klasörü bile herkes tarafından kullanılan bir şey değil. +Eğer Go'yu öğrenmeye çalışıyorsanız veya PoC (Proof of Concept) ya da kendinize oyuncak bir proje yapıyorsanız bu klasör düzeni aşırı olabilir. Çok basit bir şeyle başlayınız (tek bir `main.go` dosyası fazlasıyla yeterli). Projeniz büyüdükçe projenin iyi yapılandırıldığından emin olmanın önemli olduğunu unutmayın yoksa bir sürü gizli bağımlılık (dependency) ve bir sürü her yerden erişilebilen, `global` değişkenlerle dolu dağınık bir kodla karşılaşabilirsiniz. Proje üstünde fazla kişi çalıştığında projeyi çok daha fazla yapılandırmanız gerekebilir. İşte tam da bu durumda paketleri/kütüphaneleri idare edebilmek için ortaya ortak bir yol koymak gerekir. Açık kaynak bir projeniz olduğunda ya da başkalarının sizin projenizi kullandıklarını bildiğinizde projenizde özel paketlerin ve kodların (diğer adıyla, `internal` klasörü) olması önemlidir. Bu projeyi klonlayın, ihtiyacınız olanları bırakın ve diğer bütün her şeyi silin. Bütün klasörlerin burada olması kullanmanız gerektiği anlamına gelmez. `vendor` klasörü bile herkes tarafından kullanılan bir şey değildir. -Go 1.14 ile birlikte [`Go Modules`](https://github.com/golang/go/wiki/Modules) özelliği sonunda `production` ortamında kullanılması için hazır oldu. Eğer karşı bir nedeniniz yoksa [`Go Modules`](https://blog.golang.org/using-go-modules) kullanın eğer kullanırsanız `$GOPATH` ile ve projenizin nereye koyulacağıyla alakalı endişeler duymazsınız. Projenizde bulunan basit `go.mod` dosyası projenizin GitHub'da barındırıldığını varsayar ama bu bir gereklilik değildir. Modül yolu her şey olabilir ama modül yolunun ilk parçasının içinde bir nokta olmalıdır (Go'nun şimdiki versiyonu artık bu konuda zorlamıyor ama eğer daha eski versiyonları kullanırsanız ve derleme işleminde hata alırsanız şaşırmayın). Daha fazla bilgi için [`37554`](https://github.com/golang/go/issues/37554) ve [`32819`](https://github.com/golang/go/issues/32819) hata bildirimlerine bakabilirsiniz. +Go 1.14 ile birlikte [`Go Modules`](https://github.com/golang/go/wiki/Modules) özelliği sonunda `production` ortamında kullanılması için hazır oldu. Eğer karşı bir nedeniniz yoksa [`Go Modules`](https://blog.golang.org/using-go-modules) kullanın. Eğer kullanırsanız `$GOPATH` ile ve projenizin nereye koyulacağıyla alakalı endişeler duymazsınız. Projenizde bulunan basit `go.mod` dosyası projenizin GitHub'da barındırıldığını varsayar ama bu bir gereklilik değildir. Modül yolu her şey olabilir ama modül yolunun ilk parçasının içinde bir nokta olmalıdır (Go'nun şimdiki versiyonu artık bu konuda zorlamıyor ama eğer daha eski versiyonları kullanırsanız ve derleme işleminde hata alırsanız şaşırmayın). Daha fazla bilgi için [`37554`](https://github.com/golang/go/issues/37554) ve [`32819`](https://github.com/golang/go/issues/32819) hata bildirimlerine bakabilirsiniz. Bu proje düzeni genel bir düzendir ve belirli bir Go paketi yapısını empoze etmeye çalışmaz. -Bu bir topluluk eseridir. Eğer yeni bir şablon, düzen ile karşılaşırsanız yada olan şablonların, düzenlerin güncellenmesi gerektiğini düşünyorsanız bir hata bildirimi açınız. +Bu bir topluluk eseridir. Eğer yeni bir şablon, düzen ile karşılaşırsanız ya da olan şablonların, düzenlerin güncellenmesi gerektiğini düşünyorsanız bir hata bildirimi açınız. -Eğer isimlendirmekle, biçimlendirmeyle ve stilize etmeyle ilgili yardıma ihtiyacın varsa [`gofmt`](https://golang.org/cmd/gofmt/) ve [`golint`](https://github.com/golang/lint) yazılımlarını çalıştırmayı dene. Ayrıca aşağıdaki Go kod stili rehberlerini ve önerilerini okuduğunuzdan emin olun. +Eğer isimlendirmekle, biçimlendirmeyle ve stilize etmeyle ilgili yardıma ihtiyacınız varsa [`gofmt`](https://golang.org/cmd/gofmt/) ve [`golint`](https://github.com/golang/lint) yazılımlarını çalıştırmayı deneyin. Ayrıca aşağıdaki Go kod stili rehberlerini ve önerilerini okuduğunuzdan emin olun. * https://talks.golang.org/2014/names.slide * https://golang.org/doc/effective_go.html#names * https://blog.golang.org/package-names @@ -49,7 +49,7 @@ Projenin ana uygulamalarını içerir. Her uygulamanın klasör adı, eklemek istediğiniz uygulamanın adıyla eşleşmelidir. (örneğin, `/cmd/benimuygulamam`) -Bu klasöre çok fazla kod koymanız iyi olmaz. Eğer kodların başka projeler tarafından kullanılabileceğini düşünüyorsanız, o kodları `/pkg` klasörüne koymalısınız. Eğer kod yeniden kullanılabilecek değilse yada diğerlerinin yeniden kullanmasını istemiyorsanız, bu kodları `/internal` klasörüne koymalısınız. Niyetiniz hakkında açık olun, diğer geliştiricilerin kodunuzu ne için kullanabileceğine şaşıracaksınız! +Bu klasöre çok fazla kod koymanız iyi olmaz. Eğer kodların başka projeler tarafından kullanılabileceğini düşünüyorsanız, o kodları `/pkg` klasörüne koymalısınız. Eğer kod yeniden kullanılabilecek değilse ya da diğerlerinin yeniden kullanmasını istemiyorsanız, bu kodları `/internal` klasörüne koymalısınız. Niyetiniz hakkında açık olun, diğer geliştiricilerin kodunuzu ne için kullanabileceğine şaşıracaksınız! `/internal` ve `/pkg` klasörlerinden kod çağıran küçük bir `main` fonksiyonunuzun olması yaygındır. @@ -69,11 +69,11 @@ Ayrıca ana klasörünüz çok sayıda Go kodu olmayan dosya ve klasör içerdi Hangi popüler Go projelerinin bu düzeni kullandığını merak ediyorsanız [`/pkg`](pkg/README.md) klasörüne bakabilirsiniz. Bu genel bir yerleşim düzenidir ama herkes tarafından kabul edilmiyor ve bazı Go toplulukları bu yerleşim düzenini tavsiye etmeyebilir. -Eğer projenizde ekstra bir katmana gerek yoksa yada projeniz çok küçükse burayı kullanmamanızda bir sakınca olmaz (çok istiyorsanız kullanın). Projeniz yeterince büyük olduğunda ve ana klasörünüz karışmaya başladığında (özellikle çok fazla Go kodu olmayan dosyanız olduğunda) bunu kullanmayı düşünebilirsiniz. +Eğer projenizde ekstra bir katmana gerek yoksa ya da projeniz çok küçükse burayı kullanmamanızda bir sakınca olmaz (çok istiyorsanız kullanın). Projeniz yeterince büyük olduğunda ve ana klasörünüz karışmaya başladığında (özellikle çok fazla Go kodu olmayan dosyanız olduğunda) bunu kullanmayı düşünebilirsiniz. ### `/vendor` -Uygulama bağımlılıkları (el ile yönetilen yada yeni bir özellik olan [`Go Modules`](https://github.com/golang/go/wiki/Modules) gibi favori bağımlılık yönetim aracınızla yönetilen). `go mod vendor` komutu size yeni bir `/vendor klasörü yaratır`. Unutmayın eğer Go 1.14 kullanmıyorsanız `go build` komutuna `-mod=vendor` parametresi vermeniz gerekebilir Go 1.14 bunu varsayılan olarak yapar. +Uygulama bağımlılıkları (el ile yönetilen ya da yeni bir özellik olan [`Go Modules`](https://github.com/golang/go/wiki/Modules) gibi favori bağımlılık yönetim aracınızla yönetilen). `go mod vendor` komutu size yeni bir `/vendor klasörü yaratır`. Unutmayın eğer Go 1.14 kullanmıyorsanız `go build` komutuna `-mod=vendor` parametresi vermeniz gerekebilir Go 1.14 bunu varsayılan olarak yapar. Eğer bir kütüphane yazıyorsanız bağımlılıklarınızı `commit` etmeyin. @@ -147,7 +147,7 @@ Bu klasöre projen için destekleyici araçları koyabilirsin. Unutma bu araçla ### `/examples` -Bu klasöre yaptığın uygulamalar yada kütüphaneler için örnekleri koyabilirsin. +Bu klasöre yaptığın uygulamalar ya da kütüphaneler için örnekleri koyabilirsin. Örnekler için [`/examples`](examples/README.md) klasörüne bakabilirsiniz. @@ -173,7 +173,7 @@ Eğer GitHub Pages kullanmıyorsan burası projenin websitesinin dosyalarının ### `/src` -Bazı Go projelerinde `src` adlı bir klasör görebilirsiniz, ama bu çoğunlukla `src` klasörü kullanmanın genel bir kalıp olduğu Java dünyasından gelen geliştiricilerde olur. Eğer yapabilirseniz bu Java kalıbını benimsememeye çalışın. Gerçekten Go kodunuzun yada Go projenizin Java gibi gözükmesini istemezsiniz :-) +Bazı Go projelerinde `src` adlı bir klasör görebilirsiniz, ama bu çoğunlukla `src` klasörü kullanmanın genel bir kalıp olduğu Java dünyasından gelen geliştiricilerde olur. Eğer yapabilirseniz bu Java kalıbını benimsememeye çalışın. Gerçekten Go kodunuzun ya da Go projenizin Java gibi gözükmesini istemezsiniz :-) Proje seviyesindeki `/src` klasörü ile [`How to Write Go Code`](https://golang.org/doc/code.html) adresinde belirtilen Go'nun çalışma alanları için kullandığı `/src` klasörünü karıştırmayın. `$GOPATH` ortam değişkeni senin çalışma alanına (şuanki) işaret eder (Windows olmayan sistemlerde varsayılan olarak `$HOME/go` klasörüne işaret eder). Bu çalışma alanı içerisinde en üst katmandaki `/pkg`, `/bin` ve `/src` klasörlerini barındırır. Asıl projen `/src` klasörü altında bir alt dizin olur. Eğer projende `/src` klasörüne sahipsen, projenin dosya yolu büyük ihtimal şöyle gözükecek `/calisma-alanin/src/senin_projen/src/senin_kodun.go`. Not olarak Go 1.11 ile `$GOPATH` klasörü dışında projeler açabilirsin ama bunu yapabilmen bu yerleşim düzeninin kullanılmasının iyi bir fikir olduğu anlamına gelmez. From ebab1c68900596bf74eeafd29a3bf84d5be987d7 Mon Sep 17 00:00:00 2001 From: xis Date: Thu, 4 Feb 2021 00:07:42 +0300 Subject: [PATCH 04/76] edits --- README_tr.md | 34 +++++++++++++++++----------------- 1 file changed, 17 insertions(+), 17 deletions(-) diff --git a/README_tr.md b/README_tr.md index 3194dd1..7433e35 100644 --- a/README_tr.md +++ b/README_tr.md @@ -15,13 +15,13 @@ Bu proje Go projeleri için basit bir yerleşim düzenidir. Go geliştirici takımının belirlediği resmi standartları değil, Go ekosistemindeki ortak geçmişi ve zaman içinde ortaya çıkmış şablonları içerir. Bu şablonlardan bazıları diğerlerinden daha popülerdir. Bir dizi iyileştirmenin yanı sıra yeterli büyüklükte herhangi bir gerçek dünya uygulamasına özgü birkaç destekli dizin de içerir. -Eğer Go'yu öğrenmeye çalışıyorsanız veya PoC (Proof of Concept) ya da kendinize oyuncak bir proje yapıyorsanız bu klasör düzeni aşırı olabilir. Çok basit bir şeyle başlayınız (tek bir `main.go` dosyası fazlasıyla yeterli). Projeniz büyüdükçe projenin iyi yapılandırıldığından emin olmanın önemli olduğunu unutmayın yoksa bir sürü gizli bağımlılık (dependency) ve bir sürü her yerden erişilebilen, `global` değişkenlerle dolu dağınık bir kodla karşılaşabilirsiniz. Proje üstünde fazla kişi çalıştığında projeyi çok daha fazla yapılandırmanız gerekebilir. İşte tam da bu durumda paketleri/kütüphaneleri idare edebilmek için ortaya ortak bir yol koymak gerekir. Açık kaynak bir projeniz olduğunda ya da başkalarının sizin projenizi kullandıklarını bildiğinizde projenizde özel paketlerin ve kodların (diğer adıyla, `internal` klasörü) olması önemlidir. Bu projeyi klonlayın, ihtiyacınız olanları bırakın ve diğer bütün her şeyi silin. Bütün klasörlerin burada olması kullanmanız gerektiği anlamına gelmez. `vendor` klasörü bile herkes tarafından kullanılan bir şey değildir. +Eğer Go'yu öğrenmeye çalışıyorsanız veya PoC (Proof of Concept) ya da kendinize oyuncak bir proje yapıyorsanız bu klasör düzeni aşırı olabilir. Çok basit bir şeyle başlayın (tek bir `main.go` dosyası fazlasıyla yeterli). Projeniz büyüdükçe projenin iyi yapılandırıldığından emin olmanın önemli olduğunu unutmayın yoksa bir sürü gizli bağımlılık (dependency) ve bir sürü her yerden erişilebilen, `global` değişkenlerle dolu dağınık bir kodla karşılaşabilirsiniz. Proje üstünde fazla kişi çalıştığında projeyi çok daha fazla yapılandırmanız gerekebilir. İşte tam da bu durumda paketleri/kütüphaneleri idare edebilmek için ortaya ortak bir yol koymak gerekir. Açık kaynak bir projeniz olduğunda ya da başkalarının sizin projenizi kullandıklarını bildiğinizde projenizde özel paketlerin ve kodların (diğer adıyla, `internal` klasörü) olması önemlidir. Bu projeyi klonlayın, ihtiyacınız olanları bırakın ve diğer bütün her şeyi silin. Bütün klasörlerin burada olması kullanmanız gerektiği anlamına gelmez. `vendor` klasörü bile herkes tarafından kullanılan bir şey değildir. Go 1.14 ile birlikte [`Go Modules`](https://github.com/golang/go/wiki/Modules) özelliği sonunda `production` ortamında kullanılması için hazır oldu. Eğer karşı bir nedeniniz yoksa [`Go Modules`](https://blog.golang.org/using-go-modules) kullanın. Eğer kullanırsanız `$GOPATH` ile ve projenizin nereye koyulacağıyla alakalı endişeler duymazsınız. Projenizde bulunan basit `go.mod` dosyası projenizin GitHub'da barındırıldığını varsayar ama bu bir gereklilik değildir. Modül yolu her şey olabilir ama modül yolunun ilk parçasının içinde bir nokta olmalıdır (Go'nun şimdiki versiyonu artık bu konuda zorlamıyor ama eğer daha eski versiyonları kullanırsanız ve derleme işleminde hata alırsanız şaşırmayın). Daha fazla bilgi için [`37554`](https://github.com/golang/go/issues/37554) ve [`32819`](https://github.com/golang/go/issues/32819) hata bildirimlerine bakabilirsiniz. Bu proje düzeni genel bir düzendir ve belirli bir Go paketi yapısını empoze etmeye çalışmaz. -Bu bir topluluk eseridir. Eğer yeni bir şablon, düzen ile karşılaşırsanız ya da olan şablonların, düzenlerin güncellenmesi gerektiğini düşünyorsanız bir hata bildirimi açınız. +Bu bir topluluk eseridir. Eğer yeni bir şablon, düzen ile karşılaşırsanız ya da olan şablonların, düzenlerin güncellenmesi gerektiğini düşünüyorsanız bir hata bildirimi açınız. Eğer isimlendirmekle, biçimlendirmeyle ve stilize etmeyle ilgili yardıma ihtiyacınız varsa [`gofmt`](https://golang.org/cmd/gofmt/) ve [`golint`](https://github.com/golang/lint) yazılımlarını çalıştırmayı deneyin. Ayrıca aşağıdaki Go kod stili rehberlerini ve önerilerini okuduğunuzdan emin olun. * https://talks.golang.org/2014/names.slide @@ -38,7 +38,7 @@ Paketlerin adlandırılması ve düzenlenmesi ile diğer kod yapısı önerileri * [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) -Paket odaklı dizayn rehberi ve Mimari katmanı ile alakalı Çince bir yazı +Paket odaklı dizayn rehberi ve Mimari katmanı ile alakalı Çince bir yazı: * [面向包的设计和架构分层](https://github.com/danceyoung/paper-code/blob/master/package-oriented-design/packageorienteddesign.md) ## Go Klasörleri @@ -59,25 +59,25 @@ Bu klasöre çok fazla kod koymanız iyi olmaz. Eğer kodların başka projeler Özel uygulama ve kütüphane kodunu içerir. Buradaki kodlar diğer geliştiricilerin kendi projelerinde kullanmasını istemediğiniz kodlardır. Bu yerleşim düzeninin Go derleyicisinin kendisi tarafından uygulandığına dikkat edin. Ayrıntılar için Go 1.4 [`sürüm notları`](https://golang.org/doc/go1.4#internalpackages). Üst katmandaki `internal` klasörü ile sınırlı olmadığınızı unutmayın, projenizin herhangi bir katmanında birden fazla `internal` klasörüne sahip olabilirsiniz. -Paylaşılan ve paylaşılmayan kodunuzu ayırmak için isteğe bağlı olarak ekstra yapılar ekleyebilirsiniz. Bu gerekli değildir (özellikle küçük projeler için) ancak amaçlanan paket kullanımını gösteren görsel ipuçlarına sahip olmak güzel bir şey. Asıl uygulama kodunuz `/internal/app` klasöründe yer alabilir (örneğin, `/internal/app/benimuygulamam`) ve bu kodlar `/internal/pkg` klasöründe yer alan kodlar (örneğin, `/internal/pkg/benimözelkütüphanem`) ile paylaşılabilir. +Paylaşılan ve paylaşılmayan kodunuzu ayırmak için isteğe bağlı olarak ekstra yapılar ekleyebilirsiniz. Bu gerekli değildir (özellikle küçük projeler için) ancak amaçlanan paket kullanımını gösteren görsel ipuçlarına sahip olmak güzel bir şeydir. Asıl uygulama kodunuz `/internal/app` klasöründe yer alabilir (örneğin, `/internal/app/benimuygulamam`) ve bu kodlar `/internal/pkg` klasöründe yer alan kodlar (örneğin, `/internal/pkg/benimözelkütüphanem`) ile paylaşılabilir. ### `/pkg` Diğerleriyle paylaşmak istediğiniz kodu içerir (örneğin, `/pkg/benimherkeseaçıkkütüphanem`). Diğer projeler bu kütüphaneleri çalışacağını tahmin ederek kullanırlar. Yani buraya bir şey koyarken iki kere düşünün :-) Unutmayın ki `internal` klasörü başka projeler tarafından kullanılmasını istemediğiniz kodlar için daha iyi bir yerdir çünkü bu Go tarafından zorunlu olarak uygulanır. `/pkg` klasörü içindeki kodun başkaları tarafından kullanılmasının güvenli olduğunu açıkça belirtmek için hala iyi bir yoldur. Travis Jeffery tarafından yazılan [`I'll take pkg over internal`](https://travisjeffery.com/b/2019/11/i-ll-take-pkg-over-internal/) blog yazısı `pkg` ve `internal` klasörleri ve onları ne zaman kullanmanın mantıklı olacağına dair genel bakış sağlar. -Ayrıca ana klasörünüz çok sayıda Go kodu olmayan dosya ve klasör içerdiğinde Go kodunu tek bir yerde gruplamanın yoludur ve bazı Go araçlarını kullanmayı daha kolay hale getirir (bu konuşmalarda bahsedildiği gibi: [`Best Practices for Industrial Programming`](https://www.youtube.com/watch?v=PTE4VJIdHPg) from GopherCon EU 2018, [GopherCon 2018: Kat Zien - How Do You Structure Your Go Apps](https://www.youtube.com/watch?v=oL6JBUk6tj0) and [GoLab 2018 - Massimiliano Pippi - Project layout patterns in Go](https://www.youtube.com/watch?v=3gQa1LWwuzk)). +Ayrıca ana klasörünüz çok sayıda Go kodu olmayan dosya ve klasör içerdiğinde Go kodunu tek bir yerde gruplamanın yoludur ve bazı Go araçlarını kullanmayı daha kolay hale getirir (bu konuşmalarda bahsedildiği gibi: [`Best Practices for Industrial Programming`](https://www.youtube.com/watch?v=PTE4VJIdHPg) GopherCon Avrupa 2018 konferansından, [GopherCon 2018: Kat Zien - How Do You Structure Your Go Apps](https://www.youtube.com/watch?v=oL6JBUk6tj0) ve [GoLab 2018 - Massimiliano Pippi - Project layout patterns in Go](https://www.youtube.com/watch?v=3gQa1LWwuzk)). -Hangi popüler Go projelerinin bu düzeni kullandığını merak ediyorsanız [`/pkg`](pkg/README.md) klasörüne bakabilirsiniz. Bu genel bir yerleşim düzenidir ama herkes tarafından kabul edilmiyor ve bazı Go toplulukları bu yerleşim düzenini tavsiye etmeyebilir. +Hangi popüler Go projelerinin bu düzeni kullandığını merak ediyorsanız [`/pkg`](pkg/README.md) klasörüne bakabilirsiniz. Bu genel bir yerleşim düzenidir ama herkes tarafından kabul edilmeyebilir ve bazı Go toplulukları bu yerleşim düzenini tavsiye etmeyebilir. Eğer projenizde ekstra bir katmana gerek yoksa ya da projeniz çok küçükse burayı kullanmamanızda bir sakınca olmaz (çok istiyorsanız kullanın). Projeniz yeterince büyük olduğunda ve ana klasörünüz karışmaya başladığında (özellikle çok fazla Go kodu olmayan dosyanız olduğunda) bunu kullanmayı düşünebilirsiniz. ### `/vendor` -Uygulama bağımlılıkları (el ile yönetilen ya da yeni bir özellik olan [`Go Modules`](https://github.com/golang/go/wiki/Modules) gibi favori bağımlılık yönetim aracınızla yönetilen). `go mod vendor` komutu size yeni bir `/vendor klasörü yaratır`. Unutmayın eğer Go 1.14 kullanmıyorsanız `go build` komutuna `-mod=vendor` parametresi vermeniz gerekebilir Go 1.14 bunu varsayılan olarak yapar. +Uygulama bağımlılıkları (el ile yönetilen ya da yeni bir özellik olan [`Go Modules`](https://github.com/golang/go/wiki/Modules) gibi favori bağımlılık yönetim aracınızla yönetilen). `go mod vendor` komutu size yeni bir `/vendor` klasörü yaratır. Unutmayın eğer Go 1.14 kullanmıyorsanız `go build` komutuna `-mod=vendor` parametresi vermeniz gerekebilir Go 1.14 bunu varsayılan olarak yapar. Eğer bir kütüphane yazıyorsanız bağımlılıklarınızı `commit` etmeyin. -Not olarak [`1.13`](https://golang.org/doc/go1.13#modules) versiyonundan itibaren Go modüller için `proxy` özelliğini aktif hale getirdi (varsayılan olarak[`https://proxy.golang.org`](https://proxy.golang.org) adresini kullanır). [`Buradan`](https://blog.golang.org/module-mirror-launch) gereksinimlerinize ve kısıtlamalarınıza uyup uymadığı hakkında daha fazla bilgi edinebilirsiniz. Eğer bu size uyarsa `vendor` klasörüne çokta ihtiyacınız olmayacaktır. +Not olarak [`1.13`](https://golang.org/doc/go1.13#modules) versiyonundan itibaren Go modüller için `proxy` özelliğini aktif hale getirdi (varsayılan olarak [`https://proxy.golang.org`](https://proxy.golang.org) adresini kullanır). [`Buradan`](https://blog.golang.org/module-mirror-launch) gereksinimlerinize ve kısıtlamalarınıza uyup uymadığı hakkında daha fazla bilgi edinebilirsiniz. Eğer bu size uyarsa `vendor` klasörüne çokta ihtiyacınız olmayacaktır. ## Servis Uygulaması Klasörleri @@ -109,7 +109,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. (örnek, [`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/master/Makefile`](https://github.com/hashicorp/terraform/blob/master/Makefile)). Örnekler için [`/scripts`](scripts/README.md) klasörüne bakabilirsiniz. @@ -141,19 +141,19 @@ Tasarım ve kullanıcı dökümanları (godoc ile oluşturulmuş dökümanlara e ### `/tools` -Bu klasöre projen için destekleyici araçları koyabilirsin. Unutma bu araçlar `/pkg` ve `/internal` klasörlerindeki kodları kullanabilirler. +Bu klasöre projen için destekleyici araçları koyabilirsiniz. Unutmayın bu araçlar `/pkg` ve `/internal` klasörlerindeki kodları kullanabilirler. Örnekler için [`/tools`](tools/README.md) klasörüne bakabilirsiniz. ### `/examples` -Bu klasöre yaptığın uygulamalar ya da kütüphaneler için örnekleri koyabilirsin. +Bu klasöre yaptığınız uygulamalar ya da kütüphaneler için örnekleri koyabilirsiniz. Örnekler için [`/examples`](examples/README.md) klasörüne bakabilirsiniz. ### `/third_party` -Dış yardımcı araçlar, çatallanmış kod (forked code) ve diğer 3. parti yardımcı şeyler. (örnek, Swagger UI) +Dış yardımcı araçlar, çatallanmış kod (forked code) ve diğer 3. parti yardımcı şeyler. (örneğin, Swagger UI) ### `/githooks` @@ -165,9 +165,9 @@ Bu klasöre resim, logo ve benzeri kaynakları koyabilirsiniz. ### `/website` -Eğer GitHub Pages kullanmıyorsan burası projenin websitesinin dosyalarının konulması için doğru adres. +Eğer GitHub Pages kullanmıyorsanız burası projenin websitesinin dosyalarının konulması için doğru adres. -Örnekler için [`/website`](website/README.md) klasörüne bakabilirsiniziz. +Örnekler için [`/website`](website/README.md) klasörüne bakabilirsiniz. ## Sahip olmamanız gereken klasörler @@ -175,11 +175,11 @@ Eğer GitHub Pages kullanmıyorsan burası projenin websitesinin dosyalarının Bazı Go projelerinde `src` adlı bir klasör görebilirsiniz, ama bu çoğunlukla `src` klasörü kullanmanın genel bir kalıp olduğu Java dünyasından gelen geliştiricilerde olur. Eğer yapabilirseniz bu Java kalıbını benimsememeye çalışın. Gerçekten Go kodunuzun ya da Go projenizin Java gibi gözükmesini istemezsiniz :-) -Proje seviyesindeki `/src` klasörü ile [`How to Write Go Code`](https://golang.org/doc/code.html) adresinde belirtilen Go'nun çalışma alanları için kullandığı `/src` klasörünü karıştırmayın. `$GOPATH` ortam değişkeni senin çalışma alanına (şuanki) işaret eder (Windows olmayan sistemlerde varsayılan olarak `$HOME/go` klasörüne işaret eder). Bu çalışma alanı içerisinde en üst katmandaki `/pkg`, `/bin` ve `/src` klasörlerini barındırır. Asıl projen `/src` klasörü altında bir alt dizin olur. Eğer projende `/src` klasörüne sahipsen, projenin dosya yolu büyük ihtimal şöyle gözükecek `/calisma-alanin/src/senin_projen/src/senin_kodun.go`. Not olarak Go 1.11 ile `$GOPATH` klasörü dışında projeler açabilirsin ama bunu yapabilmen bu yerleşim düzeninin kullanılmasının iyi bir fikir olduğu anlamına gelmez. +Proje seviyesindeki `/src` klasörü ile [`How to Write Go Code`](https://golang.org/doc/code.html) adresinde belirtilen Go'nun çalışma alanları için kullandığı `/src` klasörünü karıştırmayın. `$GOPATH` ortam değişkeni sizin çalışma alanınıza (şu anki) işaret eder (Windows olmayan sistemlerde varsayılan olarak `$HOME/go` klasörüne işaret eder). Bu çalışma alanı içerisinde en üst katmandaki `/pkg`, `/bin` ve `/src` klasörlerini barındırır. Asıl projeniz `/src` klasörü altında bir alt dizin olur. Eğer projende `/src` klasörüne sahipseniz, projenizin dosya yolu büyük ihtimal şöyle gözükecek `/calismaalaniniz/src/projeniz/src/kodunuz.go`. Not olarak Go 1.11 ile `$GOPATH` klasörü dışında projeler açabilirsiniz ama bunu yapabilmeniz bu yerleşim düzeninin kullanılmasının iyi bir fikir olduğu anlamına gelmez. ## Rozetler -* [Go Report Card](https://goreportcard.com/) - Kodunu `gofmt`, `go vet`, `gocyclo`, `golint`, `ineffassign`, `license` ve `misspell` yazılımları ile tarar. `github.com/golang-standards/project-layout` linkini kendi proje linkiniz ile değiştirin. +* [Go Report Card](https://goreportcard.com/) - Kodunuzu `gofmt`, `go vet`, `gocyclo`, `golint`, `ineffassign`, `license` ve `misspell` yazılımları ile tarar. `github.com/golang-standards/project-layout` linkini kendi proje linkiniz ile değiştirin. [![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) @@ -191,7 +191,7 @@ Proje seviyesindeki `/src` klasörü ile [`How to Write Go Code`](https://golang [![PkgGoDev](https://pkg.go.dev/badge/github.com/golang-standards/project-layout)](https://pkg.go.dev/github.com/golang-standards/project-layout) -* Release - Projenin en son yayınlanmış versiyonunu gösterir. İşaret ettiği linki kendi proje linkiniz ile değiştirin. +* Release - Projenizin en son yayınlanmış versiyonunu gösterir. İşaret ettiği linki kendi proje linkiniz ile değiştirin. [![Release](https://img.shields.io/github/release/golang-standards/project-layout.svg?style=flat-square)](https://github.com/golang-standards/project-layout/releases/latest) From 78038e0a64fc1b73ff4ae0983be95a5d89ed473a Mon Sep 17 00:00:00 2001 From: "nikita.glaktionov" Date: Wed, 24 Feb 2021 15:22:48 +0300 Subject: [PATCH 05/76] Adds russian language version of README.md file --- README.md | 1 + README_ru.md | 197 +++++++++++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 198 insertions(+) create mode 100644 README_ru.md diff --git a/README.md b/README.md index bec7265..15b7155 100644 --- a/README.md +++ b/README.md @@ -9,6 +9,7 @@ Translations: * [Français](README_fr.md) * [日本語](README_ja.md) * [Español](README_es.md) +* [Русский](README_ru.md) ## Overview diff --git a/README_ru.md b/README_ru.md new file mode 100644 index 0000000..c943026 --- /dev/null +++ b/README_ru.md @@ -0,0 +1,197 @@ +# Standard Go Project Layout + +Translations: + +* [한국어 문서](README_ko.md) +* [简体中文](README_zh.md) +* [正體中文](README_zh-TW.md) +* [简体中文](README_zh-CN.md) - ??? +* [Français](README_fr.md) +* [日本語](README_ja.md) +* [Español](README_es.md) +* [English](README.md) + +## Overview + +Это базовый макет организации проектов, разработанных на Golang. Это не официально определенный командой разработчиков Golang стандарт, однако, удовлетворяет исторически сложившимся шаблонам организации проекта в экосистеме Golang. Некоторые из шаблонов могут быть известнее остальных. В макете также присутствует несколько улучшений, включая некоторые дополнительные директории, используемые в любом достаточно большом реальном приложении. + +Если вы пытаетесь изучить Golang или собрать маленький обучающий проект для личного пользования, данный макет будет явным перебором. Стоит начать с чего-нибудь действительно простого (одного файла `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) если хотите узнать об этом больше. + +Этот шаблон организации проекта намеренно делан общим, и не является примером структуры какого-то конкретного пакета Golang. + +Этот репозиторий открыт к усилиям сообщества. Создайте заявку о проблеме, если вы нашли новый шаблон или считаете, что один из существующих шаблонов необходимо обновить. + +Если вам нужна помощь в наименовании, форматировании или стилизации кода - начните с [`gofmt`](https://golang.org/cmd/gofmt/) и [`golint`](https://github.com/golang/lint). Также обязательно прочтите эти руководства по стилизации кода Golang и рекомендации: +* 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 +* [Руководство по стилизации кода для пакетов Golang](https://rakyll.org/style-packages) (rakyll/JBD) + +Обратите внимание на [`Шаблон проекта Golang`](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` + +Внутренний код приложения и библиотек. Это код, который не должен быть применен в других приложениях и библиотеках. Стоит отметить, что этот шаблон навязан самим компилятором 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` и когда есть смысл их использовать. + +Существует возможность группировать код на 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)). + +Ознакомьтесь с директорией [`/pkg`](pkg/README.md), если хотите увидеть, какие популярные репозитории используют такой шаблон организации проекта. Несмотря на его распространенность, он не был принят всеми, а некоторые в обществе Go и вовсе не рекомендует его использовать. + +Вы можете не использовать эту директорию, если проект совсем небольшой и добавление нового уровня вложенности не имеет практического смысла (разве что вы сами этого не хотите :-)). Подумайте б этом, когда ваша корневая директория начинает слишком сильно разрастаться, особенно, если у вас много компонентов, написанных не на Go. + +### `/vendor` + +Зависимости приложений, управляемые вручную или с использованием вашей любимой системы управления зависимостями, вроде новых встроенных [`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` не требуется вовсе. + +## Директории приложений-сервисов + +### `/api` + +Спецификации OpenAPI/Swagger, файлы JSON schema, файлы определения протоколов. + +Ознакомьтесь с директорией [`/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` + +Упаковка и непрерывная интеграция. + +Поместите файлы конфигурации и скрипты облака (AMI), контейнера (Docker), пакетов (deb, rpm, pkg) в директорию `/build/package`. + +Поместите ваши файлы конфигурации CI (travis, circle, drone) и скрипты в директорию `/build/ci`. Отметьте, что некоторые инструменты CI (например, Travis CI) очень требовательны к расположению их конфигурационных файлов. Попробуйте поместить их в директорию `/build/ci` создав ссылку на них в месте, где их ожидают найти инструменты Go (когда возможно). + +### `/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 hooks. + +### `/assets` + +Другие ресурсы, необходимые для работы (картинки, логотипы и т.д.) + +### `/website` + +Здесь можно разделить файлы для вебсайта вашего проекта, если вы не используете `GitHub pages`. + +Ознакомьтесь с директорией [`/website`](website/README.md) для примеров. + +## Директории, которые не стоит размещать у себя в проекте + +### `/src` + +Некоторые проекты на Go имеют директорию `src`, но это обычно происходит, когда разработкой занялся человек, пришедший из мира Java, где такой подход весьма распространен. Постарайтесь не использовать его в разработке на Golang, если не хотите, чтобы ваш код или проект выглядел, будто написан на 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-шаблон - хорошая идея. + + +## Badges + +* [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 is a new destination for Go discovery & docs. You can create a badge using the [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](https://img.shields.io/github/release/golang-standards/project-layout.svg?style=flat-square)](https://github.com/golang-standards/project-layout/releases/latest) From 52e269add58879dbeb796f6d303ac6762cfaed8c Mon Sep 17 00:00:00 2001 From: "nikita.glaktionov" Date: Wed, 28 Apr 2021 10:49:37 +0300 Subject: [PATCH 06/76] Fix typo --- README_ru.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) mode change 100644 => 100755 README_ru.md diff --git a/README_ru.md b/README_ru.md old mode 100644 new mode 100755 index c943026..8587e9a --- a/README_ru.md +++ b/README_ru.md @@ -69,7 +69,7 @@ Translations: Ознакомьтесь с директорией [`/pkg`](pkg/README.md), если хотите увидеть, какие популярные репозитории используют такой шаблон организации проекта. Несмотря на его распространенность, он не был принят всеми, а некоторые в обществе Go и вовсе не рекомендует его использовать. -Вы можете не использовать эту директорию, если проект совсем небольшой и добавление нового уровня вложенности не имеет практического смысла (разве что вы сами этого не хотите :-)). Подумайте б этом, когда ваша корневая директория начинает слишком сильно разрастаться, особенно, если у вас много компонентов, написанных не на Go. +Вы можете не использовать эту директорию, если проект совсем небольшой и добавление нового уровня вложенности не имеет практического смысла (разве что вы сами этого не хотите :-)). Подумайте об этом, когда ваша корневая директория начинает слишком сильно разрастаться, особенно, если у вас много компонентов, написанных не на Go. ### `/vendor` From 400ada333a8a94c054844a13c1f8c6155f79e11c Mon Sep 17 00:00:00 2001 From: Kyle Quest Date: Wed, 28 Apr 2021 17:37:17 -0700 Subject: [PATCH 07/76] additional links for the Romanian translation --- README.md | 5 +++-- README_es.md | 1 + README_fr.md | 1 + README_ja.md | 1 + README_ko.md | 1 + README_ptBR.md | 1 + README_ro.md | 2 ++ README_zh-CN.md | 1 + README_zh-TW.md | 1 + README_zh.md | 1 + 10 files changed, 13 insertions(+), 2 deletions(-) diff --git a/README.md b/README.md index 939e65a..286d021 100644 --- a/README.md +++ b/README.md @@ -10,12 +10,13 @@ Translations: * [日本語](README_ja.md) * [Portuguese](README_ptBR.md) * [Español](README_es.md) +* [Română](README_ro.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. 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. -If you are trying to learn Go or if you are building a PoC or a toy project for yourself this project layout is an overkill. Start with something really simple (a single `main.go` file 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. +`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. With Go 1.14 [`Go Modules`](https://github.com/golang/go/wiki/Modules) are finally ready for production. Use [`Go Modules`](https://blog.golang.org/using-go-modules) unless you have a specific reason not to use them and if you do then you don’t need to worry about $GOPATH and where you put your project. The basic `go.mod` file in the repo assumes your project is hosted on GitHub, but it's not a requirement. The module path can be anything though the first module path component should have a dot in its name (the current version of Go doesn't enforce it anymore, but if you are using slightly older versions don't be surprised if your builds fail without it). See Issues [`37554`](https://github.com/golang/go/issues/37554) and [`32819`](https://github.com/golang/go/issues/32819) if you want to know more about it. diff --git a/README_es.md b/README_es.md index 27100ab..bf98ee4 100644 --- a/README_es.md +++ b/README_es.md @@ -11,6 +11,7 @@ Traducciones: * [日本語](README_ja.md) * [Portuguese](README_ptBR.md) * [Español](README_es.md) +* [Română](README_ro.md) ## Resumen diff --git a/README_fr.md b/README_fr.md index 4d1ce0a..eb45ffe 100644 --- a/README_fr.md +++ b/README_fr.md @@ -11,6 +11,7 @@ Traductions: * [日本語](README_ja.md) * [Portuguese](README_ptBR.md) * [Español](README_es.md) +* [Română](README_ro.md) ## Introduction diff --git a/README_ja.md b/README_ja.md index fa15cf6..8976927 100644 --- a/README_ja.md +++ b/README_ja.md @@ -11,6 +11,7 @@ * [日本語](README_ja.md) * [Portuguese](README_ptBR.md) * [Español](README_es.md) +* [Română](README_ro.md) ## 概要 diff --git a/README_ko.md b/README_ko.md index a89a5e7..c2a83e4 100644 --- a/README_ko.md +++ b/README_ko.md @@ -11,6 +11,7 @@ * [日本語](README_ja.md) * [Portuguese](README_ptBR.md) * [Español](README_es.md) +* [Română](README_ro.md) ## 개요 diff --git a/README_ptBR.md b/README_ptBR.md index 4a5b4ac..0dd484e 100644 --- a/README_ptBR.md +++ b/README_ptBR.md @@ -11,6 +11,7 @@ Traduções: * [日本語](README_ja.md) * [Portuguese](README_ptBR.md) * [Español](README_es.md) +* [Română](README_ro.md) ## Visão geral diff --git a/README_ro.md b/README_ro.md index 0e2ac10..32105f2 100644 --- a/README_ro.md +++ b/README_ro.md @@ -2,12 +2,14 @@ Traduceri: +* [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) diff --git a/README_zh-CN.md b/README_zh-CN.md index 79e7f43..68a623d 100644 --- a/README_zh-CN.md +++ b/README_zh-CN.md @@ -9,6 +9,7 @@ * [日本語](README_ja.md) * [Portuguese](README_ptBR.md) * [Español](README_es.md) +* [Română](README_ro.md) 这是Go应用程序项目的基础布局。这不是Go核心开发团队定义的官方标准；无论是在经典项目还是在新兴的项目中，这都是Go生态系统中一组常见的项目布局模式。这其中有一些模式比另外的一些更受欢迎。它通过几个支撑目录为任何足够大规模的实际应用程序提供一些增强功能。 diff --git a/README_zh-TW.md b/README_zh-TW.md index 2378432..12c11e3 100644 --- a/README_zh-TW.md +++ b/README_zh-TW.md @@ -11,6 +11,7 @@ * [日本語](README_ja.md) * [Portuguese](README_ptBR.md) * [Español](README_es.md) +* [Română](README_ro.md) 這是 Go 應用程式專案的基本目錄結構。它不是核心 Go 開發團隊定義的官方標準；然而，它是 Go 生態系統中一組常見的老專案和新專案的目錄結構。其中一些目錄結構比其他目錄結構更受歡迎。這個專案目錄結構還有一些細微的改進，可以支援任何大型且實用的應用程式目錄結構。 diff --git a/README_zh.md b/README_zh.md index a0f1bd2..dfc2634 100644 --- a/README_zh.md +++ b/README_zh.md @@ -11,6 +11,7 @@ * [日本語](README_ja.md) * [Portuguese](README_ptBR.md) * [Español](README_es.md) +* [Română](README_ro.md) 这是 Go 应用程序项目的基本布局。它不是核心 Go 开发团队定义的官方标准；然而，它是 Go 生态系统中一组常见的老项目和新项目的布局模式。其中一些模式比其他模式更受欢迎。它还具有许多小的增强，以及对任何足够大的实际应用程序通用的几个支持目录。 From 4e2cf8b9b37e2ac59004c36179adc23a8abfaeeb Mon Sep 17 00:00:00 2001 From: Kyle Quest Date: Wed, 28 Apr 2021 23:06:26 -0700 Subject: [PATCH 08/76] russian translation link updates --- README.md | 4 ++-- README_es.md | 1 + README_fr.md | 1 + README_ja.md | 1 + README_ko.md | 1 + README_ptBR.md | 1 + README_ro.md | 1 + README_ru.md | 5 ++++- README_zh-CN.md | 1 + README_zh-TW.md | 1 + README_zh.md | 1 + 11 files changed, 15 insertions(+), 3 deletions(-) diff --git a/README.md b/README.md index 901e141..42edadd 100644 --- a/README.md +++ b/README.md @@ -15,9 +15,9 @@ Translations: ## 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. 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. -`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. +**`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. With Go 1.14 [`Go Modules`](https://github.com/golang/go/wiki/Modules) are finally ready for production. Use [`Go Modules`](https://blog.golang.org/using-go-modules) unless you have a specific reason not to use them and if you do then you don’t need to worry about $GOPATH and where you put your project. The basic `go.mod` file in the repo assumes your project is hosted on GitHub, but it's not a requirement. The module path can be anything though the first module path component should have a dot in its name (the current version of Go doesn't enforce it anymore, but if you are using slightly older versions don't be surprised if your builds fail without it). See Issues [`37554`](https://github.com/golang/go/issues/37554) and [`32819`](https://github.com/golang/go/issues/32819) if you want to know more about it. diff --git a/README_es.md b/README_es.md index bf98ee4..725ed70 100644 --- a/README_es.md +++ b/README_es.md @@ -12,6 +12,7 @@ Traducciones: * [Portuguese](README_ptBR.md) * [Español](README_es.md) * [Română](README_ro.md) +* [Русский](README_ru.md) ## Resumen diff --git a/README_fr.md b/README_fr.md index eb45ffe..5b53bea 100644 --- a/README_fr.md +++ b/README_fr.md @@ -12,6 +12,7 @@ Traductions: * [Portuguese](README_ptBR.md) * [Español](README_es.md) * [Română](README_ro.md) +* [Русский](README_ru.md) ## Introduction diff --git a/README_ja.md b/README_ja.md index 8976927..91e004d 100644 --- a/README_ja.md +++ b/README_ja.md @@ -12,6 +12,7 @@ * [Portuguese](README_ptBR.md) * [Español](README_es.md) * [Română](README_ro.md) +* [Русский](README_ru.md) ## 概要 diff --git a/README_ko.md b/README_ko.md index c2a83e4..5b87785 100644 --- a/README_ko.md +++ b/README_ko.md @@ -12,6 +12,7 @@ * [Portuguese](README_ptBR.md) * [Español](README_es.md) * [Română](README_ro.md) +* [Русский](README_ru.md) ## 개요 diff --git a/README_ptBR.md b/README_ptBR.md index 0dd484e..f603278 100644 --- a/README_ptBR.md +++ b/README_ptBR.md @@ -12,6 +12,7 @@ Traduções: * [Portuguese](README_ptBR.md) * [Español](README_es.md) * [Română](README_ro.md) +* [Русский](README_ru.md) ## Visão geral diff --git a/README_ro.md b/README_ro.md index 32105f2..3ddff28 100644 --- a/README_ro.md +++ b/README_ro.md @@ -12,6 +12,7 @@ Traduceri: * [Portuguese](README_ptBR.md) * [Español](README_es.md) * [Română](README_ro.md) +* [Русский](README_ru.md) ## General diff --git a/README_ru.md b/README_ru.md index 8587e9a..76e5996 100755 --- a/README_ru.md +++ b/README_ru.md @@ -2,14 +2,17 @@ Translations: +* [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) -* [English](README.md) +* [Română](README_ro.md) +* [Русский](README_ru.md) ## Overview diff --git a/README_zh-CN.md b/README_zh-CN.md index 68a623d..758c4ad 100644 --- a/README_zh-CN.md +++ b/README_zh-CN.md @@ -10,6 +10,7 @@ * [Portuguese](README_ptBR.md) * [Español](README_es.md) * [Română](README_ro.md) +* [Русский](README_ru.md) 这是Go应用程序项目的基础布局。这不是Go核心开发团队定义的官方标准；无论是在经典项目还是在新兴的项目中，这都是Go生态系统中一组常见的项目布局模式。这其中有一些模式比另外的一些更受欢迎。它通过几个支撑目录为任何足够大规模的实际应用程序提供一些增强功能。 diff --git a/README_zh-TW.md b/README_zh-TW.md index 12c11e3..c8a57de 100644 --- a/README_zh-TW.md +++ b/README_zh-TW.md @@ -12,6 +12,7 @@ * [Portuguese](README_ptBR.md) * [Español](README_es.md) * [Română](README_ro.md) +* [Русский](README_ru.md) 這是 Go 應用程式專案的基本目錄結構。它不是核心 Go 開發團隊定義的官方標準；然而，它是 Go 生態系統中一組常見的老專案和新專案的目錄結構。其中一些目錄結構比其他目錄結構更受歡迎。這個專案目錄結構還有一些細微的改進，可以支援任何大型且實用的應用程式目錄結構。 diff --git a/README_zh.md b/README_zh.md index dfc2634..a20e069 100644 --- a/README_zh.md +++ b/README_zh.md @@ -12,6 +12,7 @@ * [Portuguese](README_ptBR.md) * [Español](README_es.md) * [Română](README_ro.md) +* [Русский](README_ru.md) 这是 Go 应用程序项目的基本布局。它不是核心 Go 开发团队定义的官方标准；然而，它是 Go 生态系统中一组常见的老项目和新项目的布局模式。其中一些模式比其他模式更受欢迎。它还具有许多小的增强，以及对任何足够大的实际应用程序通用的几个支持目录。 From 23bda496bbbb57f0585fee4ad00ecf7b9b3383cb Mon Sep 17 00:00:00 2001 From: Kyle Quest Date: Thu, 29 Apr 2021 10:52:03 -0700 Subject: [PATCH 09/76] Turkish translation link updates --- README.md | 1 + README_es.md | 1 + README_fr.md | 1 + README_ja.md | 1 + README_ko.md | 1 + README_ptBR.md | 1 + README_ro.md | 1 + README_ru.md | 1 + README_tr.md | 4 ++++ README_zh-CN.md | 1 + README_zh-TW.md | 1 + README_zh.md | 1 + 12 files changed, 15 insertions(+) diff --git a/README.md b/README.md index 42edadd..d264bc5 100644 --- a/README.md +++ b/README.md @@ -12,6 +12,7 @@ Translations: * [Español](README_es.md) * [Română](README_ro.md) * [Русский](README_ru.md) +* [Türkçe](README_tr.md) ## Overview diff --git a/README_es.md b/README_es.md index 725ed70..d96eb20 100644 --- a/README_es.md +++ b/README_es.md @@ -13,6 +13,7 @@ Traducciones: * [Español](README_es.md) * [Română](README_ro.md) * [Русский](README_ru.md) +* [Türkçe](README_tr.md) ## Resumen diff --git a/README_fr.md b/README_fr.md index 5b53bea..c626e93 100644 --- a/README_fr.md +++ b/README_fr.md @@ -13,6 +13,7 @@ Traductions: * [Español](README_es.md) * [Română](README_ro.md) * [Русский](README_ru.md) +* [Türkçe](README_tr.md) ## Introduction diff --git a/README_ja.md b/README_ja.md index 91e004d..10e8603 100644 --- a/README_ja.md +++ b/README_ja.md @@ -13,6 +13,7 @@ * [Español](README_es.md) * [Română](README_ro.md) * [Русский](README_ru.md) +* [Türkçe](README_tr.md) ## 概要 diff --git a/README_ko.md b/README_ko.md index 5b87785..f2c557c 100644 --- a/README_ko.md +++ b/README_ko.md @@ -13,6 +13,7 @@ * [Español](README_es.md) * [Română](README_ro.md) * [Русский](README_ru.md) +* [Türkçe](README_tr.md) ## 개요 diff --git a/README_ptBR.md b/README_ptBR.md index f603278..80b9e8c 100644 --- a/README_ptBR.md +++ b/README_ptBR.md @@ -13,6 +13,7 @@ Traduções: * [Español](README_es.md) * [Română](README_ro.md) * [Русский](README_ru.md) +* [Türkçe](README_tr.md) ## Visão geral diff --git a/README_ro.md b/README_ro.md index 3ddff28..0078d41 100644 --- a/README_ro.md +++ b/README_ro.md @@ -13,6 +13,7 @@ Traduceri: * [Español](README_es.md) * [Română](README_ro.md) * [Русский](README_ru.md) +* [Türkçe](README_tr.md) ## General diff --git a/README_ru.md b/README_ru.md index 76e5996..61f68f7 100755 --- a/README_ru.md +++ b/README_ru.md @@ -13,6 +13,7 @@ Translations: * [Español](README_es.md) * [Română](README_ro.md) * [Русский](README_ru.md) +* [Türkçe](README_tr.md) ## Overview diff --git a/README_tr.md b/README_tr.md index 7433e35..8520bb2 100644 --- a/README_tr.md +++ b/README_tr.md @@ -2,13 +2,17 @@ Çeviriler: +* [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) ## Genel Bakış diff --git a/README_zh-CN.md b/README_zh-CN.md index 758c4ad..24c8df6 100644 --- a/README_zh-CN.md +++ b/README_zh-CN.md @@ -11,6 +11,7 @@ * [Español](README_es.md) * [Română](README_ro.md) * [Русский](README_ru.md) +* [Türkçe](README_tr.md) 这是Go应用程序项目的基础布局。这不是Go核心开发团队定义的官方标准；无论是在经典项目还是在新兴的项目中，这都是Go生态系统中一组常见的项目布局模式。这其中有一些模式比另外的一些更受欢迎。它通过几个支撑目录为任何足够大规模的实际应用程序提供一些增强功能。 diff --git a/README_zh-TW.md b/README_zh-TW.md index c8a57de..8c29708 100644 --- a/README_zh-TW.md +++ b/README_zh-TW.md @@ -13,6 +13,7 @@ * [Español](README_es.md) * [Română](README_ro.md) * [Русский](README_ru.md) +* [Türkçe](README_tr.md) 這是 Go 應用程式專案的基本目錄結構。它不是核心 Go 開發團隊定義的官方標準；然而，它是 Go 生態系統中一組常見的老專案和新專案的目錄結構。其中一些目錄結構比其他目錄結構更受歡迎。這個專案目錄結構還有一些細微的改進，可以支援任何大型且實用的應用程式目錄結構。 diff --git a/README_zh.md b/README_zh.md index a20e069..9257976 100644 --- a/README_zh.md +++ b/README_zh.md @@ -13,6 +13,7 @@ * [Español](README_es.md) * [Română](README_ro.md) * [Русский](README_ru.md) +* [Türkçe](README_tr.md) 这是 Go 应用程序项目的基本布局。它不是核心 Go 开发团队定义的官方标准；然而，它是 Go 生态系统中一组常见的老项目和新项目的布局模式。其中一些模式比其他模式更受欢迎。它还具有许多小的增强，以及对任何足够大的实际应用程序通用的几个支持目录。 From 3f9b0a28ab52e9820ebd0d8cee2a493d38b8b9d6 Mon Sep 17 00:00:00 2001 From: Wilk Date: Fri, 30 Apr 2021 15:06:47 +0200 Subject: [PATCH 10/76] Update french readme Highlight not official core project --- README_fr.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/README_fr.md b/README_fr.md index c626e93..530bc5c 100644 --- a/README_fr.md +++ b/README_fr.md @@ -17,9 +17,9 @@ Traductions: ## Introduction -Ce dépôt est une architecture basique pour des projets d'applications en Go. Il ne représente pas un standard officiel défini par l'équipe de développement principale de Go. C'est néanmoins un ensemble de modèles d'architecture que l'on peut retrouver autant sur des projets historiques que plus récents dans l'écosystème Go. Certains patterns sont plus populaires que d'autres. Il comporte également nombre d'améliorations mineures ainsi que plusieurs répertoires communs à beaucoup d'applications existantes de taille importante. +Ce dépôt est une architecture basique pour des projets d'applications en Go. **Il ne représente pas un standard officiel défini par l'équipe de développement principale de Go**. C'est néanmoins un ensemble de modèles d'architecture que l'on peut retrouver autant sur des projets historiques que plus récents dans l'écosystème Go. Certains patterns sont plus populaires que d'autres. Il comporte également nombre d'améliorations mineures ainsi que plusieurs répertoires communs à beaucoup d'applications existantes de taille importante. -Si vous commencez à apprendre Go, ou si vous souhaitez développer un petit side-project pour vous-même, cette architecture n'est pas du tout adaptée. Commencez par quelque chose de très simple (un unique fichier `main.go` est largement suffisant). Au fur et à mesure que votre projet évolue, il est important de garder à l'esprit que votre code doit être bien structuré sinon vous finirez rapidement avec un code difficile à maintenir, comprenant beaucoup de dépendances cachées et un state global. Plus il y aura de gens qui travailleront sur le projet, plus il sera important d'avoir une structure solide. C'est pourquoi il est important d'introduire une façon identique pour tout le monde de gérer les bibliothèques et les packages. Lorsque vous maintenez un projet open source ou que vous savez que d'autres projets importent votre code depuis votre dépôt, il est important d'avoir des packages et du code privé (aka `internal`). Clonez le dépôt, gardez ce dont vous avez besoin et supprimez tout le reste ! Ce n'est pas parce que des dossiers existent que vous devez impérativement tous les utiliser. Tous ces patterns ne sont pas tout le temps utilisés dans tous les projets. Même le pattern `vendor` n'est pas universel. +**Si vous commencez à apprendre Go, ou si vous souhaitez développer un petit side-project pour vous-même, cette architecture n'est pas du tout adaptée. Commencez par quelque chose de très simple (un unique fichier `main.go` est largement suffisant).** Au fur et à mesure que votre projet évolue, il est important de garder à l'esprit que votre code doit être bien structuré sinon vous finirez rapidement avec un code difficile à maintenir, comprenant beaucoup de dépendances cachées et un state global. Plus il y aura de gens qui travailleront sur le projet, plus il sera important d'avoir une structure solide. C'est pourquoi il est important d'introduire une façon identique pour tout le monde de gérer les bibliothèques et les packages. Lorsque vous maintenez un projet open source ou que vous savez que d'autres projets importent votre code depuis votre dépôt, il est important d'avoir des packages et du code privé (aka `internal`). Clonez le dépôt, gardez ce dont vous avez besoin et supprimez tout le reste ! Ce n'est pas parce que des dossiers existent que vous devez impérativement tous les utiliser. Tous ces patterns ne sont pas tout le temps utilisés dans tous les projets. Même le pattern `vendor` n'est pas universel. Depuis la sortie de Go 1.14 les [`Go Modules`](https://github.com/golang/go/wiki/Modules) sont enfin prêts à être utilisés en production. Utilisez les [`Go Modules`](https://blog.golang.org/using-go-modules) par défaut sauf si vous avez une raison bien spécifique de ne pas les utiliser. Lorsque vous les utilisez, vous n'avez pas besoin de vous embêter avec le $GOPATH ou de définir le dossier dans lequel vous allez mettre votre projet. Le fichier `go.mod` part du principe que votre dépôt est hébergé sur Github, mais ce n'est pas une obligation. Le chemin du module peut être n'importe quoi, mais il faut savoir que le premier composant du chemin devrait toujours avoir un point dans son nom (la version actuelle de Go ne l'impose plus, mais si vous utilisez des versions un peu plus anciennes ne soyez pas surpris que votre build échoue s'il n'y a pas de point). Allez voir les tickets [`37554`](https://github.com/golang/go/issues/37554) et [`32819`](https://github.com/golang/go/issues/32819) si vous souhaitez en savoir plus. From 3d3c1d63337a1fd25c81d2ba4252c8b64e37006c Mon Sep 17 00:00:00 2001 From: Kyle Quest Date: Tue, 11 May 2021 13:07:44 -0700 Subject: [PATCH 11/76] pkg dir origins --- README.md | 2 ++ pkg/README.md | 5 ++++- 2 files changed, 6 insertions(+), 1 deletion(-) diff --git a/README.md b/README.md index d264bc5..c17b313 100644 --- a/README.md +++ b/README.md @@ -74,6 +74,8 @@ See the [`/pkg`](pkg/README.md) directory if you want to see which popular Go re It's ok not to use it if your app project is really small and where an extra level of nesting doesn't add much value (unless you really want to :-)). Think about it when it's getting big enough and your root directory gets pretty busy (especially if you have a lot of non-Go app components). +The `pkg` directory origins: The old Go source code used to use `pkg` for its packages and then various Go projects in the community started copying the patteren (see [`this`](https://twitter.com/bradfitz/status/1039512487538970624) Brad Fitzpatrick's tweet for more context). + ### `/vendor` Application dependencies (managed manually or by your favorite dependency management tool like the new built-in [`Go Modules`](https://github.com/golang/go/wiki/Modules) feature). The `go mod vendor` command will create the `/vendor` directory for you. Note that you might need to add the `-mod=vendor` flag to your `go build` command if you are not using Go 1.14 where it's on by default. diff --git a/pkg/README.md b/pkg/README.md index de41157..aea53f8 100644 --- a/pkg/README.md +++ b/pkg/README.md @@ -4,10 +4,13 @@ Library code that's ok to use by external applications (e.g., `/pkg/mypubliclib` It's also a way to group Go code in one place when your root directory contains lots of non-Go components and directories making it easier to run various Go tools (as mentioned in these talks: [`Best Practices for Industrial Programming`](https://www.youtube.com/watch?v=PTE4VJIdHPg) from GopherCon EU 2018, [GopherCon 2018: Kat Zien - How Do You Structure Your Go Apps](https://www.youtube.com/watch?v=oL6JBUk6tj0) and [GoLab 2018 - Massimiliano Pippi - Project layout patterns in Go](https://www.youtube.com/watch?v=3gQa1LWwuzk)). -Note that this is not a universally accepted pattern and for every popular repo that uses it you can find 10 that don't. It's up to you to decide if you want to use this pattern or not. Regardless of whether or not it's a good pattern more people will know what you mean than not. It is a bit confusing for new Go devs, but it's a pretty simple confusion to resolve and that's one of the goals for this project layout repo. +Note that this is not a universally accepted pattern and for every popular repo that uses it you can find 10 that don't. It's up to you to decide if you want to use this pattern or not. Regardless of whether or not it's a good pattern more people will know what you mean than not. It might a bit confusing for some of the new Go devs, but it's a pretty simple confusion to resolve and that's one of the goals for this project layout repo. Ok not to use it if your app project is really small and where an extra level of nesting doesn't add much value (unless you really want to). Think about it when it's getting big enough and your root directory gets pretty busy (especially if you have a lot of non-Go app components). +The `pkg` directory origins: The old Go source code used to use `pkg` for its packages and then various Go projects in the community started copying the patteren (see [`this`](https://twitter.com/bradfitz/status/1039512487538970624) Brad Fitzpatrick's tweet for more context). + + Examples: * https://github.com/prometheus/prometheus/tree/master/pkg From 9858c49c9114b6354e1cba93557b371454f2f200 Mon Sep 17 00:00:00 2001 From: Kyle Quest Date: Tue, 11 May 2021 13:33:33 -0700 Subject: [PATCH 12/76] typos --- README.md | 2 +- pkg/README.md | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/README.md b/README.md index c17b313..3727c11 100644 --- a/README.md +++ b/README.md @@ -74,7 +74,7 @@ See the [`/pkg`](pkg/README.md) directory if you want to see which popular Go re It's ok not to use it if your app project is really small and where an extra level of nesting doesn't add much value (unless you really want to :-)). Think about it when it's getting big enough and your root directory gets pretty busy (especially if you have a lot of non-Go app components). -The `pkg` directory origins: The old Go source code used to use `pkg` for its packages and then various Go projects in the community started copying the patteren (see [`this`](https://twitter.com/bradfitz/status/1039512487538970624) Brad Fitzpatrick's tweet for more context). +The `pkg` directory origins: The old Go source code used to use `pkg` for its packages and then various Go projects in the community started copying the pattern (see [`this`](https://twitter.com/bradfitz/status/1039512487538970624) Brad Fitzpatrick's tweet for more context). ### `/vendor` diff --git a/pkg/README.md b/pkg/README.md index aea53f8..633b877 100644 --- a/pkg/README.md +++ b/pkg/README.md @@ -8,7 +8,7 @@ Note that this is not a universally accepted pattern and for every popular repo Ok not to use it if your app project is really small and where an extra level of nesting doesn't add much value (unless you really want to). Think about it when it's getting big enough and your root directory gets pretty busy (especially if you have a lot of non-Go app components). -The `pkg` directory origins: The old Go source code used to use `pkg` for its packages and then various Go projects in the community started copying the patteren (see [`this`](https://twitter.com/bradfitz/status/1039512487538970624) Brad Fitzpatrick's tweet for more context). +The `pkg` directory origins: The old Go source code used to use `pkg` for its packages and then various Go projects in the community started copying the pattern (see [`this`](https://twitter.com/bradfitz/status/1039512487538970624) Brad Fitzpatrick's tweet for more context). Examples: From b980f55d60b1191ba35738ee0106bac74147b8ad Mon Sep 17 00:00:00 2001 From: Navid Hosseini Date: Wed, 26 May 2021 13:14:49 +0430 Subject: [PATCH 13/76] Update README.md Adding go-ehtereum project as one of the biggest open-source projects to file --- cmd/README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/cmd/README.md b/cmd/README.md index 19c269e..230d813 100644 --- a/cmd/README.md +++ b/cmd/README.md @@ -17,4 +17,4 @@ Examples: * https://github.com/kubernetes/kubernetes/tree/master/cmd * https://github.com/satellity/satellity/tree/master/cmd/satellity * https://github.com/dapr/dapr/tree/master/cmd - +* https://github.com/ethereum/go-ethereum/tree/master/cmd From 5a9c66ac1fc4c4749ebd1ee7d7bc8c4dd37a5868 Mon Sep 17 00:00:00 2001 From: bossm0n5t3r Date: Fri, 4 Jun 2021 00:01:19 +0900 Subject: [PATCH 14/76] fix : Delete repo that exist no more cmd folder satellity repo does not have cmd folder --- cmd/README.md | 14 ++++++-------- 1 file changed, 6 insertions(+), 8 deletions(-) diff --git a/cmd/README.md b/cmd/README.md index 19c269e..598b2cf 100644 --- a/cmd/README.md +++ b/cmd/README.md @@ -10,11 +10,9 @@ It's common to have a small `main` function that imports and invokes the code fr Examples: -* https://github.com/heptio/ark/tree/master/cmd (just a really small `main` function with everything else in packages) -* https://github.com/moby/moby/tree/master/cmd -* https://github.com/prometheus/prometheus/tree/master/cmd -* https://github.com/influxdata/influxdb/tree/master/cmd -* https://github.com/kubernetes/kubernetes/tree/master/cmd -* https://github.com/satellity/satellity/tree/master/cmd/satellity -* https://github.com/dapr/dapr/tree/master/cmd - +- https://github.com/heptio/ark/tree/master/cmd (just a really small `main` function with everything else in packages) +- https://github.com/moby/moby/tree/master/cmd +- https://github.com/prometheus/prometheus/tree/master/cmd +- https://github.com/influxdata/influxdb/tree/master/cmd +- https://github.com/kubernetes/kubernetes/tree/master/cmd +- https://github.com/dapr/dapr/tree/master/cmd From 1671819d53c39b43b209cae41424b319fe246834 Mon Sep 17 00:00:00 2001 From: Ismael Shakverdiev Date: Sat, 14 Aug 2021 21:27:05 +0400 Subject: [PATCH 15/76] Improve and fix grammar issues Fixed some grammar issues improved the text, (Now it seems more native). --- README_tr.md | 16 ++++++++-------- 1 file changed, 8 insertions(+), 8 deletions(-) diff --git a/README_tr.md b/README_tr.md index 8520bb2..9d94306 100644 --- a/README_tr.md +++ b/README_tr.md @@ -15,17 +15,17 @@ * [Русский](README_ru.md) * [Türkçe](README_tr.md) -## Genel Bakış +## Genel Bakış: -Bu proje Go projeleri için basit bir yerleşim düzenidir. Go geliştirici takımının belirlediği resmi standartları değil, Go ekosistemindeki ortak geçmişi ve zaman içinde ortaya çıkmış şablonları içerir. Bu şablonlardan bazıları diğerlerinden daha popülerdir. Bir dizi iyileştirmenin yanı sıra yeterli büyüklükte herhangi bir gerçek dünya uygulamasına özgü birkaç destekli dizin de içerir. +Bu proje Go projeleri için basit bir yerleşim düzenidir. `Go geliştirici takımının belirlediği, resmi standartları değil`. Go ekosistemindeki, ortak geçmişi ve zaman içinde ortaya çıkmış şablonları içerir. Bu şablonlardan bazıları diğerlerinden daha popülerdir. Bir dizi iyileştirmenin yanı sıra yeterli büyüklükte herhangi bir gerçek dünya uygulamasına özgü birkaç destekli dizin de içerir. -Eğer Go'yu öğrenmeye çalışıyorsanız veya PoC (Proof of Concept) ya da kendinize oyuncak bir proje yapıyorsanız bu klasör düzeni aşırı olabilir. Çok basit bir şeyle başlayın (tek bir `main.go` dosyası fazlasıyla yeterli). Projeniz büyüdükçe projenin iyi yapılandırıldığından emin olmanın önemli olduğunu unutmayın yoksa bir sürü gizli bağımlılık (dependency) ve bir sürü her yerden erişilebilen, `global` değişkenlerle dolu dağınık bir kodla karşılaşabilirsiniz. Proje üstünde fazla kişi çalıştığında projeyi çok daha fazla yapılandırmanız gerekebilir. İşte tam da bu durumda paketleri/kütüphaneleri idare edebilmek için ortaya ortak bir yol koymak gerekir. Açık kaynak bir projeniz olduğunda ya da başkalarının sizin projenizi kullandıklarını bildiğinizde projenizde özel paketlerin ve kodların (diğer adıyla, `internal` klasörü) olması önemlidir. Bu projeyi klonlayın, ihtiyacınız olanları bırakın ve diğer bütün her şeyi silin. Bütün klasörlerin burada olması kullanmanız gerektiği anlamına gelmez. `vendor` klasörü bile herkes tarafından kullanılan bir şey değildir. +**`Eğer Go'yu öğrenmeye çalışıyorsanız veya PoC (Proof of Concept) ya da kendinize deneme bir proje yapıyorsanız bu klasör düzeni sizin için ideal olmaya bilir. Çok basit bir şeyle başlayın (tek bir` main.go `dosyası ve` go.mod `fazlasıyla yeterli olucaktır).`** Projeniz büyüdükçe projenin iyi yapılandırıldığından emin olmanın önemli olduğunu unutmayın, yoksa bir sürü gizli bağımlılık (dependency) ve bir sürü, her yerden erişilebilen, `global` değişkenlerle dolu dağınık bir kodla karşılaşabilirsiniz. Proje üstünde fazla kişi çalıştığında projeyi çok daha fazla yapılandırmanız gerekebilir. İşte tam da bu durumda paketleri/kütüphaneleri idare edebilmek için ortaya ortak bir yol koymak gerekir. Açık kaynak bir projeniz olduğunda ya da başkalarının sizin projenizi kullandıklarını bildiğinizde projenizde özel paketlerin ve kodların (diğer adıyla, `internal` klasörü) olması önemlidir. Bu projeyi klonlayın, ihtiyacınız olanları bırakın ve diğer bütün her şeyi silin. Bütün klasörlerin burada olması kullanmanız gerektiği anlamına gelmez. `vendor` klasörü bile herkes tarafından kullanılan bir şey değildir. Go 1.14 ile birlikte [`Go Modules`](https://github.com/golang/go/wiki/Modules) özelliği sonunda `production` ortamında kullanılması için hazır oldu. Eğer karşı bir nedeniniz yoksa [`Go Modules`](https://blog.golang.org/using-go-modules) kullanın. Eğer kullanırsanız `$GOPATH` ile ve projenizin nereye koyulacağıyla alakalı endişeler duymazsınız. Projenizde bulunan basit `go.mod` dosyası projenizin GitHub'da barındırıldığını varsayar ama bu bir gereklilik değildir. Modül yolu her şey olabilir ama modül yolunun ilk parçasının içinde bir nokta olmalıdır (Go'nun şimdiki versiyonu artık bu konuda zorlamıyor ama eğer daha eski versiyonları kullanırsanız ve derleme işleminde hata alırsanız şaşırmayın). Daha fazla bilgi için [`37554`](https://github.com/golang/go/issues/37554) ve [`32819`](https://github.com/golang/go/issues/32819) hata bildirimlerine bakabilirsiniz. -Bu proje düzeni genel bir düzendir ve belirli bir Go paketi yapısını empoze etmeye çalışmaz. +"Bu proje düzeni genel bir düzendir ve belirli bir Go paketi yapısını empoze etmeye çalışmaz". -Bu bir topluluk eseridir. Eğer yeni bir şablon, düzen ile karşılaşırsanız ya da olan şablonların, düzenlerin güncellenmesi gerektiğini düşünüyorsanız bir hata bildirimi açınız. +Bu proje bir topluluk eseridir. Eğer yeni bir şablon ve ya düzen ile karşılaşırsanız ya da olan şablonların, düzenlerin güncellenmesi gerektiğini düşünüyorsanız bir hata bildirimi açınız. Eğer isimlendirmekle, biçimlendirmeyle ve stilize etmeyle ilgili yardıma ihtiyacınız varsa [`gofmt`](https://golang.org/cmd/gofmt/) ve [`golint`](https://github.com/golang/lint) yazılımlarını çalıştırmayı deneyin. Ayrıca aşağıdaki Go kod stili rehberlerini ve önerilerini okuduğunuzdan emin olun. * https://talks.golang.org/2014/names.slide @@ -51,7 +51,7 @@ Paket odaklı dizayn rehberi ve Mimari katmanı ile alakalı Çince bir yazı: Projenin ana uygulamalarını içerir. -Her uygulamanın klasör adı, eklemek istediğiniz uygulamanın adıyla eşleşmelidir. (örneğin, `/cmd/benimuygulamam`) +Her uygulamanın klasör adı, eklemek istediğiniz uygulamanın adıyla eşleşmelidir. (örneğin, `/cmd/myapp`) Bu klasöre çok fazla kod koymanız iyi olmaz. Eğer kodların başka projeler tarafından kullanılabileceğini düşünüyorsanız, o kodları `/pkg` klasörüne koymalısınız. Eğer kod yeniden kullanılabilecek değilse ya da diğerlerinin yeniden kullanmasını istemiyorsanız, bu kodları `/internal` klasörüne koymalısınız. Niyetiniz hakkında açık olun, diğer geliştiricilerin kodunuzu ne için kullanabileceğine şaşıracaksınız! @@ -67,7 +67,7 @@ Paylaşılan ve paylaşılmayan kodunuzu ayırmak için isteğe bağlı olarak e ### `/pkg` -Diğerleriyle paylaşmak istediğiniz kodu içerir (örneğin, `/pkg/benimherkeseaçıkkütüphanem`). Diğer projeler bu kütüphaneleri çalışacağını tahmin ederek kullanırlar. Yani buraya bir şey koyarken iki kere düşünün :-) Unutmayın ki `internal` klasörü başka projeler tarafından kullanılmasını istemediğiniz kodlar için daha iyi bir yerdir çünkü bu Go tarafından zorunlu olarak uygulanır. `/pkg` klasörü içindeki kodun başkaları tarafından kullanılmasının güvenli olduğunu açıkça belirtmek için hala iyi bir yoldur. Travis Jeffery tarafından yazılan [`I'll take pkg over internal`](https://travisjeffery.com/b/2019/11/i-ll-take-pkg-over-internal/) blog yazısı `pkg` ve `internal` klasörleri ve onları ne zaman kullanmanın mantıklı olacağına dair genel bakış sağlar. +Diğerleriyle paylaşmak istediğiniz kodu içerir (örneğin, `/pkg/myopenlibrary`). Diğer projeler bu kütüphaneleri çalışacağını tahmin ederek kullanırlar. Yani buraya bir şey koyarken iki kere düşünün :-) Unutmayın ki `internal` klasörü başka projeler tarafından kullanılmasını istemediğiniz kodlar için daha iyi bir yerdir çünkü bu Go tarafından zorunlu olarak uygulanır. `/pkg` klasörü içindeki kodun başkaları tarafından kullanılmasının güvenli olduğunu açıkça belirtmek için hala iyi bir yoldur. Travis Jeffery tarafından yazılan [`I'll take pkg over internal`](https://travisjeffery.com/b/2019/11/i-ll-take-pkg-over-internal/) blog yazısı `pkg` ve `internal` klasörleri ve onları ne zaman kullanmanın mantıklı olacağına dair genel bakış sağlar. Ayrıca ana klasörünüz çok sayıda Go kodu olmayan dosya ve klasör içerdiğinde Go kodunu tek bir yerde gruplamanın yoludur ve bazı Go araçlarını kullanmayı daha kolay hale getirir (bu konuşmalarda bahsedildiği gibi: [`Best Practices for Industrial Programming`](https://www.youtube.com/watch?v=PTE4VJIdHPg) GopherCon Avrupa 2018 konferansından, [GopherCon 2018: Kat Zien - How Do You Structure Your Go Apps](https://www.youtube.com/watch?v=oL6JBUk6tj0) ve [GoLab 2018 - Massimiliano Pippi - Project layout patterns in Go](https://www.youtube.com/watch?v=3gQa1LWwuzk)). @@ -201,4 +201,4 @@ Proje seviyesindeki `/src` klasörü ile [`How to Write Go Code`](https://golang ## Notlar -Örnek/yeniden kullanılabilir yapılandırmalar, komut dosyaları ve kodları içeren daha kararlı bir proje şablonu yapım aşamasındadır. \ No newline at end of file +Örnek/yeniden kullanılabilir yapılandırmalar, komut dosyaları ve kodları içeren daha kararlı bir proje şablonu yapım aşamasındadır. From d3fc52fda33679049b1c30e4ffb2ce16ab659ff3 Mon Sep 17 00:00:00 2001 From: Sakakibara Tetsuya Date: Thu, 19 Aug 2021 15:36:36 +0900 Subject: [PATCH 16/76] Update Readme_ja.md --- README_ja.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/README_ja.md b/README_ja.md index 10e8603..1ef23ee 100644 --- a/README_ja.md +++ b/README_ja.md @@ -43,7 +43,7 @@ Go 1.14では、[`Go Modules`](https://github.com/golang/go/wiki/Modules)がつ * [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-directiond-design/packagedirectioneddesign.md) +* [パッケージ指向の設計とアーキテクチャの階層化](https://github.com/danceyoung/paper-code/blob/master/package-oriented-design/packageorienteddesign.md) ## Goのディレクトリ From 14763063029cae0af050c6e343fa3678012308ac Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?=E5=8F=B8=E5=BE=92=E5=85=AC=E5=AD=90?= Date: Mon, 1 Nov 2021 20:09:46 +0800 Subject: [PATCH 17/76] Fix typo --- README_zh-CN.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/README_zh-CN.md b/README_zh-CN.md index 24c8df6..7604e1c 100644 --- a/README_zh-CN.md +++ b/README_zh-CN.md @@ -144,7 +144,7 @@ IaaS，PaaS，系统和容器编排部署配置和模板（docker-compose，kube 更多样例查看[`/tools`](https://github.com/golang-standards/project-layout/blob/master/tools/README.md)。 -### `/ examples` +### `/examples` 应用程序或公共库的示例。 From 5648e0d3a293c53d2766e637540813d375331e37 Mon Sep 17 00:00:00 2001 From: Vei Ch Date: Wed, 24 Nov 2021 14:51:21 +0000 Subject: [PATCH 18/76] Update README_ru.md Making russian translation more readable --- README_ru.md | 18 +++++++++--------- 1 file changed, 9 insertions(+), 9 deletions(-) diff --git a/README_ru.md b/README_ru.md index 61f68f7..a673280 100755 --- a/README_ru.md +++ b/README_ru.md @@ -17,13 +17,13 @@ Translations: ## Overview -Это базовый макет организации проектов, разработанных на Golang. Это не официально определенный командой разработчиков Golang стандарт, однако, удовлетворяет исторически сложившимся шаблонам организации проекта в экосистеме Golang. Некоторые из шаблонов могут быть известнее остальных. В макете также присутствует несколько улучшений, включая некоторые дополнительные директории, используемые в любом достаточно большом реальном приложении. +Это базовый макет организации проектов, разработанных на Golang. Это не официально определенный командой разработчиков Golang стандарт, однако он удовлетворяет исторически сложившимся шаблонам организации проекта в экосистеме Golang. Некоторые из шаблонов могут быть известнее остальных. В макете также присутствуют несколько улучшений, включая дополнительные директории, используемые в любом достаточно большом реальном приложении. -Если вы пытаетесь изучить Golang или собрать маленький обучающий проект для личного пользования, данный макет будет явным перебором. Стоит начать с чего-нибудь действительно простого (одного файла `main.go` будет более чем достаточно). Как только ваш проект начнет расти, стоит задуматься о важности содержания кода в структурированном состоянии, чтобы в конечном итоге не получить грязный код с множеством скрытых зависимостей и global state. А как только над проектом начнут работать другие люди - понадобится еще большая структуризация. В этот момент важно определить стандартный путь организации пакетов/библиотек. Если вы разрабатываете проект с открытым исходным кодом или знаете, что вашим кодом будут пользоваться при разработке других проектов, необходимо понимать важность создания личных, внутренних (или `internal`) пакетов и кода. Склонируйте репозиторий, пользуйтесь тем, что действительно нужно,и удалите всё остальное! Наличие этого "всего остального" вовсе не означает, что это обязательно использовать. Заметьте, что ни один из этих шаблонов не обязан быть использован в абсолютно каждом проекте. Даже `vendor` не может быть универсален во всех случаях. +Если вы пытаетесь изучить Golang или собрать маленький обучающий проект для личного пользования, данный макет будет явным перебором. Стоит начать с чего-нибудь действительно простого (одного файла `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) если хотите узнать об этом больше. +С выходом обновления 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) если хотите узнать об этом больше. -Этот шаблон организации проекта намеренно делан общим, и не является примером структуры какого-то конкретного пакета Golang. +Этот шаблон организации проекта намеренно сделан обобщенным, и не является примером структуры какого-то конкретного пакета Golang. Этот репозиторий открыт к усилиям сообщества. Создайте заявку о проблеме, если вы нашли новый шаблон или считаете, что один из существующих шаблонов необходимо обновить. @@ -51,9 +51,9 @@ Translations: Основные приложения проекта. -Имя директорий для каждого приложения должно совпадать с именем исполняемого файла, который вы хотите собрать (например, `/cmd/myapp`). +Имя директории для каждого приложения должно совпадать с именем исполняемого файла, который вы хотите собрать (например, `/cmd/myapp`). -Не стоит располагать в этой директории большие объёмы кода. Если вы предполагает дальнейшее использование кода в других проектах, вам стоит хранить его в директории `/pkg` в корне проекта. Если же код не должен быть переиспользован где-то еще - ему самое место в директории `/internal` в корне проекта. Вы будете удивлены, что другие люди могут сделать, поэтому будьте уверены в своих намерениях! +Не стоит располагать в этой директории большие объёмы кода. Если вы предполагает дальнейшее использование кода в других проектах, вам стоит хранить его в директории `/pkg` в корне проекта. Если же код не должен быть переиспользован где-то еще - ему самое место в директории `/internal` в корне проекта. Вы будете удивлены тем, что другие люди могут сделать, поэтому будьте уверены в своих намерениях! Самой распространнёной практикой является использование маленькой `main` функции, которая импортирует и вызывает весь необходимый код из директорий `/internal` и `/pkg` и никаких других. @@ -71,7 +71,7 @@ Translations: Существует возможность группировать код на 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)). -Ознакомьтесь с директорией [`/pkg`](pkg/README.md), если хотите увидеть, какие популярные репозитории используют такой шаблон организации проекта. Несмотря на его распространенность, он не был принят всеми, а некоторые в обществе Go и вовсе не рекомендует его использовать. +Ознакомьтесь с директорией [`/pkg`](pkg/README.md), если хотите увидеть, какие популярные репозитории используют такой шаблон организации проекта. Несмотря на его распространенность, он не был принят всеми, а некоторые в сообществе Go и вовсе не рекомендует его использовать. Вы можете не использовать эту директорию, если проект совсем небольшой и добавление нового уровня вложенности не имеет практического смысла (разве что вы сами этого не хотите :-)). Подумайте об этом, когда ваша корневая директория начинает слишком сильно разрастаться, особенно, если у вас много компонентов, написанных не на Go. @@ -119,11 +119,11 @@ Translations: ### `/build` -Упаковка и непрерывная интеграция. +Сборка и непрерывная интеграция (Continuous Integration, CI). Поместите файлы конфигурации и скрипты облака (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` создав ссылку на них в месте, где их ожидают найти инструменты Go (если возможно). ### `/deployments` From 00c345d99a0280a4ebe77d492c7af0b46ff3e90e Mon Sep 17 00:00:00 2001 From: Mikey Boldt Date: Tue, 21 Dec 2021 14:23:02 -0600 Subject: [PATCH 19/76] Update link to Terraform example That repo's master branch was renamed to main. --- README.md | 2 +- README_es.md | 2 +- README_fr.md | 2 +- README_ja.md | 2 +- README_ko.md | 2 +- README_ptBR.md | 2 +- README_ro.md | 2 +- README_ru.md | 2 +- README_tr.md | 2 +- README_zh-CN.md | 2 +- README_zh-TW.md | 2 +- README_zh.md | 2 +- 12 files changed, 12 insertions(+), 12 deletions(-) diff --git a/README.md b/README.md index 3727c11..2a31a4e 100644 --- a/README.md +++ b/README.md @@ -114,7 +114,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. diff --git a/README_es.md b/README_es.md index d96eb20..3f19b27 100644 --- a/README_es.md +++ b/README_es.md @@ -114,7 +114,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. diff --git a/README_fr.md b/README_fr.md index 530bc5c..97964b7 100644 --- a/README_fr.md +++ b/README_fr.md @@ -113,7 +113,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. diff --git a/README_ja.md b/README_ja.md index 1ef23ee..de9aa4a 100644 --- a/README_ja.md +++ b/README_ja.md @@ -113,7 +113,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)ディレクトリを参照してください。 diff --git a/README_ko.md b/README_ko.md index f2c557c..63b96e5 100644 --- a/README_ko.md +++ b/README_ko.md @@ -115,7 +115,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) 디렉터리를 확인하세요. diff --git a/README_ptBR.md b/README_ptBR.md index 80b9e8c..35dac2b 100644 --- a/README_ptBR.md +++ b/README_ptBR.md @@ -113,7 +113,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. diff --git a/README_ro.md b/README_ro.md index 0078d41..a44938b 100644 --- a/README_ro.md +++ b/README_ro.md @@ -111,7 +111,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. diff --git a/README_ru.md b/README_ru.md index 61f68f7..0de53e2 100755 --- a/README_ru.md +++ b/README_ru.md @@ -113,7 +113,7 @@ Translations: Скрипты для сборки, установки, анализа и прочих операций над проектом. -Эти скрипты позволяют оставить основной 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) для примеров. diff --git a/README_tr.md b/README_tr.md index 9d94306..5817a14 100644 --- a/README_tr.md +++ b/README_tr.md @@ -113,7 +113,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. diff --git a/README_zh-CN.md b/README_zh-CN.md index 24c8df6..d7cf5bd 100644 --- a/README_zh-CN.md +++ b/README_zh-CN.md @@ -108,7 +108,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)。 diff --git a/README_zh-TW.md b/README_zh-TW.md index 8c29708..8ec8285 100644 --- a/README_zh-TW.md +++ b/README_zh-TW.md @@ -111,7 +111,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) 目錄獲得更多範例。 diff --git a/README_zh.md b/README_zh.md index 9257976..9d9cab7 100644 --- a/README_zh.md +++ b/README_zh.md @@ -112,7 +112,7 @@ System init（systemd，upstart，sysv）和 process manager/supervisor（runit 执行各种构建、安装、分析等操作的脚本。 -这些脚本保持了根级别的 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) 目录。 From 409528c64a9de2dcfe3ad3d6ce1feaf5090e0a17 Mon Sep 17 00:00:00 2001 From: zy Date: Fri, 28 Jan 2022 16:05:15 +0800 Subject: [PATCH 20/76] fix typo fix typo --- README_zh.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/README_zh.md b/README_zh.md index 9257976..6256c23 100644 --- a/README_zh.md +++ b/README_zh.md @@ -17,7 +17,7 @@ 这是 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 +58,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` From 1c97e8b8b88079e7efde539033fef9e81c51bc9b Mon Sep 17 00:00:00 2001 From: Atom Date: Sun, 6 Mar 2022 21:28:30 +0100 Subject: [PATCH 21/76] feat: add README_it --- README_it.md | 207 +++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 207 insertions(+) create mode 100644 README_it.md diff --git a/README_it.md b/README_it.md new file mode 100644 index 0000000..e271d8c --- /dev/null +++ b/README_it.md @@ -0,0 +1,207 @@ +# Layout standard di un progetto Go + +Traduzioni: + +* [한국어 문서](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) + +## 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. + +**`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. + +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. + +Questa struttura di progetto è intenzionalmente generica e non cerca di imporre una specifica impostazione per i packages Go. + +Questo è uno sforzo della community. Apri una issue se vedi un nuovo pattern o se pensi che uno di quelli esistenti andrebbe aggiornato. + +Se hai bisogno di aiuto per la nomenclatura, formattazione e lo stile, inizia da utilizzare [`gofmt`](https://golang.org/cmd/gofmt/) e [`golint`](https://github.com/golang/lint). Assicurati anche di leggere le linee guida di stile e i consigli: +* 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) + +Vedi [`Go Project Layout`](https://medium.com/golang-learn/go-project-layout-e5213cdcfaa2) per l'aggiunta di altre informazioni a contorno. + +Per altro riguardo la nomenclatura e l'organizzazione dei pacchetti e altre impostazioni raccomandate: +* [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) + +Un post Cinese riguardo delle linee guida per il design Package-Oriented e layer archittetturali +* [面向包的设计和架构分层](https://github.com/danceyoung/paper-code/blob/master/package-oriented-design/packageorienteddesign.md) + +## Go Cartelle + +### `/cmd` + +Applicazioni principali per questo progetto. + +Il nome della cartella per ciascun applicativo dovrebbe coincidere con il nome che vuoi avere per l'eseguibile (es: `/cmd/myapp`). + +Non mettere molto codice nella cartella dell'applicazione. Se pensi che il codice potrebbe essere importato e usato in altri progetti, allora dovrebbe essere inserito nella cartella `/pkg`. Se il codice non è riutilizzabile o non vuoi che altri lo riutilizzino, metti questo codice nella cartella `/internal`. Sarai sorpreso di vedere cosa faranno gli altri, quindi si esplicito riguardo le tue intenzioni! + +E' comune avere una piccola funzione `main` che importa e invoca il codice dalle cartelle `/internal` e `/pkg` e nient'altro. + +Vedi cartella [`/cmd`](cmd/README.md) per esempi. + +### `/internal` + +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`). + +### `/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. + +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)). + +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. + +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). + +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). + +### `/vendor` + +Dipendenze dell'applicativo (gestite manualmente o dal tuo gestore di pacchetti preferito come la nuova feature built-in [`Go Modules`](https://github.com/golang/go/wiki/Modules)). Il comando `go mod vendor` creerà la cartella `/vendor` per te. Tiene presente che potrebbe essere necessario aggiungere il flag `-mod=vendor` al tuo comando `go build` se non stai utilizzando Go 1.14, dove è utilizzato di default. + +Non effettuare il commit delle dipendenze del tuo applicativo se stai sviluppando una libreria. + +Nota che sin dalla versione [`1.13`](https://golang.org/doc/go1.13#modules) Go ha anche abilitata la caratteristica del module proxy (usando [`https://proxy.golang.org`](https://proxy.golang.org) come server proxy predefinito). Approfondisci [`quì`](https://blog.golang.org/module-mirror-launch) per vedere se questo soddisfa tutti i tuoi requisiti e vincoli. In caso positivo, allora non avrai bisogno della cartella `vendor`. + +## Cartelle di Servizio Applicativo + +### `/api` + +OpenAPI/Swagger specs, JSON schema files, files di definizione del protocollo. + +Vedi la cartella [`/api`](api/README.md) per esempi. + +## Cartelle Applicativo Web + +### `/web` + +Componenti specifici per applitavi Web: assets web statici, templates server side e SPAs. + +## Cartelle comuni applicativo + +### `/configs` + +Templates per il file di configurazione o configurazioni di default. + +Metti i tuoi templates `confd` o `consul-template` quì. + +### `/init` + +Inizializzazione del sistema (systemd, upstart, sysv) e configurazioni per process manager/supervisor (runit, supervisord). + +### `/scripts` + +Scripts 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)). + +Vedi la cartella [`/scripts`](scripts/README.md) per esempi. + +### `/build` + +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 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). + +### `/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`. + +### `/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. + +Vedi la cartella [`/test`](test/README.md) per esempi. + +## Altre Cartelle + +### `/docs` + +Documenti dell'utente e di Design (in aggiunta alla tua documentazione godoc autogenerata). + +Vedi la cartella [`/docs`](docs/README.md) per esempi. + +### `/tools` + +Strumenti di supporto per il progetto. Nota che questi strumenti possono importare codice dalle cartelle `/pkg` e `/internal`. + +Vedi la cartella [`/tools`](tools/README.md) per esempi. + +### `/examples` + +Esempi per il tuo applicativo e/o librerie pubbliche. + +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). + +### `/githooks` + +Git hooks. + +### `/assets` + +Altri assets del tuo repository (immagini, loghi, etc). + +### `/website` + +Questo è il posto in cui inserire i dati del sito Web del tuo progetto se non stai utilizzando le GitHub pages. + +Vedi la cartella [`/website`](website/README.md) per esempi. + +## Cartelle che Non Dovresti Avere + +### `/src` + +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. + + +## Badges + +* [Go Report Card](https://goreportcard.com/) - Scansione il tuo codice con `gofmt`, `go vet`, `gocyclo`, `golint`, `ineffassign`, `license` e `misspell`. Rimpiazza `github.com/golang-standards/project-layout` con la referenza al tuo progetto. + + [![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) - Fornisce una verione online della tua documentazione GoDoc generata. Cambia il link per puntare al tuo progetto.~~ + + [![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 è una nuova fonte per la scoperta di Go e documentazione. Puoi creare un badge usando lo [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 - Mostra l'ultima versione per il tuo progetto. Cambia il link github per puntare al tuo progetto. + + [![Release](https://img.shields.io/github/release/golang-standards/project-layout.svg?style=flat-square)](https://github.com/golang-standards/project-layout/releases/latest) + +## Note + +Un template di progetto standardizzato con configurazioni semplici e riutilizzabili, gli aggiornamenti per gli scripts e il codice sono in corso. \ No newline at end of file From 4fbfc42212e5696832461414060d71e50aa7770e Mon Sep 17 00:00:00 2001 From: Vladimir Malinovskii Date: Sat, 9 Apr 2022 22:14:09 +0300 Subject: [PATCH 22/76] typo fix in README_ru.md small typo fix --- README_ru.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/README_ru.md b/README_ru.md index a673280..76efb72 100755 --- a/README_ru.md +++ b/README_ru.md @@ -53,7 +53,7 @@ Translations: Имя директории для каждого приложения должно совпадать с именем исполняемого файла, который вы хотите собрать (например, `/cmd/myapp`). -Не стоит располагать в этой директории большие объёмы кода. Если вы предполагает дальнейшее использование кода в других проектах, вам стоит хранить его в директории `/pkg` в корне проекта. Если же код не должен быть переиспользован где-то еще - ему самое место в директории `/internal` в корне проекта. Вы будете удивлены тем, что другие люди могут сделать, поэтому будьте уверены в своих намерениях! +Не стоит располагать в этой директории большие объёмы кода. Если вы предполагаете дальнейшее использование кода в других проектах, вам стоит хранить его в директории `/pkg` в корне проекта. Если же код не должен быть переиспользован где-то еще - ему самое место в директории `/internal` в корне проекта. Вы будете удивлены тем, что другие люди могут сделать, поэтому будьте уверены в своих намерениях! Самой распространнёной практикой является использование маленькой `main` функции, которая импортирует и вызывает весь необходимый код из директорий `/internal` и `/pkg` и никаких других. From e78b867d1b27d34f8e8b4af44ded74ec1c595943 Mon Sep 17 00:00:00 2001 From: Alessio Pierobon Date: Wed, 4 May 2022 12:35:09 +0200 Subject: [PATCH 23/76] doc: adds missing "it" translation links --- README.md | 1 + README_es.md | 1 + README_fr.md | 1 + README_ja.md | 1 + README_ko.md | 1 + README_ptBR.md | 1 + README_ro.md | 1 + README_ru.md | 1 + README_tr.md | 1 + README_zh-CN.md | 1 + README_zh-TW.md | 1 + README_zh.md | 1 + 12 files changed, 12 insertions(+) diff --git a/README.md b/README.md index 3727c11..ee15399 100644 --- a/README.md +++ b/README.md @@ -13,6 +13,7 @@ Translations: * [Română](README_ro.md) * [Русский](README_ru.md) * [Türkçe](README_tr.md) +* [Italiano](README_it.md) ## Overview diff --git a/README_es.md b/README_es.md index d96eb20..ed15efa 100644 --- a/README_es.md +++ b/README_es.md @@ -14,6 +14,7 @@ Traducciones: * [Română](README_ro.md) * [Русский](README_ru.md) * [Türkçe](README_tr.md) +* [Italiano](README_it.md) ## Resumen diff --git a/README_fr.md b/README_fr.md index 530bc5c..0065dde 100644 --- a/README_fr.md +++ b/README_fr.md @@ -14,6 +14,7 @@ Traductions: * [Română](README_ro.md) * [Русский](README_ru.md) * [Türkçe](README_tr.md) +* [Italiano](README_it.md) ## Introduction diff --git a/README_ja.md b/README_ja.md index 1ef23ee..b915efa 100644 --- a/README_ja.md +++ b/README_ja.md @@ -14,6 +14,7 @@ * [Română](README_ro.md) * [Русский](README_ru.md) * [Türkçe](README_tr.md) +* [Italiano](README_it.md) ## 概要 diff --git a/README_ko.md b/README_ko.md index f2c557c..69664c9 100644 --- a/README_ko.md +++ b/README_ko.md @@ -14,6 +14,7 @@ * [Română](README_ro.md) * [Русский](README_ru.md) * [Türkçe](README_tr.md) +* [Italiano](README_it.md) ## 개요 diff --git a/README_ptBR.md b/README_ptBR.md index 80b9e8c..f2cee63 100644 --- a/README_ptBR.md +++ b/README_ptBR.md @@ -14,6 +14,7 @@ Traduções: * [Română](README_ro.md) * [Русский](README_ru.md) * [Türkçe](README_tr.md) +* [Italiano](README_it.md) ## Visão geral diff --git a/README_ro.md b/README_ro.md index 0078d41..5bfcada 100644 --- a/README_ro.md +++ b/README_ro.md @@ -14,6 +14,7 @@ Traduceri: * [Română](README_ro.md) * [Русский](README_ru.md) * [Türkçe](README_tr.md) +* [Italiano](README_it.md) ## General diff --git a/README_ru.md b/README_ru.md index a673280..91fa434 100755 --- a/README_ru.md +++ b/README_ru.md @@ -14,6 +14,7 @@ Translations: * [Română](README_ro.md) * [Русский](README_ru.md) * [Türkçe](README_tr.md) +* [Italiano](README_it.md) ## Overview diff --git a/README_tr.md b/README_tr.md index 9d94306..70765b9 100644 --- a/README_tr.md +++ b/README_tr.md @@ -14,6 +14,7 @@ * [Română](README_ro.md) * [Русский](README_ru.md) * [Türkçe](README_tr.md) +* [Italiano](README_it.md) ## Genel Bakış: diff --git a/README_zh-CN.md b/README_zh-CN.md index 24c8df6..2245d3b 100644 --- a/README_zh-CN.md +++ b/README_zh-CN.md @@ -12,6 +12,7 @@ * [Română](README_ro.md) * [Русский](README_ru.md) * [Türkçe](README_tr.md) +* [Italiano](README_it.md) 这是Go应用程序项目的基础布局。这不是Go核心开发团队定义的官方标准；无论是在经典项目还是在新兴的项目中，这都是Go生态系统中一组常见的项目布局模式。这其中有一些模式比另外的一些更受欢迎。它通过几个支撑目录为任何足够大规模的实际应用程序提供一些增强功能。 diff --git a/README_zh-TW.md b/README_zh-TW.md index 8c29708..da3589f 100644 --- a/README_zh-TW.md +++ b/README_zh-TW.md @@ -14,6 +14,7 @@ * [Română](README_ro.md) * [Русский](README_ru.md) * [Türkçe](README_tr.md) +* [Italiano](README_it.md) 這是 Go 應用程式專案的基本目錄結構。它不是核心 Go 開發團隊定義的官方標準；然而，它是 Go 生態系統中一組常見的老專案和新專案的目錄結構。其中一些目錄結構比其他目錄結構更受歡迎。這個專案目錄結構還有一些細微的改進，可以支援任何大型且實用的應用程式目錄結構。 diff --git a/README_zh.md b/README_zh.md index 9257976..cf798c3 100644 --- a/README_zh.md +++ b/README_zh.md @@ -14,6 +14,7 @@ * [Română](README_ro.md) * [Русский](README_ru.md) * [Türkçe](README_tr.md) +* [Italiano](README_it.md) 这是 Go 应用程序项目的基本布局。它不是核心 Go 开发团队定义的官方标准；然而，它是 Go 生态系统中一组常见的老项目和新项目的布局模式。其中一些模式比其他模式更受欢迎。它还具有许多小的增强，以及对任何足够大的实际应用程序通用的几个支持目录。 From 54525c135a70927e2e4074dcba789a57e84ddaf8 Mon Sep 17 00:00:00 2001 From: "Gerasimos (Makis) Maropoulos" Date: Wed, 18 May 2022 20:11:07 +0300 Subject: [PATCH 24/76] pkg/README.md: Remove prometheus pkg Remove https://github.com/prometheus/prometheus/tree/main/pkg example as it doesn't exist anymore --- pkg/README.md | 1 - 1 file changed, 1 deletion(-) diff --git a/pkg/README.md b/pkg/README.md index 633b877..6d70c82 100644 --- a/pkg/README.md +++ b/pkg/README.md @@ -13,7 +13,6 @@ The `pkg` directory origins: The old Go source code used to use `pkg` for its pa Examples: -* https://github.com/prometheus/prometheus/tree/master/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 From 7d3ec2bb161e3c7e345a781fd5e20f70f8edb664 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Thomas=20G=C3=BCttler?= Date: Tue, 7 Jun 2022 20:58:55 +0200 Subject: [PATCH 25/76] removed mesos and bosh mesos and bosh confuse new users. --- README.md | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/README.md b/README.md index 3727c11..6b18b69 100644 --- a/README.md +++ b/README.md @@ -1,7 +1,6 @@ # Standard Go Project Layout Translations: - * [한국어 문서](README_ko.md) * [简体中文](README_zh.md) * [正體中文](README_zh-TW.md) @@ -128,7 +127,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` From 1a40bd458accfb64c73f2ab74d4ad00bec297672 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Thomas=20G=C3=BCttler?= Date: Tue, 7 Jun 2022 20:59:29 +0200 Subject: [PATCH 26/76] Update README.md --- README.md | 1 + 1 file changed, 1 insertion(+) diff --git a/README.md b/README.md index 6b18b69..d019275 100644 --- a/README.md +++ b/README.md @@ -1,6 +1,7 @@ # Standard Go Project Layout Translations: + * [한국어 문서](README_ko.md) * [简体中文](README_zh.md) * [正體中文](README_zh-TW.md) From b29c48adcba3882163ad4e4f01a631d7226f0150 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Serhan=20KARAKO=C3=87?= <108010261+serhankarakoc@users.noreply.github.com> Date: Thu, 23 Jun 2022 22:47:44 +0300 Subject: [PATCH 27/76] Update README_tr.md --- README_tr.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/README_tr.md b/README_tr.md index 9d94306..877850b 100644 --- a/README_tr.md +++ b/README_tr.md @@ -201,4 +201,4 @@ Proje seviyesindeki `/src` klasörü ile [`How to Write Go Code`](https://golang ## Notlar -Örnek/yeniden kullanılabilir yapılandırmalar, komut dosyaları ve kodları içeren daha kararlı bir proje şablonu yapım aşamasındadır. +Örnek / yeniden kullanılabilir yapılandırmalar, komut dosyaları ve kodları içeren daha kararlı bir proje şablonu yapım aşamasındadır. From 51897f09f8c4d305af733b83487f6b9d640d4066 Mon Sep 17 00:00:00 2001 From: Sachin Prasad Date: Mon, 19 Sep 2022 10:26:58 +0530 Subject: [PATCH 28/76] Lowercasing. --- README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/README.md b/README.md index 3727c11..09f238d 100644 --- a/README.md +++ b/README.md @@ -41,7 +41,7 @@ More about naming and organizing packages as well as other code structure recomm * [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) -A Chinese Post about Package-Oriented-Design guidelines and Architecture layer +A Chinese post about Package-Oriented-Design guidelines and Architecture layer * [面向包的设计和架构分层](https://github.com/danceyoung/paper-code/blob/master/package-oriented-design/packageorienteddesign.md) ## Go Directories From 2d3e1e5738dee4a4a9ba54af57aca4c305ea4959 Mon Sep 17 00:00:00 2001 From: enespolat24 Date: Fri, 23 Sep 2022 01:41:28 +0300 Subject: [PATCH 29/76] remove dead link --- examples/README.md | 1 - 1 file changed, 1 deletion(-) diff --git a/examples/README.md b/examples/README.md index f76539e..ab44e5c 100644 --- a/examples/README.md +++ b/examples/README.md @@ -6,5 +6,4 @@ Examples: * https://github.com/nats-io/nats.go/tree/master/examples * https://github.com/docker-slim/docker-slim/tree/master/examples -* https://github.com/gohugoio/hugo/tree/master/examples * https://github.com/hashicorp/packer/tree/master/examples From a670b625706e3e36aa13494f1f71d1f3074c9a2e Mon Sep 17 00:00:00 2001 From: Chris Novak Date: Sat, 15 Oct 2022 14:50:28 -0700 Subject: [PATCH 30/76] Update branch names in interal/README Change branch names from `master` to `main` for projects that changed their branch names --- internal/README.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/internal/README.md b/internal/README.md index 285acfa..146cfbf 100644 --- a/internal/README.md +++ b/internal/README.md @@ -6,12 +6,12 @@ You can optionally add a bit of extra structure to your internal packages to sep Examples: -* https://github.com/hashicorp/terraform/tree/master/internal +* https://github.com/hashicorp/terraform/tree/main/internal * https://github.com/influxdata/influxdb/tree/master/internal * https://github.com/perkeep/perkeep/tree/master/internal -* https://github.com/jaegertracing/jaeger/tree/master/internal +* https://github.com/jaegertracing/jaeger/tree/main/internal * https://github.com/moby/moby/tree/master/internal -* https://github.com/satellity/satellity/tree/master/internal +* https://github.com/satellity/satellity/tree/main/internal ## `/internal/pkg` From 509e1be5dcb84ffb5529b6e817faea57e25f8f94 Mon Sep 17 00:00:00 2001 From: Chris Novak Date: Sat, 15 Oct 2022 14:53:50 -0700 Subject: [PATCH 31/76] Update cmd/README w/updated example URLs Updated example URLs to latest locations --- cmd/README.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/cmd/README.md b/cmd/README.md index 893105f..f93fdcd 100644 --- a/cmd/README.md +++ b/cmd/README.md @@ -10,9 +10,9 @@ It's common to have a small `main` function that imports and invokes the code fr Examples: -* https://github.com/heptio/ark/tree/master/cmd (just a really small `main` function with everything else in packages) +* https://github.com/vmware-tanzu/velero/tree/main/cmd (just a really small `main` function with everything else in packages) * https://github.com/moby/moby/tree/master/cmd -* https://github.com/prometheus/prometheus/tree/master/cmd +* https://github.com/prometheus/prometheus/tree/main/cmd * https://github.com/influxdata/influxdb/tree/master/cmd * https://github.com/kubernetes/kubernetes/tree/master/cmd * https://github.com/dapr/dapr/tree/master/cmd From b31822905f3612f61ed22f34862b75cb557d9169 Mon Sep 17 00:00:00 2001 From: Ikko Ashimine Date: Sat, 29 Oct 2022 01:52:00 +0900 Subject: [PATCH 32/76] Update Readme_ja.md minor fix --- README_ja.md | 13 ++++++++----- 1 file changed, 8 insertions(+), 5 deletions(-) diff --git a/README_ja.md b/README_ja.md index 1ef23ee..d4882a2 100644 --- a/README_ja.md +++ b/README_ja.md @@ -186,16 +186,19 @@ Goプロジェクトの中には `src` フォルダを持っているものも * [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で作成したドキュメントのオンライン版を提供します。リンクを自分のプロジェクトへのリンクに変更してください。~~ -* [Pkg.go.dev](https://pkg.go.dev) - Pkg.go.devは、囲碁の発見とドキュメントの新しい目的地です。[バッジ生成ツール](https://pkg.go.dev/badge)を使ってバッジを作成することができます。 + [![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の発見とドキュメントの新しい目的地です。[バッジ生成ツール](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のリンクを変更して、あなたのプロジェクトを指すようにしてください。 -[![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) -[![PkgGoDev](https://pkg.go.dev/badge/github.com/golang-standards/project-layout)](https://pkg.go.dev/github.com/golang-standards/project-layout) -[![リリース](https://img.shields.io/github/release/golang-standards/project-layout.svg?style=flat-square)](https://github.com/golang-standards/project-layout/releases/latest) + [![リリース](https://img.shields.io/github/release/golang-standards/project-layout.svg?style=flat-square)](https://github.com/golang-standards/project-layout/releases/latest) ## 注意事項 From 6f151674c612f0b8849bc442c44811f0a8714347 Mon Sep 17 00:00:00 2001 From: Arialdo Martini Date: Thu, 8 Dec 2022 17:41:25 +0100 Subject: [PATCH 33/76] Typo: patterns => pattern; using singular form --- README_it.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/README_it.md b/README_it.md index e271d8c..42ed73a 100644 --- a/README_it.md +++ b/README_it.md @@ -16,9 +16,9 @@ Traduzioni: ## 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. @@ -204,4 +204,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. \ No newline at end of file +Un template di progetto standardizzato con configurazioni semplici e riutilizzabili, gli aggiornamenti per gli scripts e il codice sono in corso. From cb923f608c8582326ef7f46c8b012c344dbf6658 Mon Sep 17 00:00:00 2001 From: Arialdo Martini Date: Thu, 8 Dec 2022 17:42:42 +0100 Subject: [PATCH 34/76] No comma between subject and verb --- README_it.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/README_it.md b/README_it.md index 42ed73a..52d1d22 100644 --- a/README_it.md +++ b/README_it.md @@ -63,7 +63,7 @@ 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 apps nella cartella `/internal/pkg` (es: `/internal/pkg/myprivlib`). ### `/pkg` From af59f47298e77342ddae73672d52561d7c8175de Mon Sep 17 00:00:00 2001 From: Arialdo Martini Date: Thu, 8 Dec 2022 17:43:10 +0100 Subject: [PATCH 35/76] apps => app; foreign words shall be singular --- README_it.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/README_it.md b/README_it.md index 52d1d22..771b3bb 100644 --- a/README_it.md +++ b/README_it.md @@ -63,7 +63,7 @@ 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` From 85350eb4f48c8950c5ca6a82cc84c700ebb62e0b Mon Sep 17 00:00:00 2001 From: Arialdo Martini Date: Thu, 8 Dec 2022 17:44:04 +0100 Subject: [PATCH 36/76] =?UTF-8?q?Typo:=20wrong=20accent;=20perch=C3=A8=20?= =?UTF-8?q?=3D>=20perch=C3=A9?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- README_it.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/README_it.md b/README_it.md index 771b3bb..5c53b26 100644 --- a/README_it.md +++ b/README_it.md @@ -67,7 +67,7 @@ Puoi opzionalmente aggiungere una struttura aggiuntiva ai tuoi pacchetti interni ### `/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 ha 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)). From 612a9a5ae1c325385aa0955c99044e7879f0409a Mon Sep 17 00:00:00 2001 From: Arialdo Martini Date: Thu, 8 Dec 2022 17:44:53 +0100 Subject: [PATCH 37/76] Using subjunctive instead of indicative --- README_it.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/README_it.md b/README_it.md index 5c53b26..29d2f3e 100644 --- a/README_it.md +++ b/README_it.md @@ -67,7 +67,7 @@ Puoi opzionalmente aggiungere una struttura aggiuntiva ai tuoi pacchetti interni ### `/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)). From af1fa7430deeb6d5d1ab05af23c5b94bb0ef7874 Mon Sep 17 00:00:00 2001 From: Arialdo Martini Date: Thu, 8 Dec 2022 17:45:54 +0100 Subject: [PATCH 38/76] talks => talk: foreign words in singular form --- README_it.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/README_it.md b/README_it.md index 29d2f3e..dfa6903 100644 --- a/README_it.md +++ b/README_it.md @@ -69,7 +69,7 @@ Puoi opzionalmente aggiungere una struttura aggiuntiva ai tuoi pacchetti interni 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. From a9ae989f6464552ff9c1828e5b17df685c48ba82 Mon Sep 17 00:00:00 2001 From: Arialdo Martini Date: Thu, 8 Dec 2022 17:46:28 +0100 Subject: [PATCH 39/76] repos => repo --- README_it.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/README_it.md b/README_it.md index dfa6903..00cd290 100644 --- a/README_it.md +++ b/README_it.md @@ -71,7 +71,7 @@ Codice di libreria che può essere utilizzato da applicazioni esterne (es:, `/pk 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). From d06b722278ad9a6ff72087c9015f86da7c4e0b65 Mon Sep 17 00:00:00 2001 From: Arialdo Martini Date: Thu, 8 Dec 2022 17:46:54 +0100 Subject: [PATCH 40/76] =?UTF-8?q?Replacing=20apostrophe=20with=20proper=20?= =?UTF-8?q?accent:=20E'=20=3D>=20=C3=88?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- README_it.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/README_it.md b/README_it.md index 00cd290..8259fd5 100644 --- a/README_it.md +++ b/README_it.md @@ -73,7 +73,7 @@ C'è anche un modo di raggruppare il codice Go in unico posto quando la tua cart 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 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). 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). From e552940be3a94d0e6bbf21ad1bdc4223ba7f67ce Mon Sep 17 00:00:00 2001 From: Arialdo Martini Date: Thu, 8 Dec 2022 17:47:50 +0100 Subject: [PATCH 41/76] Nesting translated to "annidamento" --- README_it.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/README_it.md b/README_it.md index 8259fd5..e17f71b 100644 --- a/README_it.md +++ b/README_it.md @@ -73,7 +73,7 @@ C'è anche un modo di raggruppare il codice Go in unico posto quando la tua cart 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. -È 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). From 4218898d24c38eef46dee2339f17b996cc83e4fe Mon Sep 17 00:00:00 2001 From: Arialdo Martini Date: Thu, 8 Dec 2022 17:49:00 +0100 Subject: [PATCH 42/76] Scripts => Script: foreign words shall be singular --- README_it.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/README_it.md b/README_it.md index e17f71b..84ecbf9 100644 --- a/README_it.md +++ b/README_it.md @@ -113,9 +113,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,9 +123,9 @@ 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 files di configurazione. Prova mettendo le configurazioni nella cartella `/build/ci` collegandole al percorso dove i strumenti di CI se le aspettano (quando possibile). ### `/deployments` From ea7256d9e24c918888d7954601ddef75b3252eba Mon Sep 17 00:00:00 2001 From: Arialdo Martini Date: Thu, 8 Dec 2022 17:49:58 +0100 Subject: [PATCH 43/76] Files => file --- README_it.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/README_it.md b/README_it.md index 84ecbf9..e8665ae 100644 --- a/README_it.md +++ b/README_it.md @@ -125,7 +125,7 @@ Packaging e Continuous Integration. 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 script 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 i strumenti di CI se le aspettano (quando possibile). ### `/deployments` From e888606ab83507aa89e20246676deac2736a27ba Mon Sep 17 00:00:00 2001 From: Arialdo Martini Date: Thu, 8 Dec 2022 17:50:16 +0100 Subject: [PATCH 44/76] Typo: "i strumenti" => "gli strumenti" --- README_it.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/README_it.md b/README_it.md index e8665ae..0e2597a 100644 --- a/README_it.md +++ b/README_it.md @@ -125,7 +125,7 @@ Packaging e Continuous Integration. 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 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 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` From 180f479c92a7fa6cb826e3bc23dbb15bb7631874 Mon Sep 17 00:00:00 2001 From: Arialdo Martini Date: Thu, 8 Dec 2022 17:50:40 +0100 Subject: [PATCH 45/76] Templates => template --- README_it.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/README_it.md b/README_it.md index 0e2597a..f00a87f 100644 --- a/README_it.md +++ b/README_it.md @@ -129,7 +129,7 @@ Metti le tue configurazioni della CI (travis, circle, drone) e script nella cart ### `/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 repos (specialmente per gli applicativi pubblicati con kubernetes) questa cartella è chiamata `/deploy`. ### `/test` From 80c62ab9d42c60534e58515651a643e2deeca73c Mon Sep 17 00:00:00 2001 From: Arialdo Martini Date: Thu, 8 Dec 2022 17:50:57 +0100 Subject: [PATCH 46/76] repos => repo --- README_it.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/README_it.md b/README_it.md index f00a87f..0bef76f 100644 --- a/README_it.md +++ b/README_it.md @@ -129,7 +129,7 @@ Metti le tue configurazioni della CI (travis, circle, drone) e script nella cart ### `/deployments` -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 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` From 70738bfb6c7006898c5ecd3f248ef928b64eab59 Mon Sep 17 00:00:00 2001 From: Arialdo Martini Date: Thu, 8 Dec 2022 17:51:22 +0100 Subject: [PATCH 47/76] Files => file --- README_it.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/README_it.md b/README_it.md index 0bef76f..208faea 100644 --- a/README_it.md +++ b/README_it.md @@ -133,7 +133,7 @@ Configurazioni e template per distribuzioni IaaS, PaaS, di sistema e basati su s ### `/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. From aa6866150af0ba15be26e70ec8e7d221867df6a3 Mon Sep 17 00:00:00 2001 From: Arialdo Martini Date: Thu, 8 Dec 2022 17:51:55 +0100 Subject: [PATCH 48/76] Utilities => utility --- README_it.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/README_it.md b/README_it.md index 208faea..61f1635 100644 --- a/README_it.md +++ b/README_it.md @@ -159,7 +159,7 @@ 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` From 93579ceb980b6789e1c25b6264758ebfa7f490d6 Mon Sep 17 00:00:00 2001 From: Arialdo Martini Date: Thu, 8 Dec 2022 17:52:09 +0100 Subject: [PATCH 49/76] Hooks => hook --- README_it.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/README_it.md b/README_it.md index 61f1635..564ffbd 100644 --- a/README_it.md +++ b/README_it.md @@ -163,7 +163,7 @@ Strumenti esterni di aiuto, codice forcato e altre utility di terze parti (es: S ### `/githooks` -Git hooks. +Hook di Git. ### `/assets` From b02db4757d9ef1ac8032de56da5fc25fc7452a44 Mon Sep 17 00:00:00 2001 From: Arialdo Martini Date: Thu, 8 Dec 2022 17:52:34 +0100 Subject: [PATCH 50/76] Assets => asset --- README_it.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/README_it.md b/README_it.md index 564ffbd..5e30812 100644 --- a/README_it.md +++ b/README_it.md @@ -167,7 +167,7 @@ Hook di Git. ### `/assets` -Altri assets del tuo repository (immagini, loghi, etc). +Altri asset del tuo repository (immagini, loghi, etc). ### `/website` From a52786e80e350df636002086c77a9b2eb60be9a0 Mon Sep 17 00:00:00 2001 From: Arialdo Martini Date: Thu, 8 Dec 2022 17:53:15 +0100 Subject: [PATCH 51/76] Workspaces => Workspace --- README_it.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/README_it.md b/README_it.md index 5e30812..0fc02ac 100644 --- a/README_it.md +++ b/README_it.md @@ -181,7 +181,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 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. ## Badges From 20c0419e819bba7c794bcaed6a8d09332da6c02e Mon Sep 17 00:00:00 2001 From: Arialdo Martini Date: Thu, 8 Dec 2022 17:53:47 +0100 Subject: [PATCH 52/76] Windows, as a proper noun, uses a capital W --- README_it.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/README_it.md b/README_it.md index 0fc02ac..12d6481 100644 --- a/README_it.md +++ b/README_it.md @@ -181,7 +181,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 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 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 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. ## Badges From 47f880167ba046188961a41d53c404d35a06bb9e Mon Sep 17 00:00:00 2001 From: Arialdo Martini Date: Thu, 8 Dec 2022 17:54:36 +0100 Subject: [PATCH 53/76] Typo: removed duplicate word --- README_it.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/README_it.md b/README_it.md index 12d6481..3b1110b 100644 --- a/README_it.md +++ b/README_it.md @@ -181,7 +181,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 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 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 From 973d9765a02797e0b15786f102d7f6002bbfd037 Mon Sep 17 00:00:00 2001 From: Arialdo Martini Date: Thu, 8 Dec 2022 17:55:15 +0100 Subject: [PATCH 54/76] Scripts => script --- README_it.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/README_it.md b/README_it.md index 3b1110b..cb85682 100644 --- a/README_it.md +++ b/README_it.md @@ -204,4 +204,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. From 5906d8fa020cc4dbeb2e0e6b2caf277e2cbffac7 Mon Sep 17 00:00:00 2001 From: Rostislav Pylypiv Date: Fri, 9 Dec 2022 14:18:16 +0200 Subject: [PATCH 55/76] Added new translation to README.md. Added README_ua.md --- README_ua.md | 207 +++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 207 insertions(+) create mode 100644 README_ua.md diff --git a/README_ua.md b/README_ua.md new file mode 100644 index 0000000..29388ac --- /dev/null +++ b/README_ua.md @@ -0,0 +1,207 @@ +# Standard Go Project Layout + +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) + +## 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. + +**`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. + +With Go 1.14 [`Go Modules`](https://github.com/golang/go/wiki/Modules) are finally ready for production. Use [`Go Modules`](https://blog.golang.org/using-go-modules) unless you have a specific reason not to use them and if you do then you don’t need to worry about $GOPATH and where you put your project. The basic `go.mod` file in the repo assumes your project is hosted on GitHub, but it's not a requirement. The module path can be anything though the first module path component should have a dot in its name (the current version of Go doesn't enforce it anymore, but if you are using slightly older versions don't be surprised if your builds fail without it). See Issues [`37554`](https://github.com/golang/go/issues/37554) and [`32819`](https://github.com/golang/go/issues/32819) if you want to know more about it. + +This project layout is intentionally generic and it doesn't try to impose a specific Go package structure. + +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: +* 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) + +See [`Go Project Layout`](https://medium.com/golang-learn/go-project-layout-e5213cdcfaa2) for additional background information. + +More about naming and organizing packages as well as other code structure recommendations: +* [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) + +A Chinese post about Package-Oriented-Design guidelines and Architecture layer +* [面向包的设计和架构分层](https://github.com/danceyoung/paper-code/blob/master/package-oriented-design/packageorienteddesign.md) + +## Go Directories + +### `/cmd` + +Main applications for this project. + +The directory name for each application should match the name of the executable you want to have (e.g., `/cmd/myapp`). + +Don't put a lot of code in the application directory. If you think the code can be imported and used in other projects, then it should live in the `/pkg` directory. If the code is not reusable or if you don't want others to reuse it, put that code in the `/internal` directory. You'll be surprised what others will do, so be explicit about your intentions! + +It's common to have a small `main` function that imports and invokes the code from the `/internal` and `/pkg` directories and nothing else. + +See the [`/cmd`](cmd/README.md) directory for examples. + +### `/internal` + +Private application and library code. This is the code you don't want others importing in their applications or libraries. Note that this layout pattern is enforced by the Go compiler itself. See the Go 1.4 [`release notes`](https://golang.org/doc/go1.4#internalpackages) for more details. Note that you are not limited to the top level `internal` directory. You can have more than one `internal` directory at any level of your project tree. + +You can optionally add a bit of extra structure to your internal packages to separate your shared and non-shared internal code. It's not required (especially for smaller projects), but it's nice to have visual clues showing the intended package use. Your actual application code can go in the `/internal/app` directory (e.g., `/internal/app/myapp`) and the code shared by those apps in the `/internal/pkg` directory (e.g., `/internal/pkg/myprivlib`). + +### `/pkg` + +Library code that's ok to use by external applications (e.g., `/pkg/mypubliclib`). Other projects will import these libraries expecting them to work, so think twice before you put something here :-) Note that the `internal` directory is a better way to ensure your private packages are not importable because it's enforced by Go. The `/pkg` directory is still a good way to explicitly communicate that the code in that directory is safe for use by others. The [`I'll take pkg over internal`](https://travisjeffery.com/b/2019/11/i-ll-take-pkg-over-internal/) blog post by Travis Jeffery provides a good overview of the `pkg` and `internal` directories and when it might make sense to use them. + +It's also a way to group Go code in one place when your root directory contains lots of non-Go components and directories making it easier to run various Go tools (as mentioned in these talks: [`Best Practices for Industrial Programming`](https://www.youtube.com/watch?v=PTE4VJIdHPg) from GopherCon EU 2018, [GopherCon 2018: Kat Zien - How Do You Structure Your Go Apps](https://www.youtube.com/watch?v=oL6JBUk6tj0) and [GoLab 2018 - Massimiliano Pippi - Project layout patterns in Go](https://www.youtube.com/watch?v=3gQa1LWwuzk)). + +See the [`/pkg`](pkg/README.md) directory if you want to see which popular Go repos use this project layout pattern. This is a common layout pattern, but it's not universally accepted and some in the Go community don't recommend it. + +It's ok not to use it if your app project is really small and where an extra level of nesting doesn't add much value (unless you really want to :-)). Think about it when it's getting big enough and your root directory gets pretty busy (especially if you have a lot of non-Go app components). + +The `pkg` directory origins: The old Go source code used to use `pkg` for its packages and then various Go projects in the community started copying the pattern (see [`this`](https://twitter.com/bradfitz/status/1039512487538970624) Brad Fitzpatrick's tweet for more context). + +### `/vendor` + +Application dependencies (managed manually or by your favorite dependency management tool like the new built-in [`Go Modules`](https://github.com/golang/go/wiki/Modules) feature). The `go mod vendor` command will create the `/vendor` directory for you. Note that you might need to add the `-mod=vendor` flag to your `go build` command if you are not using Go 1.14 where it's on by default. + +Don't commit your application dependencies if you are building a library. + +Note that since [`1.13`](https://golang.org/doc/go1.13#modules) Go also enabled the module proxy feature (using [`https://proxy.golang.org`](https://proxy.golang.org) as their module proxy server by default). Read more about it [`here`](https://blog.golang.org/module-mirror-launch) to see if it fits all of your requirements and constraints. If it does, then you won't need the `vendor` directory at all. + +## Service Application Directories + +### `/api` + +OpenAPI/Swagger specs, JSON schema files, protocol definition files. + +See the [`/api`](api/README.md) directory for examples. + +## Web Application Directories + +### `/web` + +Web application specific components: static web assets, server side templates and SPAs. + +## Common Application Directories + +### `/configs` + +Configuration file templates or default configs. + +Put your `confd` or `consul-template` template files here. + +### `/init` + +System init (systemd, upstart, sysv) and process manager/supervisor (runit, supervisord) configs. + +### `/scripts` + +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)). + +See the [`/scripts`](scripts/README.md) directory for examples. + +### `/build` + +Packaging and Continuous Integration. + +Put your cloud (AMI), container (Docker), OS (deb, rpm, pkg) package configurations and scripts in the `/build/package` directory. + +Put your CI (travis, circle, drone) configurations and scripts in the `/build/ci` directory. Note that some of the CI tools (e.g., Travis CI) are very picky about the location of their config files. Try putting the config files in the `/build/ci` directory linking them to the location where the CI tools expect them (when possible). + +### `/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`. + +### `/test` + +Additional external test apps and test data. Feel free to structure the `/test` directory anyway you want. For bigger projects it makes sense to have a data subdirectory. For example, you can have `/test/data` or `/test/testdata` if you need Go to ignore what's in that directory. Note that Go will also ignore directories or files that begin with "." or "_", so you have more flexibility in terms of how you name your test data directory. + +See the [`/test`](test/README.md) directory for examples. + +## Other Directories + +### `/docs` + +Design and user documents (in addition to your godoc generated documentation). + +See the [`/docs`](docs/README.md) directory for examples. + +### `/tools` + +Supporting tools for this project. Note that these tools can import code from the `/pkg` and `/internal` directories. + +See the [`/tools`](tools/README.md) directory for examples. + +### `/examples` + +Examples for your applications and/or public libraries. + +See the [`/examples`](examples/README.md) directory for examples. + +### `/third_party` + +External helper tools, forked code and other 3rd party utilities (e.g., Swagger UI). + +### `/githooks` + +Git hooks. + +### `/assets` + +Other assets to go along with your repository (images, logos, etc). + +### `/website` + +This is the place to put your project's website data if you are not using GitHub pages. + +See the [`/website`](website/README.md) directory for examples. + +## Directories You Shouldn't Have + +### `/src` + +Some Go projects do have a `src` folder, but it usually happens when the devs came from the Java world where it's a common pattern. If you can help yourself try not to adopt this Java pattern. You really don't want your Go code or Go projects to look like Java :-) + +Don't confuse the project level `/src` directory with the `/src` directory Go uses for its workspaces as described in [`How to Write Go Code`](https://golang.org/doc/code.html). The `$GOPATH` environment variable points to your (current) workspace (by default it points to `$HOME/go` on non-windows systems). This workspace includes the top level `/pkg`, `/bin` and `/src` directories. Your actual project ends up being a sub-directory under `/src`, so if you have the `/src` directory in your project the project path will look like this: `/some/path/to/workspace/src/your_project/src/your_code.go`. Note that with Go 1.11 it's possible to have your project outside of your `GOPATH`, but it still doesn't mean it's a good idea to use this layout pattern. + + +## Badges + +* [Go Report Card](https://goreportcard.com/) - It will scan your code with `gofmt`, `go vet`, `gocyclo`, `golint`, `ineffassign`, `license` and `misspell`. Replace `github.com/golang-standards/project-layout` with your project reference. + + [![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) - It will provide online version of your GoDoc generated documentation. Change the link to point to your project.~~ + + [![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). + + [![PkgGoDev](https://pkg.go.dev/badge/github.com/golang-standards/project-layout)](https://pkg.go.dev/github.com/golang-standards/project-layout) + +* Release - It will show the latest release number for your project. Change the github link to point to your project. + + [![Release](https://img.shields.io/github/release/golang-standards/project-layout.svg?style=flat-square)](https://github.com/golang-standards/project-layout/releases/latest) + +## Notes + +A more opinionated project template with sample/reusable configs, scripts and code is a WIP. From 275568c7e23255c93a842a49fd3bf0445d309f81 Mon Sep 17 00:00:00 2001 From: Rostislav Pylypiv Date: Fri, 9 Dec 2022 14:20:16 +0200 Subject: [PATCH 56/76] Added new translation to all README files --- README.md | 1 + README_es.md | 1 + README_fr.md | 1 + README_it.md | 1 + README_ja.md | 1 + README_ko.md | 1 + README_ptBR.md | 1 + README_ro.md | 1 + README_ru.md | 1 + README_tr.md | 1 + README_ua.md | 2 +- README_zh-CN.md | 1 + README_zh-TW.md | 1 + README_zh.md | 1 + 14 files changed, 14 insertions(+), 1 deletion(-) diff --git a/README.md b/README.md index 09f238d..fa73909 100644 --- a/README.md +++ b/README.md @@ -13,6 +13,7 @@ Translations: * [Română](README_ro.md) * [Русский](README_ru.md) * [Türkçe](README_tr.md) +* [Українська](README_ua.md) ## Overview diff --git a/README_es.md b/README_es.md index d96eb20..d0c457d 100644 --- a/README_es.md +++ b/README_es.md @@ -14,6 +14,7 @@ Traducciones: * [Română](README_ro.md) * [Русский](README_ru.md) * [Türkçe](README_tr.md) +* [Українська](README_ua.md) ## Resumen diff --git a/README_fr.md b/README_fr.md index 530bc5c..8355121 100644 --- a/README_fr.md +++ b/README_fr.md @@ -14,6 +14,7 @@ Traductions: * [Română](README_ro.md) * [Русский](README_ru.md) * [Türkçe](README_tr.md) +* [Українська](README_ua.md) ## Introduction diff --git a/README_it.md b/README_it.md index e271d8c..ce826b3 100644 --- a/README_it.md +++ b/README_it.md @@ -13,6 +13,7 @@ Traduzioni: * [Română](README_ro.md) * [Русский](README_ru.md) * [Türkçe](README_tr.md) +* [Українська](README_ua.md) ## Panoramica diff --git a/README_ja.md b/README_ja.md index d4882a2..c969a2d 100644 --- a/README_ja.md +++ b/README_ja.md @@ -14,6 +14,7 @@ * [Română](README_ro.md) * [Русский](README_ru.md) * [Türkçe](README_tr.md) +* [Українська](README_ua.md) ## 概要 diff --git a/README_ko.md b/README_ko.md index f2c557c..cd3aba6 100644 --- a/README_ko.md +++ b/README_ko.md @@ -14,6 +14,7 @@ * [Română](README_ro.md) * [Русский](README_ru.md) * [Türkçe](README_tr.md) +* [Українська](README_ua.md) ## 개요 diff --git a/README_ptBR.md b/README_ptBR.md index 80b9e8c..2ee1fb7 100644 --- a/README_ptBR.md +++ b/README_ptBR.md @@ -14,6 +14,7 @@ Traduções: * [Română](README_ro.md) * [Русский](README_ru.md) * [Türkçe](README_tr.md) +* [Українська](README_ua.md) ## Visão geral diff --git a/README_ro.md b/README_ro.md index 0078d41..f34ae34 100644 --- a/README_ro.md +++ b/README_ro.md @@ -14,6 +14,7 @@ Traduceri: * [Română](README_ro.md) * [Русский](README_ru.md) * [Türkçe](README_tr.md) +* [Українська](README_ua.md) ## General diff --git a/README_ru.md b/README_ru.md index 76efb72..0ed558b 100755 --- a/README_ru.md +++ b/README_ru.md @@ -14,6 +14,7 @@ Translations: * [Română](README_ro.md) * [Русский](README_ru.md) * [Türkçe](README_tr.md) +* [Українська](README_ua.md) ## Overview diff --git a/README_tr.md b/README_tr.md index 877850b..d049718 100644 --- a/README_tr.md +++ b/README_tr.md @@ -14,6 +14,7 @@ * [Română](README_ro.md) * [Русский](README_ru.md) * [Türkçe](README_tr.md) +* [Українська](README_ua.md) ## Genel Bakış: diff --git a/README_ua.md b/README_ua.md index 29388ac..fa73909 100644 --- a/README_ua.md +++ b/README_ua.md @@ -13,7 +13,7 @@ Translations: * [Română](README_ro.md) * [Русский](README_ru.md) * [Türkçe](README_tr.md) -* [Українська] (README_ua.md) +* [Українська](README_ua.md) ## Overview diff --git a/README_zh-CN.md b/README_zh-CN.md index 7604e1c..d8e50f9 100644 --- a/README_zh-CN.md +++ b/README_zh-CN.md @@ -12,6 +12,7 @@ * [Română](README_ro.md) * [Русский](README_ru.md) * [Türkçe](README_tr.md) +* [Українська](README_ua.md) 这是Go应用程序项目的基础布局。这不是Go核心开发团队定义的官方标准；无论是在经典项目还是在新兴的项目中，这都是Go生态系统中一组常见的项目布局模式。这其中有一些模式比另外的一些更受欢迎。它通过几个支撑目录为任何足够大规模的实际应用程序提供一些增强功能。 diff --git a/README_zh-TW.md b/README_zh-TW.md index 8c29708..761e365 100644 --- a/README_zh-TW.md +++ b/README_zh-TW.md @@ -14,6 +14,7 @@ * [Română](README_ro.md) * [Русский](README_ru.md) * [Türkçe](README_tr.md) +* [Українська](README_ua.md) 這是 Go 應用程式專案的基本目錄結構。它不是核心 Go 開發團隊定義的官方標準；然而，它是 Go 生態系統中一組常見的老專案和新專案的目錄結構。其中一些目錄結構比其他目錄結構更受歡迎。這個專案目錄結構還有一些細微的改進，可以支援任何大型且實用的應用程式目錄結構。 diff --git a/README_zh.md b/README_zh.md index 9257976..7ee4831 100644 --- a/README_zh.md +++ b/README_zh.md @@ -14,6 +14,7 @@ * [Română](README_ro.md) * [Русский](README_ru.md) * [Türkçe](README_tr.md) +* [Українська](README_ua.md) 这是 Go 应用程序项目的基本布局。它不是核心 Go 开发团队定义的官方标准；然而，它是 Go 生态系统中一组常见的老项目和新项目的布局模式。其中一些模式比其他模式更受欢迎。它还具有许多小的增强，以及对任何足够大的实际应用程序通用的几个支持目录。 From be5ef492b4883c47346cf3e7f9bb43edfec77a56 Mon Sep 17 00:00:00 2001 From: Rostislav Pylypiv Date: Sun, 11 Dec 2022 17:02:20 +0200 Subject: [PATCH 57/76] Translated to 128 string --- README_ru.md | 2 +- README_ua.md | 82 ++++++++++++++++++++++++++-------------------------- 2 files changed, 42 insertions(+), 42 deletions(-) diff --git a/README_ru.md b/README_ru.md index 0ed558b..7facec6 100755 --- a/README_ru.md +++ b/README_ru.md @@ -14,7 +14,7 @@ Translations: * [Română](README_ro.md) * [Русский](README_ru.md) * [Türkçe](README_tr.md) -* [Українська](README_ua.md) +* [Українська](README_ua.md) ## Overview diff --git a/README_ua.md b/README_ua.md index fa73909..a90099a 100644 --- a/README_ua.md +++ b/README_ua.md @@ -15,117 +15,117 @@ Translations: * [Türkçe](README_tr.md) * [Українська](README_ua.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. +Це базовий макет для проєктів Go-додатків. Це **`не є офіційним стандартом, визначеним командою розробників Go`**; тим не менш, це звід паттернів програмування в екосистемі Go, що склалися історично. Деякі з цих паттернів більш популярні та відомі ніж інші. Також в цьому макеті є декілька покращень, в тому числі декілька додаткових дерикторій, що використовуються в будь-якому достатньо великому реальному застосунку. -**`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. +**`Якщо ви тільки вивчаєте Go або створюєте якийсь демонстраційний чи простий проєкт для себе цей макет буде занадто складним. Почність з чогось дійсно простого (одного файлу `main.go` та `go.mod` буде достатньо).`** Коли проєкт почне рости не забувайте, важливо щоб код залишався добре структурованим, інакше ви отримаєте брудний код з великою кількістю прихованих залежностей та глобальних станів. Коли над проектом працює більше людей, вам знадобиться ще більше структури. Саме тоді важливо запровадити єдиний спосіб управління пакетами/бібліотеками. Коли ви маєте проект з відкритим вихідним кодом або коли ви знаєте, що інші проекти імпортують код з вашого репозиторію проекту, саме тоді важливо мати приватні (`internal`) пакети та код. Клонуйте сховище, зберігайте те, що вам потрібно, а все інше видаляйте! Те, що це є, не означає, що ви повинні використовувати все це. Жодна з цих моделей не використовується в кожному окремому проекті. Навіть паттерн `vendor` не є універсальним. -With Go 1.14 [`Go Modules`](https://github.com/golang/go/wiki/Modules) are finally ready for production. Use [`Go Modules`](https://blog.golang.org/using-go-modules) unless you have a specific reason not to use them and if you do then you don’t need to worry about $GOPATH and where you put your project. The basic `go.mod` file in the repo assumes your project is hosted on GitHub, but it's not a requirement. The module path can be anything though the first module path component should have a dot in its name (the current version of Go doesn't enforce it anymore, but if you are using slightly older versions don't be surprised if your builds fail without it). See Issues [`37554`](https://github.com/golang/go/issues/37554) and [`32819`](https://github.com/golang/go/issues/32819) if you want to know more about it. +Починаючи з 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). -This project layout is intentionally generic and it doesn't try to impose a specific Go package structure. +Ця схема проекту є навмисно загальною і не намагається нав'язати конкретну структуру пакета Go. -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: +IЯкщо вам потрібна допомога з іменуванням, форматуванням та стилем, почніть з запуску [`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) -See [`Go Project Layout`](https://medium.com/golang-learn/go-project-layout-e5213cdcfaa2) for additional background information. +Дивіться [`Go Project Layout`](https://medium.com/golang-learn/go-project-layout-e5213cdcfaa2) для додаткової довідкової інформації. -More about naming and organizing packages as well as other code structure recommendations: +Більше про іменування та організацію пакетів, а також інші рекомендації щодо структури коду: * [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) -A Chinese post about Package-Oriented-Design guidelines and Architecture layer +Китайська публікація про керівні принципи пакетно-орієнтованого проектування та рівень архітектури * [面向包的设计和架构分层](https://github.com/danceyoung/paper-code/blob/master/package-oriented-design/packageorienteddesign.md) -## Go Directories +## Go каталоги ### `/cmd` -Main applications for this project. +Головні застосунки цього проєкту -The directory name for each application should match the name of the executable you want to have (e.g., `/cmd/myapp`). +Ім'я каталогу для кожного додатка повинно збігатися з ім'ям виконуваного файлу, який ви хочете мати (наприклад `/cmd/myapp`). -Don't put a lot of code in the application directory. If you think the code can be imported and used in other projects, then it should live in the `/pkg` directory. If the code is not reusable or if you don't want others to reuse it, put that code in the `/internal` directory. You'll be surprised what others will do, so be explicit about your intentions! +Не розміщуйте багато коду в каталозі програми. Якщо ви вважаєте, що код може бути імпортований і використаний в інших проектах, то він повинен знаходитися в каталозі `/pkg`. Якщо код не може бути використаний повторно або якщо ви не хочете, щоб інші використовували його повторно, помістіть цей код в каталог `/internal`. Ви будете здивовані тим, що будуть робити інші, тому будьте відверті у своїх намірах! -It's common to have a small `main` function that imports and invokes the code from the `/internal` and `/pkg` directories and nothing else. +Зазвичай є невелика функція `main`, яка імпортує та викликає код з каталогів `/internal` та `/pkg` і нічого більше. -See the [`/cmd`](cmd/README.md) directory for examples. +Дивіться [`/cmd`](cmd/README.md) для прикладів. ### `/internal` -Private application and library code. This is the code you don't want others importing in their applications or libraries. Note that this layout pattern is enforced by the Go compiler itself. See the Go 1.4 [`release notes`](https://golang.org/doc/go1.4#internalpackages) for more details. Note that you are not limited to the top level `internal` directory. You can have more than one `internal` directory at any level of your project tree. +Приватний код додатків та бібліотек. Це код, який ви не хочете, щоб інші імпортували у свої програми або бібліотеки. Зауважте, що цей шаблон компонування забезпечується самим компілятором Go. Дивіться Go 1.4 [`release notes`](https://golang.org/doc/go1.4#internalpackages) для додаткових деталей. Зверніть увагу, що ви не обмежені директорією `internal` верхнього рівня. Ви можете мати більше одного каталогу `internal` на будь-якому рівні дерева вашого проекту. -You can optionally add a bit of extra structure to your internal packages to separate your shared and non-shared internal code. It's not required (especially for smaller projects), but it's nice to have visual clues showing the intended package use. Your actual application code can go in the `/internal/app` directory (e.g., `/internal/app/myapp`) and the code shared by those apps in the `/internal/pkg` directory (e.g., `/internal/pkg/myprivlib`). +За бажанням ви можете додати трохи додаткової структури до ваших внутрішніх пакунків, щоб відокремити ваш спільний і не спільний внутрішній код. Це не є обов'язковим (особливо для невеликих проектів), але приємно мати візуальні підказки, що показують передбачуване використання пакунків. Ваш власне код програми може знаходитися у каталозі `/internal/app` (наприклад, `/internal/app/myapp`), а код, який використовується спільно з іншими програмами, у каталозі `/internal/pkg` (наприклад, `/internal/pkg/myprivlib`). ### `/pkg` -Library code that's ok to use by external applications (e.g., `/pkg/mypubliclib`). Other projects will import these libraries expecting them to work, so think twice before you put something here :-) Note that the `internal` directory is a better way to ensure your private packages are not importable because it's enforced by Go. The `/pkg` directory is still a good way to explicitly communicate that the code in that directory is safe for use by others. The [`I'll take pkg over internal`](https://travisjeffery.com/b/2019/11/i-ll-take-pkg-over-internal/) blog post by Travis Jeffery provides a good overview of the `pkg` and `internal` directories and when it might make sense to use them. +Код бібліотеки, який можна використовувати зовнішніми програмами (наприклад, `/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` і того, коли може мати сенс їх використання. -It's also a way to group Go code in one place when your root directory contains lots of non-Go components and directories making it easier to run various Go tools (as mentioned in these talks: [`Best Practices for Industrial Programming`](https://www.youtube.com/watch?v=PTE4VJIdHPg) from GopherCon EU 2018, [GopherCon 2018: Kat Zien - How Do You Structure Your Go Apps](https://www.youtube.com/watch?v=oL6JBUk6tj0) and [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)). -See the [`/pkg`](pkg/README.md) directory if you want to see which popular Go repos use this project layout pattern. This is a common layout pattern, but it's not universally accepted and some in the Go community don't recommend it. +Якщо ви хочете побачити, які популярні репозиторії Go використовують цей шаблон оформлення проектів, зверніться до каталогу [`/pkg`](pkg/README.md). Це загальноприйнятий шаблон, але він не є загальноприйнятим, і дехто у спільноті Go не рекомендує його використовувати. -It's ok not to use it if your app project is really small and where an extra level of nesting doesn't add much value (unless you really want to :-)). Think about it when it's getting big enough and your root directory gets pretty busy (especially if you have a lot of non-Go app components). +Можна не використовувати його, якщо ваш проект програми дійсно невеликий і де додатковий рівень вкладеності не додає особливої цінності (якщо тільки ви дійсно цього не хочете :-)). Подумайте про це, коли він стане досить великим і ваш кореневий каталог буде досить зайнятий (особливо якщо у вас багато компонентів програми, які не є Go). -The `pkg` directory origins: The old Go source code used to use `pkg` for its packages and then various Go projects in the community started copying the pattern (see [`this`](https://twitter.com/bradfitz/status/1039512487538970624) Brad Fitzpatrick's tweet for more context). +Походження каталогу `pkg`: старий вихідний код Go використовував `pkg` для своїх пакунків, а потім різні проекти Go у спільноті почали копіювати цей шаблон (див. [`це`] (https://twitter.com/bradfitz/status/1039512487538970624) твіт Бреда Фіцпатріка для більш детального контексту). ### `/vendor` -Application dependencies (managed manually or by your favorite dependency management tool like the new built-in [`Go Modules`](https://github.com/golang/go/wiki/Modules) feature). The `go mod vendor` command will create the `/vendor` directory for you. Note that you might need to add the `-mod=vendor` flag to your `go build` command if you are not using Go 1.14 where it's on by default. +Залежності додатків (управляються вручну або за допомогою вашого улюбленого інструменту управління залежностями, наприклад, нової вбудованої функції [`Go модулі`] (https://github.com/golang/go/wiki/Modules)). Команда `go mod vendor` створить для вас каталог `/vendor`. Зауважте, що вам може знадобитися додати прапорець `-mod=vendor` до команди `go build`, якщо ви не використовуєте Go 1.14, де він увімкнений за замовчуванням. -Don't commit your application dependencies if you are building a library. +Не фіксуйте залежності програми, якщо ви створюєте бібліотеку. -Note that since [`1.13`](https://golang.org/doc/go1.13#modules) Go also enabled the module proxy feature (using [`https://proxy.golang.org`](https://proxy.golang.org) as their module proxy server by default). Read more about it [`here`](https://blog.golang.org/module-mirror-launch) to see if it fits all of your requirements and constraints. If it does, then you won't need the `vendor` directory at all. +Зверніть увагу, що починаючи з [`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` вам взагалі не знадобиться. -## Service Application Directories +## Каталоги сервісних додатків ### `/api` -OpenAPI/Swagger specs, JSON schema files, protocol definition files. +Специфікації OpenAPI/Swagger, файли схем JSON, файли визначення протоколів. -See the [`/api`](api/README.md) directory for examples. +Приклади див. у каталозі [`/api`](api/README.md). -## Web Application Directories +## Каталоги веб-додатків ### `/web` -Web application specific components: static web assets, server side templates and SPAs. +Специфічні компоненти веб-додатків: статичні веб-активи, шаблони на стороні сервера та односторінкові застосунки. -## Common Application Directories +## Загальні директорії додатків ### `/configs` -Configuration file templates or default configs. +Шаблони файлів конфігурації або конфігурації за замовчуванням. -Put your `confd` or `consul-template` template files here. +Сюди викладіть файли шаблонів `confd` або `consul-template`. ### `/init` -System init (systemd, upstart, sysv) and process manager/supervisor (runit, supervisord) configs. +Конфігурації системного запуску (systemd, upstart, sysv) та диспетчера/супервізора процесів (runit, supervisord). ### `/scripts` -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)). +Ці скрипти роблять Makefile кореневого рівня невеликим і простим (наприклад, [`https://github.com/hashicorp/terraform/blob/master/Makefile`](https://github.com/hashicorp/terraform/blob/master/Makefile)). -See the [`/scripts`](scripts/README.md) directory for examples. +Приклади див. у каталозі [`/scripts`](scripts/README.md). ### `/build` -Packaging and Continuous Integration. +Упаковка та безперервна інтеграція (CI). -Put your cloud (AMI), container (Docker), OS (deb, rpm, pkg) package configurations and scripts in the `/build/package` directory. +Конфігурації хмарних (AMI), контейнерних (Docker), ОС (deb, rpm, pkg) пакетів та скрипти покладіть в каталог `/build/package`. -Put your CI (travis, circle, drone) configurations and scripts in the `/build/ci` directory. Note that some of the CI tools (e.g., Travis CI) are very picky about the location of their config files. Try putting the config files in the `/build/ci` directory linking them to the location where the CI tools expect them (when possible). +Помістіть конфігурації та скрипти CI (travis, circle, drone) в каталог `/build/ci`. Зверніть увагу, що деякі інструменти CI (наприклад, Travis CI) дуже прискіпливі до розташування своїх конфігураційних файлів. Спробуйте помістити конфігураційні файли в каталог `/build/ci`, пов'язавши їх з тим місцем, де їх очікують інструменти CI (коли це можливо). ### `/deployments` From dee1f6093440ae211de3e4fec13f2120d17d03d6 Mon Sep 17 00:00:00 2001 From: Rostislav Pylypiv Date: Wed, 14 Dec 2022 10:49:30 +0200 Subject: [PATCH 58/76] Translated up to string 185 --- README_ua.md | 34 +++++++++++++++++----------------- 1 file changed, 17 insertions(+), 17 deletions(-) diff --git a/README_ua.md b/README_ua.md index a90099a..16b6872 100644 --- a/README_ua.md +++ b/README_ua.md @@ -129,59 +129,59 @@ IЯкщо вам потрібна допомога з іменуванням, ф ### `/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, системної та контейнерної оркестрації (docker-compose, kubernetes/helm, mesos, terraform, bosh). Зверніть увагу, що в деяких репозиторіях (особливо для додатків, що розгортаються за допомогою kubernetes) цей каталог називається `/deploy`. ### `/test` -Additional external test apps and test data. Feel free to structure the `/test` directory anyway you want. For bigger projects it makes sense to have a data subdirectory. For example, you can have `/test/data` or `/test/testdata` if you need Go to ignore what's in that directory. Note that Go will also ignore directories or files that begin with "." or "_", so you have more flexibility in terms of how you name your test data directory. +Додаткові зовнішні тестові програми та тестові дані. Не соромтеся структурувати каталог `/test` як завгодно. Для великих проектів має сенс мати підкаталог даних. Наприклад, ви можете мати `/test/data` або `/test/testdata`, якщо вам потрібно, щоб команда Go ігнорувала те, що знаходиться в цьому каталозі. Зауважте, що Go також ігноруватиме каталоги або файли, які починаються з "." або "_", тому у вас є більше гнучкості в плані того, як ви можете назвати свій каталог тестових даних. -See the [`/test`](test/README.md) directory for examples. +Приклади дивіться у каталозі [`/test`](test/README.md). ## Other Directories ### `/docs` -Design and user documents (in addition to your godoc generated documentation). +Проектна та користувацька документація (на додаток до вашої документації, згенерованої в godoc). -See the [`/docs`](docs/README.md) directory for examples. +Приклади дивіться у каталозі [`/docs`](docs/README.md). ### `/tools` -Supporting tools for this project. Note that these tools can import code from the `/pkg` and `/internal` directories. +Допоміжні інструменти для цього проекту. Зверніть увагу, що ці інструменти можуть імпортувати код з каталогів `/pkg` та `/internal`. -See the [`/tools`](tools/README.md) directory for examples. +Приклади дивіться у каталозі [`/tools`](tools/README.md). ### `/examples` -Examples for your applications and/or public libraries. +Приклади для ваших додатків та/або публічних бібліотек. -See the [`/examples`](examples/README.md) directory for examples. +Приклади дивіться у каталозі [`/examples`](examples/README.md). ### `/third_party` -External helper tools, forked code and other 3rd party utilities (e.g., Swagger UI). +Зовнішні допоміжні інструменти, форкований код та інші утиліти сторонніх розробників (наприклад, Swagger UI). ### `/githooks` -Git hooks. +Скріпти (хуки) Git. ### `/assets` -Other assets to go along with your repository (images, logos, etc). +Інші ресурси, які будуть супроводжувати ваш репозиторій (зображення, логотипи тощо). ### `/website` -This is the place to put your project's website data if you are not using GitHub pages. +Це місце для розміщення даних сайту вашого проекту, якщо ви не використовуєте GitHub Pages. -See the [`/website`](website/README.md) directory for examples. +Приклади дивіться у каталозі [`/website`](website/README.md). -## Directories You Shouldn't Have +## Директорії, яких у вас не має бути ### `/src` -Some Go projects do have a `src` folder, but it usually happens when the devs came from the Java world where it's a common pattern. If you can help yourself try not to adopt this Java pattern. You really don't want your Go code or Go projects to look like Java :-) +Деякі проекти Go мають папку `src`, але це зазвичай трапляється, коли розробники прийшли зі світу Java, де це є поширеним шаблоном. Намагайтеся не використовувати цей патерн Java. Ви ж не хочете, щоб ваш Go код або Go проекти виглядали як Java :-) -Don't confuse the project level `/src` directory with the `/src` directory Go uses for its workspaces as described in [`How to Write Go Code`](https://golang.org/doc/code.html). The `$GOPATH` environment variable points to your (current) workspace (by default it points to `$HOME/go` on non-windows systems). This workspace includes the top level `/pkg`, `/bin` and `/src` directories. Your actual project ends up being a sub-directory under `/src`, so if you have the `/src` directory in your project the project path will look like this: `/some/path/to/workspace/src/your_project/src/your_code.go`. Note that with Go 1.11 it's possible to have your project outside of your `GOPATH`, but it still doesn't mean it's a good idea to use this layout pattern. +Не плутайте каталог `/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`, але це ще не означає, що це гарна ідея використовувати цей шаблон компонування. ## Badges From 93f9b19413bb1cb20adf1b17d4f79e46ebc5446f Mon Sep 17 00:00:00 2001 From: Rostislav Pylypiv Date: Wed, 14 Dec 2022 10:58:24 +0200 Subject: [PATCH 59/76] Translation compleated --- README_ua.md | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/README_ua.md b/README_ua.md index 16b6872..d7fe144 100644 --- a/README_ua.md +++ b/README_ua.md @@ -186,22 +186,22 @@ IЯкщо вам потрібна допомога з іменуванням, ф ## Badges -* [Go Report Card](https://goreportcard.com/) - It will scan your code with `gofmt`, `go vet`, `gocyclo`, `golint`, `ineffassign`, `license` and `misspell`. Replace `github.com/golang-standards/project-layout` with your project reference. +* [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) - It will provide online version of your GoDoc generated documentation. Change the link to point to your project.~~ +* ~~[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 - It will show the latest release number for your project. Change the github link to point to your project. +* Реліз - покаже номер останнього релізу для вашого проекту. Змініть посилання на 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) -## Notes +## Нотатки -A more opinionated project template with sample/reusable configs, scripts and code is a WIP. +Більш розгорнутий шаблон проекту зі зразками/багаторазовими конфігураціями, скриптами та кодом - це WIP. From 0036211c5573d5ff32ada65ce89b5329691451dc Mon Sep 17 00:00:00 2001 From: Rostislav Pylypiv Date: Wed, 14 Dec 2022 11:05:03 +0200 Subject: [PATCH 60/76] Updated word project to new grammar rules --- README_ua.md | 40 ++++++++++++++++++++-------------------- 1 file changed, 20 insertions(+), 20 deletions(-) diff --git a/README_ua.md b/README_ua.md index d7fe144..b162927 100644 --- a/README_ua.md +++ b/README_ua.md @@ -19,11 +19,11 @@ Translations: Це базовий макет для проєктів Go-додатків. Це **`не є офіційним стандартом, визначеним командою розробників Go`**; тим не менш, це звід паттернів програмування в екосистемі Go, що склалися історично. Деякі з цих паттернів більш популярні та відомі ніж інші. Також в цьому макеті є декілька покращень, в тому числі декілька додаткових дерикторій, що використовуються в будь-якому достатньо великому реальному застосунку. -**`Якщо ви тільки вивчаєте Go або створюєте якийсь демонстраційний чи простий проєкт для себе цей макет буде занадто складним. Почність з чогось дійсно простого (одного файлу `main.go` та `go.mod` буде достатньо).`** Коли проєкт почне рости не забувайте, важливо щоб код залишався добре структурованим, інакше ви отримаєте брудний код з великою кількістю прихованих залежностей та глобальних станів. Коли над проектом працює більше людей, вам знадобиться ще більше структури. Саме тоді важливо запровадити єдиний спосіб управління пакетами/бібліотеками. Коли ви маєте проект з відкритим вихідним кодом або коли ви знаєте, що інші проекти імпортують код з вашого репозиторію проекту, саме тоді важливо мати приватні (`internal`) пакети та код. Клонуйте сховище, зберігайте те, що вам потрібно, а все інше видаляйте! Те, що це є, не означає, що ви повинні використовувати все це. Жодна з цих моделей не використовується в кожному окремому проекті. Навіть паттерн `vendor` не є універсальним. +**`Якщо ви тільки вивчаєте 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 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. +Ця схема проєкту є навмисно загальною і не намагається нав'язати конкретну структуру пакета Go. Це зусилля спільноти. Відкрийте тему, якщо ви бачите новий шаблон або якщо ви вважаєте, що один з існуючих шаблонів потребує оновлення. @@ -42,7 +42,7 @@ IЯкщо вам потрібна допомога з іменуванням, ф * [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 каталоги @@ -53,7 +53,7 @@ IЯкщо вам потрібна допомога з іменуванням, ф Ім'я каталогу для кожного додатка повинно збігатися з ім'ям виконуваного файлу, який ви хочете мати (наприклад `/cmd/myapp`). -Не розміщуйте багато коду в каталозі програми. Якщо ви вважаєте, що код може бути імпортований і використаний в інших проектах, то він повинен знаходитися в каталозі `/pkg`. Якщо код не може бути використаний повторно або якщо ви не хочете, щоб інші використовували його повторно, помістіть цей код в каталог `/internal`. Ви будете здивовані тим, що будуть робити інші, тому будьте відверті у своїх намірах! +Не розміщуйте багато коду в каталозі програми. Якщо ви вважаєте, що код може бути імпортований і використаний в інших проєктах, то він повинен знаходитися в каталозі `/pkg`. Якщо код не може бути використаний повторно або якщо ви не хочете, щоб інші використовували його повторно, помістіть цей код в каталог `/internal`. Ви будете здивовані тим, що будуть робити інші, тому будьте відверті у своїх намірах! Зазвичай є невелика функція `main`, яка імпортує та викликає код з каталогів `/internal` та `/pkg` і нічого більше. @@ -61,21 +61,21 @@ IЯкщо вам потрібна допомога з іменуванням, ф ### `/internal` -Приватний код додатків та бібліотек. Це код, який ви не хочете, щоб інші імпортували у свої програми або бібліотеки. Зауважте, що цей шаблон компонування забезпечується самим компілятором Go. Дивіться Go 1.4 [`release notes`](https://golang.org/doc/go1.4#internalpackages) для додаткових деталей. Зверніть увагу, що ви не обмежені директорією `internal` верхнього рівня. Ви можете мати більше одного каталогу `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`). +За бажанням ви можете додати трохи додаткової структури до ваших внутрішніх пакунків, щоб відокремити ваш спільний і не спільний внутрішній код. Це не є обов'язковим (особливо для невеликих проєктів), але приємно мати візуальні підказки, що показують передбачуване використання пакунків. Ваш власне код програми може знаходитися у каталозі `/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` і того, коли може мати сенс їх використання. +Код бібліотеки, який можна використовувати зовнішніми програмами (наприклад, `/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`](pkg/README.md). Це загальноприйнятий шаблон, але він не є загальноприйнятим, і дехто у спільноті Go не рекомендує його використовувати. -Можна не використовувати його, якщо ваш проект програми дійсно невеликий і де додатковий рівень вкладеності не додає особливої цінності (якщо тільки ви дійсно цього не хочете :-)). Подумайте про це, коли він стане досить великим і ваш кореневий каталог буде досить зайнятий (особливо якщо у вас багато компонентів програми, які не є Go). +Можна не використовувати його, якщо ваш проєкт програми дійсно невеликий і де додатковий рівень вкладеності не додає особливої цінності (якщо тільки ви дійсно цього не хочете :-)). Подумайте про це, коли він стане досить великим і ваш кореневий каталог буде досить зайнятий (особливо якщо у вас багато компонентів програми, які не є Go). -Походження каталогу `pkg`: старий вихідний код Go використовував `pkg` для своїх пакунків, а потім різні проекти Go у спільноті почали копіювати цей шаблон (див. [`це`] (https://twitter.com/bradfitz/status/1039512487538970624) твіт Бреда Фіцпатріка для більш детального контексту). +Походження каталогу `pkg`: старий вихідний код Go використовував `pkg` для своїх пакунків, а потім різні проєкти Go у спільноті почали копіювати цей шаблон (див. [`це`] (https://twitter.com/bradfitz/status/1039512487538970624) твіт Бреда Фіцпатріка для більш детального контексту). ### `/vendor` @@ -133,7 +133,7 @@ IЯкщо вам потрібна допомога з іменуванням, ф ### `/test` -Додаткові зовнішні тестові програми та тестові дані. Не соромтеся структурувати каталог `/test` як завгодно. Для великих проектів має сенс мати підкаталог даних. Наприклад, ви можете мати `/test/data` або `/test/testdata`, якщо вам потрібно, щоб команда Go ігнорувала те, що знаходиться в цьому каталозі. Зауважте, що Go також ігноруватиме каталоги або файли, які починаються з "." або "_", тому у вас є більше гнучкості в плані того, як ви можете назвати свій каталог тестових даних. +Додаткові зовнішні тестові програми та тестові дані. Не соромтеся структурувати каталог `/test` як завгодно. Для великих проєктів має сенс мати підкаталог даних. Наприклад, ви можете мати `/test/data` або `/test/testdata`, якщо вам потрібно, щоб команда Go ігнорувала те, що знаходиться в цьому каталозі. Зауважте, що Go також ігноруватиме каталоги або файли, які починаються з "." або "_", тому у вас є більше гнучкості в плані того, як ви можете назвати свій каталог тестових даних. Приклади дивіться у каталозі [`/test`](test/README.md). @@ -141,13 +141,13 @@ IЯкщо вам потрібна допомога з іменуванням, ф ### `/docs` -Проектна та користувацька документація (на додаток до вашої документації, згенерованої в godoc). +Проєктна та користувацька документація (на додаток до вашої документації, згенерованої в godoc). Приклади дивіться у каталозі [`/docs`](docs/README.md). ### `/tools` -Допоміжні інструменти для цього проекту. Зверніть увагу, що ці інструменти можуть імпортувати код з каталогів `/pkg` та `/internal`. +Допоміжні інструменти для цього проєкту. Зверніть увагу, що ці інструменти можуть імпортувати код з каталогів `/pkg` та `/internal`. Приклади дивіться у каталозі [`/tools`](tools/README.md). @@ -171,7 +171,7 @@ IЯкщо вам потрібна допомога з іменуванням, ф ### `/website` -Це місце для розміщення даних сайту вашого проекту, якщо ви не використовуєте GitHub Pages. +Це місце для розміщення даних сайту вашого проєкту, якщо ви не використовуєте GitHub Pages. Приклади дивіться у каталозі [`/website`](website/README.md). @@ -179,9 +179,9 @@ IЯкщо вам потрібна допомога з іменуванням, ф ### `/src` -Деякі проекти Go мають папку `src`, але це зазвичай трапляється, коли розробники прийшли зі світу Java, де це є поширеним шаблоном. Намагайтеся не використовувати цей патерн Java. Ви ж не хочете, щоб ваш Go код або Go проекти виглядали як 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/ваш_проект/src/ваш_код.go`. Зауважте, що з Go 1.11 можна мати проект поза `GOPATH`, але це ще не означає, що це гарна ідея використовувати цей шаблон компонування. +Не плутайте каталог `/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`, але це ще не означає, що це гарна ідея використовувати цей шаблон компонування. ## Badges @@ -190,7 +190,7 @@ IЯкщо вам потрібна допомога з іменуванням, ф [![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) @@ -198,10 +198,10 @@ IЯкщо вам потрібна допомога з іменуванням, ф [![PkgGoDev](https://pkg.go.dev/badge/github.com/golang-standards/project-layout)](https://pkg.go.dev/github.com/golang-standards/project-layout) -* Реліз - покаже номер останнього релізу для вашого проекту. Змініть посилання на github, щоб воно вказувало на ваш проект. +* Реліз - покаже номер останнього релізу для вашого проєкту. Змініть посилання на 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. +Більш розгорнутий шаблон проєкту зі зразками/багаторазовими конфігураціями, скриптами та кодом - це WIP. From b5abb5ce3f9110454b4bdfc6edc47639ff51632d Mon Sep 17 00:00:00 2001 From: Rostislav Pylypiv Date: Wed, 14 Dec 2022 11:16:29 +0200 Subject: [PATCH 61/76] Fixing mistakes --- README_ua.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/README_ua.md b/README_ua.md index b162927..b54fd16 100644 --- a/README_ua.md +++ b/README_ua.md @@ -1,4 +1,4 @@ -# Standard Go Project Layout +# Стандартний макет проєкту Go Translations: @@ -27,7 +27,7 @@ Translations: Це зусилля спільноти. Відкрийте тему, якщо ви бачите новий шаблон або якщо ви вважаєте, що один з існуючих шаблонів потребує оновлення. -IЯкщо вам потрібна допомога з іменуванням, форматуванням та стилем, почніть з запуску [`gofmt`](https://golang.org/cmd/gofmt/) та [`golint`](https://github.com/golang/lint). Також обов'язково ознайомтеся з цими керівними принципами та рекомендаціями щодо стилю коду 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 @@ -67,7 +67,7 @@ IЯкщо вам потрібна допомога з іменуванням, ф ### `/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` і того, коли може мати сенс їх використання. +Код бібліотеки, який можна використовувати зовнішніми програмами (наприклад, `/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)). From cc4079e70b93de5343d19077a044c13e7e1130ce Mon Sep 17 00:00:00 2001 From: Rostislav Pylypiv Date: Wed, 14 Dec 2022 11:21:50 +0200 Subject: [PATCH 62/76] Fixing mistakes 2 --- README_ua.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/README_ua.md b/README_ua.md index b54fd16..a0915b8 100644 --- a/README_ua.md +++ b/README_ua.md @@ -69,7 +69,7 @@ Translations: Код бібліотеки, який можна використовувати зовнішніми програмами (наприклад, `/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 в одному місці, коли ваш кореневий каталог містить багато не-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 не рекомендує його використовувати. From b9253a31a98977bb3b6d5b85621a9c94db24431a Mon Sep 17 00:00:00 2001 From: Rostislav Pylypiv Date: Wed, 14 Dec 2022 11:23:33 +0200 Subject: [PATCH 63/76] Fixing mistakes 3 --- README_ua.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/README_ua.md b/README_ua.md index a0915b8..ac689af 100644 --- a/README_ua.md +++ b/README_ua.md @@ -75,7 +75,7 @@ Translations: Можна не використовувати його, якщо ваш проєкт програми дійсно невеликий і де додатковий рівень вкладеності не додає особливої цінності (якщо тільки ви дійсно цього не хочете :-)). Подумайте про це, коли він стане досить великим і ваш кореневий каталог буде досить зайнятий (особливо якщо у вас багато компонентів програми, які не є Go). -Походження каталогу `pkg`: старий вихідний код Go використовував `pkg` для своїх пакунків, а потім різні проєкти Go у спільноті почали копіювати цей шаблон (див. [`це`] (https://twitter.com/bradfitz/status/1039512487538970624) твіт Бреда Фіцпатріка для більш детального контексту). +Походження каталогу `pkg`: старий вихідний код Go використовував `pkg` для своїх пакунків, а потім різні проєкти Go у спільноті почали копіювати цей шаблон (див. [`це`](https://twitter.com/bradfitz/status/1039512487538970624) твіт Бреда Фіцпатріка для більш детального контексту). ### `/vendor` From 93f39589939b2ab18a63b0aec6e481f13a3d9300 Mon Sep 17 00:00:00 2001 From: Rostislav Pylypiv Date: Wed, 14 Dec 2022 11:30:32 +0200 Subject: [PATCH 64/76] Fixing mistakes 4 in vendor --- README_ua.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/README_ua.md b/README_ua.md index ac689af..d8c1363 100644 --- a/README_ua.md +++ b/README_ua.md @@ -79,7 +79,7 @@ Translations: ### `/vendor` -Залежності додатків (управляються вручну або за допомогою вашого улюбленого інструменту управління залежностями, наприклад, нової вбудованої функції [`Go модулі`] (https://github.com/golang/go/wiki/Modules)). Команда `go mod vendor` створить для вас каталог `/vendor`. Зауважте, що вам може знадобитися додати прапорець `-mod=vendor` до команди `go build`, якщо ви не використовуєте Go 1.14, де він увімкнений за замовчуванням. +Залежності додатків (управляються вручну або за допомогою вашого улюбленого інструменту управління залежностями, наприклад, нової вбудованої функції [`Go модулі`](https://github.com/golang/go/wiki/Modules)). Команда `go mod vendor` створить для вас каталог `/vendor`. Зауважте, що вам може знадобитися додати прапорець `-mod=vendor` до команди `go build`, якщо ви не використовуєте Go 1.14, де він увімкнений за замовчуванням. Не фіксуйте залежності програми, якщо ви створюєте бібліотеку. From 007d031a7b360f7eeb51917dd35b27d3e8c60047 Mon Sep 17 00:00:00 2001 From: Rostislav Pylypiv Date: Wed, 14 Dec 2022 11:35:23 +0200 Subject: [PATCH 65/76] Fixing mistakes 4 in vendor --- README_ua.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/README_ua.md b/README_ua.md index d8c1363..ce46a19 100644 --- a/README_ua.md +++ b/README_ua.md @@ -91,7 +91,7 @@ Translations: Специфікації OpenAPI/Swagger, файли схем JSON, файли визначення протоколів. -Приклади див. у каталозі [`/api`](api/README.md). +Приклади дивіться у каталозі [`/api`](api/README.md). ## Каталоги веб-додатків @@ -137,7 +137,7 @@ Translations: Приклади дивіться у каталозі [`/test`](test/README.md). -## Other Directories +## Інші директорії ### `/docs` @@ -181,7 +181,7 @@ Translations: Деякі проєкти 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`, але це ще не означає, що це гарна ідея використовувати цей шаблон компонування. +Не плутайте каталог `/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`, але це ще не означає, що це гарна ідея використовувати цей шаблон компонування. ## Badges From be2f207b6cce83a21b6e3c2dd5fbaca7e44d9da5 Mon Sep 17 00:00:00 2001 From: Rostislav Pylypiv Date: Wed, 14 Dec 2022 11:35:58 +0200 Subject: [PATCH 66/76] Fixing mistakes 5 --- README_ua.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/README_ua.md b/README_ua.md index ce46a19..8e87048 100644 --- a/README_ua.md +++ b/README_ua.md @@ -184,7 +184,7 @@ Translations: Не плутайте каталог `/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`, але це ще не означає, що це гарна ідея використовувати цей шаблон компонування. -## Badges +## Бейджі * [Go Report Card](https://goreportcard.com/) - відсканує ваш код за допомогою `gofmt`, `go vet`, `gocyclo`, `golint`, `ineffassign`, `license` та `misspell`. Замініть `github.com/golang-standards/project-layout` посиланням на ваш проєкт. From 698922df0ed5c4bf3a0f273b8af0a7a6b9d8a75a Mon Sep 17 00:00:00 2001 From: Sakakibara Tetsuya Date: Thu, 29 Dec 2022 14:19:05 +0900 Subject: [PATCH 67/76] update go.mod to the latest go version --- go.mod | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/go.mod b/go.mod index de79b35..dc69b8a 100644 --- a/go.mod +++ b/go.mod @@ -1,3 +1,3 @@ module github.com/YOUR-USER-OR-ORG-NAME/YOUR-REPO-NAME -go 1.14 +go 1.19 From 7210d1e8d23d5172cc4810ef8379ac7da19e01b7 Mon Sep 17 00:00:00 2001 From: japananh Date: Wed, 29 Sep 2021 11:29:16 +0700 Subject: [PATCH 68/76] Add Vietnamese translation --- README.md | 1 + README_es.md | 1 + README_fr.md | 1 + README_ja.md | 1 + README_ko.md | 1 + README_ptBR.md | 1 + README_ro.md | 1 + README_ru.md | 1 + README_tr.md | 1 + README_vi.md | 204 ++++++++++++++++++++++++++++++++++++++++++++++++ README_zh-CN.md | 1 + README_zh-TW.md | 1 + README_zh.md | 1 + 13 files changed, 216 insertions(+) create mode 100644 README_vi.md diff --git a/README.md b/README.md index 3727c11..53abc22 100644 --- a/README.md +++ b/README.md @@ -13,6 +13,7 @@ Translations: * [Română](README_ro.md) * [Русский](README_ru.md) * [Türkçe](README_tr.md) +* [Vietnamese](README_vi.md) ## Overview diff --git a/README_es.md b/README_es.md index d96eb20..834b359 100644 --- a/README_es.md +++ b/README_es.md @@ -14,6 +14,7 @@ Traducciones: * [Română](README_ro.md) * [Русский](README_ru.md) * [Türkçe](README_tr.md) +* [Vietnamese](README_vi.md) ## Resumen diff --git a/README_fr.md b/README_fr.md index 530bc5c..8749072 100644 --- a/README_fr.md +++ b/README_fr.md @@ -14,6 +14,7 @@ Traductions: * [Română](README_ro.md) * [Русский](README_ru.md) * [Türkçe](README_tr.md) +* [Vietnamese](README_vi.md) ## Introduction diff --git a/README_ja.md b/README_ja.md index 1ef23ee..0dd7131 100644 --- a/README_ja.md +++ b/README_ja.md @@ -14,6 +14,7 @@ * [Română](README_ro.md) * [Русский](README_ru.md) * [Türkçe](README_tr.md) +* [Vietnamese](README_vi.md) ## 概要 diff --git a/README_ko.md b/README_ko.md index f2c557c..6ce42ab 100644 --- a/README_ko.md +++ b/README_ko.md @@ -14,6 +14,7 @@ * [Română](README_ro.md) * [Русский](README_ru.md) * [Türkçe](README_tr.md) +* [Vietnamese](README_vi.md) ## 개요 diff --git a/README_ptBR.md b/README_ptBR.md index 80b9e8c..1a4fe7c 100644 --- a/README_ptBR.md +++ b/README_ptBR.md @@ -14,6 +14,7 @@ Traduções: * [Română](README_ro.md) * [Русский](README_ru.md) * [Türkçe](README_tr.md) +* [Vietnamese](README_vi.md) ## Visão geral diff --git a/README_ro.md b/README_ro.md index 0078d41..3266ba6 100644 --- a/README_ro.md +++ b/README_ro.md @@ -14,6 +14,7 @@ Traduceri: * [Română](README_ro.md) * [Русский](README_ru.md) * [Türkçe](README_tr.md) +* [Vietnamese](README_vi.md) ## General diff --git a/README_ru.md b/README_ru.md index 61f68f7..81b3030 100755 --- a/README_ru.md +++ b/README_ru.md @@ -14,6 +14,7 @@ Translations: * [Română](README_ro.md) * [Русский](README_ru.md) * [Türkçe](README_tr.md) +* [Vietnamese](README_vi.md) ## Overview diff --git a/README_tr.md b/README_tr.md index 9d94306..1d3495e 100644 --- a/README_tr.md +++ b/README_tr.md @@ -14,6 +14,7 @@ * [Română](README_ro.md) * [Русский](README_ru.md) * [Türkçe](README_tr.md) +* [Vietnamese](README_vi.md) ## Genel Bakış: diff --git a/README_vi.md b/README_vi.md new file mode 100644 index 0000000..9d8d348 --- /dev/null +++ b/README_vi.md @@ -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` và `/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` và `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` và `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` và `/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. diff --git a/README_zh-CN.md b/README_zh-CN.md index 24c8df6..d2c5b86 100644 --- a/README_zh-CN.md +++ b/README_zh-CN.md @@ -12,6 +12,7 @@ * [Română](README_ro.md) * [Русский](README_ru.md) * [Türkçe](README_tr.md) +* [Vietnamese](README_vi.md) 这是Go应用程序项目的基础布局。这不是Go核心开发团队定义的官方标准；无论是在经典项目还是在新兴的项目中，这都是Go生态系统中一组常见的项目布局模式。这其中有一些模式比另外的一些更受欢迎。它通过几个支撑目录为任何足够大规模的实际应用程序提供一些增强功能。 diff --git a/README_zh-TW.md b/README_zh-TW.md index 8c29708..ff164f4 100644 --- a/README_zh-TW.md +++ b/README_zh-TW.md @@ -14,6 +14,7 @@ * [Română](README_ro.md) * [Русский](README_ru.md) * [Türkçe](README_tr.md) +* [Vietnamese](README_vi.md) 這是 Go 應用程式專案的基本目錄結構。它不是核心 Go 開發團隊定義的官方標準；然而，它是 Go 生態系統中一組常見的老專案和新專案的目錄結構。其中一些目錄結構比其他目錄結構更受歡迎。這個專案目錄結構還有一些細微的改進，可以支援任何大型且實用的應用程式目錄結構。 diff --git a/README_zh.md b/README_zh.md index 9257976..07ab939 100644 --- a/README_zh.md +++ b/README_zh.md @@ -14,6 +14,7 @@ * [Română](README_ro.md) * [Русский](README_ru.md) * [Türkçe](README_tr.md) +* [Vietnamese](README_vi.md) 这是 Go 应用程序项目的基本布局。它不是核心 Go 开发团队定义的官方标准；然而，它是 Go 生态系统中一组常见的老项目和新项目的布局模式。其中一些模式比其他模式更受欢迎。它还具有许多小的增强，以及对任何足够大的实际应用程序通用的几个支持目录。 From f1bfa97315257226519a97500e6956c6072e111b Mon Sep 17 00:00:00 2001 From: Taehyung Lee <55282922+rolancia@users.noreply.github.com> Date: Fri, 3 Feb 2023 10:40:46 +0900 Subject: [PATCH 69/76] fix typo in README.md --- README_ko.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/README_ko.md b/README_ko.md index cd3aba6..4d54783 100644 --- a/README_ko.md +++ b/README_ko.md @@ -70,7 +70,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)). From ee38795581fdf9ad77efeb69dd67e1116b39e07b Mon Sep 17 00:00:00 2001 From: jcambrosi Date: Mon, 6 Feb 2023 14:45:35 -0300 Subject: [PATCH 70/76] Update README.md MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Portuguese > Português (as it is in portuguese language) --- README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/README.md b/README.md index fa73909..d92e09b 100644 --- a/README.md +++ b/README.md @@ -8,7 +8,7 @@ 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) From 571d0ace87a1585ccee3e6f79139bcd46cdf51f9 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?=C3=89tienne=20BERSAC?= <542613+bersace@users.noreply.github.com> Date: Wed, 12 Apr 2023 08:42:41 +0200 Subject: [PATCH 71/76] Fix coquille in French translation --- README_fr.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/README_fr.md b/README_fr.md index 8355121..bd6d771 100644 --- a/README_fr.md +++ b/README_fr.md @@ -68,7 +68,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)). From dbe94ec89ad60c8a35bdec99d144cffd43576cd8 Mon Sep 17 00:00:00 2001 From: seregavspb <96838602+seregavspb@users.noreply.github.com> Date: Tue, 18 Apr 2023 15:05:13 +0300 Subject: [PATCH 72/76] Update Russian translation Minor changes to make the translation more natural --- README_ru.md | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/README_ru.md b/README_ru.md index 7facec6..3627c3f 100755 --- a/README_ru.md +++ b/README_ru.md @@ -26,7 +26,7 @@ Translations: Этот шаблон организации проекта намеренно сделан обобщенным, и не является примером структуры какого-то конкретного пакета Golang. -Этот репозиторий открыт к усилиям сообщества. Создайте заявку о проблеме, если вы нашли новый шаблон или считаете, что один из существующих шаблонов необходимо обновить. +Этот репозиторий открыт к участию сообщества. Создайте заявку о проблеме, если вы нашли новый шаблон или считаете, что один из существующих шаблонов необходимо обновить. Если вам нужна помощь в наименовании, форматировании или стилизации кода - начните с [`gofmt`](https://golang.org/cmd/gofmt/) и [`golint`](https://github.com/golang/lint). Также обязательно прочтите эти руководства по стилизации кода Golang и рекомендации: * https://talks.golang.org/2014/names.slide @@ -54,7 +54,8 @@ Translations: Имя директории для каждого приложения должно совпадать с именем исполняемого файла, который вы хотите собрать (например, `/cmd/myapp`). -Не стоит располагать в этой директории большие объёмы кода. Если вы предполагаете дальнейшее использование кода в других проектах, вам стоит хранить его в директории `/pkg` в корне проекта. Если же код не должен быть переиспользован где-то еще - ему самое место в директории `/internal` в корне проекта. Вы будете удивлены тем, что другие люди могут сделать, поэтому будьте уверены в своих намерениях! +Не стоит располагать в этой директории большие объёмы кода. Если вы предполагаете дальнейшее использование кода в других проектах, вам стоит хранить его в директории `/pkg` в корне проекта. Если же код не должен быть переиспользован где-то еще - ему самое место в директории `/internal` в корне проекта. Вы будете удивлены тем, что могут сделать другие люди, по +тому выражайте свои намерения явно! Самой распространнёной практикой является использование маленькой `main` функции, которая импортирует и вызывает весь необходимый код из директорий `/internal` и `/pkg` и никаких других. From 13cebc536817398adfe5541426c355aea67ef6b1 Mon Sep 17 00:00:00 2001 From: Alfan Mubarok Date: Sun, 4 Jun 2023 23:01:09 +0700 Subject: [PATCH 73/76] Add indonesian translation --- README_id.md | 207 +++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 207 insertions(+) create mode 100644 README_id.md diff --git a/README_id.md b/README_id.md new file mode 100644 index 0000000..fa73909 --- /dev/null +++ b/README_id.md @@ -0,0 +1,207 @@ +# Standard Go Project Layout + +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) + +## 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. + +**`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. + +With Go 1.14 [`Go Modules`](https://github.com/golang/go/wiki/Modules) are finally ready for production. Use [`Go Modules`](https://blog.golang.org/using-go-modules) unless you have a specific reason not to use them and if you do then you don’t need to worry about $GOPATH and where you put your project. The basic `go.mod` file in the repo assumes your project is hosted on GitHub, but it's not a requirement. The module path can be anything though the first module path component should have a dot in its name (the current version of Go doesn't enforce it anymore, but if you are using slightly older versions don't be surprised if your builds fail without it). See Issues [`37554`](https://github.com/golang/go/issues/37554) and [`32819`](https://github.com/golang/go/issues/32819) if you want to know more about it. + +This project layout is intentionally generic and it doesn't try to impose a specific Go package structure. + +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: +* 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) + +See [`Go Project Layout`](https://medium.com/golang-learn/go-project-layout-e5213cdcfaa2) for additional background information. + +More about naming and organizing packages as well as other code structure recommendations: +* [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) + +A Chinese post about Package-Oriented-Design guidelines and Architecture layer +* [面向包的设计和架构分层](https://github.com/danceyoung/paper-code/blob/master/package-oriented-design/packageorienteddesign.md) + +## Go Directories + +### `/cmd` + +Main applications for this project. + +The directory name for each application should match the name of the executable you want to have (e.g., `/cmd/myapp`). + +Don't put a lot of code in the application directory. If you think the code can be imported and used in other projects, then it should live in the `/pkg` directory. If the code is not reusable or if you don't want others to reuse it, put that code in the `/internal` directory. You'll be surprised what others will do, so be explicit about your intentions! + +It's common to have a small `main` function that imports and invokes the code from the `/internal` and `/pkg` directories and nothing else. + +See the [`/cmd`](cmd/README.md) directory for examples. + +### `/internal` + +Private application and library code. This is the code you don't want others importing in their applications or libraries. Note that this layout pattern is enforced by the Go compiler itself. See the Go 1.4 [`release notes`](https://golang.org/doc/go1.4#internalpackages) for more details. Note that you are not limited to the top level `internal` directory. You can have more than one `internal` directory at any level of your project tree. + +You can optionally add a bit of extra structure to your internal packages to separate your shared and non-shared internal code. It's not required (especially for smaller projects), but it's nice to have visual clues showing the intended package use. Your actual application code can go in the `/internal/app` directory (e.g., `/internal/app/myapp`) and the code shared by those apps in the `/internal/pkg` directory (e.g., `/internal/pkg/myprivlib`). + +### `/pkg` + +Library code that's ok to use by external applications (e.g., `/pkg/mypubliclib`). Other projects will import these libraries expecting them to work, so think twice before you put something here :-) Note that the `internal` directory is a better way to ensure your private packages are not importable because it's enforced by Go. The `/pkg` directory is still a good way to explicitly communicate that the code in that directory is safe for use by others. The [`I'll take pkg over internal`](https://travisjeffery.com/b/2019/11/i-ll-take-pkg-over-internal/) blog post by Travis Jeffery provides a good overview of the `pkg` and `internal` directories and when it might make sense to use them. + +It's also a way to group Go code in one place when your root directory contains lots of non-Go components and directories making it easier to run various Go tools (as mentioned in these talks: [`Best Practices for Industrial Programming`](https://www.youtube.com/watch?v=PTE4VJIdHPg) from GopherCon EU 2018, [GopherCon 2018: Kat Zien - How Do You Structure Your Go Apps](https://www.youtube.com/watch?v=oL6JBUk6tj0) and [GoLab 2018 - Massimiliano Pippi - Project layout patterns in Go](https://www.youtube.com/watch?v=3gQa1LWwuzk)). + +See the [`/pkg`](pkg/README.md) directory if you want to see which popular Go repos use this project layout pattern. This is a common layout pattern, but it's not universally accepted and some in the Go community don't recommend it. + +It's ok not to use it if your app project is really small and where an extra level of nesting doesn't add much value (unless you really want to :-)). Think about it when it's getting big enough and your root directory gets pretty busy (especially if you have a lot of non-Go app components). + +The `pkg` directory origins: The old Go source code used to use `pkg` for its packages and then various Go projects in the community started copying the pattern (see [`this`](https://twitter.com/bradfitz/status/1039512487538970624) Brad Fitzpatrick's tweet for more context). + +### `/vendor` + +Application dependencies (managed manually or by your favorite dependency management tool like the new built-in [`Go Modules`](https://github.com/golang/go/wiki/Modules) feature). The `go mod vendor` command will create the `/vendor` directory for you. Note that you might need to add the `-mod=vendor` flag to your `go build` command if you are not using Go 1.14 where it's on by default. + +Don't commit your application dependencies if you are building a library. + +Note that since [`1.13`](https://golang.org/doc/go1.13#modules) Go also enabled the module proxy feature (using [`https://proxy.golang.org`](https://proxy.golang.org) as their module proxy server by default). Read more about it [`here`](https://blog.golang.org/module-mirror-launch) to see if it fits all of your requirements and constraints. If it does, then you won't need the `vendor` directory at all. + +## Service Application Directories + +### `/api` + +OpenAPI/Swagger specs, JSON schema files, protocol definition files. + +See the [`/api`](api/README.md) directory for examples. + +## Web Application Directories + +### `/web` + +Web application specific components: static web assets, server side templates and SPAs. + +## Common Application Directories + +### `/configs` + +Configuration file templates or default configs. + +Put your `confd` or `consul-template` template files here. + +### `/init` + +System init (systemd, upstart, sysv) and process manager/supervisor (runit, supervisord) configs. + +### `/scripts` + +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)). + +See the [`/scripts`](scripts/README.md) directory for examples. + +### `/build` + +Packaging and Continuous Integration. + +Put your cloud (AMI), container (Docker), OS (deb, rpm, pkg) package configurations and scripts in the `/build/package` directory. + +Put your CI (travis, circle, drone) configurations and scripts in the `/build/ci` directory. Note that some of the CI tools (e.g., Travis CI) are very picky about the location of their config files. Try putting the config files in the `/build/ci` directory linking them to the location where the CI tools expect them (when possible). + +### `/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`. + +### `/test` + +Additional external test apps and test data. Feel free to structure the `/test` directory anyway you want. For bigger projects it makes sense to have a data subdirectory. For example, you can have `/test/data` or `/test/testdata` if you need Go to ignore what's in that directory. Note that Go will also ignore directories or files that begin with "." or "_", so you have more flexibility in terms of how you name your test data directory. + +See the [`/test`](test/README.md) directory for examples. + +## Other Directories + +### `/docs` + +Design and user documents (in addition to your godoc generated documentation). + +See the [`/docs`](docs/README.md) directory for examples. + +### `/tools` + +Supporting tools for this project. Note that these tools can import code from the `/pkg` and `/internal` directories. + +See the [`/tools`](tools/README.md) directory for examples. + +### `/examples` + +Examples for your applications and/or public libraries. + +See the [`/examples`](examples/README.md) directory for examples. + +### `/third_party` + +External helper tools, forked code and other 3rd party utilities (e.g., Swagger UI). + +### `/githooks` + +Git hooks. + +### `/assets` + +Other assets to go along with your repository (images, logos, etc). + +### `/website` + +This is the place to put your project's website data if you are not using GitHub pages. + +See the [`/website`](website/README.md) directory for examples. + +## Directories You Shouldn't Have + +### `/src` + +Some Go projects do have a `src` folder, but it usually happens when the devs came from the Java world where it's a common pattern. If you can help yourself try not to adopt this Java pattern. You really don't want your Go code or Go projects to look like Java :-) + +Don't confuse the project level `/src` directory with the `/src` directory Go uses for its workspaces as described in [`How to Write Go Code`](https://golang.org/doc/code.html). The `$GOPATH` environment variable points to your (current) workspace (by default it points to `$HOME/go` on non-windows systems). This workspace includes the top level `/pkg`, `/bin` and `/src` directories. Your actual project ends up being a sub-directory under `/src`, so if you have the `/src` directory in your project the project path will look like this: `/some/path/to/workspace/src/your_project/src/your_code.go`. Note that with Go 1.11 it's possible to have your project outside of your `GOPATH`, but it still doesn't mean it's a good idea to use this layout pattern. + + +## Badges + +* [Go Report Card](https://goreportcard.com/) - It will scan your code with `gofmt`, `go vet`, `gocyclo`, `golint`, `ineffassign`, `license` and `misspell`. Replace `github.com/golang-standards/project-layout` with your project reference. + + [![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) - It will provide online version of your GoDoc generated documentation. Change the link to point to your project.~~ + + [![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). + + [![PkgGoDev](https://pkg.go.dev/badge/github.com/golang-standards/project-layout)](https://pkg.go.dev/github.com/golang-standards/project-layout) + +* Release - It will show the latest release number for your project. Change the github link to point to your project. + + [![Release](https://img.shields.io/github/release/golang-standards/project-layout.svg?style=flat-square)](https://github.com/golang-standards/project-layout/releases/latest) + +## Notes + +A more opinionated project template with sample/reusable configs, scripts and code is a WIP. From 9cd5ff7b14c6073484b0e37f4a39b286565b4102 Mon Sep 17 00:00:00 2001 From: Alfan Mubarok Date: Mon, 5 Jun 2023 08:10:08 +0700 Subject: [PATCH 74/76] Complete the translation --- README_id.md | 130 +++++++++++++++++++++++++-------------------------- 1 file changed, 64 insertions(+), 66 deletions(-) diff --git a/README_id.md b/README_id.md index fa73909..59b2896 100644 --- a/README_id.md +++ b/README_id.md @@ -1,6 +1,6 @@ # Standard Go Project Layout -Translations: +Terjemahan: * [한국어 문서](README_ko.md) * [简体中文](README_zh.md) @@ -15,151 +15,149 @@ Translations: * [Türkçe](README_tr.md) * [Українська](README_ua.md) -## Overview +## Ringkasan -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. +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. -**`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. +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 menggunakannya semua. Tidak satu pun dari pola-pola ini digunakan dalam setiap proyek. Bahkan pola `vendor` tidaklah universal. -With Go 1.14 [`Go Modules`](https://github.com/golang/go/wiki/Modules) are finally ready for production. Use [`Go Modules`](https://blog.golang.org/using-go-modules) unless you have a specific reason not to use them and if you do then you don’t need to worry about $GOPATH and where you put your project. The basic `go.mod` file in the repo assumes your project is hosted on GitHub, but it's not a requirement. The module path can be anything though the first module path component should have a dot in its name (the current version of Go doesn't enforce it anymore, but if you are using slightly older versions don't be surprised if your builds fail without it). See Issues [`37554`](https://github.com/golang/go/issues/37554) and [`32819`](https://github.com/golang/go/issues/32819) if you want to know more about it. +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. -This project layout is intentionally generic and it doesn't try to impose a specific Go package structure. +Tata letak proyek ini sengaja dirancang secara generik dan tidak mencoba memaksakan struktur paket Go yang spesifik. -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. +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. -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: +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) -See [`Go Project Layout`](https://medium.com/golang-learn/go-project-layout-e5213cdcfaa2) for additional background information. +Lihatlah [`Go Project Layout`](https://medium.com/golang-learn/go-project-layout-e5213cdcfaa2) untuk informasi latar belakang tambahan. -More about naming and organizing packages as well as other code structure recommendations: +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) -A Chinese post about Package-Oriented-Design guidelines and Architecture layer +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) -## Go Directories +## Direktori Go ### `/cmd` -Main applications for this project. +Aplikasi utama untuk proyek ini. -The directory name for each application should match the name of the executable you want to have (e.g., `/cmd/myapp`). +Nama direktori untuk setiap aplikasi harus sesuai dengan nama file eksekusi yang diinginkan (misalnya, /cmd/myapp). -Don't put a lot of code in the application directory. If you think the code can be imported and used in other projects, then it should live in the `/pkg` directory. If the code is not reusable or if you don't want others to reuse it, put that code in the `/internal` directory. You'll be surprised what others will do, so be explicit about your intentions! +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! -It's common to have a small `main` function that imports and invokes the code from the `/internal` and `/pkg` directories and nothing else. +Biasanya, terdapat fungsi `main` kecil yang mengimpor dan memanggil kode dari direktori `/internal` dan `/pkg`, dan tidak ada yang lain. -See the [`/cmd`](cmd/README.md) directory for examples. +Lihat direktori [`/cmd`](cmd/README.md) untuk contoh-contoh lebih lanjut. ### `/internal` -Private application and library code. This is the code you don't want others importing in their applications or libraries. Note that this layout pattern is enforced by the Go compiler itself. See the Go 1.4 [`release notes`](https://golang.org/doc/go1.4#internalpackages) for more details. Note that you are not limited to the top level `internal` directory. You can have more than one `internal` directory at any level of your project tree. +Kode aplikasi dan library privat. Ini adalah kode anda yang tidak ingin diimpor oleh aplikasi atau perpustakaan 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. -You can optionally add a bit of extra structure to your internal packages to separate your shared and non-shared internal code. It's not required (especially for smaller projects), but it's nice to have visual clues showing the intended package use. Your actual application code can go in the `/internal/app` directory (e.g., `/internal/app/myapp`) and the code shared by those apps in the `/internal/pkg` directory (e.g., `/internal/pkg/myprivlib`). +Secara opsional anda dapat menambahkan struktur tambahan ke paket internal anda, untuk memisahkan kode internal yang bersifat berbagi (shared) dan tidak berbagi (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` -Library code that's ok to use by external applications (e.g., `/pkg/mypubliclib`). Other projects will import these libraries expecting them to work, so think twice before you put something here :-) Note that the `internal` directory is a better way to ensure your private packages are not importable because it's enforced by Go. The `/pkg` directory is still a good way to explicitly communicate that the code in that directory is safe for use by others. The [`I'll take pkg over internal`](https://travisjeffery.com/b/2019/11/i-ll-take-pkg-over-internal/) blog post by Travis Jeffery provides a good overview of the `pkg` and `internal` directories and when it might make sense to use them. +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. -It's also a way to group Go code in one place when your root directory contains lots of non-Go components and directories making it easier to run various Go tools (as mentioned in these talks: [`Best Practices for Industrial Programming`](https://www.youtube.com/watch?v=PTE4VJIdHPg) from GopherCon EU 2018, [GopherCon 2018: Kat Zien - How Do You Structure Your Go Apps](https://www.youtube.com/watch?v=oL6JBUk6tj0) and [GoLab 2018 - Massimiliano Pippi - Project layout patterns in Go](https://www.youtube.com/watch?v=3gQa1LWwuzk)). +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)). -See the [`/pkg`](pkg/README.md) directory if you want to see which popular Go repos use this project layout pattern. This is a common layout pattern, but it's not universally accepted and some in the Go community don't recommend it. +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. -It's ok not to use it if your app project is really small and where an extra level of nesting doesn't add much value (unless you really want to :-)). Think about it when it's getting big enough and your root directory gets pretty busy (especially if you have a lot of non-Go app components). +Tidak masalah jika juga anda tidak menggunakannya, jika proyek aplikasi anda benar-benar kecil dan tingkatan level tambahan tidak begitu penting (kecuali jika anda benar-benar menginginkannya :-)). Pikirkanlah tentang hal itu ketika proyek anda cukup besar dan direktori root anda sudah cukup sibuk (terutama jika anda memiliki banyak komponen aplikasi non-Go). -The `pkg` directory origins: The old Go source code used to use `pkg` for its packages and then various Go projects in the community started copying the pattern (see [`this`](https://twitter.com/bradfitz/status/1039512487538970624) Brad Fitzpatrick's tweet for more context). +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` -Application dependencies (managed manually or by your favorite dependency management tool like the new built-in [`Go Modules`](https://github.com/golang/go/wiki/Modules) feature). The `go mod vendor` command will create the `/vendor` directory for you. Note that you might need to add the `-mod=vendor` flag to your `go build` command if you are not using Go 1.14 where it's on by default. +Dependency 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. -Don't commit your application dependencies if you are building a library. +Jangan meng-commit dependency aplikasi anda jika anda sedang membangun sebuah library. -Note that since [`1.13`](https://golang.org/doc/go1.13#modules) Go also enabled the module proxy feature (using [`https://proxy.golang.org`](https://proxy.golang.org) as their module proxy server by default). Read more about it [`here`](https://blog.golang.org/module-mirror-launch) to see if it fits all of your requirements and constraints. If it does, then you won't need the `vendor` directory at all. +Perlu dicatat bahwa sejak versi [`1.13`](https://golang.org/doc/go1.13#modules), Go juga 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`. -## Service Application Directories +## Direktori Servis Aplikasi ### `/api` -OpenAPI/Swagger specs, JSON schema files, protocol definition files. +Spesifikasi OpenAPI/Swagger, file skema JSON, file definisi protokol. -See the [`/api`](api/README.md) directory for examples. - -## Web Application Directories +Lihat direktori [`/api`](api/README.md) untuk contoh-contohnya. ### `/web` -Web application specific components: static web assets, server side templates and SPAs. +Komponen-komponen spesifik aplikasi web: aset web statis, template di sisi server, dan SPAs. -## Common Application Directories +## Direktori Umum Aplikasi ### `/configs` -Configuration file templates or default configs. +Template file konfigurasi atau konfigurasi default. -Put your `confd` or `consul-template` template files here. +Letakkan file template anda di `confd` atau `consul-template`.. ### `/init` -System init (systemd, upstart, sysv) and process manager/supervisor (runit, supervisord) configs. +Konfigurasi sistem init (systemd, upstart, sysv) dan manajer proses/supervisor (runit, supervisord). ### `/scripts` -Scripts to perform various build, install, analysis, etc operations. +Skrip-skrip untuk melakukan berbagai operasi seperti build, instalasi, analisis, dll. -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)). +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)). -See the [`/scripts`](scripts/README.md) directory for examples. +Lihat direktori [`/scripts`](scripts/README.md) untuk melihat contoh-contohnya. ### `/build` -Packaging and Continuous Integration. +Pemaketan (Packaging) dan Integrasi Berkelanjutan (Continuous Integration). -Put your cloud (AMI), container (Docker), OS (deb, rpm, pkg) package configurations and scripts in the `/build/package` directory. +Letakkan skrip paket dan konfigurasi untuk cloud (AMI), container (Docker), sistem operasi (deb, rpm, pkg) anda di direktori `/build/package`. -Put your CI (travis, circle, drone) configurations and scripts in the `/build/ci` directory. Note that some of the CI tools (e.g., Travis CI) are very picky about the location of their config files. Try putting the config files in the `/build/ci` directory linking them to the location where the CI tools expect them (when possible). +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` -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`. +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` -Additional external test apps and test data. Feel free to structure the `/test` directory anyway you want. For bigger projects it makes sense to have a data subdirectory. For example, you can have `/test/data` or `/test/testdata` if you need Go to ignore what's in that directory. Note that Go will also ignore directories or files that begin with "." or "_", so you have more flexibility in terms of how you name your test data directory. +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. -See the [`/test`](test/README.md) directory for examples. +Lihat direktori [`/test`](test/README.md) untuk contoh-contohnya. -## Other Directories +## Direktori Lainya ### `/docs` -Design and user documents (in addition to your godoc generated documentation). +Dokumentasi desain dan pengguna (selain dokumentasi yang dihasilkan oleh godoc). -See the [`/docs`](docs/README.md) directory for examples. +Lihat direktori [`/docs`](docs/README.md) untuk contoh-contohnya. ### `/tools` -Supporting tools for this project. Note that these tools can import code from the `/pkg` and `/internal` directories. +Tools pendukung untuk proyek ini. Perhatikan bahwa tools ini dapat mengimpor kode dari direktori `/pkg` dan `/internal`. -See the [`/tools`](tools/README.md) directory for examples. +Lihat direktori [`/tools`](tools/README.md) untuk contoh-contohnya. ### `/examples` -Examples for your applications and/or public libraries. +Contoh-contoh aplikasi atau library publik Anda. -See the [`/examples`](examples/README.md) directory for examples. +Lihat direktori [`/examples`](examples/README.md) untuk melihat contoh-contohnya. ### `/third_party` -External helper tools, forked code and other 3rd party utilities (e.g., Swagger UI). +Tools eksternal, kode yang di-fork, dan utilitas pihak ketiga (third party) lainnya (misalnya, Swagger UI). ### `/githooks` @@ -167,41 +165,41 @@ Git hooks. ### `/assets` -Other assets to go along with your repository (images, logos, etc). +Aset lainnya yang ada di repositori anda (gambar, logo, dll). ### `/website` -This is the place to put your project's website data if you are not using GitHub pages. +Tempat untuk meletakkan data situs web proyek Anda jika anda tidak menggunakan halaman GitHub. -See the [`/website`](website/README.md) directory for examples. +Lihat direktori [`/website`](website/README.md) untuk contoh-contohnya. -## Directories You Shouldn't Have +## Direktori yang Sebaiknya Tidak Dimiliki ### `/src` -Some Go projects do have a `src` folder, but it usually happens when the devs came from the Java world where it's a common pattern. If you can help yourself try not to adopt this Java pattern. You really don't want your Go code or Go projects to look like Java :-) +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 :-) -Don't confuse the project level `/src` directory with the `/src` directory Go uses for its workspaces as described in [`How to Write Go Code`](https://golang.org/doc/code.html). The `$GOPATH` environment variable points to your (current) workspace (by default it points to `$HOME/go` on non-windows systems). This workspace includes the top level `/pkg`, `/bin` and `/src` directories. Your actual project ends up being a sub-directory under `/src`, so if you have the `/src` directory in your project the project path will look like this: `/some/path/to/workspace/src/your_project/src/your_code.go`. Note that with Go 1.11 it's possible to have your project outside of your `GOPATH`, but it still doesn't mean it's a good idea to use this layout pattern. +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/) - It will scan your code with `gofmt`, `go vet`, `gocyclo`, `golint`, `ineffassign`, `license` and `misspell`. Replace `github.com/golang-standards/project-layout` with your project reference. +* [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) - It will provide online version of your GoDoc generated documentation. Change the link to point to your project.~~ +* ~~[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 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 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 - It will show the latest release number for your project. Change the github link to point to your project. +* 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) -## Notes +## Catatan -A more opinionated project template with sample/reusable configs, scripts and code is a WIP. +Opsi Template lainaya dengan contoh konfigurasi, skrip, dan kode yang dapat digunakan kembali sedang dalam pengembangan (WIP). From d76d6794405cfe234c6fd55dd4877b19e6e54443 Mon Sep 17 00:00:00 2001 From: Alfan Mubarok Date: Mon, 5 Jun 2023 08:33:44 +0700 Subject: [PATCH 75/76] Fix typo --- README_id.md | 32 ++++++++++++++++---------------- 1 file changed, 16 insertions(+), 16 deletions(-) diff --git a/README_id.md b/README_id.md index 59b2896..ac7063c 100644 --- a/README_id.md +++ b/README_id.md @@ -1,4 +1,4 @@ -# Standard Go Project Layout +# Standar Tata Letak Proyek Go Terjemahan: @@ -19,9 +19,9 @@ Terjemahan: 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 menggunakannya semua. Tidak satu pun dari pola-pola ini digunakan dalam setiap proyek. Bahkan pola `vendor` tidaklah universal. +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. +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. @@ -51,9 +51,9 @@ Sebuah postingan dalam bahasa Cina tentang pedoman Package-Oriented Design dan A Aplikasi utama untuk proyek ini. -Nama direktori untuk setiap aplikasi harus sesuai dengan nama file eksekusi yang diinginkan (misalnya, /cmd/myapp). +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! +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. @@ -61,29 +61,29 @@ 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 perpustakaan 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. +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 berbagi (shared) dan tidak berbagi (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`). +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. +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 juga anda tidak menggunakannya, jika proyek aplikasi anda benar-benar kecil dan tingkatan level tambahan tidak begitu penting (kecuali jika anda benar-benar menginginkannya :-)). Pikirkanlah tentang hal itu ketika proyek anda cukup besar dan direktori root anda sudah cukup sibuk (terutama jika anda memiliki banyak komponen aplikasi non-Go). +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` -Dependency 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. +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 juga 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`. +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 @@ -131,7 +131,7 @@ Konfigurasi dan template untuk IaaS, PaaS, orkestrasi sistem, dan container (doc ### `/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. +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. @@ -151,7 +151,7 @@ Lihat direktori [`/tools`](tools/README.md) untuk contoh-contohnya. ### `/examples` -Contoh-contoh aplikasi atau library publik Anda. +Contoh-contoh aplikasi atau library publik anda. Lihat direktori [`/examples`](examples/README.md) untuk melihat contoh-contohnya. @@ -169,7 +169,7 @@ 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. +Tempat untuk meletakkan data situs web proyek anda jika anda tidak menggunakan halaman GitHub. Lihat direktori [`/website`](website/README.md) untuk contoh-contohnya. @@ -188,7 +188,7 @@ Jangan bingung antara direktori proyek `/src` dengan direktori `/src` yang digun [![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.~~ +* ~~[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) @@ -202,4 +202,4 @@ Jangan bingung antara direktori proyek `/src` dengan direktori `/src` yang digun ## Catatan -Opsi Template lainaya dengan contoh konfigurasi, skrip, dan kode yang dapat digunakan kembali sedang dalam pengembangan (WIP). +Opsi template lainya disertai contoh konfigurasi, skrip, dan kode yang dapat digunakan kembali sedang dalam pengembangan (WIP). From 194703678f1588a292c6d452a1a2699e54e2ecbd Mon Sep 17 00:00:00 2001 From: Alfan Mubarok Date: Mon, 5 Jun 2023 08:39:46 +0700 Subject: [PATCH 76/76] Add indonesian translation to all README files --- README.md | 1 + README_es.md | 1 + README_fr.md | 1 + README_id.md | 1 + README_it.md | 1 + README_ja.md | 1 + README_ko.md | 1 + README_ptBR.md | 1 + README_ro.md | 1 + README_ru.md | 1 + README_tr.md | 1 + README_ua.md | 1 + README_zh-CN.md | 1 + README_zh-TW.md | 1 + README_zh.md | 1 + 15 files changed, 15 insertions(+) diff --git a/README.md b/README.md index fa73909..0c37a15 100644 --- a/README.md +++ b/README.md @@ -14,6 +14,7 @@ Translations: * [Русский](README_ru.md) * [Türkçe](README_tr.md) * [Українська](README_ua.md) +* [Indonesian](README_id.md) ## Overview diff --git a/README_es.md b/README_es.md index d0c457d..94a61a6 100644 --- a/README_es.md +++ b/README_es.md @@ -15,6 +15,7 @@ Traducciones: * [Русский](README_ru.md) * [Türkçe](README_tr.md) * [Українська](README_ua.md) +* [Indonesian](README_id.md) ## Resumen diff --git a/README_fr.md b/README_fr.md index 8355121..f98edf0 100644 --- a/README_fr.md +++ b/README_fr.md @@ -15,6 +15,7 @@ Traductions: * [Русский](README_ru.md) * [Türkçe](README_tr.md) * [Українська](README_ua.md) +* [Indonesian](README_id.md) ## Introduction diff --git a/README_id.md b/README_id.md index ac7063c..7ee9d3d 100644 --- a/README_id.md +++ b/README_id.md @@ -14,6 +14,7 @@ Terjemahan: * [Русский](README_ru.md) * [Türkçe](README_tr.md) * [Українська](README_ua.md) +* [Indonesian](README_id.md) ## Ringkasan diff --git a/README_it.md b/README_it.md index ce826b3..0ba0b7f 100644 --- a/README_it.md +++ b/README_it.md @@ -14,6 +14,7 @@ Traduzioni: * [Русский](README_ru.md) * [Türkçe](README_tr.md) * [Українська](README_ua.md) +* [Indonesian](README_id.md) ## Panoramica diff --git a/README_ja.md b/README_ja.md index c969a2d..98a9e92 100644 --- a/README_ja.md +++ b/README_ja.md @@ -15,6 +15,7 @@ * [Русский](README_ru.md) * [Türkçe](README_tr.md) * [Українська](README_ua.md) +* [Indonesian](README_id.md) ## 概要 diff --git a/README_ko.md b/README_ko.md index cd3aba6..eac84ec 100644 --- a/README_ko.md +++ b/README_ko.md @@ -15,6 +15,7 @@ * [Русский](README_ru.md) * [Türkçe](README_tr.md) * [Українська](README_ua.md) +* [Indonesian](README_id.md) ## 개요 diff --git a/README_ptBR.md b/README_ptBR.md index 2ee1fb7..805813f 100644 --- a/README_ptBR.md +++ b/README_ptBR.md @@ -15,6 +15,7 @@ Traduções: * [Русский](README_ru.md) * [Türkçe](README_tr.md) * [Українська](README_ua.md) +* [Indonesian](README_id.md) ## Visão geral diff --git a/README_ro.md b/README_ro.md index f34ae34..b55a975 100644 --- a/README_ro.md +++ b/README_ro.md @@ -15,6 +15,7 @@ Traduceri: * [Русский](README_ru.md) * [Türkçe](README_tr.md) * [Українська](README_ua.md) +* [Indonesian](README_id.md) ## General diff --git a/README_ru.md b/README_ru.md index 7facec6..1f231dd 100755 --- a/README_ru.md +++ b/README_ru.md @@ -15,6 +15,7 @@ Translations: * [Русский](README_ru.md) * [Türkçe](README_tr.md) * [Українська](README_ua.md) +* [Indonesian](README_id.md) ## Overview diff --git a/README_tr.md b/README_tr.md index d049718..cc58851 100644 --- a/README_tr.md +++ b/README_tr.md @@ -15,6 +15,7 @@ * [Русский](README_ru.md) * [Türkçe](README_tr.md) * [Українська](README_ua.md) +* [Indonesian](README_id.md) ## Genel Bakış: diff --git a/README_ua.md b/README_ua.md index 8e87048..24b99b1 100644 --- a/README_ua.md +++ b/README_ua.md @@ -14,6 +14,7 @@ Translations: * [Русский](README_ru.md) * [Türkçe](README_tr.md) * [Українська](README_ua.md) +* [Indonesian](README_id.md) ## Огляд diff --git a/README_zh-CN.md b/README_zh-CN.md index d8e50f9..25c26c1 100644 --- a/README_zh-CN.md +++ b/README_zh-CN.md @@ -13,6 +13,7 @@ * [Русский](README_ru.md) * [Türkçe](README_tr.md) * [Українська](README_ua.md) +* [Indonesian](README_id.md) 这是Go应用程序项目的基础布局。这不是Go核心开发团队定义的官方标准；无论是在经典项目还是在新兴的项目中，这都是Go生态系统中一组常见的项目布局模式。这其中有一些模式比另外的一些更受欢迎。它通过几个支撑目录为任何足够大规模的实际应用程序提供一些增强功能。 diff --git a/README_zh-TW.md b/README_zh-TW.md index 761e365..3c8ea1d 100644 --- a/README_zh-TW.md +++ b/README_zh-TW.md @@ -15,6 +15,7 @@ * [Русский](README_ru.md) * [Türkçe](README_tr.md) * [Українська](README_ua.md) +* [Indonesian](README_id.md) 這是 Go 應用程式專案的基本目錄結構。它不是核心 Go 開發團隊定義的官方標準；然而，它是 Go 生態系統中一組常見的老專案和新專案的目錄結構。其中一些目錄結構比其他目錄結構更受歡迎。這個專案目錄結構還有一些細微的改進，可以支援任何大型且實用的應用程式目錄結構。 diff --git a/README_zh.md b/README_zh.md index 7ee4831..963bd9d 100644 --- a/README_zh.md +++ b/README_zh.md @@ -15,6 +15,7 @@ * [Русский](README_ru.md) * [Türkçe](README_tr.md) * [Українська](README_ua.md) +* [Indonesian](README_id.md) 这是 Go 应用程序项目的基本布局。它不是核心 Go 开发团队定义的官方标准；然而，它是 Go 生态系统中一组常见的老项目和新项目的布局模式。其中一些模式比其他模式更受欢迎。它还具有许多小的增强，以及对任何足够大的实际应用程序通用的几个支持目录。