アドテク x golang勉強会 -オレシカナイトvol.2- に参加してきました

サイバーエージェントが運営するメディアの広告部門である「MDH」のエンジニアが、新規技術に挑戦するにあたって踏んできた地雷を皆様に共有する勉強会です。前回に続き第２回目の開催となります。今回はMDH内でのGO言語を利用した話を中心に、これまでの開発における体験や失敗についてお話しします。

最近は、組み込みシステムをC言語で書くのが辛いので、現実逃避気味にGoとかRustの勉強をしています。

Goは、プログラミング言語Goをざっと読んで、Webの記事を読んで、ちょっぴり手を動かしたレベルの初心者なのですが、今回のイベントではGoを使う現場の声を聞けるとのことで面白そうだと思い参加してきました。

以下、各セッションについてのメモ書きとコメント

1年目でgolangとscalaを触った話

大江善渡氏

片田雄樹氏

DSPって広告配信のプラットフォーム（Demand-Side Platform）のことらしいです。プロセッサではなく…

森拓真氏

（Scalaをかじっていたお陰で話についていけた）

Goで末尾再起最適化はされるのか、検証してみた
呼び出し元をスタックに積む必要がないアルゴリズムは、末尾再帰最適化できる
- Scala コンパイラは、最適化でループに置き換えている
- Rubyでもオプションで、末尾再帰を有効にできる
Goのメーリングリストでは、「Goは一部のケースで末尾再帰最適化できる」とのこと
- しかし実際に検証してみると全く最適化されない
- アセンブリでも末尾再帰最適化されたかチェックした
  - コンパイルオプションで、アセンブリを見れる

再帰で書きたいケースは、Goではどう書けばよいのだろう？？

渋江一晃氏

WebAPIは作ったことがないので、そういうもんなのか〜っていう感じで話を聞いていた
WebAPI書く人にとっては便利なのだろう

確かに、以下をみてみると、APIの仕様とドキュメントを一箇所にかけていて、ここからコードが生成できるのは便利そうだなと思った

公式ドキュメントも日本語化されており、わかりやすい

大澤翔吾氏

アツい方だった。
本発表であったユニットテストで抱える課題は組み込み業界でも同様（より悪質かも）で、発表内容に共感できた

名言が結構あって、私も会社で使わせてもらおうと思った。

簡単なサンプルコードをJavaとGoで書いて、それぞれでテストをどう書くか比較しながら説明。
サンプルコードは、公開

Goがシンプルさを実現するために何を犠牲にしたか
テストの依存性の分離をしないと、別モジュールが壊れても自モジュールが壊れて原因特定が難しくなる
再現性の担保ができないテストは、誰も信用しない
依存性の注入＝外からスタブを入れられること
自動生成など使って、スタブを1行くらいで書けると生産性が高い
- 逆にできないと、テストケースが増えたときに辛い
Javaのリフレクションで、テストしやすい設計ができる
C++でもモックの実行時生成とかできるぽい、
Goはmockgenが使える
- mockgenが生成したモックをファクトリ関数にいれて、依存性を注入したオブジェクトをインスタンスする
Goは機能が少ないぶん、ルールが多い
- テストにおいても、設計で上手いことしないといけない
ユニットテストは、メンテナンスコストと網羅性のトレードオフ
- どこをテストする？自明なところをテストするよりは、コケそうなところをテストすべき
- メンテする価値ある？など振り返ると良い。

Goを製品に取り入れていこう！という選択ができる環境がまず羨ましいと感じた
他の人が書いたコード読みやすいとか、誰が書いてもだいたい統一されるってのは大規模開発する上でメリットでは
モダンな言語だと、ユニットテストも楽々かと思っていたが、意外と課題はあるようだ
- 今回の発表の趣旨が特に課題を共有する部分にあったため、なおさらそう感じたのだと思う
Goは使うところを選べば、パフォーマンスを発揮できそうな言語だという印象が強くなった
- <-> なんでもかんでもGo、というよりは。

プログラミングGoの訳者あとがきを読むと、翻訳の柴田氏は組み込みプロジェクトでGoを導入しテスト駆動で開発していたとある。面白そう…