Go in Corporate Solutions Engineering

Go in Corporate Solutions Engineering

mercari.go #5

Ff822949384025796e11fd7f681df060?s=128

Katsuhiro OGAWA

January 08, 2019
Tweet

Transcript

  1. Go in Corporate Solutions Engineering mercari.go #5 / @fivestar

  2. 自己紹介

  3. 小川 雄大 (OGAWA Katsuhiro) • @fivestar • CSE 所属 •

    Backend Engineering アーキテクト • 2018/1/1 入社 • 得意な言語は PHP • 前職は Ancar Inc. / CTO
  4. CSE について 今日のトピック 01 プロダクトと開発チーム体制 02 Backend of People Products

    03 開発の歩み 04 技術的課題 05
  5. CSE について

  6. 4 Corporate Solutions Engineering チーム “Solving business challenges with engineering”

    経営課題をエンジニアリングで解決する
  7. • 2017/11 に元メルカリ CTO・VPoE の @sotarok により立ち上げ ◦ 初期名称は Corporate

    Engineering チーム • 組織課題の解決にフォーカスしたエンジニアチーム • メルカリアプリの開発チームからは独立 ◦ メルカリのバリューを活かしつつ独自のチーム文化を形成 生い立ち
  8. 2018 /01 3人 / 1ドメイン プロダクト開発が始まる 2月には人数が倍に 2018 /07 15人

    / 3ドメイン 2018 /12 26人 / 4ドメイン IIT から新卒加入 CSE チームの変遷 PM 加入 チーム名を CSE に変更
  9. ビジネスドメイン People Products 人と組織のデータベース、人事評価 Accounting Products 会計システム、連結決算、会計監査レポート Communication & Knowledge

    Wiki PR & Branding コーポレート Web
  10. プロダクトと 開発チーム体制

  11. People Products Teams 人と組織のデータベース Reviews 人事評価システム Benefits インセンティブマネジメント

  12. Frontend / Backend Frontend フレームワークは プロダクトごとに選定 REST API Backend

  13. People Products 開発チーム体制 • エンジニアリングマネージャー (EM) / 2人 • プロダクトマネージャー

    (PM) / 2人 • ソフトウェアエンジニア / 11人 • QAエンジニア / 1人 • デザイナー / 2人
  14. • 担当領域 ◦ プロダクトあるいはエピックごとに担当をつける ◦ ある程度流動的 • 技術領域 ◦ 多くのメンバーは

    Frontend/Backend 両方やる エンジニアリングチーム体制
  15. • Frontend / Backend それぞれにアーキテクトが1人 ◦ 一部 Tech Lead のロールを兼任

    ◦ プロダクト横断でアーキテクチャに責任を持つ • コードもめっちゃ書く アーキテクト
  16. • 月に1度、2日に渡って技術的課題解決に注力する ◦ リファクタリングやドキュメンテーションなど ◦ PM ではなくエンジニアがオーナーシップを持つ • EM も参加

    DevDay
  17. Backend of People Products

  18. Backend 基本構成 • アプリケーション ◦ Go 製の API • インフラ

    ◦ メルカリの Microservices プラットフォーム ◦ MySQL (CloudSQL)
  19. Backend アーキテクチャ • REST API • Entity Model • Repository

    • Service (Usecase)
  20. REST フレームワーク • BEAR.Sunday respected • Handler を Resource 単位で管理

    • HAL フォーマットをサポート
  21. • On{HttpMethod} ハンドラー ◦ 未定義の場合は 405 • View Model ◦

    JSON 定義はこちらに • resource.Base ◦ State 管理 Resource 指向ハンドラー
  22. この他に使用している主な外部パッケージ • github.com/dgrijalva/jwt-go • github.com/go-chi/chi • github.com/mattes/migrate • github.com/pilu/fresh •

    go.uber.org/zap • gopkg.in/guregu/null.v3
  23. 開発の歩み

  24. 開発の歩み (2018/1~) • Reviews の MVP バージョンリリース ◦ 1月末に実施される評価に向けた機能開発を2週間で実装 •

    Go はみんな素人レベル ◦ @fivestar が趣味でツール作ってた程度 • 動くこと最優先 ◦ ベタベタに Handler を書いていた ◦ hot-reload の仕組みを最優先で整えた
  25. • 2週間で REST フレームワーク開発 • ドメイン層の基本アーキテクチャを決める ◦ シンプルな Entity Model

    ◦ DDD 由来の Repository / Service 開発の歩み (2018/2~)
  26. • Teams / Reviews の正式リリース • リリースを前に管理者用ページがなく運用面がガバガバだったため PHP でその場しのぎのツールを作る ◦

    未だに活用されてしまっている... 開発の歩み (2018/4~)
  27. • API アクセスコントロールのための仕組みを導入 ◦ Teams IAM • データ暗号化基盤の導入 ◦ 評価等の機密データを暗号化

    ◦ Cloud KMS を利用 開発の歩み (2018/6~)
  28. • Slack 通知の仕組みを Cloud Functions を用いて実装 ◦ 新卒が担当 ◦ Go…

    ではなく JavaScript • Benefits リリース ◦ 日本初の挑戦を。メルカリが新インセンティブ制度に込めた想いとその舞台裏 開発の歩み (2018/12~)
  29. 技術的課題

  30. • ORM などは導入しておらず SQL をベタベタと書いている • カラム追加時などソースコードの変更箇所が多いため効率的にスキーマ・ クエリ管理ができるツールがほしい SQL Building

  31. • 途中で testify が導入された ◦ 個人的には testing パッケージで十分だと思っている • モックどうするか

    テストの書き方が統一されていない
  32. • バックエンドも肥大化しつつある • 少なくともアプリケーションドメインごとにコードを分けたい マイクロサービス化

  33. • 短期間で作ったため DevDay にて調整中 REST フレームワークの OSS 化

  34. • メルカリ本体側の人たちともっと交流したい Go のスペシャリスト不在

  35. Any questions?