1行に凝縮するな！「スマートなコード」より「脳内メモリに優しいコード」を書く技術
目次
「動くけれど読めない・保守できない」コードの恐怖
仕様書のないレガシーシステムの改修や、納期に追われたギリギリの機能追加。「とりあえず、今の仕様通りに動くコードを書いてマージしてしまおう」場当たり的に修正してしまったコードが、後工程の保守担当やコードレビューアを絶望させることがあります。
if の中に if が何重にも重なった「ネストのタワー」や、1行に無理やり詰め込まれた謎のワンライナー。
動いてはいるものの、まるで要塞のように複雑怪奇化したコードは、次にその中身を見る人のエネルギーをジワジワと削り、知らず知らずのうちに大きな負担をかけてしまいます。
脳内メモリのオーバーヒートと、コードレビューの地獄
深いネスト
テスト仕様書を組み立てたり、「どういう条件を網羅すべきか」というテスト観点のレビューであれば、境界値などもきちんと整理されており、条件の抜け漏れを防ぐことはできます。しかし、実際のソースコードレビューで深いネストや複雑な条件分岐に出くわすと話は別です。
読み手が上から順にコードを追っていくとき、ネストの深さのせいで「いま自分は一体、何の条件を満たした状態のブロックにいるんだっけ？」と脳のメモリを完全に使い果たしてしまう。その結果、本来あるべきチェックやエッジケース（境界値）の処理がちゃんと書かれているかを見極めるのが難しくなり、重大なバグや見落としをスルーしてしまうという地獄が生まれます。
意味のないコメント（解読パズル）
1行に圧縮された複雑な三項演算子やスマートすぎる記述は、書いた本人以外にとってはただの「解読パズル」です。
さらにタチが悪いのは、コードの直上に書かれた「ここで1を足す」「変数を判定する」といった、コードを見れば一目でわかる「How（何をしているか）」だけの無意味なコメントの数々。一番知りたい「なぜその特殊な分岐や変則的な処理が必要なのか（Why）」が一切書かれていないため、結局は過去のチケットやコミットログ、有識者への確認が必要になり、時間が溶けていくのです。
レビューと保守を爆速にする2つの技術
この「読めないコード地獄」を打破するため、私はレガシーコードに手を入れる際、以下の2つの技術を徹底しています。
技術1：既存の構造を壊さない範囲でガード節（早期リターン）を入れる
動いている既存のソースを大きく構造から変えてしまうのは、デグレ（バグ混入）のリスクが高すぎるため厳禁です。
そのため、メソッド全体を大改修するのではなく、処理の冒頭にある「明らかに処理対象外のケース」をガード節で早期に return させるなど、最小限の差分でネストを浅くするアプローチをとります。また、自身がレガシーコードに新しい処理を追加する際に対しても、この早期リターンを徹底します。これだけで脳のメモリ消費量が激減します。
技術2：スマートさより、既存の文脈を殺さない「読みやすさとWhyの補足」を優先する
変にワンライナーにしたり、カッコよく書き換える必要はありません。「リファクタリングして綺麗にしよう」と意気込んでも、仕様のないレガシーシステムではそれ自体に膨大な時間がかかり、デグレのリスクも跳ね上がります。
だからこそ、多少冗長になっても既存の処理の流れはそのまま活かしつつ、コメントで補足を入れる。この「Why（理由・背景）」が数文字あるだけで、後から読む人間が謎解きに時間を溶かすのをピタッと防げます。
「未来の自分や仲間を迷子にさせない技術」
「コードは書く時間より、読まれる時間の方が圧倒的に長い」
納期に追われていると、どうしても「いかに早く書き上げるか」「いかに1行でも短くスマートにまとめるか」に意識が向きがちになります。
しかし、エンジニアが仕事の大半を費やしているのは、新しいコードを書く時間ではなく「既存のコードを読み解く時間」です。だからこそ、自己満足なクールでスマートなコードを目指す必要なんてありません。
最小限の差分でできる工夫
動いているレガシーなソースを大きく変えるデグレの危険は冒せない。だからこそ、最小限の差分でできる工夫があります。
- アーリーリターン（ガード節）でネストを浅くし、脳のメモリ（思考スタック）をオーバーヒートさせない。
- スマートなワンライナーではなく、多少冗長であっても一読して意図がスッと入ってくる構造にする。
- コードに現れない「Why（なぜこの分岐があるのか）」をコメントでそっと残す。
派手な最新技術や美しいアーキテクチャの導入だけがエンジニアの仕事ではありません。
「次にこのコードを開く人間が、無駄な謎解きや調査に時間を溶かさなくて済むようにする」
その泥臭いまでの人間味ある配慮こそが、結果としてチーム全体の開発スピードと品質を支える最大の武器になるのです。
