lightair/project-layout
1
0
Fork 0
mirror of https://github.com/golang-standards/project-layout.git synced 2026-05-09 09:06:07 +00:00
Code Issues Projects Releases Wiki Activity

improve Japanese in README_ja.md (#275)

Browse Source
This commit is contained in:
Sora Daibu
2026-04-28 19:09:18 +02:00
committed by GitHub
parent 0be11592f7
commit 284b21dc70
1 changed files with 5 additions and 5 deletions
Download Patch File Download Diff File Expand all files Collapse all files

10
README_ja.md
View File

@@ -24,11 +24,11 @@
## 概要 ## 概要
これは、Goアプリケーションプロジェクトの基本的なレイアウトです。これは、コアとなるGo開発チームによって定義された公式の標準ではありませんが、Goエコシステムの中で、歴史的に共通しているプロジェクトのレイアウトパターンのセットとなっています。これらのパターンの中には、他のパターンよりも人気のあるものもあります。また、現実世界の大規模なアプリケーションに共通するいくつかのサポートディレクトリに加えて、いくつかの小さな機能強化が行われています。 これはGoアプリケーションプロジェクトの基本的なレイアウトです。`コアとなるGo開発チームによって定義された公式の標準ではありません`が、Goエコシステムの中で、歴史的に共通しているプロジェクトのレイアウトパターンのセットです。これらのパターンの中には、他のパターンよりも人気のあるものもあります。また、現実世界の大規模なアプリケーションに共通するいくつかのサポートディレクトリに加えて、いくつかの小さな機能強化が行われています。
Goを学ぼうとしている場合や、自分でPoCやおもちゃのプロジェクトを構築しようとしている場合、このプロジェクトレイアウトはやりすぎです。最初は本当にシンプルなものから始めてください（`main.go`ファイルが1つあれば十分です）。プロジェクトが大きくなるにつれて、コードが適切に構造化されているかどうかが重要になることに注意してください。そうしないと、多くの隠れた依存関係やグローバルな状態を持つ厄介なコードになってしまいます。プロジェクトで作業する人が増えれば、さらに多くの構造が必要になります。そこで、パッケージやライブラリを管理するための共通の方法を導入することが重要になります。オープンソースプロジェクトがある場合や、他のプロジェクトがプロジェクトリポジトリからコードをインポートしていることを知っている場合は、プライベートな(内部的な)パッケージやコードを持つことが重要になります。リポジトリをクローンして、必要なものだけを残し、他のものはすべて削除してください。リポジトリにあるからといって、すべてを使わなければならないわけではありません。これらのパターンはすべてのプロジェクトで使われているわけではありません。`vendor`パターンでさえも、万能ではありません。 Goを学ぼうとしている場合や、自分でPoCや簡単なプロジェクトを構築しようとしている場合、このプロジェクトレイアウトはやりすぎです。最初は本当にシンプルなものから始めてください（`main.go`ファイルが1つあれば十分です）。プロジェクトが大きくなるにつれて、コードが適切に構造化されているかどうかが重要になることに注意してください。そうしないと、多くの隠れた依存関係やグローバルな状態を持つ厄介なコードになってしまいます。プロジェクトで作業する人が増えれば、さらに多くの構造が必要になります。そこで、パッケージやライブラリを管理するための共通の方法を導入することが重要になります。オープンソースプロジェクトがある場合や、他のプロジェクトがプロジェクトリポジトリからコードをインポートしていることを知っている場合は、プライベートな(`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 のバージョンではもうこれを強制していませんが、少し古いバージョンを使っているのであれば、これを付けなくてもビルドが失敗しても驚かないでください)。これについて詳しく知りたい場合は、Issue [`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 でホストされていることを前提としていますが、Githubである必要はありません。モジュールパスは何でも構いませんが、最初のモジュールパスコンポーネントの名前にはドットを付けてください (現在の Go のバージョンではもうこれを強制していませんが、少し古いバージョンを使っているのであれば、これを付けないとビルドが失敗する可能性があります)。これについて詳しく知りたい場合は、Issue [`37554`](https://github.com/golang/go/issues/37554) と [`32819`](https://github.com/golang/go/issues/32819) を参照してください。
このプロジェクトは意図的に一般的なレイアウトを使用しており、特定のGoパッケージを押し付けているわけではありません。 このプロジェクトは意図的に一般的なレイアウトを使用しており、特定のGoパッケージを押し付けているわけではありません。
@@ -68,7 +68,7 @@ Go 1.14では、[`Go Modules`](https://go.dev/wiki/Modules)がついに本番に
### `/internal` ### `/internal`
プライベートなアプリケーションやライブラリのコード。これは、他の人が自分のアプリケーションやライブラリにインポートしたくないコードです。このレイアウトパターンは、Goコンパイラによって強制されることに注意してください。詳細については、Go 1.4の[`リリースノート`](https://golang.org/doc/go1.4#internalpackages)を参照してください。トップレベルの内部ディレクトリに限定されないことに注意してください。プロジェクトツリーのどのレベルでも、複数の内部ディレクトリを持つことができます。 プライベートなアプリケーションやライブラリのコード。これは他の人が自分のアプリケーションやライブラリにインポートしたくないコードです。このレイアウトパターンは、Goコンパイラによって強制されることに注意してください。詳細については、Go 1.4の[`リリースノート`](https://golang.org/doc/go1.4#internalpackages)を参照してください。トップレベルの内部ディレクトリに限定されないことに注意してください。プロジェクトツリーのどのレベルでも、複数の内部ディレクトリを持つことができます。
オプションで、内部パッケージに少し余分な構造を追加して、共有内部コードと非共有内部コードを分離することができます。(特に小規模なプロジェクトでは) 必須ではありませんが、パッケージの使用目的を示す視覚的な手がかりがあるのは良いことです。実際のアプリケーションコードは `/internal/app` ディレクトリ (例: `/internal/app/myapp`) に、それらのアプリケーションで共有されるコードは `/internal/pkg` ディレクトリ (例: `/internal/pkg/myprivlib`) に置くことができます。 オプションで、内部パッケージに少し余分な構造を追加して、共有内部コードと非共有内部コードを分離することができます。(特に小規模なプロジェクトでは) 必須ではありませんが、パッケージの使用目的を示す視覚的な手がかりがあるのは良いことです。実際のアプリケーションコードは `/internal/app` ディレクトリ (例: `/internal/app/myapp`) に、それらのアプリケーションで共有されるコードは `/internal/pkg` ディレクトリ (例: `/internal/pkg/myprivlib`) に置くことができます。
@@ -185,7 +185,7 @@ GitHubページを使用していない場合は、プロジェクトのWebサ
### `/src` ### `/src`
Goプロジェクトの中には `src` フォルダを持っているものもありますが、これは通常、開発者が一般的なパターンであるJavaの世界から来た場合に起こります。可能であれば、このようなJavaのパターンを採用しないようにしてください。あなたのGoコードやGoプロジェクトがJavaのように見えることは本当に避けてください。 Goプロジェクトの中には `src` フォルダを持っているものもありますが、これは開発者がJavaの世界から来た場合によく起こるパターンです。可能であれば、このようなJavaのパターンを採用しないようにしてください。あなたのGoコードやGoプロジェクトがJavaのように見えることは避けてください。
プロジェクトレベルの `/src` ディレクトリと、[`Goコードの書き方`](https://golang.org/doc/code.html)で説明されているように、Go がワークスペースに使用する `/src` ディレクトリを混同しないようにしてください。環境変数 `$GOPATH` は、(現在の)ワークスペースを指します (Windows 以外のシステムでは、デフォルトでは `$HOME/go` を指します)。このワークスペースには、トップレベルの `/pkg`, `/bin`, `/src` ディレクトリが含まれています。実際のプロジェクトは `/src` の下のサブディレクトリになりますので、プロジェクト内に `/src` ディレクトリがある場合、プロジェクトのパスは以下のようになります。`/some/path/to/workspace/src/your_project/src/your_code.go` のようになります。Go 1.11 では、プロジェクトを `GOPATH` の外に置くことができますが、このレイアウトパターンを使うのが良いというわけではないことに注意してください。 プロジェクトレベルの `/src` ディレクトリと、[`Goコードの書き方`](https://golang.org/doc/code.html)で説明されているように、Go がワークスペースに使用する `/src` ディレクトリを混同しないようにしてください。環境変数 `$GOPATH` は、(現在の)ワークスペースを指します (Windows 以外のシステムでは、デフォルトでは `$HOME/go` を指します)。このワークスペースには、トップレベルの `/pkg`, `/bin`, `/src` ディレクトリが含まれています。実際のプロジェクトは `/src` の下のサブディレクトリになりますので、プロジェクト内に `/src` ディレクトリがある場合、プロジェクトのパスは以下のようになります。`/some/path/to/workspace/src/your_project/src/your_code.go` のようになります。Go 1.11 では、プロジェクトを `GOPATH` の外に置くことができますが、このレイアウトパターンを使うのが良いというわけではないことに注意してください。