プログラマが知るべき97のこと
本記事は、株式会社オライリー・ジャパンより出版された『プログラマが知るべき97のこと』の中からひとつのエッセイを取り上げ、そのエッセイをクリエイティブ・コモンズ表示3.0の条件下で転載したものです。
本書の各々のエッセイは、オープンソースモデルに従い、ほぼ無制限で利用が可能です。クリエイティブ・コモンズ表示3.0の条件下で、自由に使用することができるのです。つまり、どのエッセイも、著者の名前を明記すれば、自由に転載、改変が可能であるということです。
『プログラマが知るべき97のこと』はじめに（p.XII）
なお、原書（英文）のエッセイは、下記のWebサイトで公開されています。
Contributions Appearing in the Book – Programmer 97-things
29 DRY原則
スティーブ・スミス (Steve Smith)
DRY原則を学ぶ
「DRY（Don’t Repeat Yourself：繰り返しを避けること）原則」は、プログラミング に関して守るべきとされている原則の中でも、特に重要なものと言っていいでしょう。これは、Andy Hunt と Dave Thomas が、著書『達人プログラマー』の中で提唱した原則です。
よく知られたソフトウェア開発のベストプラクティスやデザインパターンの中にも、基本的な考え方がこの原則と同じものがたくさんあります。
開発者は、アプリケーションの中に何らかの「重複」があれば、また重複が起きそうであれば、それを察知する必要があります。そして、適切なプラクティスや抽象化によってそれを排除する必要があるのです。そのための方法を学べば、よりきれいなコードを書けるようになるはずです。
重複は無駄である
アプリケーションを構成するコードはすべて、保守を必要とします。どのコードも将来バグになる危険性を秘めています。重複があると、コードベースは不必要に大きくなり、
それにつれて、バグが生じる危険性も高まります。
また、システムの構造は、そう意図していないにもかかわらず複雑になってしまいます。重複によりコードベースが大きくなれば、開発に携わる人間がシステム全体を完全に理解することも難しくなります。
特に困るのはコードに変更を加える時です。どこかに変更を加えた場合、それとロジック等が重複している箇所にも同様の変更が必要かどうかを確認しなければなりません。
DRY原則を守れば、そういう事態に陥らずに済みます。DRY原則を守るとは、言い換えれば「すべての知識はシステム内において、単一、かつ明確な、そして信頼できる表現になっていなければならない」という条件を満たすことです。
作業の重複は自動化で防ぐ
ソフトウェア開発に関わる作業の多くは「同じことの繰り返し」です。つまり作業が何度も重複します。この重複は、自動化によって容易に解消できます。DRY原則は、アプリケーションのソースコードだけでなく、開発作業にも適応すべき原則ですが、そのためには自動化が役立つというわけです。
たとえばテストは同じ作業の繰り返しになることが多いですが、手作業でそれをやっていては手間も時間もかかり、しかも誤りも起きやすくなります。したがって、可能な限り、テストは自動化すべきなのです。
同様に、ソフトウェアの統合（ビルド）も同じ作業の繰り返しになることが多いですが、手作業だと時間がかかり、誤りが起きやすくなります。従ってビルドプロセスも自動化し、しかも頻繁に走らせるべきです。コミットの度に走らせるというのが理想でしょう。
手作業だと負担が大きすぎるようなものは、すべて自動化の対象となります。自動化し、かつ標準化するのが望ましいです。大事なのは、作業を遂行するための方法を１つだけにするということです。そうすれば、手間が省ける上、問題も起きにくいと言えます。
ロジックの重複は抽象化で防ぐ
ロジックの重複には多数の種類があります。たとえば、if-then や switch の部分が単純にコピー＆ペーストされている場合は、発見するのも解消するのも非常に容易でしょう。デザインパターンの多くは、明らかにアプリケーションの中の重複を減らす。あるいは排除することを目的としています。
あるオブジェクトを使用するために整えるべき条件がほぼいつも同じであれば、その場合は Abstract Factory パターンや Factory Method パターンを使用すればいいでしょう。
オブジェクトのふるまいに様々な種類があり得る、という場合には、長い if-then を書くよりは、Strategy パターンを使用します。実際、デザインパターンは、同じような問題について何度も繰り返し解決策を考えるという重複が起きないように作られたとも言えます。
DRY原則は、データベース スキーマなどの構造にも適用されます。これは、いわゆる「正規化」につながります。
関連する原則
ソフトウェア開発に関する原則には、他にもDRY原則に関連するものがいくつかあります。
OAOO (Once and Only Once：１度、ただ１度）原則はその１つです。これは、コードの機能、ふるまいについてのみ適用される原則で、DRY原則を特殊化したものと考えることもできます。
OCP（Open/Closed Principle：開放 / 閉鎖原則）というのもあります。これは、クラスなどのプログラム単位は、拡張に対して「開いて（open)」いなくてはならならず、反対に、修正に対しては「閉じて(close)」いなくてはならない、という原則です。この原則は、DRY原則が守られている場合にのみ有効です。
他には、SRP(Single Responsibility Princile：単一責任原則)という有名な原則もあります。「クラスに変更を加える理由は２つ以上存在してはならない(１つの変更の理由は常に１つでなければならない)」という原則で、やはりDRY原則が守られている場合にのみ有効です。
重複がどうしても必要なこともある
DRY原則は、構造、ロジック、プロセス、機能などのあらゆる面で、開発者がシンプルなアプリケーションを作る上での基本的な指針です。この原則を守ることで、シンプルで、品質が高く、保守もしやすいアプリケーションが作りやすくなるのです。
状況によっては、パフォーマンスを上げるため、あるいは何らかの要件（データベース を非正規化しなくてはならないなど）を満たすために、重複がどうしても必要ということはあり得ます。
ただし、現実にすでに目の前にある問題に対処する以外の目的で、DRY原則を破ってはなりません。「こういう問題が起きそうだから、原則をあらかじめ破っておこう」ということをしてはいけないのです。
コメント