Future Tech Blog
フューチャー技術ブログ
Programmingカテゴリ

Goのフラットパッケージについて登壇しました

はじめに

TIG真野です。

2021/3/19(金)にFuture Tech Night #7 〜フューチャーの開発事例と共に学べるGo勉強会〜 を開催しました。

トップバッターでGoの開発構成・アプリアーキテクチャについて話したので報告します。

なお、その他の登壇者の資料はこちら に公開済み。他の登壇者のレポートはこちらです。

発表内容：Goでフラットパッケージを導入してみて良かったこと、これから

フューチャー技術ブログで、GoのWebアプリ開発でフラットパッケージにした話 という記事を公開した内容の改定版になります。なぜフラットパッケージに至ったかの経緯についてなるべく自分がたどった経路を細かに説明することを意識しました。

かなり挑戦的で大胆な設計だったとおもいますが、一定の賛同（？）をいただけて嬉しかったです。

発表資料でも記載の通り、何事もトレードオフがあると思いますが、フラットパッケージがハマる領域も少なからずあるかと思いますので、活用して頂けると嬉しいです。

発表で話せなかったこと

15分枠だと話せなかったことがいくつかあるので、補足しておきます。

  • パッケージ構造がどうこうより、テストが大変です
    • これは業務系システムの開発者だとけっこう同意してくれると思うのですが、カバレッジ・テスト密度やらをある程度指標に持って品質を見ていこうとすると、けっこうなテスト数、テストコード量になると思います
      • スクロールをどれだけしても、Table Driven Tesingのテーブル宣言部分が終わらないとかザラです
    • 特に業務システム系だと、マスタデータの種類が多く、テストのデータパターンをかなり考える必要があります
    • モックでデータパターンを考えようが、実際のDBを使おうが正直大変さは同じですが、込み入ったデータを作るときは実際のDBを用いれたほうがいっそ楽だという視点もあるかなと思います
  • 大きくなると破綻しない？
    • 5~10人で1年以上開発を続けていますが、今のところは大丈夫です
    • 正直複雑化するのはパッケージ構造ではなく、データパターンとか業務ロジックそのものなので、パッケージ構造だから破綻というのは現時点だと自分のチームだと想定しにくく、もし本当に巨大になるのであればリポジトリごと分けるので大丈夫かなと思います
  • 次にGoで新規開発するときもフラットパッケージにするか？
    • 規模感やドメインにもよりますが選択できるのであれば多分すると思います
      • 現実的には他の開発者の好みや考えもあると思うので、1つの意見として出すレベルかと思います
  • モデルにテストを寄せている話
    • どうしても外部サービスに対して、テストケースや関数毎にデータ登録すると速度が遅くなります
    • handlerレベルのテストケースが肥大化しないために、なるべくmodelにロジックを寄せて、model単位でテストするようにしています
      • modelは外界へのアクセスが基本的にないので、関数の引数・戻り値で検証可能。go-cmpで行っています

反省点

Zoomで開催していて質問をもらうスタイルでしたが、中にはTwitterでハッシュタグ付きでコメントしてくれた人もいました。私もよく行うスタイルですが完全に見逃していて、全部終わったあとに気が付きました。次回からはそちらも拾うようにします。

また、最後に座談会のような時間があったのですが、発表後の放心状態からうまく登壇者同士でワイワイ話すことができませんでした。今後は第三者のモデレータ？ のような人を置くなどで改善したいと思います。

さいごに

聞き飽きた？ 感じもあるGoのパッケージですが、意外とフラットな構造でもいけるぞって発表でした。

フューチャーは2020年から社内の知見を発信して少しでも皆様のお役に建てるように、ブログだけではなく勉強会も積極的に開催していこうとしています。こちらの記事にあるように、年間の計画をたてています。ぜひウォッチしていただければです。