29-DRY原則

「プログラマが知るべき97のこと」の29個目のエピソードは、DRY原則に関する話です。「DRY（Don't Repeat Yourself:繰り返しを避けること）原則」は達人プログラマーの中で提唱された原則の１つであり、プログラマならば誰もが聞いたことのある最も有名で重要な教えの１つです。同じようなコードが幾つもある状況は、無駄であり、メンテナンスコストも高くなります。いわゆる「コピペ」コードを量産すると、ライン数は稼げますが品質は下がるのは誰もが経験しているのではないでしょうか？このエピソードでは、そんなDRY原則を再確認しています。
DRY原則は、コードの重複だけに当てはまるものではありません。単体テストやパッケージングなど「繰り返して実行するタスク」に関しても当てはまります。コードの重複を排除するときにはデザインパターンやリファクタリングを使いますが、タスクの自動化には自動するツールやスクリプトを書くことになります。最近は、JUnitによるテストの自動化とSCMと組み合わせた継続的ビルドも一般的になってきており、自分のプロダクトや会社でもHudsonを導入しています。自動化により常にバックグラウンドでテストが走り、問題があれば直ぐにメールで通知されるのです。自動化をするには最初に学習・サーバの準備・設定などコストはかかります。しかし、自動化によって開発に安心感が生まれます。
また、DRY原則によりコードの重複を減らす努力は設計力も向上させます。コピーしたコードを「どうやって重複を排除するか？」と考えるプロセスが重要なのです。設計パターンが豊富に蓄積されているプログラマであれば、直ぐに重複を排除できます。ある程度のパターンを覚えてしまえば、自然に蓄積されるパターンも増え、応用力もついてきます。その為には、デザインパターンなどを勉強しておくのも有効です。そして、最も効果的なのはペアプログラミングです。ペアの相手が様々なテクニックでコーディングをしていく様を見る事は大きな刺激になりますし、指摘され新しい技を教えて貰う事もできるのです。重複を排除する姿勢は確実に設計力を向上させます。
しかし、どんな時にもDRY原則を守る・・・DRY原理主義者にはならないようにしましょう。見た目には同じコードかもしれませんが、それは論理的に別の意味を持つコードかもしれません。見た目だけで重複を排除してしまえば、後からの仕様変更の時に無駄に手間がかかってしまいます。重複が排除されるからと入ってデザインパターンを使いすぎるとかえって見通しの悪いコードになることもあります。重複を排除し共通化したため、そのコードを修正するとシステムのあちこちに影響が及ぶのです。
DRY原則は大切な教えですが、「原則」である事を忘れずに、柔軟に適切に運用したいところです。

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