Genel Bakış

Bu, Go uygulama projeleri için temel bir düzenidir. Go çekirdek geliştirme ekibi tarafından resmi olarak belirlenmiş bir standart değildir; topluluk Go projeleri için yaygın olarak kullanılan bir dizin düzenidir.

Go öğreniyorsanız veya bir kanıt oluşturuyorsanız (PoC) veya basit kişisel bir proje geliştiriyorsanız, bu proje düzeni çok karmaşıktır. Bunun yerine, gerçekten basit bir düzenle başlayın (sadece bir main.go dosyası ve go.mod yeterlidir). Projeniz geliştikçe kod yapınızın iyi olduğundan emin olun, aksi takdirde gizli bağımlılıklar ve global durum içeren dağınık kodlarla karşılaşabilirsiniz. Daha fazla insan projeyle ilgilenmeye başladığında daha yapılandırılmış bir yola ihtiyacınız olacaktır. Bu durumda, paket/kütüphane yönetimini yönetmek için ortak bir yolun tanıtılması önemlidir. Bir açık kaynak projesiniz varsa veya diğer projelerin kodlarını deposundan içe aktardığınızı biliyorsanız, özel (ayrıca internal olarak da bilinir) paketlere ve kodlara sahip olmak önemlidir. Deposunu klonlayın, ihtiyacınız olan kısımları saklayın ve geri kalan her şeyi silin! Var olması demek, hepsini kullanmanız gerektiği anlamına gelmez. Bu kalıpların hiçbiri her projede kullanılmaz. Hatta vendor kalıbı bile evrensel değildir.

Bu proje düzeni, çok genel olacak şekilde tasarlanmıştır ve belirli bir Go paketi yapısı dayatmaya çalışmaz.

Go Proje Dizin Belirtimi

Aşağıda önerilen Go proje dizin belirtimi bulunmaktadır.

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

Her bir dizinin anlamları aşağıda tanıtılmıştır.

/cmd

Projenin ana uygulamaları, yani programların giriş noktası. Bu dizindeki Go dosyaları genellikle yürütülebilir dosyalar oluşturur. Basit bir proje için, /test/main.go gibi bir dosya giriş noktası olarak hizmet edebilir.

Her uygulama dizininin adı, istediğiniz yürütülebilir dosyanın adıyla eşleşmelidir (örneğin, /cmd/myapp).

Uygulama dizinine çok fazla kod koymayın. Kodun diğer projelerde içe aktarılabilir ve kullanılabilir olduğunu düşünüyorsanız, onu /pkg dizinine koyun. Kodun tekrar kullanılamaz veya başkalarının onu yeniden kullanmasını istemiyorsanız, kodu /internal dizinine koyun. Diğer insanların davranışları sizi şaşırtabilir, bu nedenle niyetinizi açıkça belirtin!

Genellikle /internal ve /pkg dizinlerinden kodları içe aktaran ve çağıran küçük bir main fonksiyonu vardır ve başka hiçbir şey yoktur.

/internal

Özel uygulama ve kitaplık kodu. Bu, başkalarının uygulamalarına veya kitaplıklarına içe aktarmasını istemediğiniz kodlardır. Bu düzen modelinin Go derleyicisi tarafından zorunlu kılınan bir düzen modeli olduğunu unutmayın. Daha detaylı bilgi için, Go 1.4 için sürüm notlarına bakınız. Ayrıca, bu yalnızca üst düzey internal dizini ile sınırlı değildir. Proje ağacının herhangi bir seviyesinde birden fazla internal dizininiz olabilir.

Paylaşılan ve paylaşılmayan dahili paketleri ayırt etmek için dahili paketler için ek bir yapı eklemeyi seçebilirsiniz. Bu zorunlu değildir (özellikle daha küçük projeler için), ancak paketlerin kullanım amaçlarını görsel olarak göstermek iyi bir uygulamadır. Gerçek uygulama kodunuzu /internal/app dizinine (örneğin, /internal/app/myapp) yerleştirebilirsiniz ve bu uygulamalar için paylaşılan kodu /internal/pkg dizinine (örneğin, /internal/pkg/myprivlib) yerleştirebilirsiniz.

/pkg

Harici uygulamalar tarafından kullanılabilen kütüphane kodu (örneğin, /pkg/mypubliclib). Diğer projeler bu kitaplıkları içe aktaracak ve bunların düzgün çalışmasını bekleyecek, bu nedenle buraya içerik eklemekten önce iyi düşünün :-) internal dizini, özel paketlerin içe aktarılamamasını sağlamak için daha iyi bir yoldur, çünkü Go tarafından zorunlu kılınır. /pkg dizini, bu dizindeki kodun başkaları tarafından kullanmak için güvenli olduğunu açıkça iletmek için hala iyi bir yoldur.

Uygulama projesiniz çok küçük ise ve çok katmanlı gömme çok fazla değer katmıyorsa, kullanmamak da mümkündür (gerçekten kullanmak istemediğiniz sürece :-)). Proje yeterince büyüdüğünde ve kök dizin çok meşgul hale geldiğinde, bunu düşünün (özellikle çok sayıda Go olmayan uygulama bileşeni varsa).

/vendor

