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

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

Transcript

1. 組織のコード品質を向上させる “レビューシステム”の取り組み @pospome
2. 登壇者 名前：pospome（ぽすぽめ） 所属：DMM.com Twitter:@pospome
3. 内容について DMMプラットフォームで取り組んでいる”組織全体のコード品質向上”の取り組 みについて話します。
4. DMMプラットフォーム 扱う領域：DMM会員、決済、DMMポイント、不正対策など エンジニア数：120名以上 開発チーム数：16チーム マイクロサービス数：約40サービス ピーク時のリクエスト：19,000RPS ＊2016年くらいからマイクロサービスに取り組んでいる。
5. レビューシステムとは? DMMプラットフォーム全体のコード品質を向上させる仕組みと活動の総称であ る。 2021年4月くらいから取り組んでいる。
6. DMMプラットフォームとGo言語の歴史について
7. Go言語をデファクト・スタンダードな言語として定義 2020年からDMMプラットフォームはGo言語をバックエンド開発におけるデファ クト・スタンダードなプログラミング言語として定義した。 ＊フロントエンドはTypeScriptです。 ＊あくまでデファクト・スタンダードなだけで他の言語を利用することもできま す。
8. 補足：ここらへんの話は以下で詳細に説明しています
9. 既存のマイクロサービスもGoにリプレイス タイミングよく既存のマイクロサービスを全体的にリプレイスする大規模プロジェ クトが走る直前だったので、すべての既存マイクロサービスがGo言語で開発さ れる予定である。 ＊新規マイクロサービスもGo言語で開発されています。
10. レビューシステムが生まれるまで
11. Go言語をデファクト・スタンダードにする上での課題 各チームのGoに対する習熟度が まちまちなので、 学習コストがかかってしまう。
12. 学習コストを下げるための取り組み pospomeの知見を共有する形で学習コストを下げようと思い、 とりあえずドキュメントを書いた。
14. 補足：フレームワークの選定について
15. 学習コストを下げるための取り組み ペライチのドキュメントで下がる学習コストはたかが知れている。 pospomeは脳筋タイプのエンジニアなので、 「習熟度を上げるには、とにかく手を動かして書くしかない」 という考えが強い。
16. とにかく書いてもらう & 有識者のレビュー 単に書くだけでなく、それを有識者がレビューするというサイクルが一番効果的 だと思った。 しっかりと工数をかけて組織全体のGoに対する習熟度を向上させていく。
17. “有識者による組織横断のGoに対するコードレビュー” これがレビューシステムの原点である
18. レビューシステム Version 1.0
19. 誰がレビューするのか? たまたま自分のチームに Goの有識者が数人いたので、 その人達にレビューしてもらった。 ＊有識者がいない場合は 　pospomeが担当する予定だった。 pospomeチーム 会員チーム 決済チーム レビューする
20. レビュー担当者の活動時間 レビュー担当者は既存の開発作業もあるので、 レビューシステムにフルコミットできるわけではない。 レビュー担当者の活動時間は1人あたり週に4時間を上限としている。 大体2~3人が活動していたので週に8~12時間程度の工数を割くことになる。
21. レビューシステムのルール やっていることは単なるPull Requestのレビューだが、いくつかルールが有る。 1. レビュー担当者からの指摘は提案である。 2. レビューシステムによるレビューを待たずにPRをmergeしていい。 3. レビューシステムを利用するかどうかは任意である。 4. レビューシステムではGoのコード以外はレビューしない。
22. ”レビューのレビュー”について レビュー担当者同士が定期的にレビュー内容を共有する。 それぞれの指摘を共有することで、”良いコード”, “悪いコード”に対する認識を合 わせ、レビュー担当者自身のスキルアップを狙う。 ＊pospomeも参加しています。
23. 例
24. 補足：レビュー対象Pull Requestの管理 (´・ω・`)（マツケンサンバってなに・・・ ?
25. 補足：GoogleのReadability Processについて Googleにも “Readability Process” というコードレビューのルールがある。 Readability Processは「コードに対する承認権限を持つ人の承認がないと実装 をmergeできない」というものらしい。 承認権限を持つエンジニアは全体の1~2%らしい。
26. レビューシステム Version 1.0 の感想
27. 感想1. 予想以上に好評だった
28. 感想1. 予想以上に好評だった
29. 感想1. 予想以上に好評だった
30. 感想2. Go言語に関する指摘はすぐに不要になった 最初はGoの学習コスト削減が目的だったが、言語仕様がシンプルなこともあり 短期間のレビューで知見共有は不要になった気がする。 むしろGoに依存しない設計部分の指摘が多かった。 例：usecase層でトランザクションかけましょう
31. 感想3. 組織全体の知見共有のハブになれる 各チームのコードレビューをしているので、 「これと同じ問題を決済チームが解決していたので相談するといいです」 みたいなことができるようになった。
32. 感想4. 開発効率の向上に目を向けるようになった 特定のチームの開発効率が低いことを知り、改善した。
33. 感想5. 最終的には各チームの能力に依存する レビューシステムによる指摘を受け入れるかどうかは各チーム次第なので、最 終的なコード品質は各チームの能力に依存する。 例：「トランザクションスクリプトの方が分かりやすいです」
34. 感想6. ドメイン知識が必要な場合は厳しい DMMプラットフォームは以下の領域を扱っているので、それぞれのドメイン知 識がない状態でのレビューには限界がある。 • DMM会員 • 決済 • DMMポイント • 不正対策 • カスタマーサポート • などなど・・・
35. レビューシステム自体はまあまあ成功した
36. レビューシステムによって感じた組織課題
37. レビューシステムを通して感じた組織課題 レビューシステムを通して以下の課題を感じた。 1. 各チームの設計スキルに大きな差があること。 2. DMMプラットフォームの開発生産性が不透明であること。 ＊各チームのGoの習熟度は最低ライン保証されたと思う。
38. 次に何をすべきか?
39. Developer Productivity Team の設立
40. Developer Productivity Team とは? DMMプラットフォーム内の “開発生産性” を向上させる専門チームである。 今まで片手までやっていたレビューシステムを含め、DMMプラットフォームの 開発生産性を向上させるためだけに活動する。
41. Developer Productivity Team の活動 以下のような活動をしている。 • レビューシステムの運用によるコード品質の改善（既存の活動 • テストカバレッジの可視化 & 改善 • 各種エコシステムの開発 e.g. 負荷試験基盤, モノレポetc.
42. レビューシステム Version 2.0 について
43. レビューシステム Version 2.0 について 「Go言語の学習コストを下げる」という目的で始まったレビューシステムだった が、それを達成したことで「コード品質の向上」という目標にシフトする必要が あった。
44. レビューシステム Version 2.0 について 既存の活動に加えて以下の2点を追加した。 1. Issue共有会 2. Issue消化のトラッキング
45. レビューシステム Version 2.0 について 既存の活動に加えて以下の2点を追加した。 1. Issue共有会 2. Issue消化のトラッキング
46. レビューシステムでの指摘が抱える課題 レビューシステムによる指摘には以下の課題があった。 1. 「さすがにこれは対応した方がいい」という指摘に対応してもらえない。 2. merge済みのPRに対する指摘が対応されているか分からない。
47. Issue共有会について 「対応済みかどうか分からないもの」や「これは対応した方がいい」というものを 各チームのGitHubリポジトリのIssueに登録する。
48. 登録したIssueの例
49. Issue共有会について Issueがある程度溜まってきたら、各チームのテックリードとミーティングをして、 対応の必要性と意図を伝える。
50. 口頭でディスカッションすることの重要性 各チームのテックリードと直接会話する機会を設けることによって以下のメリット がある。 1. 効率よく設計に対する深い話ができる。 2. 会話の過程で各チームが抱える開発課題をヒアリングすることができる。
51. Issue共有会について Issue共有会によって以下を解決することができる。 1. 「さすがにこれは対応した方がいい」という指摘に対応してもらえない。 2. merge済みのPRに対する指摘が対応されているか分からない。
52. レビューシステム Version 2.0 について 既存の活動に加えて以下の2点を追加した。 1. Issue共有会 2. Issue消化のトラッキング
53. Issue消化のトラッキング 各チームのGitHubリポジトリに登録したIssueの数はスプレッドシートで管理さ れており、 それらがどの程度消化されたのかをトラッキングする。
54. なぜトラッキングするのか? 長期間Issueが消化されていない場合、開発チームがリファクタリングに工数を 割いていない可能性がある。 そういった兆候が見られた場合は、対象チームのマネージャー、部長に直接連 絡し、技術的負債の返済に対して工数を割いているかどうかを確認する。
55. 客観的に負債具合を判断する レビューシステムによってコードの状態や既存の課題を認識しているDeveoper Productivity Teamが第三者の立場で介入することによって、 開発チームの危険性を客観的に伝えることができる。 ＊実際にリファクタリングに工数を割く方針に倒したチームもあります。
56. レビューシステム Version 2.0 について 1. Issue共有会 2. Issue消化のトラッキング 今後も継続的にコード品質を向上させていく予定です。
57. まとめ
58. まとめ 大きな組織になればなるほどエンジニアのレベル差は大きくなり、 コード品質にもバラつきがでてしまう。 これを各チーム自身で改善するのは難しい。 コード品質という領域に専門性を持ったエンジニアが第三者の観点でレビュー することによって、組織全体のコード品質を底上げする。
59. 宣伝
60. pospomeがマネージャーを務めるチームの採用 マイクロサービスアーキテクトグループでは、 エンジニアを募集しています。 詳細をブログにまとめているので、 興味のある方は読んでみてください。
61. Developer Productivity Team の活動 以下のような活動をしている。 • レビューシステムの運用によるコード品質の改善（既存の活動 • テストカバレッジの可視化 & 改善 • 各種エコシステムの開発 e.g. 負荷試験基盤, モノレポ, etc.
62. テストカバレッジの可視化 & 改善
63. エコシステムの開発（負荷試験基盤
64. エコシステムの開発（モノレポ
65. Developer Productivity Team について 開発生産性に向きあう技術特化なチームなので、以下のような人であれば楽し めると思います。 • 開発生産性に興味のある人 • とにかく技術が好きな人 • コード品質に興味がある人
66. おわり