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を見ろ!」
ロガー
- 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