$30 off During Our Annual Pro Sale. View Details »

組織のコード品質を向上させる “レビューシステム”の取り組み

pospome
September 19, 2023

組織のコード品質を向上させる “レビューシステム”の取り組み

dmm.go #6 の登壇資料です。
https://dmm.connpass.com/event/295065/

pospome

September 19, 2023
Tweet

More Decks by pospome

Other Decks in Programming

Transcript

  1. 組織のコード品質を向上させる
    “レビューシステム”の取り組み
    @pospome

    View Slide

  2. 登壇者
    名前:pospome(ぽすぽめ)
    所属:DMM.com
    Twitter:@pospome

    View Slide

  3. 内容について
    DMMプラットフォームで取り組んでいる”組織全体のコード品質向上”の取り組
    みについて話します。

    View Slide

  4. DMMプラットフォーム
    扱う領域:DMM会員、決済、DMMポイント、不正対策など
    エンジニア数:120名以上
    開発チーム数:16チーム
    マイクロサービス数:約40サービス
    ピーク時のリクエスト:19,000RPS
    *2016年くらいからマイクロサービスに取り組んでいる。

    View Slide

  5. レビューシステムとは?
    DMMプラットフォーム全体のコード品質を向上させる仕組みと活動の総称であ
    る。
    2021年4月くらいから取り組んでいる。

    View Slide

  6. DMMプラットフォームとGo言語の歴史について

    View Slide

  7. Go言語をデファクト・スタンダードな言語として定義
    2020年からDMMプラットフォームはGo言語をバックエンド開発におけるデファ
    クト・スタンダードなプログラミング言語として定義した。
    *フロントエンドはTypeScriptです。
    *あくまでデファクト・スタンダードなだけで他の言語を利用することもできま
    す。

    View Slide

  8. 補足:ここらへんの話は以下で詳細に説明しています

    View Slide

  9. 既存のマイクロサービスもGoにリプレイス
    タイミングよく既存のマイクロサービスを全体的にリプレイスする大規模プロジェ
    クトが走る直前だったので、すべての既存マイクロサービスがGo言語で開発さ
    れる予定である。
    *新規マイクロサービスもGo言語で開発されています。

    View Slide

  10. レビューシステムが生まれるまで

    View Slide

  11. Go言語をデファクト・スタンダードにする上での課題
    各チームのGoに対する習熟度が
    まちまちなので、
    学習コストがかかってしまう。

    View Slide

  12. 学習コストを下げるための取り組み
    pospomeの知見を共有する形で学習コストを下げようと思い、
    とりあえずドキュメントを書いた。

    View Slide

  13. View Slide

  14. 補足:フレームワークの選定について

    View Slide

  15. 学習コストを下げるための取り組み
    ペライチのドキュメントで下がる学習コストはたかが知れている。
    pospomeは脳筋タイプのエンジニアなので、
    「習熟度を上げるには、とにかく手を動かして書くしかない」
    という考えが強い。

    View Slide

  16. とにかく書いてもらう & 有識者のレビュー
    単に書くだけでなく、それを有識者がレビューするというサイクルが一番効果的
    だと思った。
    しっかりと工数をかけて組織全体のGoに対する習熟度を向上させていく。

    View Slide

  17. “有識者による組織横断のGoに対するコードレビュー”
    これがレビューシステムの原点である

    View Slide

  18. レビューシステム Version 1.0

    View Slide

  19. 誰がレビューするのか?
    たまたま自分のチームに
    Goの有識者が数人いたので、
    その人達にレビューしてもらった。
    *有識者がいない場合は
     pospomeが担当する予定だった。 pospomeチーム
    会員チーム 決済チーム
    レビューする

    View Slide

  20. レビュー担当者の活動時間
    レビュー担当者は既存の開発作業もあるので、
    レビューシステムにフルコミットできるわけではない。
    レビュー担当者の活動時間は1人あたり週に4時間を上限としている。
    大体2~3人が活動していたので週に8~12時間程度の工数を割くことになる。

    View Slide

  21. レビューシステムのルール
    やっていることは単なるPull Requestのレビューだが、いくつかルールが有る。
    1. レビュー担当者からの指摘は提案である。
    2. レビューシステムによるレビューを待たずにPRをmergeしていい。
    3. レビューシステムを利用するかどうかは任意である。
    4. レビューシステムではGoのコード以外はレビューしない。

    View Slide

  22. ”レビューのレビュー”について
    レビュー担当者同士が定期的にレビュー内容を共有する。
    それぞれの指摘を共有することで、”良いコード”, “悪いコード”に対する認識を合
    わせ、レビュー担当者自身のスキルアップを狙う。
    *pospomeも参加しています。

    View Slide


  23. View Slide

  24. 補足:レビュー対象Pull Requestの管理
    (´・ω・`)(マツケンサンバってなに・・・ ?

    View Slide

  25. 補足:GoogleのReadability Processについて
    Googleにも “Readability Process” というコードレビューのルールがある。
    Readability Processは「コードに対する承認権限を持つ人の承認がないと実装
    をmergeできない」というものらしい。
    承認権限を持つエンジニアは全体の1~2%らしい。

    View Slide

  26. レビューシステム Version 1.0 の感想

    View Slide

  27. 感想1. 予想以上に好評だった

    View Slide

  28. 感想1. 予想以上に好評だった

    View Slide

  29. 感想1. 予想以上に好評だった

    View Slide

  30. 感想2. Go言語に関する指摘はすぐに不要になった
    最初はGoの学習コスト削減が目的だったが、言語仕様がシンプルなこともあり
    短期間のレビューで知見共有は不要になった気がする。
    むしろGoに依存しない設計部分の指摘が多かった。
    例:usecase層でトランザクションかけましょう

    View Slide

  31. 感想3. 組織全体の知見共有のハブになれる
    各チームのコードレビューをしているので、
    「これと同じ問題を決済チームが解決していたので相談するといいです」
    みたいなことができるようになった。

    View Slide

  32. 感想4. 開発効率の向上に目を向けるようになった
    特定のチームの開発効率が低いことを知り、改善した。

    View Slide

  33. 感想5. 最終的には各チームの能力に依存する
    レビューシステムによる指摘を受け入れるかどうかは各チーム次第なので、最
    終的なコード品質は各チームの能力に依存する。
    例:「トランザクションスクリプトの方が分かりやすいです」

    View Slide

  34. 感想6. ドメイン知識が必要な場合は厳しい
    DMMプラットフォームは以下の領域を扱っているので、それぞれのドメイン知
    識がない状態でのレビューには限界がある。
    ● DMM会員
    ● 決済
    ● DMMポイント
    ● 不正対策
    ● カスタマーサポート
    ● などなど・・・

    View Slide

  35. レビューシステム自体はまあまあ成功した

    View Slide

  36. レビューシステムによって感じた組織課題

    View Slide

  37. レビューシステムを通して感じた組織課題
    レビューシステムを通して以下の課題を感じた。
    1. 各チームの設計スキルに大きな差があること。
    2. DMMプラットフォームの開発生産性が不透明であること。
    *各チームのGoの習熟度は最低ライン保証されたと思う。

    View Slide

  38. 次に何をすべきか?

    View Slide

  39. Developer Productivity Team の設立

    View Slide

  40. Developer Productivity Team とは?
    DMMプラットフォーム内の “開発生産性” を向上させる専門チームである。
    今まで片手までやっていたレビューシステムを含め、DMMプラットフォームの
    開発生産性を向上させるためだけに活動する。

    View Slide

  41. Developer Productivity Team の活動
    以下のような活動をしている。
    ● レビューシステムの運用によるコード品質の改善(既存の活動
    ● テストカバレッジの可視化 & 改善
    ● 各種エコシステムの開発
    e.g. 負荷試験基盤, モノレポetc.

    View Slide

  42. レビューシステム Version 2.0 について

    View Slide

  43. レビューシステム Version 2.0 について
    「Go言語の学習コストを下げる」という目的で始まったレビューシステムだった
    が、それを達成したことで「コード品質の向上」という目標にシフトする必要が
    あった。

    View Slide

  44. レビューシステム Version 2.0 について
    既存の活動に加えて以下の2点を追加した。
    1. Issue共有会
    2. Issue消化のトラッキング

    View Slide

  45. レビューシステム Version 2.0 について
    既存の活動に加えて以下の2点を追加した。
    1. Issue共有会
    2. Issue消化のトラッキング

    View Slide

  46. レビューシステムでの指摘が抱える課題
    レビューシステムによる指摘には以下の課題があった。
    1. 「さすがにこれは対応した方がいい」という指摘に対応してもらえない。
    2. merge済みのPRに対する指摘が対応されているか分からない。

    View Slide

  47. Issue共有会について
    「対応済みかどうか分からないもの」や「これは対応した方がいい」というものを
    各チームのGitHubリポジトリのIssueに登録する。

    View Slide

  48. 登録したIssueの例

    View Slide

  49. Issue共有会について
    Issueがある程度溜まってきたら、各チームのテックリードとミーティングをして、
    対応の必要性と意図を伝える。

    View Slide

  50. 口頭でディスカッションすることの重要性
    各チームのテックリードと直接会話する機会を設けることによって以下のメリット
    がある。
    1. 効率よく設計に対する深い話ができる。
    2. 会話の過程で各チームが抱える開発課題をヒアリングすることができる。

    View Slide

  51. Issue共有会について
    Issue共有会によって以下を解決することができる。
    1. 「さすがにこれは対応した方がいい」という指摘に対応してもらえない。
    2. merge済みのPRに対する指摘が対応されているか分からない。

    View Slide

  52. レビューシステム Version 2.0 について
    既存の活動に加えて以下の2点を追加した。
    1. Issue共有会
    2. Issue消化のトラッキング

    View Slide

  53. Issue消化のトラッキング
    各チームのGitHubリポジトリに登録したIssueの数はスプレッドシートで管理さ
    れており、
    それらがどの程度消化されたのかをトラッキングする。

    View Slide

  54. なぜトラッキングするのか?
    長期間Issueが消化されていない場合、開発チームがリファクタリングに工数を
    割いていない可能性がある。
    そういった兆候が見られた場合は、対象チームのマネージャー、部長に直接連
    絡し、技術的負債の返済に対して工数を割いているかどうかを確認する。

    View Slide

  55. 客観的に負債具合を判断する
    レビューシステムによってコードの状態や既存の課題を認識しているDeveoper
    Productivity Teamが第三者の立場で介入することによって、
    開発チームの危険性を客観的に伝えることができる。
    *実際にリファクタリングに工数を割く方針に倒したチームもあります。

    View Slide

  56. レビューシステム Version 2.0 について
    1. Issue共有会
    2. Issue消化のトラッキング
    今後も継続的にコード品質を向上させていく予定です。

    View Slide

  57. まとめ

    View Slide

  58. まとめ
    大きな組織になればなるほどエンジニアのレベル差は大きくなり、
    コード品質にもバラつきがでてしまう。
    これを各チーム自身で改善するのは難しい。
    コード品質という領域に専門性を持ったエンジニアが第三者の観点でレビュー
    することによって、組織全体のコード品質を底上げする。

    View Slide

  59. 宣伝

    View Slide

  60. pospomeがマネージャーを務めるチームの採用
    マイクロサービスアーキテクトグループでは、
    エンジニアを募集しています。
    詳細をブログにまとめているので、
    興味のある方は読んでみてください。

    View Slide

  61. Developer Productivity Team の活動
    以下のような活動をしている。
    ● レビューシステムの運用によるコード品質の改善(既存の活動
    ● テストカバレッジの可視化 & 改善
    ● 各種エコシステムの開発
    e.g. 負荷試験基盤, モノレポ, etc.

    View Slide

  62. テストカバレッジの可視化 & 改善

    View Slide

  63. エコシステムの開発(負荷試験基盤

    View Slide

  64. エコシステムの開発(モノレポ

    View Slide

  65. Developer Productivity Team について
    開発生産性に向きあう技術特化なチームなので、以下のような人であれば楽し
    めると思います。
    ● 開発生産性に興味のある人
    ● とにかく技術が好きな人
    ● コード品質に興味がある人

    View Slide

  66. おわり

    View Slide