レビューガイドラインで技術力を見える化する

・https://rakus.connpass.com/event/240393/
・https://rakus.connpass.com/event/251357/

で発表した資料になります。

Transcript

1. 〜 数値で分かるチームの弱点 〜 レビューガイドラインで 技術力を見える化する @akkiee76
2. 自己紹介 Akihiko Sato / 株式会社ラクス Lead Engineer / @akkiee76 SaaS 開発 (Backend, Frontend) / Mobile 開発 (iOS, Android) 上流工程、コードレビュー、チームの課題改善など 読書 / コーヒー / HHKB / 腹筋ローラー
3. 今日伝えたいこと レビューガイドラインで チームの特徴を見える化させることはとても有意義！
4. 私が join した当時のチーム状況 ・実装のセオリーが分からない ・レビューの観点が分からない レビューがしっかり行われていない体制だった モバイル開発経験者が少なく実装のノウハウがない
5. その結果・・・ ・技術力がなかなか伸びない ・定期的にバグが発生する
6. レビュー指摘を類型化できないか？ チームメンバーの弱点を表せないか？ どうやって課題を改善するか ガイドラインを作って、レビューコメントを類型化しよう！ （ レビュー指摘は財産 ）
7. ガイドライン作成にあたって 基本的なアウトラインを決めよう！ 重要度 x 観点 の基準でレビューコメントを類型化することに
8. 重要度について まずは指摘の重要度を 4 つに分類 ・MUST（修正が必須） ・SHOULD（リリースまでには修正が必要） ・IMO（修正なしも許容） ・NITS（細かい指摘）
9. 観点について ① 指摘の観点を 7 つに分類 ・Design（設計） ・Functionality（機能を充足しているか） ・Simplicity（理解容易性） ・Style（コードスタイル）
10. 観点について ② 指摘の観点を 7 つに分類 ・Naming（クラス、メソッド、変数名などの命名） ・Tests（自動テストが適切である） ・Document（コメント、ドキュメンに関連）
11. 具体的な利用方法 コメントの prefix として利用する。 指摘例 MUST（Design）：ドメインロジックがControllerクラスに実装されてます。 domain層の対象packageに新しくクラスを作成して実装を移してください。
12. prefix を付けたコメントを集計 GitLab API （Note API）を利用してコメント集計します。 具体的な方法は、 ラクス Advent Calendar 2021（12/23） 「GitLab API で Merge Request のコメントを一括取得する方法」 をご覧ください。
13. 集計結果 運用開始 2 ヶ月で、コメント数は約 75 件。
14. 得られた気付き ➔ Tests のコメントが圧倒的に多い ◆ テストコードの実装力の課題 ➔ 次いで Design のコメントが多い ◆ 設計力、オブジェクト指向が課題
15. 苦手克服のため今後のアクションプラン 　① オブジェクト指向の輪読会の実施 　② テストの書き方トレーニング会 　③ ペアプロの導入
16. まとめ レビューガイドラインで技術力を見える化すると 　① チームメンバーのスキルが定量化できる 　② 苦手分野が明らかになる 　③ スキルアップのためのアクションプランが検討しやすい チームでの導入を検討してみてはいかがでしょうか
17. ご清聴ありがとうございました