improve Belarusian translation from machine-generated to human-readable (#263)

* improve Belarusian translation from machine-generated to human-readable

* use more consistent vocabulary
This commit is contained in:
Edvin Dulko 2024-11-06 23:46:11 +01:00 committed by GitHub
parent 608700a5b7
commit 20f4258478
No known key found for this signature in database
GPG Key ID: B5690EEEBB952194
18 changed files with 76 additions and 76 deletions

View File

@ -19,7 +19,7 @@ Translations:
* [Indonesian](README_id.md)
* [हिन्दी](README_hi.md)
* [فارسی](README_fa.md)
* [Беларускі](README_by.md)
* [Беларуская](README_by.md)
## Overview

View File

@ -19,30 +19,30 @@
* [Indonesian](README_id.md)
* [हिन्दी](README_hi.md)
* [فارسی](README_fa.md)
* [Беларускі](README_by.md)
* [Беларуская](README_by.md)
## Агляд
Гэта базавая структура для праектаў прыкладанняў на Go. Звярніце ўвагу, што яна базавая з пункту гледжання змесціва, бо засяроджваецца толькі на агульнай структуры і не ўлічвае тое, што знаходзіцца ўнутры. Яна таксама базавая таму, што вельмі высокага ўзроўню і не паглыбляецца ў дэталі таго, як можна яшчэ больш структуравана арганізаваць ваш праект. Напрыклад, яна не спрабуе ахапіць структуру праекта з чымсьці накшталт Чыстай Архітэктуры.
Гэта базавая структура для праектаў праграм на Go. Звярніце ўвагу, што яна базавая з пункту гледжання зместу, бо канцэнтруецца толькі на агульнай структуры, а не тым, што ўнутры. Яна таксама базавая таму, што вельмі высокага ўзроўню і не паглыбляецца ў дэталі таго, як можна яшчэ больш структуравана арганізаваць ваш праект. Напрыклад, яна не спрабуе ахапіць структуру на ўзор чагосьці накшталт Чыстай Архітэктуры.
Гэта **`НЕ афіцыйны стандарт, вызначаны асноўнай камандай распрацоўшчыкаў Go`**. Гэта набор агульных гістарычных і новых шаблонаў размяшчэння праектаў у экасістэме Go. Некаторыя з гэтых шаблонаў больш папулярныя за іншыя. Ён таксама ўключае шэраг невялікіх удасканаленняў разам з некалькімі дапаможнымі каталогамі, якія звычайна сустракаюцца ў любым дастаткова вялікім рэальным дадатку. Звярніце ўвагу, што асноўная **каманда Go дае выдатны набор агульных рэкамендацый па структурыраванні праектаў на Go** і што гэта азначае для вашага праекта пры яго імпарце і ўсталёўцы. Глядзіце старонку [`Арганізацыя модуля Go`](https://go.dev/doc/modules/layout) ў афіцыйнай дакументацыі Go для атрымання больш падрабязнай інфармацыі. Яна ўключае ўзоры каталогаў `internal` і `cmd` (апісаныя ніжэй) і іншую карысную інфармацыю.
Гэта **`НЕ афіцыйны стандарт, вызначаны асноўнай камандай распрацоўшчыкаў Go`**. Гэта набор агульных гістарычных і новых шаблонаў размяшчэння праектаў у экасістэме Go. Некаторыя з гэтых шаблонаў больш папулярныя за іншыя. Ён таксама ўключае шэраг невялікіх удасканаленняў разам з некалькімі дапаможнымі каталогамі, якія звычайна сустракаюцца ў любым дастаткова вялікай рэальнай праграме. Звярніце ўвагу, што асноўная **каманда Go дае выдатны набор агульных рэкамендацый па структурыраванні праектаў на Go** і што гэта азначае для вашага праекта пры яго імпарце і ўсталёўцы. Глядзіце старонку [`Арганізацыя модуля Go`](https://go.dev/doc/modules/layout) ў афіцыйнай дакументацыі Go для больш падрабязнай інфармацыі. Яна ўключае ўзоры каталогаў `internal` і `cmd` (апісаныя ніжэй) і іншую карысную інфармацыю.
**`Калі вы спрабуеце вывучыць Go або ствараеце PoC ці просты праект для сябе, гэтая структура праекта з'яўляецца празмернасцю. Пачніце з чагосьці сапраўды простага (адзін `main.go` файл і `go.mod` больш чым дастаткова).`** Па меры росту вашага праекта памятайце, што важна пераканацца, што ваш код добра структураваны, у адваротным выпадку вы атрымаеце блытаны код з мноствам схаваных залежнасцей і глабальным станам. Калі ў вас будзе больш людзей, якія працуюць над праектам, вам спатрэбіцца яшчэ большая структура. Вось тады важна ўвесці агульны спосаб кіравання пакетамі/бібліятэкамі. Калі ў вас ёсць адкрыты крынічны праект або калі вы ведаеце іншыя праекты імпартуюць код з вашага рэпазіторыя проекта - вось тады важна мець прыватныя (гэта значыць `internal`) пакеты і код. Кланіруйце рэпазіторый, захавайце тое, што вам трэба і выдаліце ўсё астатняе! Толькі таму што яно там ёсць не азначае што вам трэба выкарыстоўваць усё гэта. Ні адзін з гэтых шаблонаў не выкарыстоўваецца ва ўсіх без выключэннях праектах. Нават шаблон `vendor` не універсальны.
**`Калі вы спрабуеце вывучыць Go або ствараеце PoC ці просты праект для сябе, гэтая структура праекта з'яўляецца празмернасцю. Пачніце з чагосьці сапраўды простага (адзін `main.go` файл і `go.mod` больш чым дастаткова).`** Па меры росту вашага праекта памятайце, што важна пераканацца, што ваш код добра структураваны, у адваротным выпадку вы атрымаеце блытаны код з мноствам схаваных залежнасцей і глабальным станам. Калі над праектам будзе працаваць больш людзей, вам спатрэбіцца яшчэ большая структура. Вось тады важна ўвесці агульны спосаб кіравання пакетамі/бібліятэкамі. Калі ў вас ёсць праект з адкрытым зыходным кодам або вы ведаеце што іншыя праекты імпартуюць код з рэпазіторыя вашага праекта - вось тады важна мець прыватныя (`internal`) пакеты і код. Кланіруйце рэпазіторый, захавайце тое, што вам трэба і выдаліце ўсё астатняе! Толькі таму што яно там ёсць не азначае што вам усё гэта патрэбна. Ніводзен з гэтых шаблонаў не выкарыстоўваецца ва ўсіх без выключэннях праектах. Нават шаблон `vendor` не універсальны.
З Go 1.14 [`Go Modules`](https://go.dev/wiki/Modules) нарэшце гатовыя для вытворчасці. Выкарыстоўвайце [`Go Modules`](https://blog.golang.org/using-go-modules), калі ў вас няма канкрэтнай прычыны не выкарыстоўваць іх, і калі вы гэта робіце, то вам не трэба турбавацца пра $GOPATH і дзе размясціць ваш праект. Асноўны файл `go.mod` у рэпазіторыі мяркуе, што ваш праект размешчаны на GitHub, але гэта не з'яўляецца абавязковым патрабаваннем. Шлях модуля можа быць любым, хоць першы кампанент шляху модуля павінен мець кропку ў сваім назве (цяперашняя версія Go больш гэтага не патрабуе, але калі вы карыстаецеся крыху старэйшымі версіямі - не здзіўляйцеся, калі вашы зборкі будуць няўдалымі без яе). Глядзіце Issues [`37554`](https://github.com/golang/go/issues/37554) і [`32819`](https://github.com/golang/go/issues/32819) для атрымання дадатковай інфармацыі.
З Go 1.14 [`Go Modules`](https://go.dev/wiki/Modules) нарэшце гатовыя да ўжытку. Выкарыстоўвайце [`Go Modules`](https://blog.golang.org/using-go-modules), калі ў вас няма канкрэтнай прычыны не выкарыстоўваць іх, а калі і ёсць, то вам не трэба турбавацца пра $GOPATH і дзе размясціць ваш праект. Асноўны файл `go.mod` у рэпазіторыі разлічвае, што ваш праект размешчаны на GitHub, але гэта не абавязковае патрабаванне. Шлях модуля можа быць любым, хоць першы кампанент шляху модуля павінен мець кропку ў сваёй назве (цяперашняя версія Go больш гэтага не патрабуе, але калі вы карыстаецеся крыху старэйшымі версіямі - не здзіўляйцеся, калі сабраць праект без яе не ўдасца). Глядзіце Issues [`37554`](https://github.com/golang/go/issues/37554) і [`32819`](https://github.com/golang/go/issues/32819) для дадатковай інфармацыі.
Гэты макет праекта наўмысна агульны і не спрабуе навязаць канкрэтную структуру пакета Go.
Гэты шаблон праекта наўмысна агульны і не спрабуе навязаць канкрэтную структуру пакета Go.
Гэта намаганне супольнасці. Адкрыйце пытанне, калі заўважыце новы ўзор або лічыце, што адзін з існуючых узораў трэба абнавіць.
Гэта намаганне супольнасці. Адкрыйце issue, калі знойдзеце новы ўзор або лічыце, што адзін з існуючых трэба абнавіць.
Калі вам патрэбна дапамога з назвай, фарматаваннем і стылем, пачніце з запуску [`gofmt`](https://golang.org/cmd/gofmt/) і [`staticcheck`](https://github.com/dominikh/go-tools/tree/master/cmd/staticcheck). Папярэдні стандартны лінтар golint цяпер састарэў і не падтрымліваецца; рэкамендуецца выкарыстоўваць падтрымліваемы лінтар, такі як staticcheck. Таксама пераканайцеся, што вы прачыталі гэтыя рэкамендацыі па стылі кода Go:
Калі вам патрэбна дапамога з назвай, фарматаваннем і стылямі, пачніце з запуску [`gofmt`](https://golang.org/cmd/gofmt/) і [`staticcheck`](https://github.com/dominikh/go-tools/tree/master/cmd/staticcheck). Папярэдні стандартны лінтар golint цяпер састарэў і не падтрымліваецца; рэкамендуецца выкарыстоўваць лінтар які падтрымліваецца, такі як staticcheck. Таксама пераканайцеся, што вы прачыталі гэтыя стайлгайды для Go:
* https://talks.golang.org/2014/names.slide
* https://golang.org/doc/effective_go.html#names
* https://blog.golang.org/package-names
* https://go.dev/wiki/CodeReviewComments
* [Кіраўніцтва па стылі для пакетаў Go](https://rakyll.org/style-packages) (rakyll/JBD)
Глядзіце [`макет праекта Go`](https://medium.com/golang-learn/go-project-layout-e5213cdcfaa2) для дадатковай фонавай інфармацыі.
Глядзіце [`шаблон праекта Go`](https://medium.com/golang-learn/go-project-layout-e5213cdcfaa2) для дадатковай інфармацыі.
Больш пра найменне і арганізацыю пакетаў, а таксама іншыя рэкамендацыі па структуры кода:
* [GopherCon EU 2018: Пітэр Бургон - Лепшыя практыкі для прамысловага праграмавання](https://www.youtube.com/watch?v=PTE4VJIdHPg)
@ -50,72 +50,72 @@
* [GopherCon 2017: Эдвард Мюлер - Анты-шаблоны ў Go](https://www.youtube.com/watch?v=ltqV6pDKZD8)
* [GopherCon 2018: Кат Зіен - Як структуравать вашы Go прыкладанні](https://www.youtube.com/watch?v=oL6JBUk6tj0)
Кітайскі пост пра кіруючыя прынцыпы Package-Oriented-Design і архітэктурны пласт
Кітайскі пост пра прынцыпы Package-Oriented-Design і архітэктурны слой
* [Пакетна-арыентаваны дызайн і архітэктурнае напластаванне](https://github.com/danceyoung/paper-code/blob/master/package-oriented-design/packageorienteddesign.md)
## Go каталогi
### `/cmd`
Асноўныя прыкладанні для гэтага праекта.
Асноўныя прымяненні для гэтага праекта.
Назва каталога для кожнай праграмы павінна адпавядаць назве выканальнага файла, які вы хочаце мець (напрыклад, `/cmd/myapp`).
Назва каталога для кожнай праграмы павінна адпавядаць назве выканальнага файла (напрыклад, `/cmd/myapp`).
Не змяшчайце шмат кода ў каталог прыкладання. Калі вы лічыце, што код можна імпартаваць і выкарыстоўваць у іншых праектах, ён павінен знаходзіцца ў каталогу `/pkg`. Калі код не можа быць паўторна выкарыстаны або калі вы не хочаце, каб іншыя яго выкарыстоўвалі, змясціце гэты код у каталог `/internal`. Вы будзеце здзіўлены тым, што зробяць іншыя, таму дакладна выражайце свае намеры!
Не змяшчайце шмат кода ў каталог праграмы. Калі вы лічыце, што код можна імпартаваць і выкарыстоўваць у іншых праектах, ён павінен знаходзіцца ў каталогу `/pkg`. Калі код не можа быць паўторна выкарыстаны або калі вы не хочаце, каб іншыя яго выкарыстоўвалі, змясціце гэты код у каталог `/internal`. Вы бы здзівіліся, што іншыя бы зрабілі, таму ясна выражайце свае намеры!
Звычайна мець невялікую `main` функцыю, якая імпартуе і выклікае код з каталогаў `/internal` і `/pkg`, і больш нічога.
Распаўсюджаная практыка мець невялікую `main` функцыю, якая імпартуе і выклікае код з каталогаў `/internal` і `/pkg`, і больш нічога.
Глядзіце каталог [`/cmd`](cmd/README.md) для прыкладаў.
Прыклады ў каталогу [`/cmd`](cmd/README.md).
### `/internal`
Прыватны код прыкладання і бібліятэкі. Гэта код, які вы не хочаце, каб іншыя імпартавалі ў свае прыкладанні або бібліятэкі. Звярніце ўвагу, што гэты шаблон размяшчэння забяспечваецца самім кампілятарам Go. Глядзіце [`нататкі да выпуску`](https://golang.org/doc/go1.4#internalpackages) Go 1.4 для больш падрабязнай інфармацыі. Заўважце, што вы не абмежаваныя толькі верхнім узроўнем `internal` каталога. Вы можаце мець больш за адзін `internal` каталог на любым узроўні вашага дрэва праектаў.
Прыватны код праграмы і бібліятэкі. Гэта код, які вы не хочаце, каб іншыя імпартавалі ў свае праграмы або бібліятэкі. Звярніце ўвагу, што гэты шаблон размяшчэння забяспечваецца самім кампілятарам Go. Глядзіце [`нататкі да выпуску`](https://golang.org/doc/go1.4#internalpackages) Go 1.4 для больш падрабязнай інфармацыі. Заўважце, што вы не абмежаваныя толькі верхнім узроўнем `internal` каталога. Вы можаце мець больш за адзін `internal` каталог на любым узроўні вашага дрэва праекта.
Вы можаце дадаткова дадаць трохі структуры ў вашы ўнутраныя пакеты, каб аддзяліць агульны і неагульны ўнутраны код. Гэта не абавязкова (асабліва для меншых праектаў), але прыемна мець візуальныя падказкі, якія паказваюць на меркаванае выкарыстанне пакета. Ваш фактычны код прыкладання можа знаходзіцца ў каталогу `/internal/app` (напрыклад, `/internal/app/myapp`), а код, які выкарыстоўваецца гэтымі праграмамі - у каталогу `/internal/pkg` (напрыклад,`/internal/pkg/myprivlib`).
Вы можаце дадаткова дадаць трохі структуры ў вашы ўнутраныя пакеты, каб аддзяліць агульны і неагульны ўнутраны код. Гэта не абавязкова (асабліва для меншых праектаў), але прыемна мець візуальныя падказкі, якія паказваюць на запланаванае выкарыстанне пакета. Ваш фактычны код праграмы можа знаходзіцца ў каталогу `/internal/app` (напрыклад, `/internal/app/myapp`), а код, які выкарыстоўваецца гэтымі праграмамі - у каталогу `/internal/pkg` (напрыклад,`/internal/pkg/myprivlib`).
Вы выкарыстоўваеце ўнутраныя каталогі, каб зрабіць пакеты прыватнымі. Калі вы размяшчаеце пакет унутры ўнутранага каталога, то іншыя пакеты не могуць яго імпартаваць, калі яны не маюць агульнага продка. І гэта адзіны каталог, названы ў дакументацыі Go і мае спецыяльную апрацоўку кампілятарам.
Вы выкарыстоўваеце `internal` каталогі, каб зрабіць пакеты прыватнымі. Калі вы размяшчаеце пакет унутры `internal` каталога, то іншыя пакеты не могуць яго імпартаваць, калі яны не маюць агульнага продка. І гэта адзіны каталог, названы ў дакументацыі Go, які мае спецыяльную апрацоўку кампілятарам.
### `/pkg`
Код бібліятэкі, які можна выкарыстоўваць знешнімі праграмамі (напрыклад, `/pkg/mypubliclib`). Іншыя праекты будуць імпартаваць гэтыя бібліятэкі, разлічваючы на іх працу, таму двойчы падумайце перад тым, як размясціць тут нешта 😃 Звярніце ўвагу, што `internal` каталог - лепшы спосаб забяспечыць недаступнасць вашых прыватных пакетаў для імпарту, бо гэта забяспечваецца Go. Каталог `/pkg` па-ранейшаму добры спосаб выразна паведаміць аб бяспецы кода ў гэтым каталогу для выкарыстання іншымі. Блог-паведамленне [`I'll take pkg over internal`](https://travisjeffery.com/b/2019/11/i-ll-take-pkg-over-internal/) Трэвіса Джэферы дае добры агляд каталогаў `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/) Трэвіса Джэферы дае добры агляд каталогаў `pkg` і `internal` і калі ёсць сэнс іх выкарыстоўваць.
Гэта таксама спосаб згрупаваць код Go ў адным месцы, калі ваш каранёвы каталог утрымлівае шмат кампанентаў і каталогаў, якія не з'яўляюцца Go, што палягчае запуск розных інструментаў Go (як згадваецца ў гэтых дакладах: [`Лепшыя практыкі для прамысловага праграмавання`](https://www.youtube.com/watch?v=PTE4VJIdHPg) з GopherCon EU 2018, [`GopherCon 2018: Кат Зіен - Як структураваны вашы прыкладанні на Go`](https://www.youtube.com/watch?v=oL6JBUk6tj0) і [`GoLab 2018 - Масімільяна Піппі - Шаблоны размяшчэння праектаў у Go`](https://www.youtube.com/watch?v=3gQa1LWwuzk)).
Гэта таксама спосаб згрупаваць код Go ў адным месцы, калі ваш каранёвы каталог утрымлівае шмат не-Go кампанентаў і каталогаў, што палягчае запуск розных інструментаў Go (як згадваецца ў гэтых дакладах: [`Лепшыя практыкі для прамысловага праграмавання`](https://www.youtube.com/watch?v=PTE4VJIdHPg) з GopherCon EU 2018, [`GopherCon 2018: Кат Зіен - Як структураваны вашы праграмы на Go`](https://www.youtube.com/watch?v=oL6JBUk6tj0) і [`GoLab 2018 - Масімільяна Піппі - Шаблоны размяшчэння праектаў у 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`
Залежнасці прыкладання (кіруюцца ўручную або з дапамогай вашага любімага інструмента кіравання залежнасцямі, як новая ўбудаваная функцыя [`Go Modules`](https://go.dev/wiki/Modules) feature)). Каманда `go mod vendor` створыць для вас каталог `/vendor`. Звярніце ўвагу, што вам можа спатрэбіцца дадаць сцяг `-mod=vendor` у вашу каманду `go build`, калі вы не выкарыстоўваеце Go 1.14, дзе ён уключаны па змаўчанні.
Залежнасці праграмы (кіруюцца ўручную або з дапамогай вашага любімага інструмента кіравання залежнасцямі, як новая ўбудаваная функцыя [`Go Modules`](https://go.dev/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`.
Звярніце ўвагу, што з версіі [`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` увогуле не спатрэбіцца.
## Каталёгі заяў на абслугоўванне
## Каталогі cервісных праграм
### `/api`
Спецыфікацыі OpenAPI/Swagger, файлы схем JSON, файлы вызначэння пратаколу.
Спецыфікацыі OpenAPI/Swagger, файлы схем JSON, файлы вызначэння пратаколаў.
Глядзіце каталог [`/api`](api/README.md) для прыкладаў.
Прыклады ў каталогу [`/api`](api/README.md).
## Каталёгі вэб-прыкладанняў
## Каталогі вэб-праграм
### `/web`
Кампаненты, спецыфічныя для вэб-прыкладанняў: статычныя вэб-актывы, шаблоны на баку сервера і SPA.
Кампаненты, спецыфічныя для вэб-праграм: статычныя файлы, шаблоны для апрацоўкі з боку сервера і SPA (аднастаронкавыя праграмы).
## Агульныя каталогі прыкладанняў
## Агульныя каталогі праграм
### `/configs`
Шаблоны файлаў канфігурацыі або стандартныя налады.
Шаблоны файлаў канфігурацыі або стандартныя канфігурацыі.
Пакладзіце свае файлы шаблонаў `confd` або `consul-template` сюды.
ае файлы шаблонаў размясціце ў `confd` або `consul-template`.
### `/init`
@ -123,53 +123,53 @@
### `/scripts`
Скрыпты для выканання розных аперацый зборкі, ўстаноўкі, аналізу і г.д.
Скрыпты для выканання розных аперацый зборкі, ўсталёўкі, аналізу і г.д.
Гэтыя скрыпты захоўваюць файл Makefile на коранёвым узроўні маленькім і простым (напрыклад, [`https://github.com/hashicorp/terraform/blob/main/Makefile`](https://github.com/hashicorp/terraform/blob/main/Makefile)).
Гэтыя скрыпты пакідаюць файл каранёвы Makefile маленькім і простым (напрыклад, [`https://github.com/hashicorp/terraform/blob/main/Makefile`](https://github.com/hashicorp/terraform/blob/main/Makefile)).
Глядзіце каталог [`/scripts`](scripts/README.md) для прыкладаў.
Прыклады ў каталогу [`/scripts`](scripts/README.md).
### `/build`
Ўпакоўка і бесперапынная інтэграцыя.
Зборка і бесперапынная інтэграцыя (Continuous Integration, CI).
Змесціце вашыя канфігурацыі і скрыпты воблака (AMI), кантэйнера (Docker), пакета аперацыйнай сістэмы (deb, rpm, pkg) у каталог `/build/package`.
Змясціце вашыя канфігурацыі і скрыпты пакетаў воблака (AMI), кантэйнера (Docker), аперацыйнай сістэмы (deb, rpm, pkg) у каталогу `/build/package`.
Змясціце вашы канфігурацыі і скрыпты CI (travis, circle, drone) у каталог `/build/ci`. Звярніце ўвагу, што некаторыя інструменты CI (напрыклад, Travis CI) вельмі патрабавальныя да размяшчэння сваіх файлаў канфігурацыі. Паспрабуйце змясціць файлы канфігурацыі ў каталог `/build/ci` з спасылкай на месца, дзе інструменты CI чакаюць іх знайсці (калі гэта магчыма).
Змясціце вашы канфігурацыі і скрыпты CI (travis, circle, drone) у каталогу `/build/ci`. Звярніце ўвагу, што некаторыя інструменты CI (напрыклад, Travis CI) вельмі капрызныя да размяшчэння сваіх файлаў канфігурацыі. Cпрабуйце змясціць файлы канфігурацыі ў каталогу `/build/ci` з спасылкай на месца, дзе інструменты CI чакаюць іх знайсці (калі гэта магчыма).
### `/deployments`
IaaS, PaaS, канфігурацыі разгортвання аркестрацыі сістэм і кантэйнераў і шаблоны (docker-compose, kubernetes/helm, terraform). Звярніце ўвагу, што ў некаторых рэпазіторыях (асабліва прыкладаннях, разгорнутых з дапамогай kubernetes) гэты каталог называецца `/deploy`.
IaaS, PaaS, канфігурацыі разгортвання аркестрацыі сістэм і кантэйнераў і шаблоны (docker-compose, kubernetes/helm, terraform). Звярніце ўвагу, што ў некаторых рэпазіторыях (асабліва праграмах, разгорнутых з дапамогай kubernetes) гэты каталог называецца `/deploy`.
### `/test`
Дадатковыя знешнія тэставыя праграмы і тэставыя даныя. Вы можаце свабодна структуравать каталог `/test` так, як вам зручна. Для большых праектаў мае сэнс мець падкаталог для даных. Напрыклад, вы можаце мець `/test/data` або `/test/testdata`, калі вам трэба, каб Go ігнараваў тое, што знаходзіцца ў гэтым каталогу. Звярніце ўвагу, што Go таксама будзе ігнараваць каталоги або файлы, якія пачынаюцца з "." або "_", таму ў вас ёсць большая гнуткасць у тым, як называць ваш каталог тэставых даных.
Дадатковыя знешнія тэставыя праграмы і тэставыя даныя. Вы можаце свабодна структуравать каталог `/test` так, як вам зручна. Для большых праектаў мае сэнс мець падкаталог для даных. Напрыклад, вы можаце мець `/test/data` або `/test/testdata`, калі вам трэба, каб Go ігнараваў тое, што знаходзіцца ў гэтым каталогу. Звярніце ўвагу, што Go таксама будзе ігнараваць каталогі або файлы, якія пачынаюцца з "." або "_", таму ў вас ёсць большая гнуткасць у тым, як называць ваш каталог тэставых даных.
Глядзіце каталог [`/test`](test/README.md) для прыкладаў.
Прыклады ў каталогу [`/test`](test/README.md).
## Other Directories
### `/docs`
Дызайн і дакументы карыстальніка (у дадатак да вашай дакументацыі, створанай godoc).
Дызайн і дакументы карыстальніка (у дадатак да вашай дакументацыі, згенераванай godoc).
Глядзіце каталог [`/docs`](docs/README.md) для прыкладаў.
Прыклады ў каталогу [`/docs`](docs/README.md).
### `/tools`
Інструменты падтрымкі для гэтага праекта. Звярніце ўвагу, што гэтыя інструменты могуць імпартаваць код з каталогаў `/pkg` і `/internal`.
Глядзіце каталог [`/tools`](tools/README.md) для прыкладаў.
Прыклады ў каталогу [`/tools`](tools/README.md).
### `/examples`
Прыклады для вашых прыкладанняў і/або публічных бібліятэк.
Прыклады для вашых праграм і/або публічных бібліятэк.
Глядзіце каталог [`/examples`](examples/README.md) для прыкладаў.
Прыклады ў каталогу [`/examples`](examples/README.md).
### `/third_party`
Знешнія дапаможныя інструменты, раздвоены код і іншыя ўтыліты трэціх бакоў (напрыклад, Swagger UI).
Знешнія дапаможныя інструменты, раздвоены код і іншыя зьнешнія ўтыліты (напрыклад, Swagger UI).
### `/githooks`
@ -177,40 +177,40 @@ Git хукі.
### `/assets`
Іншыя актывы, якія суправаджаюць ваш рэпазітарый (малюнкі, лагатыпы і г.д.).
Іншыя файлы, якія суправаджаюць ваш рэпазітарый (малюнкі, лагатыпы і г.д.).
### `/website`
Гэта месца для размяшчэння дадзеных вашага праекта, калі вы не выкарыстоўваеце GitHub Pages.
Гэта месца для размяшчэння даных вашага праекта, калі вы не выкарыстоўваеце GitHub Pages.
Глядзіце каталог [`/website`](website/README.md) для прыкладаў.
Прыклады ў каталогу [`/website`](website/README.md).
## Каталогі, якіх у вас не павінна быць
### `/src`
Некаторыя праекты на Go сапраўды маюць тэчку `src`, але гэта звычайна адбываецца, калі распрацоўшчыкі прыйшлі з Java-свету, дзе гэта агульная схема. Калі вы можаце дапамагчы сабе, паспрабуйце не прымаць гэты шаблон Java. Вы сапраўды не хочаце, каб ваш код на Go або праекты на Go выглядалі як Java 😃
Некаторыя праекты на Go сапраўды маюць тэчку `src`, але гэта звычайна адбываецца, калі распрацоўшчыкі прыйшлі з Java-свету, дзе гэта агульная схема. Калі не цяжка, паспрабуйце не прымаць гэты шаблон Java. Вы сапраўды не хочаце, каб ваш код на Go або праекты на Go выглядалі як Java 😃
Не блытайце каталог `/src` на ўзроўні праекта з каталогам `/src`, які Go выкарыстоўвае для сваіх працоўных асяроддзяў, як апісана ў [`Як пісаць код на Go`](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`, але гэта ўсё роўна не азначае, што добрая ідэя выкарыстоўваць гэты шаблон размяшчэння.
Не блытайце каталог `/src` на ўзроўні праекта з каталогам `/src`, які Go выкарыстоўвае для сваіх працоўных асяроддзяў, як апісана ў [`Як пісаць код на Go`](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`, але гэта ўсё роўна не робіць гэты шаблон размяшчэння добрым.
## Значкі
* [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/) - праскануе ваш код праз `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. Змяніце спасылку, каб паказваць на ваш праект.~~
* ~~[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 - гэта новае месца для адкрыцця і дакументацыі Go. Вы можаце стварыць значок, выкарыстоўваючы [інструмент генерацыі значкоў](https://pkg.go.dev/badge).
* [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)
* Release - Ён пакажа апошні нумар рэлізу для вашага праекта. Змяніце спасылку на GitHub, каб паказваць на ваш праект.
* Release - пакажа апошні нумар рэлізу для вашага праекта. Змяніце спасылку на 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)
## Нататкі
Больш меркаваная шаблон праекта з узорамі/павторна выкарыстоўваемымі канфігурацыямі, скрыптамі і кодам знаходзіцца ў распрацоўцы.
Больш смелы шаблон праекта з узорамі, паўторна выкарыстоўваемымі канфігурацыямі, скрыптамі і кодам знаходзіцца ў распрацоўцы.

View File

@ -19,7 +19,7 @@ Traducciones:
* [Українська](README_ua.md)
* [Indonesian](README_id.md)
* [हिन्दी](README_hi.md)
* [Беларускі](README_by.md)
* [Беларуская](README_by.md)
## Resumen

View File

@ -19,7 +19,7 @@ Traductions:
* [Українська](README_ua.md)
* [Indonesian](README_id.md)
* [हिन्दी](README_hi.md)
* [Беларускі](README_by.md)
* [Беларуская](README_by.md)
## Introduction

View File

@ -20,7 +20,7 @@
* [正體中文](README_zh-TW.md)
* [简体中文](README_zh.md)
* [English](README.md)
* [Беларускі](README_by.md)
* [Беларуская](README_by.md)
## अवलोकन

View File

@ -16,7 +16,7 @@ Terjemahan:
* [Українська](README_ua.md)
* [Indonesian](README_id.md)
* [हिन्दी](README_hi.md)
* [Беларускі](README_by.md)
* [Беларуская](README_by.md)
## Ringkasan

View File

@ -16,7 +16,7 @@ Traduzioni:
* [Українська](README_ua.md)
* [Indonesian](README_id.md)
* [हिन्दी](README_hi.md)
* [Беларускі](README_by.md)
* [Беларуская](README_by.md)
## Panoramica

View File

@ -19,7 +19,7 @@
* [Українська](README_ua.md)
* [Indonesian](README_id.md)
* [हिन्दी](README_hi.md)
* [Беларускі](README_by.md)
* [Беларуская](README_by.md)
## 概要

View File

@ -19,7 +19,7 @@
* [Українська](README_ua.md)
* [Indonesian](README_id.md)
* [हिन्दी](README_hi.md)
* [Беларускі](README_by.md)
* [Беларуская](README_by.md)
## 개요

View File

@ -19,7 +19,7 @@ Traduções:
* [Українська](README_ua.md)
* [Indonesian](README_id.md)
* [हिन्दी](README_hi.md)
* [Беларускі](README_by.md)
* [Беларуская](README_by.md)
## Visão geral

View File

@ -19,7 +19,7 @@ Traduceri:
* [Українська](README_ua.md)
* [Indonesian](README_id.md)
* [हिन्दी](README_hi.md)
* [Беларускі](README_by.md)
* [Беларуская](README_by.md)
## General

View File

@ -19,7 +19,7 @@
* [Українська](README_ua.md)
* [Indonesian](README_id.md)
* [हिन्दी](README_hi.md)
* [Беларускі](README_by.md)
* [Беларуская](README_by.md)
## Обзор

View File

@ -19,7 +19,7 @@
* [Українська](README_ua.md)
* [Indonesian](README_id.md)
* [हिन्दी](README_hi.md)
* [Беларускі](README_by.md)
* [Беларуская](README_by.md)
## Genel Bakış:

View File

@ -16,7 +16,7 @@ Translations:
* [Українська](README_ua.md)
* [Indonesian](README_id.md)
* [हिन्दी](README_hi.md)
* [Беларускі](README_by.md)
* [Беларуская](README_by.md)
## Огляд

View File

@ -16,7 +16,7 @@ Các bản dịch:
* [Türkçe](README_tr.md)
* [Vietnamese](README_vi.md)
* [हिन्दी](README_hi.md)
* [Беларускі](README_by.md)
* [Беларуская](README_by.md)
## Tổng quan

View File

@ -17,7 +17,7 @@
* [Українська](README_ua.md)
* [Indonesian](README_id.md)
* [हिन्दी](README_hi.md)
* [Беларускі](README_by.md)
* [Беларуская](README_by.md)
这是Go应用程序项目的基础布局。这不是Go核心开发团队定义的官方标准无论是在经典项目还是在新兴的项目中这都是Go生态系统中一组常见的项目布局模式。这其中有一些模式比另外的一些更受欢迎。它通过几个支撑目录为任何足够大规模的实际应用程序提供一些增强功能。

View File

@ -19,7 +19,7 @@
* [Українська](README_ua.md)
* [Indonesian](README_id.md)
* [हिन्दी](README_hi.md)
* [Беларускі](README_by.md)
* [Беларуская](README_by.md)
這是 Go 應用程式專案的基本目錄結構。它不是核心 Go 開發團隊定義的官方標準;然而,它是 Go 生態系統中一組常見的老專案和新專案的目錄結構。其中一些目錄結構比其他目錄結構更受歡迎。這個專案目錄結構還有一些細微的改進,可以支援任何大型且實用的應用程式目錄結構。

View File

@ -19,7 +19,7 @@
* [Українська](README_ua.md)
* [Indonesian](README_id.md)
* [हिन्दी](README_hi.md)
* [Беларускі](README_by.md)
* [Беларуская](README_by.md)
这是 Go 应用程序项目的基本布局。它不是核心 Go 开发团队定义的官方标准;然而,它是 Go 生态系统中一组常见的老项目和新项目的布局模式。其中一些模式比其他模式更受欢迎。它还具有许多小的增强,以及对任何足够大的实际应用程序通用的几个支持目录。