あなたのGoアプリ/ライブラリのパッケージ構成もっとシンプルでよくない？ | フューチャー技術ブログ

Goでプロジェクトのフォルダ構成どうしよう、とググると見つかるStandard Go Project Layout。とはいえ、これはかなりコード量を増やしてしまう恐れがありますので、導入する場合のデメリットも考えておく方が良いです。 特に、プログラマーは、最初にみたプログラミング言語のフォルダ構成を親だと思う特性があり、Javaや.NETに影響されるとかなり細かくフォルダを切りたくなったり、package privateなど細かく可視性を制御しようとしたりして、なおかつ「privateのテストってどうすべきなんですか？」とか議論を始めたりもしますが、Go先生によればこれぐらいは1パッケージにファイルをぶっこんでもいいわけです。勇気を持ちましょう。 本エントリーでは、小中規模のGoプロジェクト、あるいは小さいところから少しずつ育てていく上でのパッケージ構成について紹介します。すでにメンバーが

[p1ass]

それな “特に、プログラマーは、最初にみたプログラミング言語のフォルダ構成を親だと思う特性があり”

[digo]

循環参照めんどいから結構フラットにしていてそれは良いのだけど名前が長くなりがちなのよね。ファイルスコープとかnamespace的なのが欲しい

[tasshi820]

さぁ何か書こうって時にStandard Go Project Layoutはやりすぎじゃない？って思ってた民なので共感した。

[mapyo]

良さそう！

[cynipe]

わかる “人はルールを作るときは厳しめのルールの方がいい、と思ってしまいがちです。”

[snowcrush]

main以外全部ルートに置くのが一番スッキリするんだけど、ソースファイルを整理するためにディレクトリで分けたくなるのよね。

[yujiorama]

はまった事があることばかり書いてある。Makefile についてはどうなんだろう

[dededidou]

これは(駄目な意味で)ヤバい、公式ドキュメントを読めといいたい

[send]

golang の場合はなるべくフラットになるようにしたほうがいいと思ってる

[zentarou]

割り切ってこそのGo

[roshi]

モデリング界隈の用語定義の残念さは確かに。golangはシンプル維持でそういうのやりたければscalaとか向いてる言語でやる方がいいと思う。

[kuenishi]

経験知だ

[mano-junki]

Goのパッケージ論。そんなに複雑にしなくてフラットで良いんじゃない？って話