コードの重複は、誤った抽象化よりも安上がりである
開発者はDRY原則を好みます。
同じことを繰り返したくない、エレガントで再利用可能なコードを書きたい、と考えるものです。
しかし、この目標はしばしば「早すぎる抽象化」という罠につながります。
コードの繰り返しは、何か間違っているように感じられます。しかし、不適切な抽象化を行うよりも、コードを重複させる方が安上がりであることが多いのです。
私たちは完璧なモジュール化されたシステムを構築しようとします。複雑さを管理するために、パターンを探し、ロジックを抽出します。
よく設計された抽象化は、ソフトウェアのスケーラビリティを助けます。
しかし、多くの抽象化は時期尚早に行われます。問題を完全に理解していない状態で抽象化を行うと、それは負債となります。
誤った抽象化は、いくつかの問題を引き起こします：
- オーバーエンジニアリング：単純な問題に対して、複雑な解決策を構築してしまう。
- 硬直性：起こり得ない未来を予測しようとするため、コードの変更が困難になる。
- 意図の隠蔽：ビジネスロジックが汎用的なインターフェースの層の下に隠れてしまい、デバッグが困難になる。
- 密結合：システムの各部分が、抽象化そのものに縛り付けられてしまう。
そのコストは高くつきます。ユーザーの課題を解決する代わりに、自分たちが作ったアーキテクチャと戦うことに時間を費やすことになります。これはチームのスピードを落とし、リファクタリングを困難にします。
すべてをコピー＆ペーストしろと言っているわけではありません。私は現実的なアプローチを提案しているのです。
「制御された重複」を一つのツールとして使いましょう。要件の変化が激しい領域や、不確実性が高い領域で活用するのです。
抽象化を構築する前に、パターンが明確に見えるまで待ってください。