Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

20171105 go con2017_lt

1,228 views

Published on

GoCon 2017 Autumn

Published in: Internet
  • Be the first to comment

  • Be the first to like this

20171105 go con2017_lt

  1. 1. パッケージ構成っていつでも悩ましい Go Conference 2017 Autumn 2017/11/5 Future Architect Inc, Keigo Suda(@keigodasu)
  2. 2. * エンジニア@FutureArchitect.Inc * ⽇頃はKafka、Sparkとか⼤きなデータを扱うミドルウェアが専⾨ * 「君のJava僕のJava」に疲れてGoを導⼊し始めた 須⽥桂伍 (すだ けいご) @keigodasu ※のちほど英訳版もアップしますm(_ _)m
  3. 3. 最初に結論 l パッケージ構成の⼤切なことはここに書いてある(まずはこれを読め) l そして話すことがなくなった。。。 😇 ü パッケージ構成のパターン ü DDDライクなパッケージ構成実例 ü インタフェースによる実装 ü and more ...
  4. 4. パッケージを決めるための考慮ポイント l ⾒通しの良さ l 機能配置の視認性(どこに何があるか分かる,サイクルインポートさせない作り, ・・・) l テストのやりやすさ(テスト実⾏の単位, ・・・) l 再利⽤のしやすさ l 独⽴して利⽤できる機能 l internalパッケージの利⽤ l 詳細の隠蔽 l パッケージ間の連携はインタフェースで l あげればきりがない・・・
  5. 5. 規模の⼤きなシステムを作る時の選択肢は? 🤔 l ライブラリ系/ミドルウェアはOSSを漁ればお⼿本はたくさんある l こんな感じで作ればいいなっていう勘所は⼗分つかめる l 規模の⼤きいシステムをGo未経験者も含むようなチーム(10⼈~)で作る際の お⼿本はあまりみかけない l GopherCon等含め意外とパッケージ構成のパターンに⾔及してるものは少ない l 本LTでは特にここについてどう考えるようにしているかお話します l インタフェース設計の話などテクニック的な話はないです 🙇
  6. 6. ちまたの流儀? l Golang Package Composition for Web Application: The Case of Mercari Kauru l https://speakerdeck.com/mercari/ja-golang-package-composition-for-web- application-the-case-of-mercari-kauru l Standard Package Layout l https://medium.com/@benbjohnson/standard-package-layout-7cdbc8391fc1 l Go and a Package Focused Design l https://medium.com/@benbjohnson/standard-package-layout-7cdbc8391fc1
  7. 7. でも現実は。。。 😎 l DDDを意識としたパターンが多い気がする l Goとはいえオブジェクト指向的な考えも必要で、メンバ構成次第では機能配置等で維持 メンテ、レビュー⾟い時もある。 l そこそこ⼤きなシステムを経験者/未経験者混合チームで作る時はトランザク ションスクリプトの余地も残しておく必要あってまた悩ましい
  8. 8. どのように判断しているか(Goに限らず) l ⽐較的シンプル/未経験者も多い時はRailsライク(model/controller) l Pros) ちまたのノウハウを取り⼊れやすい/ある程度の同品質を保ちやすい(新規参画者が 馴染みやすい) l Cons) prosの裏返し。⼤きくなるにつれどんどんGoっぽさがなくなってくる感じがする l 経験者が多い時はDDDライク(厳密なDDDではなく・・・)に近づけてく l Pros) Goではみかける事が多く、その点では参考情報も得やすい l Cons) オブジェクト指向的な考え経験がないと維持つらい
  9. 9. 例)センサデータ受け付けるAPIサーバ l ~5⼈(Go経験1⼈/Java経験4⼈)ほどで開発した際のパッケージ構成 l Javaユーザへの導⼊としては意外とはまる(Goらしいかというと、、、) ・ ┗━━ data-uploader ┣━━ main.go ┣━━ api ┃ ┣━━handler.go ┃ ┗━━route.go ┣━━ controller ┃ ┣━━event.go ┃ ┗━━sensor.go ┣━━ service ←作らない時もある ┃ ┣━━ topic_routing.go ┃ ┗━━ ・・・ ┣━━ model ┃ ┣━━event.go ┃ ┗━━sensor.go ┗━━ util ┣━━ xxxutil ┃ ┗━━ ・・・ ┗━━ ・・・ https://www.slideshare.net/keigosuda/iot-72733494 ココのところ
  10. 10. ちなみにパッケージ名どう考える? 🤔 GoPhoerCon 2017 - Go Anti-Patterns
  11. 11. ちなみにパッケージ名どう考える? 🤔 l encodingパッケージなども例としてわかりやすい
  12. 12. ほんとすいません🙇🙇🙇🙇🙇🙇🙇🙇🙇 Golang UK Conference 2016 - Building an enterprise service in Go GoPhoerCon 2017 - Go Anti-Patterns l よく使われているのには理由がある? l これぐらいのよくあるネーミングの⽅が未経験ユーザへの導⼊はしやすい?
  13. 13. まとめ l 新規導⼊時など、ときにはGoに⼊ればGoに従わない勇気も必要なシーンも 多々あった l もっとパッケージ構成の⽣々しいノウハウやパターンが発信されるといいのかも Golang UK 2016 keynote Dave Cheney
  14. 14. ありがとうございました!!

×