【コードレビュー】ファンズのコードレビューについてご紹介

Shinji Iida

2023年12月4日 11:55

こんにちは！ファンズ株式会社でバックエンドエンジニアを担当している飯田と申します。2022年にファンズにJoinしました。

今回はファンズのバックエンドチームのコードレビューについて紹介してみようと思います！

われわれのチーム開発の雰囲気が少しでも伝わると幸いです！

プラットフォームはgithubを採用しています！

ルール

まずファンズではコードレビューをどのように実施すべきかを、テックリードがドキュメントに明文化しています。
そのルールに則ってレビューを行うことでバックエンドチーム全体のコードレビューの品質を担保しています。

大きく以下のようなことを明記しています！

いつレビューするか
誰がレビューするか
レビュー観点

誰がレビューするか

バックエンドチームから2名を選びレビュー依頼をします！

ファンズでの開発歴の長さで2つのグループに分かれており、それぞれ1名ずつラウンドロビン方式で選出する形にしています！

指定された 2名が approve 後に晴れてマージ可能となります！

こちらに関しては1名体制でも良いのではないか？との声もあったり、品質を担保するために2名のままでよいのではないか？との声もあったり、絶賛議論が進んでいる最中です！

是非、他社さんの事例を聞いてみたいところです！

話は変わりますが、テックリード主宰で『バックエンドチーム言いたいこと言おう会』というチーム改善の場を四半期に1回くらいのペースで開催しており、ここで日々の開発についての改善案をワイワイ会話したりもしています！

いつレビューするか

「レビュー依頼検知後 1 営業日以内に行うこと」と明文化しています！

もしレビュアーがレビューを多く受け持ちしすぎて自身の作業に指標をきたす場合は、同グループの他の方にお願いするといった柔軟な運用を行なっています。

また特に急ぎのレビューを必要としている場合は、slackでバックエンドメンバー全員にメンションして、すぐ対応可能なメンバーにみてもらうなど助け合いの精神でコードレビューを行なっていたりします！

レビュー観点

指摘がある場合はコメント略語をつかいながらコメントします！

ファンズでよく使われる略語は以下です

MUST
Question
IMO
NITS
LGTM

MUST

絶対に修正して欲しい指摘です。
仕様を満たしていなかったり、ユニットテストは足りていない場合にRequest Changesと共にコメントします！

Question

金融領域ということで、初見では仕様の理解が難しい場合があります。
その場合はレビュアー側も積極的に質問することで仕様を理解することに努めます！

IMO

文字通り私ならこう書きますという提案に使います！
なるべく具体的なコードを書いて提案することが多いです！

NITS

些細な指摘事項です！

ADR に沿った書き方となっていなかったり、タイポやデバッグ消し忘れなど軽微な修正において使っています

LGTM

IMO / NITS のみのレビューコメントだった場合、レビュアーは approve します。コメントに対応するかはレビュイーに委ねられます。

もし意見がぶつかってしまった場合はテックリードなど第三者を巻き込むことで、納得のいく落とし所を見つけるなどの動きをしています！

レビュアーもレビュイーもお互いにリスペクトを持ちながら日々レビューを行なっています！

レビュイーが準備すること

レビュアー視点でお話ししましたが、レビュイー側もPRを依頼するにあたり準備する必要があります！

以下の項目についてPR作成時にざざっと書くことを求めています！

概要
変更内容
仕様書のリンク
確認相談事項

仕様書がない場合は先に仕様書を作成します！これによりレビューアーが対象のコードの仕様をキャッチアップできるようにします！

また特にみて欲しい項目に関してはgithubにて対象のコードにコメントを残すことで確認ポイントをわかりやすくすることに努めます！

さいごに

このnoteによってファンズのバックエンドチームを知っていただけると嬉しいです！
また、ファンズではさまざまな職種で仲間を募集しております！
少しでも関心持たれたかたいらっしゃいましたら、ぜひお話ししませんか？

ファンズの理解が深まる採用ページも是非ご覧ください！

この記事が気に入ったらサポートをしてみませんか？

【コードレビュー】 ファンズのコードレビューについてご紹介

ルール