コードレビューで評価されるコードの書き方

はじめに

コードレビューをしていると、「このコード、レビューしやすいな」と感じることがあります。
逆に下記のようなコードも少なくありません。
・読むのに時間がかかる
・意図が分からない
・指摘が多くなる
実務では「正しく動くコード」だけでなく「レビューしやすいコード」が評価されることが多いです。
この記事では、現場で評価されるレビューしやすいコードの書き方についてまとめます。

① 命名で意図が伝わる

レビューしやすいコードは命名だけでほぼ理解できる状態になっています。
例えば

const data = getData();

ではなく

const activeUserList = fetchActiveUsers();

のように何のデータか？何をしているか？が分かる命名です。
レビューする側は「読むコスト」が大きく下がります

② 差分が小さい（変更範囲が明確）

レビューで重要なのが「何が変わったか分かりやすいか」です。
例えば下記のような要素があるとレビューがしづらくなります。
・関係ないコードまで触っている
・フォーマットがバラバラ
・不要なリファクタが混ざっている
理想は変更の意図が明確で差分が最小限である事です。
1つの目的に対して1PR

③ 1関数1責務が守られている

レビューしやすいコードは関数単位で理解できるようになっています。
例えば

async function processUser(id) { ... }

のように何でもやる関数ではなく

fetchUser
validateUser
formatUser
saveUser

のように分かれている状態です。
レビュー側が「部分的に確認できる」

④ 「なぜ」が分かる

レビューで一番困るのが「なんでこう書いてるの？」です。
例えば

// 外部APIの仕様でnullが返る可能性があるためチェック
if (!user) return;

のように「仕様」「制約」「背景」が分かるとレビューが一気に楽になります。
「なぜ」が分かれば指摘が減る

まとめ

レビューで評価されるコードの特徴は下記です。
・命名で意図が伝わる
・差分が小さい
・責務が分かれている
・「なぜ」が分かる
これらは高度な技術ではなく、「レビューする人の視点を持てるか」がポイントです。
レビューしやすいコードはチーム全体の速度を上げるコードです。

一緒に開発できる方へ

弊社では現在、下記のような形でエンジニアとつながりを持てればと考えています。
・フリーランス・業務委託での参画
・副業からのジョイン
・中長期的なパートナーシップ
コードレビュー文化・設計議論・実務水準に共感いただける方は、お気軽にDMください。