golang-standarder / projektlayout

översättningar:

  • Portuguese
  • Portuguese
  • Portuguese
  • Portuguese
  • Portuguese
  • Portuguese
  • Portuguese – ???
  • Fran Portuguese
  • portugisiska
  • Espa Portuguese

översikt

detta är en grundläggande layout för GO-applikationsprojekt. Det är inte en officiell standard som definieras av core Go dev-teamet; det är dock en uppsättning gemensamma historiska och framväxande projektlayoutmönster i go-ekosystemet. Några av dessa mönster är mer populära än andra. Det har också ett antal små förbättringar tillsammans med flera stödjande kataloger som är gemensamma för alla tillräckligt stora verkliga applikationer.

Om du försöker lära dig Go eller om du bygger ett PoC eller ett leksaksprojekt för dig själv är denna projektlayout en överkill. Börja med något riktigt enkelt (en enda main.go – fil är mer än tillräckligt). När ditt projekt växer, kom ihåg att det är viktigt att se till att din kod är välstrukturerad annars kommer du att sluta med en rörig kod med massor av dolda beroenden och globalt tillstånd. När du har fler människor som arbetar med projektet behöver du ännu mer struktur. Det är då det är viktigt att införa ett vanligt sätt att hantera paket / bibliotek. När du har ett open source-projekt eller när du känner till andra projekt importerar koden från ditt projektförråd, då är det viktigt att ha privata (aka internal) paket och kod. Klona förvaret, behåll det du behöver och ta bort allt annat! Bara för att det är där betyder det inte att du måste använda allt. Inget av dessa mönster används i varje enskilt projekt. Även mönstret vendor är inte universellt.

med Go 1.14 Go Modules är äntligen redo för produktion. Använd Go Modules om du inte har en särskild anledning att inte använda dem och om du gör det behöver du inte oroa dig för $GOPATH och var du lägger ditt projekt. Den grundläggande filen go.mod I repo förutsätter att ditt projekt är värd på GitHub, men det är inte ett krav. Modulvägen kan vara vad som helst, men den första modulvägskomponenten ska ha en punkt i sitt namn (den nuvarande versionen av Go verkställer inte den längre, men om du använder lite äldre versioner, bli inte förvånad om dina byggnader misslyckas utan det). Se problem 37554 och 32819 om du vill veta mer om det.

denna projektlayout är avsiktligt Generisk och den försöker inte införa en specifik Go-paketstruktur.

detta är en gemenskap ansträngning. Öppna ett problem om du ser ett nytt mönster eller om du tror att ett av de befintliga mönstren behöver uppdateras.

om du behöver hjälp med namngivning, formatering och stil börja med att köra gofmt och golint. Se också till att läsa dessa riktlinjer och rekommendationer för Go-kodstil:

  • 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
  • stilriktlinje för GO-paket (rakyll/JBD)

se Go Project Layout för ytterligare bakgrundsinformation.

mer om att namnge och organisera paket samt andra rekommendationer kodstruktur:

  • GopherCon EU 2018: Peter Bourgon-bästa praxis för industriell programmering
  • GopherCon Ryssland 2018: Ashley McNamara + Brian Ketelsen – Go bästa praxis.
  • GopherCon 2017: Edward Muller-Go Anti-Patterns
  • GopherCon 2018: Kat Zien – hur strukturerar du dina Go-appar

ett kinesiskt inlägg om riktlinjer för Paketorienterad Design och Arkitekturlager

  • Portuguese

go-kataloger

/cmd

huvudapplikationer för detta projekt.

katalognamnet för varje applikation ska matcha namnet på den körbara filen du vill ha (t.ex. /cmd/myapp).

lägg inte mycket kod i programkatalogen. Om du tror att koden kan importeras och användas i andra projekt, borde den leva i katalogen /pkg. Om koden inte kan återanvändas eller om du inte vill att andra ska återanvända den, lägg den koden i katalogen/internal. Du kommer att bli förvånad över vad andra kommer att göra, så var tydlig om dina avsikter!

det är vanligt att ha en liten main funktion som importerar och åberopar koden från /internal och /pkg kataloger och inget annat.

