#2でアーキテクチャとテストについて考えるチーム開発で、Goに本格的に取り組むことになって少し経ったところなのですが、最近Goで気になっているのはアーキテクチャまわりとテストだったので、その点に注目して参加してきた。ゲーム業界はタイトル毎の要求項目が細かく違いそうなモノだけど、かなり難しいのではなかろうか...と思ったが、いわゆるガチャも共有の仕組みの一つのよう。収益の本流も共通なら、なるほど必要だろうなぁ。サーバをGoにした理由は、学習コスト対効果が良いから。具体的に他のどの言語やフレームワークとの比較で学習コストが低かったのかを聞きそびれてしまった。Spannerとのことなので、このあたりはゲーム用基盤として最適化されていて便利そう。getして利用するあたりは、package単位で利用するGoの利便性が際立っているように思える。このあたり、package設計は重要なポイントだろうと思う。できるかぎり自動化をがんばるProtocolBufferはなかなか良いとの推しを頂く。インターフェースだけでなく、ドキュメント生成もできるらしい。generateを使う方向で検討していたが、今回の勉強会ではgenerateの話は一切無かった。コード量が多いと言われるGoにあって、できる限りの自動化はやりたいところ。本番用のコードにgoタグつけるのが嫌なので、テスト用に同じ構造体を自動生成してる前者は順当な話。テストの実施に必要なデータは冪等性を担保すべきだ。並列テストにおけるfakerはなかなか便利そう。テストデータを用意する上で省エネが図れるなら試す価値はあるかも。本番用のコードにgoタグつけるのが嫌このあたりは非常に意見が割れそうだが、そのテストだけのために同一構造体自体をテスト用に自動生成するのは気合入った話だと思う。gomockを使って、テスト中はmockをDIする。会社のセキュリティポリシーとしてDBの暗号化+カラムの暗号化アーキテクチャのお話で、レイヤードアーキテクチャを採用しているとのこと。ディレクトリは割と素直な名付けになっている。噂によるとメルカリさんもレイヤードアーキテクチャらしい。ぼくのチームはクリーンアーキテクチャで進めているため、読み替えができれば大きな違いは無し。導入メリットは、やはり変更時の影響分離が大きいところだそう。エンベロープ暗号は聞いたことが無かったのでこれは別途調べる。そのほかいろんな方面から耳にした内容。サンプル数の少ない情報として、あくまでメモ程度。Infrastructure層のテストは実際のFirestoreを叩きに行っているとのお話がありローカルシミュレータの挙動がちょっと...ということのようだが、テストを回す毎にお金がかかるのとパフォーマンス効率の面では厳しい部分がある。本番の環境を叩きに行くテストのメリットはあり、悩ましいところのようだ。firstと言われている段階なので時期尚早なのかもしれない。エディタはみんな好きにやってる最近になって、VSCodeはコード補完(LSP)が良い感じに向上してきたようで増えてきた模様。JetBrainsは独自の補完を実装しており、それが爆速(らしい)。Goでテストの可読性を上げるためにはテーブルドリブンテストはおすすめ。データや期待値は.golden拡張子で定義することができる。RDBMSのいい感じのデファクトORMはなさそうが、黒魔術感がなく薄めのORMとして構造体の受け渡しができるsqlxは良さそう。CやRubyを書いていた人がGoも触れているというところから、参入コストは低い。Goはそもそもコード量は多い。そのため、チーム開発ではコードの自動生成をどうするか真面目に考える必要がある。プロダクトやチーム規模によるが、サービスの改善を行うためにもドメインの分離をするためにもアーキテクチャは大事。コード量増加は辛く折れそうになるが自動化と気合で乗り切る。Goのテストはテーブルドリブンの導入やツール類を駆使することで可読性は随分違う。DeNAさんの勉強会は選べるお弁当、選べるドリンクが豊富であたまが下がる思い。ハッカーの「サイバー攻撃日誌」が読めたらレ...builderscon初参加しました。ハッカーの「サイバー攻撃日誌」が読めたらレポ月別アーカイブはてなブログをはじめよう!yospigさんは、はてなブログを使っています。ブログを報告するスターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。