1 万行のコードより 1 冊の設計書が勝つ場面

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

コードを書く速さで評価される時代は終わった

ジュニアエンジニアのころは、コードを速く大量に書ける人が評価されます。機能を実装し、バグを直し、タスクを消化する。生産性はコード量で測られがちです。

しかし、ある段階から「たくさん書ける」ことの価値が頭打ちになります。1 万行のコードで実装した機能が、設計を見直せば 2000 行で済んだ。しかも 2000 行の方が読みやすく、テストしやすく、変更にも強い。

この差を生むのが設計の知識です。

コード量で解決できない 3 つの問題

問題 1: 変更のたびに壊れるシステム

機能 A を修正したら、無関係に見える機能 B が壊れた。原因を調べると、A と B が内部で密結合していた。修正のたびにデグレが発生し、テストの工数が膨らむ。

この問題にコードを追加しても解決しません。テストを増やしても、根本原因である密結合は残ったまま。必要なのは、モジュール間の依存関係を整理する設計の知識です。依存性逆転の原則、インターフェースによる抽象化、レイヤードアーキテクチャ。これらの概念を知っていれば、密結合を解消する具体的な手段が見えます。

問題 2: スケールしないアーキテクチャ

ユーザー数が 10 倍になったとき、レスポンスタイムが 100 倍になった。サーバーを増やしても改善しない。ボトルネックはコードの書き方ではなく、データの持ち方とアクセスパターンの設計にある。

キャッシュ戦略、データベースのインデックス設計、非同期処理のパターン。これらは「もっとコードを書く」では解決できず、「どう設計するか」の知識が必要です。

問題 3: 新メンバーが戦力にならない

チームに新しいメンバーが入っても、コードベースが複雑すぎて理解に数ヶ月かかる。ドキュメントを書いても追いつかない。

アーキテクチャの本が教える「関心の分離」や「境界の明確化」を実践すれば、コードベースの構造が明快になり、新メンバーのオンボーディング期間が短縮されます。

設計の知識が「引き算」を可能にする

優れた設計は、コードを減らします。

不要な抽象化を排除する。重複したロジックを統合する。複雑な条件分岐をポリモーフィズムで置き換える。これらはすべて「引き算」の操作です。

引き算をするには、何を残して何を削るかの判断基準が必要です。その判断基準を与えてくれるのが、設計の原則とパターンです。SOLID 原則を知らなければ、「この抽象化は必要か不要か」を判断する軸がありません。

設計書を読むべきタイミング

設計の本は、ある程度のコーディング経験がないと実感が湧きません。目安として、以下の経験があるときに読むと最も効果的です。

• 自分が書いたコードを半年後に読み返して「何をやっているかわからない」と感じたことがある
• 機能追加のたびに既存コードの修正範囲が広がっていると感じる
• コードレビューで「設計を見直した方がいい」と言われたことがある
• チームの他のメンバーが自分のコードを理解するのに苦労している

これらの経験がある人は、設計の本を読む準備ができています。経験がない人は、まずコードを書く量を増やす方が先です。

1 冊の設計書が 1 万行を救った実例

あるプロジェクトで、決済処理のコードが 3000 行に膨れ上がっていました。クレジットカード、銀行振込、コンビニ払い、電子マネー。決済方法が追加されるたびに巨大な switch 文が伸び、テストケースが爆発的に増えていました。

チームのリーダーが Strategy パターンを適用し、各決済方法を独立したクラスに分離しました。コードは 1200 行に減り、新しい決済方法の追加は 1 つのクラスを追加するだけで済むようになりました。

このリファクタリングに要した知識は、デザインパターンの本の 1 章分です。1 章を読む時間は 30 分。その 30 分が、3000 行のコードを 1200 行に減らし、以後の開発速度を恒久的に改善しました。

関連記事

• 設計の引き出しは本でしか増えない
• 「動くコード」と「良いコード」の間にある本

まとめ

コードを大量に書く力と、適切な設計を選ぶ力は別のスキルです。変更のたびに壊れる、スケールしない、新メンバーが理解できない。これらの問題はコード量では解決できず、設計の知識が必要です。1 冊の設計書が教える原則とパターンは、1 万行のコードを 2000 行に減らし、チーム全体の生産性を恒久的に改善する力を持っています。