Python | テスト・設計・品質：コードレビュー

Python Python
スポンサーリンク

コードレビューって何？まずは目的からはっきりさせる

コードレビューは、
「他の人（または未来の自分）が、あなたの書いたコードを読んで、気づいたことをフィードバックするプロセス」です。

バグを見つけるため
読みやすさ・保守性を上げるため
設計やテストの観点を揃えるため
チーム全体のスキルを底上げするため

こういう目的が全部まとめて乗っかっています。

「ダメ出しの場」ではなく、
「コードを一緒に育てる場」として捉えると、ぐっと健全になります。

具体例でイメージする：レビュー前のコードとレビュー後のコード

レビュー前のコード（初心者が書きがちな形）

例えば、ユーザーのフルネームを作る関数を考えます。

# user.py

def f(u):
    if u["first_name"] == "" or u["last_name"] == "":
        return ""
    return u["last_name"] + " " + u["first_name"]
Python

動きとしては、

first_name または last_name が空なら空文字を返す
そうでなければ「姓＋スペース＋名」を返す

という仕様です。

動くことは動きますが、レビューで突っ込まれそうなポイントがいくつかあります。

関数名が意味不明（f）
引数名も抽象的（u）
辞書アクセスがベタ書きで、キーの存在チェックもない
「空文字なら空を返す」という仕様が分かりにくい

これをレビューでどう改善していくかを見てみます。

レビュー後のコード（レビューで育てた形）

# user.py

from dataclasses import dataclass

@dataclass
class User:
    first_name: str
    last_name: str

def get_full_name(user: User) -> str:
    """姓と名からフルネームを '姓 名' の形式で返す。
    どちらかが空文字の場合は空文字を返す。
    """
    if not user.first_name or not user.last_name:
        return ""
    return f"{user.last_name} {user.first_name}"
Python

レビューで改善されたポイントを言語化すると、

関数名が「何をするか」を表すようになった（get_full_name）
引数が User 型になり、構造が明示された
docstring で仕様（空文字の扱い）が説明された
if not user.first_name のように「空文字・None などをまとめて扱える」書き方になった
f-string で可読性が上がった

同じ「フルネームを返す関数」でも、
レビューを通すことで「他の人が読んでも分かるコード」に育っていきます。

コードレビューで見るべき観点（初心者がまず押さえるところ）

動くかどうかだけじゃなく「読みやすさ」を見る

初心者のうちは、「動くかどうか」だけを気にしがちです。
でも、レビューではむしろ、

このコードを初見で読んだとき、意図がすぐ分かるか
変数名・関数名から役割が想像できるか
ネストが深すぎて追いにくくなっていないか

といった「読みやすさ」がかなり重視されます。

例えば、こんなコードがあったとします。

def calc(a, b, c):
    if a:
        if b:
            return c * 2
        else:
            return c + 1
    else:
        return c
Python

レビューでは、こういう指摘が入りえます。

calc という名前では何を計算しているか分からない
a, b, c では意味が分からない
ネストが深くて条件の意図が読み取りにくい

これを受けて、例えばこう直せます。

def adjust_score(is_premium: bool, has_coupon: bool, base_score: int) -> int:
    if is_premium and has_coupon:
        return base_score * 2
    if is_premium and not has_coupon:
        return base_score + 1
    return base_score
Python

やっていることは同じでも、
「何をしている関数か」が一気に伝わりやすくなります。

テストの有無・内容もレビュー対象

テストを書いている場合、
レビューでは「テストの中身」も重要なチェックポイントです。

正常系だけでなく、
境界値（0、空、最大値など）
異常系（エラーになるべき入力）

がテストされているかどうか。

例えば、さっきの get_full_name なら、

普通の名前
first_name が空
last_name が空
両方空

などのパターンがテストされているかを見ます。

コードとテストをセットでレビューすることで、
「仕様の抜け」や「想定していないパターン」に気づきやすくなります。

レビューコメントの受け取り方・書き方（ここが人間的に一番大事）

受け取る側：人格ではなく「コード」に対するフィードバックだと切り分ける

初心者が一番しんどくなりやすいのがここです。

「ここ分かりにくいですね」
「この名前だと意図が伝わりにくいです」

といったコメントを、
「自分がダメだと言われている」と感じてしまうことがあります。

でも、レビューで話しているのは「コード」であって「あなた」ではありません。

