if文の「中身」に名前をつけよう。レビュー力を高める「意図の言語化」

AIにロジックを書かせると、以下のようなコードがよく生成されます。

// 😱 何を判定しているのか、一瞬で理解できますか?
if (user.age >= 18 && user.hasAgreed && !user.isSuspended && user.plan === 'premium') {
  // 処理...
}

このコードの最大の問題は、「ビジネス上の意図」が記号の羅列(&&!)に隠れてしまっていることです。

1. 条件式を関数に切り出すメリット

条件判定を独立した関数(述語関数)に切り出すことで、コードに「名前」がつきます。

  • ドキュメント化: コメントを書かなくても、関数名がそのまま仕様書になります。
  • 認知負荷の低減: 複雑なロジックを読み飛ばし、「何が起きているか」という大枠の把握に集中できます。
  • 再利用性とテスト: 判定ロジック単体に対してユニットテストが書けるようになります。

2. リファクタリングのビフォー・アフター

Before: 記号を解読しなければならないコード

エンジニアは「18歳以上で、同意済みで、停止されてなくて…」と脳内で翻訳作業を行う必要があります。

if (user.age >= 18 && user.hasAgreed && !user.isSuspended && user.plan === 'premium') {
  showSpecialContent();
}

After: 意図が「名前」として現れるコード

関数に切り出すことで、ビジネスルールが明確になります。

/**
 * プレミアム会員かつ、コンテンツ視聴が可能な状態かを判定する
 */
const canAccessPremiumContent = (user: User): boolean => {
  const isAdult = user.age >= 18;
  const isActive = !user.isSuspended && user.hasAgreed;
  const isPremium = user.plan === 'premium';

  return isAdult && isActive && isPremium;
};

// レビューで見たいのは「この一行」の妥当性
if (canAccessPremiumContent(user)) {
  showSpecialContent();
}

3. レビューでどこを見るべきか?

AI時代、私たちはコードの書き手から**「コードのチェッカー(意味の番人)」**へと役割がシフトしています。

  • 「そのif文、名前をつけられませんか?」: 条件が3つ以上重なったら切り出しのサインです。
  • 「名前と実態は合っていますか?」: canAccess という名前なのに、中でユーザーのデータを更新(副作用)していないかチェックします。

まとめ:AIに「意味」を教えるのは人間の仕事

AIは「正しい構文」を書くのは得意ですが、そのコードが「自社のビジネスにおいてどういう意味を持つのか」までは理解していません。

if (a && b || c)if (isEligibleForCampaign(user)) に書き換える。この一工夫が、1年後の自分やチームメイトの認知負荷を劇的に下げ、保守性の高いソフトウェアを作り上げます。