Goで社内ツールを作るならこんなふうに

バックグラウンド 最近企業でにわかにGoの採用が増えているようですね。この流れを受けて実際にうちでも採用してみようと考えている方も多いかもしれません。しかし、Goに限った話ではないのですが、いきなり大きなプロジェクトに未経験の技術を投入するのはリスクが伴います。ですから最初は技術検証とGoの教育を兼ねて、小さな社内ツールなどから導入するのがよいでしょう。幸い、Goは非常に習得が容易な言語ですから、既に他言語の経験があるプログラマーがじゅうぶんに開発できるようになるまでには、数日と掛からないことがほとんどです。 この記事は、そんな小さなツールの導入フェーズにあたって、自らの経験から少し役に立つかもしれない情報をシェアします。 リポジトリの構成 自らの経験上、初めてGoを触れるときによく出る質問の一つは「リポジトリ構成はどうすればいいのか？」です。 結論から申し上げると、 テンプレもルールもな

[send]

俺も極力フラットにしろ派だけど、結構反発されることが多いんだよな

[snowcrush]

基本フラットで良くて必要があればサブパッケージを生やせばいいだけなのに、変なオレオレプラクティスを広める人が多いせいで混乱している気はする

[l-_-ll]

https://tenn.in/go

[oooooooo]

cmd/pkg 構成は 3.5k Stars の https://github.com/golang-standards/project-layout/blob/master/README_ja.md が由来なのかな

[nmcli]

確かに、すぐディレクトリ掘りたくなっちゃう癖ある

[for-my-internet-demo]

さすがにnamesapceないとつらい

[kuenishi]

ディレクトリ構成は統一されてれば何でもいいと思うのだけど、むしろ配布やデプロイをどうしてるかの方が興味がある。特に最初のブートストラップ

[t2hnd]

丁度goで何か作る機運が高まってたのでメモ

[zentarou]

フラットのほうが循環参照気にしなくていいから楽。でもパッケージ名の文脈ないと関数名が長くなりがちなのがなぁ。

[turanukimaru]

基本的にフラットにしてるけど go.mod はパッケージごとに切ってる。依存は常に一方通行になるようにしてるから平気。問題はバージョン管理。go get 失敗しまくる。あーそういや go 1.18 対応まだしてないや…

[everybodyelse]

結構フラット派多いんだな。フラットだと、書き方が悪いとコンポーネントがお互い依存しあってテスト書く時とかつらくならない？

[tettekete37564]

“テンプレもルールもない。自分で考えて決める。” < おっとのっけからフリーダム。ベストプラクティスがないって事？

[kanopen]

参考にしている

[cocoasynn]

基本フラット派だけど最近社内ツールは全部internalにしてる