86-WETなシステムはボトルネックが見つかりにくい

「プログラマが知るべき97のこと」の86個目のエピソードは、DRYとパフォーマンスチューニングに関する話です。DRY（Don't Repeat Yourslef）は、きのこ本でも何回か登場している有名な原則で、システムの中で同じものが複数あることは避けるというものです。DRY原則を絶対的に守ると反って読みにくくなるという場合もありますが、DRY原則を守ることが基本でしょう。これに対してWETという原則があるそうです。WET（Write Every Time）はDRYとは全く反対の状況で、同じようなコードがあっても都度実装するという、いわばDRYを守っていないシステムへの皮肉と思われます。
システムがDRY原則を守って作られているならばそれは幸せな事ですが、現実としてはWETなシステムが数多く存在します。酷い場合にはコーディング規約で勝手にメソッドやクラスを作ることが禁止されており、DRYにしようにも出来ない場合すらあります。大抵の場合はバグの温床になったり、同じ原因の不具合がシステムの至る所に点在し収集がつかなくなるなどの結末を迎えるでしょう。また、このエピソードにあるようにパフォーマンスチューニングにも問題をもたらします。
システムのパフォーマンスの問題が見つかったならば、ボトルネックの調査から始まります。よく言われる事ですが、パフォーマンスの問題を解決するために、細かい部分を徹底的にやっても効果は高くありません。ほとんどの場合、ごく一部のロジックや処理がパフォーマンス悪化のほとんどの原因となっており、ボトルネックと呼ばれています。他の部分はそれなりにスムーズに処理が流れている一方で、ある一カ所がボトルネックとなっているのです。したがって、ボトルネックさえ解消すれば、システムのパフォーマンスが改善する事が多いのです。
ボトルネックを調べるにはどうすれば良いでしょうか？処理時間の測定をメソッド毎にいれる、モニタリングツールを使いオブジェクトの生成数などを調べる、コードを読みながらアタリをつけるなどの方法があります。しかし、WETなシステムでは同じロジックが至る所に点在しているため、オブジェクトの生成などの分析ツールでは検知しにくいものとなります。また、その部分を修正し、改善したとしても、同じようなボトルネックがシステムの至る所にあるのです。これではパフォーマンスチューニングは円滑に進みません。しかし、DRYに構築されたシステムであれば、上記のような問題は起こりにくくなり、修正による効果も高くなります。尚、最悪のパターンは、パフォーマンスチューニングされ可読性の低くなった（そしてバグのある）コードのコピペです。・・・悪夢としか言いようがありません。
やりすぎは禁物ですが、システムは可能な限りDRY原則に従うべきです。

プログラマが知るべき97のこと