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

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

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

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

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

溝を埋める 3 つの知識領域

1. 命名と関数の分割

最初に学ぶべきは、コードの最小単位である変数名と関数の設計です。data ではなく userProfiles、process ではなく validateEmailFormat。名前が処理の内容を語っていれば、呼び出し側を読むだけで何が起きるか追えます。逆に名前と中身がずれていると、読み手は名前を信用できなくなり、毎回定義まで飛んで確かめることになります。

関数の分割も同じです。ただし、100 行の関数を機械的に 10 行ずつ 10 個へ切っても責務は明確になりません。呼び出し側が 10 個の呼ぶ順序と前提を覚えなければならず、かえって読みにくくなります。分割が効くのは、切れ目が責務の境界と重なったときだけです。この「どこで切るか」の判断基準を扱う本を選んでください。

2. 依存関係の管理

命名と関数分割の次に壁になるのが、クラスやモジュール間の依存関係です。A が B に依存し、B が C に依存し、C が A に依存する。この循環依存が生まれると、1 箇所の変更が全体に波及し、コードが触れなくなります。

依存関係を扱うには、インターフェースの切り方、依存の方向の制御、レイヤーの分離といった知識が必要です。これらは目の前のコードを直しているだけでは輪郭が見えにくい種類の知識です。「依存の向き」という見方そのものを外から与えてもらう必要があるため、本で学ぶ価値が大きい領域です。

3. テストの設計

テストを書く技術は、テストフレームワークの使い方とは別物です。「何をテストするか」「どの粒度でテストするか」「モックをどこまで使うか」。これらの判断基準を持たないままモックを重ねると、テストが実装の形をそのまま写し取ってしまいます。振る舞いが変わっていないのに実装を整理した途端テストが赤くなり、リファクタリングのたびにテストを書き直す羽目になります。

リファクタリングは、外から見た動作を変えずに内部の構造を変える作業です。だからこそ命名・関数分割・依存関係の整理は同じ土台の上に乗り、その土台を支えるのがテストになります。この 4 つを地続きで扱う本が、「動くコード」から「良いコード」への最初の一歩に向いています。

本を読むタイミング

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

逆に、まだコードが動かせない段階で設計の本を読んでも、抽象的な話として頭を素通りします。まず動くコードを書く経験を積み、その後で「良いコード」の本を読む。逆の順序だと、読んだ内容を結びつける先が自分の中にありません。

読んだ後にやること

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

このとき先に用意しておくべきものが 1 つあります。変更の前後で動作が同じだと確かめる手段です。テストがあればそれを、無ければ実行して結果を見る手順をメモしておく。これを省くと、構造を良くしたつもりで壊れたコードが残ります。リファクタリングの失敗の多くは、設計の理解不足ではなくこの確認手段の不在から起きます。

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

関連記事

• 「とりあえず動く」で 5 年過ごしたエンジニアの末路
• リーダブルコードの次に読む本 - ステップアップの読書ルート

まとめ

「動くコード」と「良いコード」の間には、命名と関数分割、依存関係の管理、テストの設計という 3 つの知識領域があります。どれも日々の実装のなかで断片的には身につきますが、判断基準として言語化されるまでには時間がかかります。動くコードが書けるようになった今は、自分のコードの不満と本の記述が最も結びつきやすい時期です。