golang.tokyo #1 行ってきたメモ

2016/10/25にメルカリで行われたgolang.tokyo #1に行ってきたメモ
http://golangtokyo.connpass.com/event/39965/

Twitterのハッシュタグは #golangtokyo

知らない名前がたくさん出てきて半分以上聞き漏らした

メンバーのGo教育

• レビューでGoっぽくない書き方を指摘するときは、blogとか外部の資料を参照して指摘する（レビュワー個人の意見ではなく一般的な点だと伝える）

IDEやデバッグ

• vim, InteliJ, Atom, emacs
  • だいたい何かしらプラグインがある
• 会場内でデバッガ使ってる人はあまりいなかった
• Bleveっていうのがあるらしい

コーディング規約は？ レビューの指針は？ golintに従ってます？

• 変数名は簡潔にする（Goの文化）
  • でも事業ドメインなコードを書く場合どうしても説明的になっちゃうのは仕方ない
• 正規表現のMustCompileの使い方
• golintは対応しておこう
  • ただし辛い場合はベストエフォートで。
  • golint使っとくと、いけないコードをパートナーに指摘するときに言いやすい。

Webフレームワーク・テンプレートエンジン・ORM

• gin
• https://github.com/go-xorm/xorm
• https://github.com/flosch/pongo2
• テンプレートについては、そもそもフロントエンドはreactとかangular任せな場合が多い

エラー処理どうしてますか？

• pkg/errors
  • 外部ライブラリがまともなエラーを返さない場合にいい感じにwrapしよう
• errgroup
• 必須なものがないとかいう場合は積極的にpanic使おう

goのお手本になりそうなもの

• https://github.com/aws/aws-sdk-go
• https://github.com/google/go-github
• kaneshin「俺のGitHubを見ろ！」
  • https://github.com/kaneshin

ロガー

• logrus
• zap
• http://www.fluentd.org/

パッケージ分け

責務で分けたい？機能で分けたい？

• ドメイン単位で切る
  • ニュース、ユーザーとかのドメインで分けてその中でデザインパターン
• internalパッケージはライブラリを作るのでなければ使わない方がいい

テスト周り

• GAE向けのアプリ使う場合でも、出来るだけgo本体だけで完結するようなロジックにして疎にしておく
• テスティングフレームワーク使わない(testingのみ)
  • テストのためだけのミニ言語を覚えるとかめんどいし、後からのメンバーの受け入れコストもある
• 出来るだけDBのテストは書かない
  • データはすべてinterfaceを定義しておけばモックできる
• できるだけDB立ててテストするべきだよ派も

デプロイまでのフローとか工夫してる点、CI

• goは基本ビルドが早い
  • 循環インポートとか周りから依存されまくってるパッケージが変わるとキャッシュが使われずフルビルド走っちゃう。ビルドが遅い場合は設計が悪いかも。
  • kaneshin「そういう事があって、ペアーズのビルドは遅くなっちゃってる。別に一人で書いてるやつは早いけどね！」
• 本番ビルドはChatOpsで3回コマンド叩かないといけない、とか
  • 3回の中で他メンバーのチェックを入れるようにしたり

pprof使ってる？本番のモニタリングとかチューニングとか

• pprofでなくdd
• stringを+で繋ぐな、とか地味なやつ

リファクタしたいところ／Goのイマイチな点

• テンプレートエンジン…
• timeのフォーマット…

---

メモ

パッケージの分け方について

Golangのパッケージの分け方やディレクトリ構成は benbjohnsonの https://t.co/9wKKDlHW6O と Peter Bourgonの https://t.co/PMI4zFT155 が決定版ですかね．今の所は． #golangtokyo

— Taichi Nakashima (@deeeet) October 25, 2016