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

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

コードを書く速さで測れる範囲には限りがある

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

しかし、ある段階から「たくさん書ける」ことの価値が頭打ちになります。力任せに書き上げた機能が、設計を見直すと数分の一の行数で書き直せる、という場面が出てきます。しかも行数が減った方が読みやすく、テストしやすく、変更にも強くなります。

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

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

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

機能 A を修正したら、無関係に見える機能 B が壊れます。原因を追うと、A と B が内部で密結合しています。修正のたびにデグレが起き、テストの工数が膨らみます。

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

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

ユーザー数が 10 倍になったとき、レスポンスタイムの悪化が 10 倍では済まない形で現れることがあります。サーバーを増やしても改善しません。この場合のボトルネックはコードの書き方ではなく、データの持ち方とアクセスパターンの設計にあります。

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

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

チームに新しいメンバーが入っても、コードベースが複雑すぎて全体像をつかむまでに時間がかかります。ドキュメントを書き足しても、変更の速度に追いつきません。

アーキテクチャの本が扱う「関心の分離」や「境界の明確化」を実践すれば、どこに何があるかを構造から読み取れるようになります。新しく入った人が最初に触る範囲を絞りやすくなる、という形で効いてきます。

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

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

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

引き算をするには、何を残して何を削るかの判断基準が必要です。その判断基準を与えてくれるのが、設計の原則とパターンです。SOLID 原則のような手掛かりを持たないままだと、「この抽象化は必要か不要か」がチーム内で好みの話になり、議論が収束しません。

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

設計の本は、ある程度のコーディング経験がないと実感が湧きません。以下のような経験があるときが、読み始めの目安になります。

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

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

設計のパターン 1 つがコードの形を変える

決済処理を例にします。クレジットカード、銀行振込、コンビニ払い、電子マネーと支払手段が増えるたびに分岐の中身が足され、巨大な switch 文が伸びていく。この形になると、支払手段を 1 つ足すだけでも分岐の全経路をテストし直すことになります。

ここで効くのが、条件分岐をポリモーフィズムへ置き換える手当てです。Martin Fowler のリファクタリングカタログには、型によって振る舞いが分かれる switch 文を、共通のインターフェースを持つクラス階層へ移す手順が Replace Conditional with Polymorphism としてまとめられています。支払手段ごとの処理を独立したクラスへ移せば、呼び出し側から分岐が消え、追加のたびに触る範囲は新しいクラスとその登録先に閉じます。

この手当てに必要な知識は、設計の本のうちパターン 1 つ分です。読む分量は数ページから 1 節ぶん。読むのにかかる時間の短さと、その後に効いてくる範囲の広さが釣り合わないところが、設計の本の特異な点です。

関連記事

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

まとめ

コードを大量に書く力と、適切な設計を選ぶ力は別のスキルです。変更のたびに壊れる、スケールしない、新メンバーが理解できない。これらの問題はコード量では解決できず、設計の知識が必要です。1 冊の設計書が教える原則とパターンは、書く量を増やしても届かない場所に手を伸ばすための道具です。コードの総量が減り、変更の影響範囲が読めるようになれば、その効きはチーム全体に及びます。