Să presupunem că ați citit articolul meu „Starting a Go Project”, ar trebui să aveți punctul de plecare pentru un serviciu web Go minim. Pentru primul proiect este mai ușor să păstrați tot codul într-un singur folder, la baza proiectului, dar la un moment dat veți dori să restructurați lucrurile, acest lucru se face din câteva motive:
- Având totul într-un singur folder rezultă o mulțime de interdependențe în cod.
- Reutilizarea în afara proiectului poate fi dificilă, deoarece codul este conceput pentru a fi utilizat doar într-un singur pachet.
- Este imposibil să aveți mai mult de un binar, deoarece puteți avea doar o singură metodă
main.
Această postare va oferi o prezentare generală a structurii pe care o urmez în proiectele mele Go atunci când construiesc servicii web.
Nota: Dacă construiți doar o bibliotecă pentru a o folosi în serviciile dvs. sau pentru a o împărtăși cu alții, este în regulă să puneți totul în folderul de bază al proiectului dvs., un exemplu în acest sens este biblioteca mea dynastore.
/cmd
Acest dosar conține fișierele principale ale punctului de intrare al aplicației pentru proiect, numele directorului corespunzând cu numele pentru binar. Astfel, de exemplu cmd/simple-service, ceea ce înseamnă că binarul pe care îl vom publica va fi simple-service.
/internal
Acest pachet conține codul bibliotecii private utilizate în serviciul dumneavoastră, este specific funcției serviciului și nu este partajat cu alte servicii. Un lucru de reținut este că această confidențialitate este impusă de compilatorul însuși, consultați notele de lansare Go 1.4 pentru mai multe detalii.
/pkg
Acest folder conține codul care este OK pentru ca alte servicii să îl consume, acesta poate include clienți API sau funcții de utilitate care pot fi utile pentru alte proiecte, dar care nu justifică propriul proiect. Personal, prefer să folosesc acest lucru în loc de internal, în principal pentru că îmi place să păstrez lucrurile deschise pentru reutilizare în majoritatea proiectelor.
Structura proiectului
În timp ce vă construiți proiectul există câteva obiective foarte importante pe care ar trebui să le luați în considerare atunci când vine vorba de modul în care vă structurați pachetele:
- Păstrați coerența lucrurilor
- Păstrați lucrurile cât mai simple posibil, dar nu mai simple
- Cuplați ușor secțiunile serviciului sau aplicației
- Încercați să vă asigurați că este ușor de navigat
În general, atunci când începeți, ar trebui să experimentați puțin, să încercați câteva idei diferite atunci când vă construiți primul și să obțineți un feedback pe baza obiectivelor de mai sus.
Obiectivul numărul unu este să construiți un software ușor de întreținut, coerent și fiabil.
Exemplu
Vă recomand să aruncați o privire la exitus pentru a vedea cum îmi structurez proiectele, majoritatea codului se află în folderul pkg, fiecare subdirector având unul sau mai multe fișiere. De la nivelul superior este destul de clar la ce se referă fiecare pachet și, deși este slab la teste, are câteva exemple.
$ tree exitus/ exitus/ exitus/├─── cmd│ ├─── authtest│ │ └─── main.go│ ├── backend│ │ └──── main.go│ └─ client│ └─ main.go├─ dev│ ├─ add_migration.sh│ └─ docker-compose.yml├─ Dockerfile├─ go.mod├─ go.sum│ ├─ 20190721131113_extensions.down.sql│ ├─ 20190721131113_extensions.up.sql│ ├─ 20190723044115_customer_projects.down.sql│ ├─ 20190723044115_customer_projects.up.sql│ ├─ 20190726175158_issues.down.sql│ ├── 20190726175158_issues.up.sql│ ├─ 20190726201649_comments.down.sql│ ├─ 20190726201649_comments.up.sql│ ├─ bindata.go│ ├─── migrations_test.go│ └─ README.md├─── pkg│ ├─ api│ │ ├─ exitus.gen.go│ │ ├─ exitus.yml│ │ └─ gen.go│ ├─── auth│ │ ├─ scopes.go│ └─ utilizator.go│ ├─ conf│ │ ├─ conf.go│ │ └─ conf_test.go│ ├── db│ │ ├─ db.go│ │ ├─ db.go│ │ ├─ dbtesting.go│ │ ├─── migrate.go│ │ ├── sqlhooks.go│ │ │ └─ tranzacții.go│ ├─── env│ │ └──── env.go│ ├─ healthz│ │ ├─ healthz.go│ │ └─── healthz_test.go│ ├─── jwt│ │ └─── jwt.go│ ├── metrics│ │ └─── metrics.go│ ├── middleware│ │ └─── middleware.go│ ├─ oidc│ │ └──── client.go│ ├──── server│ ├─ reflect.go│ └─ server.go│ └─ store│ ├─── comments.go│ ├── comments_test.go│ ├── comments_test.go│ ├─ customers.go│ ├─ customers_test.go│ ├─ issues.go│ ├─ issues_test.go│ ├─ migrate_test.go│ ├─ projects.go│ ├─ projects_test.go│ ├─ projects_test.go│ └─ store.go└─── README.md
Scopul aici este de a ilustra modul în care vă dezvoltați proiectul de la câteva fișiere, la un serviciu web mai mare. Vă încurajez să parcurgeți proiectele de pe github și să cercetați modul în care alți dezvoltatori le-au structurat pe ale lor și, mai presus de toate, să le încercați singuri!
- GopherCon EU 2018: Peter Bourgon – Cele mai bune practici pentru programare industrială
- Standard Go Project Layout
- GopherCon 2018: Cat Seeing – Cum vă structurați aplicațiile Go
Feedback
Nu ezitați să ne contactați prin:
- @ me on Twitter
- Send me an Email
- Starting a Go Project
- Building a WLToys A979 donkey car
- Guilding a WLToys A979 donkey car
- Getting started with Cognito?
- De ce CDK?
- Serverless Background jobs part 2
.