「動くコード」と「良いコード」の間にある本

この記事は約 5 分で読めます。

「動く」と「良い」の間には深い溝がある

プログラミングを学び始めて半年。文法を覚え、フレームワークの使い方を理解し、機能を実装できるようになった。コードは動く。しかし、自分のコードと先輩のコードを見比べると、何かが決定的に違う。

この「何か」を言語化できないのが、初級者と中級者の境目です。動くコードは書ける。しかし、変更に強く、読みやすく、テストしやすいコードが書けない。この溝を埋めるのが、設計とプラクティスに関する本です。

最初に学ぶべきは、コードの最小単位である変数名と関数の設計です。data ではなく userProfiles、process ではなく validateEmailFormat。命名を変えるだけで、コードの読みやすさは劇的に変わります。

関数の分割も同様です。100 行の関数を 10 行の関数 10 個に分割すると、各関数の責務が明確になり、テストも書きやすくなります。この「なぜ分割するのか」「どこで分割するのか」の判断基準を、体系的に教えてくれる本があります。

中級者が最も苦労するのは、クラスやモジュール間の依存関係です。A が B に依存し、B が C に依存し、C が A に依存する。この循環依存が生まれると、1 箇所の変更が全体に波及し、コードが触れなくなります。

依存関係を適切に管理するには、インターフェースの切り方、依存の方向の制御、レイヤーの分離といった知識が必要です。これらは実務で偶然学べるものではなく、本で体系的に学ぶのが最も効率的です。

テストを書く技術は、テストフレームワークの使い方とは別物です。「何をテストするか」「どの粒度でテストするか」「モックをどこまで使うか」。これらの判断基準を持っていないと、テストを書いても保守コストばかりが増えます。

リファクタリングの本は、命名・関数分割・依存関係・テストのすべてに触れており、「動くコード」から「良いコード」への最初の一歩に最適です。

「動くコード」が書けるようになった直後が、最も効果的なタイミングです。自分のコードの問題点を肌で感じている状態で設計の本を読むと、「これは自分のあのコードのことだ」と具体的に結びつきます。

逆に、まだコードが動かせない段階で設計の本を読んでも、抽象的な話として頭を素通りします。まず動くコードを書く経験を積み、その後で「良いコード」の本を読む。この順序が重要です。

設計の本を読んだら、自分の過去のコードを 1 つ選んでリファクタリングしてみてください。本で学んだパターンを 1 つだけ適用する。命名を改善する、関数を分割する、依存関係を整理する。

1 つのリファクタリングが成功したら、次のパターンを試す。この繰り返しで、本の知識が実践的なスキルに変わります。

「動くコード」と「良いコード」の間には、命名と関数分割、依存関係の管理、テストの設計という 3 つの知識領域があります。これらは実務経験だけでは体系的に身につきません。動くコードが書けるようになった今が、設計の本を手に取る最適なタイミングです。