Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
マイクロサービスを横断したGoのコードレビュー
Search
yuyu_hf
PRO
March 07, 2024
Technology
1
460
マイクロサービスを横断したGoのコードレビュー
DMM.go #7の登壇資料です。
https://dmm.connpass.com/event/310876/
yuyu_hf
PRO
March 07, 2024
Tweet
Share
More Decks by yuyu_hf
See All by yuyu_hf
encoding/json v2を予習しよう!
yuyu_hf
PRO
1
490
クラウドネイティブなNewSQLで実現するミッションクリティカルなアプリケーションの運用
yuyu_hf
PRO
1
300
他チームレビューのコツ
yuyu_hf
PRO
0
140
DMMプラットフォームを支える負荷試験基盤
yuyu_hf
PRO
2
2.2k
DMMの取り組み最前線 ~フルマネージドNewSQLであるTiDB Cloudの可能性~
yuyu_hf
PRO
4
4.1k
マイクロサービスプラットフォーム向け負荷試験基盤の初期リリースを終えた話
yuyu_hf
PRO
2
2k
Other Decks in Technology
See All in Technology
Amazon CloudWatchのメトリクスインターバルについて / Metrics interval matters
ymotongpoo
3
300
生成AIによる情報システムへのインパクト
taka_aki
1
210
ファインディにおける Dataform ブランチ戦略
hiracky16
0
230
「育てる」サーバーレス 〜チーム開発研修で学んだ、小さく始めて大きく拡張するAWS設計〜
yu_kod
1
200
FAST導入1年間のふりかえり〜現実を直視し、さらなる進化を求めて〜 / Review of the first year of FAST implementation
wooootack
1
210
SAE J1939シミュレーション環境構築
daikiokazaki
1
200
Perlアプリケーションで トレースを実装するまでの 工夫と苦労話
masayoshi
0
180
公開初日に個人環境で試した Gemini CLI 体験記など / Gemini CLI実験レポート
you
PRO
3
1.1k
手動からの解放!!Strands Agents で実現する総合テスト自動化
ideaws
3
410
モバイルゲームの開発を支える基盤の歩み ~再現性のある開発ラインを量産する秘訣~
qualiarts
0
900
AI時代の知識創造 ─GeminiとSECIモデルで読み解く “暗黙知”と創造の境界線
nyagasan
0
170
ユーザー理解の爆速化とPdMの価値
kakehashi
PRO
1
110
Featured
See All Featured
Imperfection Machines: The Place of Print at Facebook
scottboms
267
13k
Thoughts on Productivity
jonyablonski
69
4.8k
StorybookのUI Testing Handbookを読んだ
zakiyama
30
5.9k
Easily Structure & Communicate Ideas using Wireframe
afnizarnur
194
16k
VelocityConf: Rendering Performance Case Studies
addyosmani
332
24k
A designer walks into a library…
pauljervisheath
207
24k
Java REST API Framework Comparison - PWX 2021
mraible
31
8.7k
How to Think Like a Performance Engineer
csswizardry
25
1.8k
Making Projects Easy
brettharned
117
6.3k
The Invisible Side of Design
smashingmag
301
51k
The Pragmatic Product Professional
lauravandoore
35
6.8k
Agile that works and the tools we love
rasmusluckow
329
21k
Transcript
© DMM.com マイクロサービスを横断した Goのコードレビュー DMM.go #7 プラットフォーム事業本部 いっぬ(@yuyu-hf) 1
© DMM.com 自己紹介 いっぬ(@yuyu_hf) ➢ 合同会社DMM.com(2019.04 - 現在) ◦ プラットフォーム事業本部
マイクロサービスアーキテクトグループ 認可チーム リードエンジニア ➢ 認可プロダクトをリプレースするお仕事 ◦ PHP -> Go ◦ MySQL -> TiDB Cloud ◦ オンプレ -> GKE/EKS ➢ 認可チームの採用 ◦ 2名(2023.03) -> 4名(2024.03) ◦ 引き続き採用しています 2
© DMM.com 今日話すこと DMMの共通基盤ではマイクロサービスを採用しています 今日は各マイクロサービスの開発チームに Goのコードレビューのサービスを提供した話をします サービスの内容や運用方法、実際にやってみてどうだったかについて話します 前回のDMM.go #6でpospomeさんが発表した内容の一部の具体的な話です 「組織のコード品質を向上させる
“レビューシステム ”の取り組み」のレビューシステム Version 1.0の話 https://speakerdeck.com/pospome/zu-zhi-nokodopin-zhi-woxiang-shang-saseru-rebiyusisutemu-noqu-rizu-mi?slide=18 3
© DMM.com 今日話すこと ➢ 自チーム外へのGoのコードレビューを紹介 ◦ コードレビューを実施した背景 ◦ コードレビューするときのルール ◦
コードレビューした具体的な内容 ◦ コードレビューの内容をレビューしてもらう仕組み ◦ 半年に1回、利用者アンケートを実施 ➢ 自チーム外へのGoのコードレビューをやってみた感想 4
© DMM.com DMMプラットフォーム DMMプラットフォームとは DMMの各サービスで共通して使われる基盤です 会員の管理、ユーザーの認証 /認可、各種決済周り、 DMMポイントやtoreta+といった電子マネーの仕組みを提 供しています 5
© DMM.com DMMプラットフォームのGoのユースケース DMMプラットフォームでは技術戦略として Goを採用しています ➢ バックエンドAPIを開発するときはGoを使う ◦ 既存のアプリケーションは Goでリライトする
➢ マイクロサービス共通のエコシステムでも Goを採用した ◦ 負荷試験基盤で試験スクリプトを Goで書けるようにした 120名の開発組織を支える、技術マネジメントと選定 https://speakerdeck.com/pospome/120ming-nokai-fa-zu-zhi-wozhi-eru-ji-shu-manezimentotoxuan-ding DMMプラットフォームを支える負荷試験基盤 https://speakerdeck.com/yuyu_hf/cndt-2022-dmm-load-testing-platform-for-dmm-platform 6
© DMM.com 自チーム外にGoのコードレビューを始めた背景 昔のDMMプラットフォームはPHP、Java、Go、Scala、Kotlinなど様々なプログラミング言語で書かれたプロダクト が混在するカオスな状態 ↓ DMMプラットフォームの技術戦略として Goを採用 ↓ DMMプラットフォームでは
Goを使った開発をするのが初めての人も多かった Goに詳しい人に技術支援してもらったほうが開発効率が上がるので、 Goに詳しい人にコードレビューしてもらお う! ↓ マイクロサービスアーキテクトグループで先行して Goを採用していたので、自チーム外への Goのコードレビュー の仕組みを提供開始 7
© DMM.com 自チーム外にGoのコードレビューを提供 ➢ コードレビューの依頼方法 ◦ 各チームからプロダクト単位でコードレビューを任意で依頼してもらう ➢ コードレビューするときのルール ◦
コードレビューの指摘内容は強制ではなく提案 ◦ コードレビューはベストエフォートで行う ◦ PRのmerge後に追加のコードレビューや書いたコードレビューについて訂正する可能性がある ➢ 1週間に1度、上司がコードレビュー内容をレビューする 8
© DMM.com 実際にレビューした内容①(Goの書き方) コードレビューを開始してから半年くらいは Goの基本的な書き方についてレビューすることが多いです ➢ Goの文法 ➢ Goの書き方の紹介 ◦
Go本体のコード ◦ Goの有名なライブラリのコード ◦ コーディングスタイルガイド ➢ 名前付き戻り値の扱い方 ➢ 値レシーバ、ポインタレシーバの使い分け ➢ http.Response.BodyをCloseし忘れの注意 ➢ deprecatedのpackageを使っている場合の注意( ex. io/ioutil package) ➢ etc… GoのNamed return valueについてメリデメを考える https://zenn.dev/yuyu_hf/articles/c7ab8e435509d2 9
© DMM.com レビュー例 Goの変数の命名方法についてレビュー 変数のスコープが短い or 型から何の用途で使われる変数なのかわかる場合のみ 変数名を簡易的な名前にしてもいい 10
© DMM.com レビュー例 名前付き戻り値の使い方 11 元のコード
© DMM.com 実際にレビューした内容②(一般的な開発の知識) ➢ プログラミング原則の説明 ◦ 変数や関数の命名 ◦ DRY ➢
コメントの書き方 ➢ モジュールの結合度 ➢ デザインパターンの紹介 ◦ ドメインモデリングパターン ◦ ファーストクラスコレクション ➢ トランザクションに関する実装方法 ➢ バリデーションの実装方法 ➢ MVCやオニオンアーキテクチャの導入支援 ➢ DDDの導入支援 ➢ etc… 12 社内のプロダクト開発でコメントを書くときの考え方 https://zenn.dev/yuyu_hf/articles/64061802544c87 ファーストクラスコレクション https://zenn.dev/yuyu_hf/articles/93ba0a734208b3 トランザクションを考慮した実装について考える https://zenn.dev/yuyu_hf/articles/df92f9cd0caa0f
© DMM.com レビュー例 変数や関数の命名 13
© DMM.com レビュー例 変数や関数の命名 14
© DMM.com レビュー例 ファーストクラスコレクションの使い方 15
© DMM.com レビュー例 トランザクション処理に関する実装 16
© DMM.com 実際にレビューした内容③(チーム間の知見の共有) 私がチーム間で知見を共有するハブとなって、別チームの知見やプロダクトの実装の紹介をしていました ➢ Goのライブラリの使い方 ➢ アクセスログを出力するミドルウェアの実装例 ➢ エラーハンドリングの仕組みの実装例
➢ Datadogの分散トレーシング用の http clientの実装方法 ➢ MVCやオニオンアーキテクチャの Goでの実装例 ➢ etc… 17
© DMM.com コードレビューのレビュー コードレビューしたPull Requestをspreadsheetで管理しています 1週間に1回、コードレビューした内容について上司からレビューを受けます 18
© DMM.com コードレビューのレビュー コードレビューの指摘内容やコメントについて上司がレビューします よくレビューされた内容 ➢ レビューで提案したら提案のメリデメを必ず説明する ◦ 私のコメント「...にするのはどうでしょうか?」 上司「メリデメを説明しないと指摘されたから直すになってしまってこの先も同じレビューをし続けるこ
とになりますよ(´・ω・`)」 ◦ 私のコメント「DDD的に...」 上司「デメリットが無いなら今の実装でいいですよ (´・ω・`)」 ➢ 抽象的な言葉を使わない。具体的に説明する ◦ 私のコメント「UI層の責務で...」 上司「責務って何ですか?ふわふわした言葉で説明しないでください (´・ω・`)」 19
© DMM.com 半年に1回利用者アンケートを実施 21名中17名が別の開発案件でもコードレビューをぜひ受けたいと回答しました 20
© DMM.com 半年に1回利用者アンケートを実施 21
© DMM.com 自チーム外のコードレビューをやって良かったこと ➢ Goを初めて書くチームに Goを書くときのノウハウを共有できた ◦ 半年くらいでGoの書き方に関するレビューはほとんど無くなった ➢ 品質の高いコードを書くノウハウを共有できた
◦ チーム内で品質の高いコードを維持するためのレビューができるようになった ◦ チーム内に有識者がいない設計手法を導入する支援ができた ➢ チームを横断したノウハウの共有ができた ◦ 問題に当たったときに同じ問題に当たった別のチームの解決策を共有して開発効率を上げた ➢ マイクロサービスを開発する各チームのコーディングレベルの課題が可視化された 22
© DMM.com 大変だったこと①(ハレーションが発生した) ハレーションの内容 基本的なプログラミング原則を指摘するレビューを口頭で実施したときに強く反論された 当時の対応 私の上司にエスカレーションして、レビュー先のチームとマネージャーを含めて話し合いが行われた 原因 & こうすればよかった
コードレビューは提案だがレビューされた側に「強制」に見えてしまったかもしれない テキストコミュニケーションだけだと「提案感」が伝わらなかった可能性がある 普段から口頭でのコミュニケーションを併用して「提案感」をわかってもらう努力をすれば良かった 23
© DMM.com 大変だったこと②(時期によって残業が多かった) 多いときには4つのプロダクトを担当して 1日10PR以上を1人でレビューしていた PRが作成されたらその日中にレビューする必要があったため残業しました 原因 コードレビュー先のチーム内でコーディングルールができていない状態だったので、コードレビューでコーディング ルールを守ることを徹底していました コードレビューはベストエフォートなので、コードレビューが遅れると
PRがマージされてしまいます コーディングルールを守ってないコードが追加されると、コーディングルールを守ってないコードを参考にしてコー ドを書く人が出てきます もっとこうすれば良かった PRをマージした後でもコードを改善してもらうように働きかければ良かった spreadsheetなどでコードを改善するための Issueを管理し開発のXX%を改善に当てるなどの提案をする 24
© DMM.com 今後の展望 1年くらいレビューしていると Goの書き方や品質の高いコードの書き方についてレビューすることが少なくなりまし た 今はコードレビューだけでなく開発生産性を上げるための取り組みを各チームに提供しています PRのリードタイムの削減 プルリクのリードタイムを 5分の1に劇的改善。科学的思考とオーナーシップで変革する
DMM.comのエンジニア組織 https://blog.findy-team.io/posts/interview_dmm_01/ 開発生産性を上げることを専任で取り組むために Developer Productivity Team の創設 組織全体で開発生産性に取り組むために 専門チームを作った話 https://speakerdeck.com/pospome/zu-zhi-quan-ti-dekai-fa-sheng-chan-xing-niqu-rizu-mutameni-zhuan-men-timuwozuo-tutahua 25
© DMM.com 今日話したこと ➢ 自チーム外へのコードレビューを紹介 ◦ コードレビューを実施した背景 ◦ コードレビューするときのルール ◦
コードレビューした具体的な内容 ◦ コードレビューの内容をレビューしてもらう仕組み ◦ 半年に1回利用者アンケートを実施 ➢ 自チーム外へのコードレビューをやってみた感想 26