se katalogen/cmd för exempel.

/ intern

privat applikation och bibliotekskod. Det här är koden du inte vill att andra importerar i sina applikationer eller bibliotek. Observera att detta layoutmönster verkställs av GO-kompilatorn själv. Se Go 1.4 release notes för mer information. Observera att du inte är begränsad till den översta nivån internal katalog. Du kan ha mer än en internal katalog på vilken nivå som helst i ditt projektträd.

Du kan valfritt lägga till lite extra struktur i dina interna paket för att separera din delade och icke-delade interna kod. Det är inte nödvändigt (speciellt för mindre projekt), men det är trevligt att ha visuella ledtrådar som visar den avsedda paketanvändningen. Din faktiska programkod kan gå i katalogen/internal/app (t.ex./internal/app/myapp) och koden som delas av dessa appar i katalogen/internal/pkg (t. ex./internal/pkg/myprivlib).

/Pkg

bibliotekskod som är ok att använda av externa program (t. ex., /pkg/mypubliclib). Andra projekt importerar dessa bibliotek och förväntar sig att de ska fungera, så tänk två gånger innan du lägger något här 🙂 Observera att katalogen internal är ett bättre sätt att se till att dina privata paket inte kan importeras eftersom det verkställs av Go. Katalogen/pkg är fortfarande ett bra sätt att uttryckligen kommunicera att koden i den katalogen är säker för användning av andra. I'll take pkg over internal blogginlägg av Travis Jeffery ger en bra översikt över katalogerna pkg och internal och när det kan vara vettigt att använda dem.

det är också ett sätt att gruppera Go-kod på ett ställe när din rotkatalog innehåller massor av icke – Go – komponenter och kataloger som gör det lättare att köra olika Go – verktyg (som nämns i dessa samtal: Best Practices for Industrial Programming från GopherCon EU 2018, GopherCon 2018: Kat Zien-hur strukturerar du dina Go-appar och GoLab 2018-Massimiliano Pippi-projektlayoutmönster I Go).

se katalogen/pkg om du vill se vilka populära Go repos som använder detta projektlayoutmönster. Detta är ett vanligt layoutmönster, men det är inte allmänt accepterat och vissa I go-communityn rekommenderar det inte.

det är ok att inte använda det om ditt appprojekt är riktigt litet och där en extra nivå av nestning inte ger mycket värde (om du inte verkligen vill :-)). Tänk på det när det blir tillräckligt stort och din rotkatalog blir ganska upptagen (speciellt om du har många icke-Go-appkomponenter).

/vendor

Applikationsberoenden (hanteras manuellt eller av ditt favoritberoende verktyg som den nya inbyggdaGo Modules-funktionen). Kommandotgo mod vendor skapar katalogen/vendor åt dig. Observera att du kan behöva lägga till -mod=vendor flagga till go build kommando om du inte använder Go 1.14 där det är på som standard.

använd inte dina programberoenden om du bygger ett bibliotek.

