Ce diaporama a bien été signalé.
Nous utilisons votre profil LinkedIn et vos données d’activité pour vous proposer des publicités personnalisées et pertinentes. Vous pouvez changer vos préférences de publicités à tout moment.

20171105 go con2017_lt

1 598 vues

Publié le

GoCon 2017 Autumn

Publié dans : Internet
  • Soyez le premier à commenter

  • Soyez le premier à aimer ceci

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. ありがとうございました!!

×