Uygulama bağımlılıkları (manuel olarak yönetilen veya tercih ettiğiniz bağımlılık yönetim aracını kullanarak, örneğin yerleşik Go Modülleri özelliği).

go mod vendor komutu /vendor dizinini oluşturacaktır. Unutmayın ki varsayılan olarak etkinleştirilmiş Go 1.14 sürümünü kullanmıyorsanız, go build komutuna -mod=vendor bayrağını eklemeniz gerekebilir.

Eğer bir kütüphane oluşturuyorsanız, lütfen uygulama bağımlılıklarınızı taahhüt etmeyin.

Servis Uygulaması Dizinleri

/api

OpenAPI/Swagger spesifikasyonları, JSON şema dosyaları, protokol tanım dosyaları ve API protokol dizinleri.

Web Uygulaması Dizinleri

/web

Web uygulamaları için özel bileşenler: statik web site varlıkları, sunucu tarafı şablonları ve tek sayfa uygulamaları (SPA'lar).

Genel Uygulama Dizinleri

/configs

Yapılandırma dosyası şablonları veya varsayılan yapılandırmalar.

confd veya consul-template şablon dosyalarını buraya yerleştirin.

/init

Sistem başlatma (systemd, upstart, sysv) ve işlem yöneticisi/servis (runit, supervisord) yapılandırmaları.

/scripts

Çeşitli derleme, kurulum, analiz ve diğer işlemler için betikler.

/build

Paketleme ve sürekli entegrasyon.

Bulut (AMI), konteyner (Docker), işletim sistemi (deb, rpm, pkg) paketi yapılandırmalarını ve betiklerini /build/package dizinine yerleştirin.

Sürekli entegrasyon (travis, circle, drone) yapılandırmalarını ve betiklerini /build/ci dizinine yerleştirin. Lütfen dikkat edin, belirli sürekli entegrasyon araçları (örneğin Travis CI) yapılandırma dosyalarının konumuna oldukça özeldir. Mümkünse yapılandırma dosyalarını /build/ci dizinine yerleştirin ve bunları sürekli entegrasyon araçları tarafından beklenen konuma bağlamak için bağlantılar kullanın.

/deployments

Altyapı servis sağlayıcıları, platform servis sağlayıcıları, sistem ve konteyner orkestrasyonu (docker-compose, kubernetes/helm, terraform) için dağıtım yapılandırmaları ve şablonları. Lütfen dikkat edin, bazı depolarda (özellikle Kubernetes ile dağıtılan uygulamalar için) bu dizin /deploy olarak adlandırılır.

/test

Diğer harici test uygulamaları ve test verileri. /test dizinini ihtiyaçlarınıza uygun bir şekilde düzenleyebilirsiniz. Daha büyük projeler için verileri alt dizinlere ayırmak mantıklı olabilir. Örneğin, Go'nun içeriğini görmezden gelmesi için /test/data veya /test/testdata dizinleri oluşturabilirsiniz. Lütfen dikkat edin, Go ayrıca "." veya "_" ile başlayan dizin veya dosyaları görmezden gelir, test veri dizinlerini adlandırırken daha fazla esneklik sağlar.

Diğer Dizinler

/docs

Tasarım ve kullanıcı belgeleri (godoc dokümanlarınızın dışında).

/tools

Bu proje için destekleyici araçlar. Lütfen unutmayın, bu araçlar /pkg ve /internal dizinlerinden kod içe aktarabilir.

/examples

Uygulamalar ve/veya genel kütüphaneler için örnekler.

/third_party

Harici yardımcı araçlar, çatallanan kod ve diğer üçüncü taraf yardımcı araçlar (örneğin, Swagger UI).

/githooks

Git hook'ları.

/assets

Depo ile birlikte sağlanan ek varlıklar (resimler, logolar vb.).

/website

Eğer GitHub Pages kullanmıyorsanız, projenin web sitesi verilerini depolamak için konum.

/src

Bazı Go projelerinde bir src klasörü olabilir, ancak bu genellikle geliştiricilerin, özellikle Java dünyasından geldiği için yaygın bir modeldir. Mümkünse, bu Java benzeri deseni benimsemekten kaçının. Gerçekten de Go kodunuzun veya projenizin Java'ya benzemesini istemezsiniz :-)

Lütfen proje düzeyindeki /src dizinini, Go Kodu Nasıl Yazılır bölümünde açıklanan Go çalışma alanı için kullanılan /src diziniyle karıştırmayın. $GOPATH ortam değişkeni, (varsayılan olarak, Windows olmayan sistemlerde $HOME/go dizinine işaret eder) (geçerli) çalışma alanınıza işaret eder. Bu çalışma alanı üst düzey /pkg, /bin ve /src dizinlerini içerir. Gerçek projeniz /src dizini altında bir alt dizin olacaktır, bu nedenle eğer projenizde bir /src dizini varsa, proje yolunuz şöyle görünecektir: /bazı/dizin/çalışma/alanı/src/projeniz/src/kodunuz.go. Lütfen dikkat edin, Go 1.11'den itibaren projenizi GOPATH dışında da yerleştirebilirsiniz, ancak bu düzen modelini kullanmanın iyi bir fikir olduğu anlamına gelmez.