2016年10月25日火曜日

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

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

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

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

ロガー

パッケージ分け

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

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

テスト周り

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

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

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

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

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

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

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

メモ

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