Alai

Zakładając, że przeczytałeś mój post o rozpoczynaniu projektu Go, powinieneś mieć punkt wyjścia dla minimalnej usługi internetowej Go. Dla twojego pierwszego projektu łatwiej jest trzymać cały kod w jednym folderze, w bazie twojego projektu, ale w pewnym momencie będziesz chciał zrestrukturyzować rzeczy, jest to robione z kilku powodów:

• Mając wszystko w jednym folderze powoduje wiele zależności w kodzie.
• Ponowne użycie poza projektem może być trudne, ponieważ kod jest przeznaczony tylko do użycia w jednym pakiecie.
• Niemożliwe jest posiadanie więcej niż jednej binarki, ponieważ możesz mieć tylko jedną main metodę.

Ten post zapewni przegląd struktury, której używam w moich projektach Go podczas budowania usług sieciowych.

Uwaga: Jeśli po prostu budujesz bibliotekę do użycia w swoich usługach, lub dzielisz się z innymi, dobrze jest umieścić wszystko w folderze bazowym projektu, przykładem tego jest moja biblioteka dynastore.

/cmd

Ten folder zawiera pliki głównego punktu wejścia aplikacji dla projektu, z nazwą katalogu pasującą do nazwy binarnej. Tak więc na przykład cmd/simple-service oznacza, że binarka, którą opublikujemy będzie simple-service.

/internal

Ten pakiet przechowuje prywatny kod biblioteki używany w twojej usłudze, jest on specyficzny dla funkcji usługi i nie jest współdzielony z innymi usługami. Jedną rzeczą do zauważenia jest to, że ta prywatność jest wymuszana przez sam kompilator, zobacz noty wydania Go 1.4 po więcej szczegółów.

/pkg

Ten folder zawiera kod, który jest OK dla innych usług do wykorzystania, może to obejmować klientów API lub funkcje użytkowe, które mogą być przydatne dla innych projektów, ale nie uzasadniają własnego projektu. Osobiście wolę używać tego niż internal, głównie dlatego, że lubię utrzymywać rzeczy otwarte do ponownego użycia w większości projektów.

Struktura projektu

Jak budujesz swój projekt, są pewne bardzo ważne cele, które powinieneś rozważyć, jeśli chodzi o to, jak układasz swoje pakiety:

• Keep things consistent
• Keep things as simple as possible, but no simpler
• Loose couple sections of the service or application
• Aim to ensure it is easy to navigate your way around

Overall when getting started you should experiment bit, try a few different ideas when building out your first and get some feedback on based on on the above goals.

Celem numer jeden jest budowanie łatwego w utrzymaniu, spójnego i niezawodnego oprogramowania.

Przykład

Zalecam spojrzeć na exitus aby zobaczyć jak strukturyzuję moje projekty, większość kodu znajduje się w folderze pkg z każdym podfolderem posiadającym jeden lub więcej plików. Z najwyższego poziomu jest całkiem jasne, do czego odnosi się każdy pakiet, i chociaż nie jest on oparty na testach, ma kilka przykładów.

$ tree 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│ ├─ 201907201649_comments.up.sql│ ├─ bindata.go│ ├── migrations_test.go│ └─ README.md├── pkg│ ├─ api│ │ ├─ exitus.gen.go│ │ ├─ exitus.yml│ │ └─ gen.go│ ├── auth│ │ ├─ scopes.go│ └─ user.go│ ├─ conf│ │ ├─ conf.go│ │ └─ conf_test.go│ ├── db│ │ ├─ db.go│ │ ├─ dbtesting.go│ │ ├── migrate.go│ │ ├── sqlhooks.go│ │ └─ transactions.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│ ├─ customers.go│ ├─ customers_test.go│ ├─ issues.go│ ├─ issues_test.go│ ├─ migrate_test.go│ ├─ projects.go│ ├─ projects_test.go│ └─ store.go└─── README.md

Celem jest tutaj zilustrowanie, jak rozwijać swój projekt od kilku plików, do większego serwisu internetowego. Zachęcam do przejrzenia projektów na githubie i sprawdzenia, jak inni programiści zbudowali swoje, a przede wszystkim do wypróbowania tego samemu!

• GopherCon EU 2018: Peter Bourgon – Best Practices for Industrial Programming
• Standard Go Project Layout
• GopherCon 2018: Cat Seeing – How Do You Structure Your Go Apps

Feedback

Feel free to reach out via:

• @ me on Twitter
• Send me an Email

• Starting a Go Project
• Building a WLToys A979 donkey car
• Getting started with Cognito?
• Dlaczego CDK?
• Bezserwerowe zadania w tle cz. 2

Więcej o