コードは何度でも書き換えられるし、
レビューを通してどんどん良くなっていきます。

「自分の価値」と「コードの出来」を切り離して考えること。
これは、長くプログラミングを続けるうえでかなり重要なメンタルスキルです。

書く側：指摘ではなく「提案」として書く

レビューコメントを書くときは、
「ダメ出し」ではなく「提案」にすると、空気がかなり柔らかくなります。

例えば、

「この変数名は意味が分かりません」
よりも
「この変数、役割的には total_price みたいな名前だと分かりやすそうです」

「この if 文はネストが深すぎます」
よりも
「ここの条件、早期 return にするとネストが浅くなって読みやすくなりそうです」

のように、「どう良くできそうか」まで書くと、
相手も「なるほど、そういう考え方があるのか」と学びやすくなります。

コードレビューと設計・品質の関係

レビューは「設計のすり合わせの場」でもある

コードレビューは、単に文法や書き方を見るだけではありません。

この関数、責務が多すぎないか
このクラス、本当にここまで知っていていいのか
このモジュールの分割、もう少し整理できないか

といった「設計レベル」の話も、レビューでよく出てきます。

例えば、こんな関数があったとします。

def create_user_and_send_mail(db, email, name):
    user = User(email=email, name=name)
    db.add(user)
    db.commit()
    send_welcome_email(email)
    return user
Python

レビューで、

ユーザー作成とメール送信を 1 関数にまとめるとテストしにくい
ユーザー作成と通知は責務を分けた方がよさそう

という話になり、こう分割されるかもしれません。

def create_user(db, email, name):
    user = User(email=email, name=name)
    db.add(user)
    db.commit()
    return user

def notify_user_created(email):
    send_welcome_email(email)
Python

こういう「設計の分割」は、
一人で書いていると気づきにくいことが多いです。

レビューは、「設計の感覚」をチームで共有していく場でもあります。

レビューを通して「チームの共通ルール」が育つ

レビューを続けていくと、

命名のルール
例外の扱い方
ログの出し方
テストの書き方

などについて、「うちのチームではこうしよう」という共通認識が少しずつできてきます。

それが「コーディング規約」や「ベストプラクティス」として固まっていくと、
新しく入った人も迷いにくくなり、
コード全体の品質も揃っていきます。

初心者がコードレビューから最大限学ぶためのコツ

「なぜそうした方がいいのか」を必ず聞く・考える

レビューで指摘されたとき、
ただ直すだけだと「作業」で終わってしまいます。

可能なら、

「なぜこの書き方の方が良いのか」
「この設計の分け方にはどんなメリットがあるのか」

を質問したり、自分なりに考えてみると、
一気に学びの密度が上がります。

例えば、

「ここは早期 return にしましょう」
と言われたら、

「ネストが浅くなって読みやすくなる」
「条件の否定形を減らせる」

といった理由があるはずです。

その「理由」までセットで理解すると、
別のコードを書くときにも自分で判断できるようになります。

自分でも「レビュー目線」でコードを読む練習をする

他人のコードだけでなく、
自分のコードも「他人になったつもりで」読み直してみると、
レビューの感覚が鍛えられます。

この関数名で、初見の人は意図が分かるか
この if の条件、パッと読んで理解できるか
このテスト名で、何を保証しているか伝わるか

といった視点で、自分のコードにツッコミを入れてみる。
それ自体が、立派な「セルフコードレビュー」です。

まとめ（コードレビューは「コードと自分を育てる場」）

コードレビューを初心者目線で整理すると、こうなります。

コードレビューは、バグ取りだけでなく、「読みやすさ」「設計」「テスト」を含めてコードを一緒に育てるプロセス。
レビュー前後のコードを比べると、命名・責務の分割・テストの観点などが少しずつ洗練されていく。
コメントは「人格」ではなく「コード」に対するものであり、受け取る側も書く側も「提案」としてやりとりするのが健全。
レビューを通して、設計の感覚やチームの共通ルールが育ち、自分自身の設計・品質のセンスも鍛えられていく。

もしよければ、あなたが最近書いた小さな関数やクラスを一つ貼ってみませんか。
実際に「レビューコメント」を付ける形で、どう直すと読みやすく・テストしやすくなるか、一緒に具体的に見ていきましょう。

スポンサーリンク
タイトルとURLをコピーしました