💻

2000行のPRを投げつけた僕が学んだ、コーディングで大切な5つの習慣

に公開1

はじめに

Social Databank Advent Calendar 2025 の6日目です。
こんにちは🐉
日々のコーディング業務の中で、上司の助言や本の知識から抜粋して意識していることを5つピックアップしてみました。
これらは自分が実践している中で特に効果を感じている習慣です。

1. PRの差分はなるべく200行以内に抑える

Pull Requestのサイズは、レビューの質に直接影響します。

なぜ200行なのか?
それは多すぎるとレビュアーは読まなくなるからです😊

レビュアーにも集中力があります。
人間の集中力なんてたかが知れてるので、あまりに修正が多いと集中が切れて見落としが多くなるからです。
LGTMという書籍曰く、1回のレビューにかける適正時間は20分〜40分だそうです。
なので200行以内に収めると20分程度でこなせるのでおすすめということ。(ちなみに僕は最初2000行の変更PRを先輩に投げつけました)
lgtmBook

おすすめはPRのタイトル以外のものは実装しないこと
タイトルが文言修正なら文言修正だけをそのPRで修正する。
そのタイトル以外の修正は含めないことをお勧めします。

大きな機能開発でも、意味のある単位で分割することを心がけています。
バックエンドとフロントエンドでPRを分けたり、もっと小さい機能単位に分けたり…

これにより、レビュアーも段階的に理解でき、変更の意図が伝わりやすくなります。

2. 変数にやたらと突っ込まない

一時変数を作りすぎると、コードの見通しが返って悪くなります。

悪い例
const user = getUser();
const userName = user.name;
const upperName = userName.toUpperCase();
return upperName;
良い例
return getUser().name.toUpperCase();

もちろん、可読性を考慮して変数に切り出すべきケースもあります。
判断基準は 「この変数名が処理の理解を助けるか?」 です。

適切な変数の使用例
const isAdminUser = user.role === 'admin' && user.permissions.includes('write');
if (isAdminUser) {
  // 変数名が意図を明確にしている
}

3. ifをなるべく使わない書き方を考える

条件分岐が増えると、コードの複雑度が上がります。
まず基本として、早期リターンガード節を活用することでネストを減らせます。

ifが多い例
function processUser(user) {
  if (user) {
    if (user.isActive) {
      if (user.age >= 18) {
        return doSomething(user);
      } else {
        return 'Too young';
      }
    } else {
      return 'Inactive user';
    }
  } else {
    return 'No user';
  }
}
早期リターンで改善
function processUser(user) {
  if (!user) return 'No user';
  if (!user.isActive) return 'Inactive user';
  if (user.age < 18) return 'Too young';

  return doSomething(user);
}

さらに、そもそも処理が別なら別の関数に分けるという考え方も重要です。

条件で処理が分岐する例
function handleUserAction(user, action) {
  if (action === 'create') {
    // 作成処理
    validateUserData(user);
    saveToDatabase(user);
    sendWelcomeEmail(user);
  } else if (action === 'update') {
    // 更新処理
    validateUserData(user);
    updateDatabase(user);
    sendUpdateNotification(user);
  } else if (action === 'delete') {
    // 削除処理
    archiveUserData(user);
    deleteFromDatabase(user);
    sendGoodbyeEmail(user);
  }
}
関数分割で改善
function createUser(user) {
  validateUserData(user);
  saveToDatabase(user);
  sendWelcomeEmail(user);
}

function updateUser(user) {
  validateUserData(user);
  updateDatabase(user);
  sendUpdateNotification(user);
}

function deleteUser(user) {
  archiveUserData(user);
  deleteFromDatabase(user);
  sendGoodbyeEmail(user);
}

// 呼び出し側
const actions = {
  create: createUser,
  update: updateUser,
  delete: deleteUser
};

actions[action]?.(user);

処理が異なるなら、それぞれ独立した関数にすることで考える労力を減らすことができます。

4. 便利なものを常に探す意識を持つ

コードを書く前に、「既に用意されている機能や関数はないか?」 を探す習慣が大切です。

例えば、URLの判定ロジックを自分で書こうとした場合下記のようになるはず

自分で実装しようとする例
function isValidUrl($url) {
  // http:// または https:// で始まるか
  if (!preg_match('/^https?:\/\//', $url)) {
    return false;
  }
  // ドメイン部分の検証
  if (!preg_match('/^https?:\/\/[a-zA-Z0-9-\.]+/', $url)) {
    return false;
  }
  // さらに細かい検証...
  return true;
}

しかし、PHPには既にfilter_var()という関数とFILTER_VALIDATE_URLという組み込み定数が用意されています。

PHPの標準機能を使う
function isValidUrl($url) {
  return filter_var($url, FILTER_VALIDATE_URL) !== false;
}

たった1行で、複雑な正規表現を書くことなくURLの検証ができます。

以前、先輩に「この関数使った方がいいよ」と教えてもらったとき、僕はすべての標準関数を覚えなければいけないと勘違いしていました。
いっぱい覚えているからすぐに引き出しから取り出せるんだろうなぁと…
しかし後で聞いてみると、その先輩もレビュー時にその関数の存在を知っていたわけではなかったのです。

大切なのは、すべてを暗記することではなく、「これって既にあるんじゃないか?」と気づき、探す癖をつけることでした。
コードを自分で書きすぎているかも?と気づく嗅覚が大事ということです。
これはいまだにAIでもよしなにやってくれないので自分で気づく必要があります。

この気づく感覚を持つことが、車輪の再発明を防ぎ読みやすいコードを書く第一歩です。

5. 作ってくれた人に感謝する

技術的なことではありませんが、最も大切だと思っています。
目に見えているコードは全て誰かがプッシュしてくれたコードです。
その人が頑張って書いてくれたコードだということを念頭に感謝と敬意をもってコードを読みましょう。
自分も誰かの役に立てるコードを書きたいですね。

おわりに

今回紹介した5つの意識することで僕のプログラミングの意識は大きく変わりました。
完璧にできなくても大丈夫です。僕も全て完璧にできているわけではありません。
少しずつ意識していくことで、自然と身につくものだと思っています。

皆さんも日々のコーディングで意識していることがあれば、ぜひ共有してください!🚀

ソーシャルデータバンク テックブログ

Discussion

KvraKvra

機能追加とか、ついでにリファクタリングも初めてついつい一つのプルリクに詰め込みすぎるので、私も気をつけようと思いました。