「まただ…」深夜のオフィスに、僕の独り言が響いた。画面に映るのは、何重にも折り重なったif文のネスト。まるで迷路だ。条件分岐が複雑に絡み合い、どこで何が起きているのか、もはや書いた本人である僕にも理解不能だった。
「このバグ、一体どこから来てるんだ…？」
もう日付が変わる。明日はこの機能のリリース日なのに、どうしても解決できない不具合が一つ、残っていた。コーヒーは何度目かもわからない。頭の中は靄がかかったように思考が停止し、焦燥感だけが募る。こんなはずじゃなかった。僕はもっとスマートにコードを書けるはずだと思っていたのに。
先輩の厳しい視線が脳裏をよぎる。「お前、またこんな読みにくいコード書いてるのか？これじゃデバッグもレビューも地獄だぞ」。あの時の屈辱感と、自分の不甲斐なさに、心の底から「もうダメかもしれない…」と呟いた。このままじゃ、家族にも、チームにも申し訳ない。プログラマーとしての自信は、深いifのネストに埋もれていくばかりだった。
そんな泥沼のような日々を過ごしていたある日、僕のメンターであるベテランのAさんが、僕のコードを覗き込んだ。
「お、また迷宮入りしてるな。これじゃあ、まるで複雑な入場ゲートだ。年齢確認して、チケット確認して、手荷物検査して、健康チェックして…全部クリアしないとアトラクションに行けない。途中で何か引っかかると、また最初の部屋に戻ってやり直し、みたいな非効率さだろ？」
僕が頷くと、Aさんは続けた。
「もっとシンプルな『関所』をイメージしてみろ。まずパスポートを見せる。NGなら『はい、次の方』。OKなら次にビザ。NGなら『はい、次の方』。全部OKなら『どうぞお入りください』。各チェックポイントで条件を満たさなければ、即座に『リジェクト』される。これが『早期リターン』、別名『ガード節』だ。」
Aさんの言葉は、僕の頭の中に一筋の光を差し込んだ。僕はこれまで、すべての条件が揃ってから初めて処理を実行しようと、ifの奥深くへと潜り込むばかりだった。しかし、Aさんの言う「早期リターン」は、条件に合わないなら即座に処理を中断し、関数から抜けるという逆転の発想だった。
「つまり、悪い条件は先に弾き出すってことですか？」
「その通りだ。コードは小説じゃない。設計図なんだ。無駄な回り道をさせるな。これによって、コードの意図が明確になり、可読性が劇的に上がる。バグの温床も減るし、何よりお前の精神衛生にもいい。」
僕は半信半疑ながらも、Aさんのアドバイス通り、あの迷路のようなコードをリファクタリングしてみた。
まず、引数のバリデーション。無効な値が来たら、真っ先にreturnする。
次に、特定の状態でのみ実行されるべき処理。その状態でないなら、すぐにreturn。
するとどうだろう。たった数行の変更で、あの複雑だったifのネストが、まるで霧が晴れるようにスッキリと見通しが良くなったのだ。
「うわ…、これ、めちゃくちゃ読みやすい！」
まるで重い呪縛から解き放たれたような感覚だった。以前は、どこが正常な処理で、どこがエラー処理なのか、判断するのに一苦労だったが、早期リターンを導入したことで、正常なパスが一直線に見えるようになった。デバッグも格段に楽になり、あの忌々しいバグも、あっという間に特定し、修正できた。
「これだ！この解放感は！」
その日から、僕は積極的に早期リターンを取り入れるようになった。新しい機能を実装する際も、まずは「何を拒否するか」から考えるようになったのだ。コードレビューでも、先輩から「最近、コードがすごくクリーンになったな」と褒められるようになった。
早期リターンは、単なるプログラミングテクニックではない。それは、複雑な問題に対するシンプルな解決策であり、開発者の思考を整理し、コードに「風通し」をもたらす哲学のようなものだ。もしあなたが、かつての僕のように、深いifのネストに囚われ、バグの泥沼でもがいているのなら、ぜひこの「関所の哲学」を試してみてほしい。きっと、あなたのコードと、そしてあなた自身の開発人生が、劇的に変わるはずだ。