Observera att eftersom 1.13Go också aktiverade modulproxyfunktionen (medhttps://proxy.golang.org som deras modulproxyserver som standard). Läs mer om det here för att se om det passar alla dina krav och begränsningar. Om det gör det behöver du inte katalogen vendor alls.

Serviceapplikationskataloger

/api

OpenAPI / Swagger-SPECIFIKATIONER, JSON-schemafiler, protokolldefinitionsfiler.

se katalogen/api för exempel.

Webbapplikationskataloger

/ web

Webbapplikationsspecifika komponenter: statiska webbtillgångar, serversidemallar och spa.

vanliga programkataloger

/configs

Konfigurationsfilmallar eller standardkonfigurationer.

Lägg dinaconfd ellerconsul-template mallfiler här.

/init

System init (systemd, uppkomling, sysv) och process manager/handledare (runit, supervisord) configs.

/scripts

skript för att utföra olika bygg, installera, analys, etc operationer.

dessa skript håller rotnivån Makefile liten och enkel (t.ex. https://github.com/hashicorp/terraform/blob/master/Makefile).

se katalogen/scripts för exempel.

/Bygg

förpackning och kontinuerlig Integration.

Lägg dina moln (AMI), Behållare (Docker), OS (deb, rpm, pkg) paketkonfigurationer och skript i katalogen /build/package.

Lägg din CI (travis, circle, drone) konfigurationer och skript i /build/ci katalog. Observera att vissa av CI-verktygen (t. ex., Travis CI) är väldigt kräsen om platsen för deras konfigurationsfiler. Försök att sätta konfigurationsfilerna i katalogen /build/ci som länkar dem till den plats där CI-verktygen förväntar sig dem (när det är möjligt).

/distributioner

IaaS, PaaS, system-och containerorkestreringsinstallationskonfigurationer och mallar (docker-compose, kubernetes / helm, mesos, terraform, bosh). Observera att i vissa repor (särskilt appar som distribueras med kubernetes) kallas denna katalog /deploy.

/ test

ytterligare externa testappar och testdata. Känn dig fri att strukturera/test katalog ändå du vill. För större projekt är det vettigt att ha en datakatalog. Du kan till exempel ha /test/data eller /test/testdata om du behöver gå för att ignorera vad som finns i den katalogen. Observera att Go också ignorerar kataloger eller filer som börjar med “.”eller”_”, så du har mer flexibilitet när det gäller hur du namnger din testdatakatalog.

se katalogen /test för exempel.

andra kataloger

/ docs

Design och användardokument (förutom din godoc-genererade dokumentation).

se katalogen/docs för exempel.

/tools

stödverktyg för detta projekt. Observera att dessa verktyg kan importera kod från katalogerna /pkg och /internal.

se katalogen /tools för exempel.

/exempel

exempel för dina applikationer och / eller offentliga bibliotek.

se katalogen/examples för exempel.

/third_party

externa hjälparverktyg, gaffelkod och andra 3: e parts verktyg (t.ex. Swagger UI).

/githooks

git krokar.

/tillgångar

andra tillgångar att följa med ditt arkiv (bilder, logotyper, etc.).

/website

det här är platsen att placera ditt projekts webbplatsdata om du inte använder GitHub-sidor.

se katalogen/website för exempel.

kataloger du borde inte ha

/src

vissa Go-projekt har ensrc mapp, men det händer vanligtvis när devs kom från Java-världen där det är ett vanligt mönster. Om du kan hjälpa dig själv försök att inte anta detta Java-mönster. Du vill verkligen inte att din Go-kod eller Go-projekt ska se ut som Java: -)

förväxla inte projektnivån/src katalog med/src katalog Go använder för sina arbetsytor som beskrivs iHow to Write Go Code. Miljövariabeln$GOPATH pekar på din (nuvarande) arbetsyta (som standard pekar den på$HOME/go på icke-windows-system). Den här arbetsytan innehåller katalogerna /pkg/bin och /src. Ditt faktiska projekt slutar vara en underkatalog under /src, så om du har katalogen /src I ditt projekt kommer projektvägen att se ut så här: /some/path/to/workspace/src/your_project/src/your_code.go. Observera att med Go 1.11 Det är möjligt att ha ditt projekt utanför ditt GOPATH, men det betyder fortfarande inte att det är bra att använda det här layoutmönstret.

märken

  • gå rapportkort – det kommer att skanna din kod med gofmtgo vetgocyclogolintineffassignlicense och misspell. Ersätt github.com/golang-standards/project-layout med din projektreferens.

    gå rapportkort

  • GoDoc – det kommer att ge online-version av din GoDoc genererade dokumentation. Ändra länken för att peka på ditt projekt.

    gå Doc

  • Pkg.gå.dev-Pkg.gå.dev är en ny destination för Go discovery & docs. Du kan skapa ett märke med hjälp av märkesgenereringsverktyget.

    PkgGoDev

  • släpp – det visar det senaste släppnumret för ditt projekt. Ändra github-länken för att peka på ditt projekt.

    Release

anteckningar

en mer opinionated projektmall med prov/återanvändbara configs, skript och kod är en WIP.

Lämna ett svar

Din e-postadress kommer inte publiceras.