29. DRY原則 Steve Smith：『プログラマが知るべき97のこと』

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

posted with カエレバ

和田卓人オライリージャパン 2010-12-18

Amazonで探す

楽天市場で探す

Yahooショッピングで探す

# 目次

29. DRY原則スティーブ・スミス (Steve Smith)：『プログラマが知るべき97のこと』
重複は無駄である．
作業の重複は自動化で防ぐ．
ロジックの重複は抽象化で防ぐ
関連する原則
関連記事
MyEnigma Supporters

# はじめに

以下の記事は，オライリージャパン社から出版された

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

の中から1つのエッセイを選び，

そのエッセイを，クリエイティブコモンズ3.0の条件の元で転載したものです．

Creative Commons ― 表示 3.0 アメリカ合衆国 ― CC BY 3.0

本書の内容は，オープンソースモデルに従い，
ほぼ無制限で利用が可能です．
クリエイティブ・コモンズ表示3.0の条件下で，
自由に使用することができるのです．
つまり，どのエッセイも，
著者の名前を明記すれば，自由に転載，改変が可能であるということです．
ーー"はじめに"から抜粋 pXII

もし，他のエッセイを読みたい場合には，

記事末のリンクを辿るか，

以下のリンク先のTwitterアカウントのつぶやきからお探し下さい．

Twitter Account: 97 Things Bot

また，元の英文によるエッセイを読みたい方は，

こちらを参照して下さい．

Contributions Appearing in the Book - Programmer 97-things

29. DRY原則スティーブ・スミス (Steve Smith)：『プログラマが知るべき97のこと』

「DRY (Don't Repeat Yourself：

繰り返しを避けること)原則」は，

プログラミングに関して

守るべきとされている原則の中でも，

特に重要なものと言っていいでしょう．

これは，Andy HuntとDave Thomasが，

著書『達人プログラマー』

達人プログラマー―システム開発の職人から名匠への道

posted with AZlink at 2011.11.2

アンドリューハント,デビッドトーマス,Andrew Hunt,David Thomas,村上雅章
ピアソンエデュケーション
売り上げランキング: 13001

Amazon.co.jp で詳細を見る

の中で提唱した原則です．

よく知られたソフトウェア開発のベストプラクティスや

デザインパターンの中にも，

基本的な考え方がこの原則と同じものがたくさんあります．

開発者は，

アプリケーションの中に何らかの「重複」があれば，

または，重複が起きそうであれば，

それを察知する必要があります．

そして，適切なプラクティスや抽象化によって

それを排除する必要があるのです．

そのための方法を学べば，

よりきれいなコードを書けるようになるはずです．

重複は無駄である．

アプリケーションを構成するコードはすべて，

保守を必要とします．

どのコードも将来バグになる危険性を秘めています．

重複があると，

コードベースは不必要に大きくなり，

それにつれて，

バグが生じる危険性も高まります．

また，システムの構造は，

そう意図していないにも複雑になってしまいます．

重複によりコードベースが大きくなれば，

開発に携わる人間が

システム全体を完全に理解することも難しくなります．

特に困るのはコードに変更を加える時です．

どこかに変更を加えた場合，

それとロジック等が重複している箇所にも，

同様の変更が必要かどうかを確認しなければなりません．

DRY原則を守れば，

そういう事態に陥らずに済みます．

DRY原則を守るとは，

言い換えれば

「すべての知識はシステム内において，

単一，かつ明確な，

そして信頼できる表現になっていなければならない」．

という条件を満たすことです．

作業の重複は自動化で防ぐ．

ソフトウェア開発に関わる作業の多くは

「同じことの繰り返し」です．

つまり，作業が何度も重複します．

この重複は，自動化によって容易に解消できます．

DRY原則は，アプリケーションのソースコードだけでなく，

開発作業にも適応すべき原則ですが，

そのためには自動化が役立つというわけです．

例えば，テストは同じ作業の繰り返しになることが多いですが，

手作業でそれをやっていては手間も時間もかかり，

しかも誤りも起きやすくなります．

従って，可能な限り，テストは自動化すべきなのです．

同様に，ソフトウェアの統合（ビルド）も

同じ作業の繰り返しになることが多いですが，

手作業だと時間がかかり，

誤りが起きやすくなります．

従ってビルドプロセスも自動化し，

しかも頻繁に走らせるべきです．

コミットの度に走らせるというのが理想でしょう．

手作業だと負担が大きすぎるようなものは，

すべて自動化の対象となります．

自動化し，かつ標準化するのが望ましいです．

大事なのは，作業を遂行するための方法を

一つだけにするということです．

そうすれば，手間が省ける上，

問題も起きにくいと言えます．

ロジックの重複は抽象化で防ぐ

ロジックの重複には多数の種類があります．

例えばif-thenやswitchの部分が

単純にコピー＆ペーストされている場合は，

発見するのも解消するのも非常に容易でしょう．

デザインパターンの多くは，

明らかにアプリケーションの中の重複を減らす．

あるいは排除することを目的としています．

あるオブジェクトを使用するために，

整えるべき条件がほぼいつも同じであれば，

あの場合はAbstract Factoryパターンや

Factory Methodパターンを使用すればいいでしょう．

オブジェクトの振る舞いに様々な種類があり得る，

という場合には，長いif-thenを書くよりは，

Strategyパターンを使用します．

実際，デザインパターンは，

同じような問題について何度も繰り返し解決策を考えるという

重複が起きないように作られたとも言えます．

DRY原則は，

データベーススキーマなどの構造にも適用されます．

これは，いわゆる「正規化」につながります．

MyEnigma Supporters

もしこの記事が参考になり、

ブログをサポートしたいと思われた方は、

こちらからよろしくお願いします。

https://gumroad.com/l/myenigmasupportersgumroad.com

29. DRY原則 スティーブ・スミス (Steve Smith)：『プログラマが知るべき97のこと』

重複は無駄である．

作業の重複は自動化で防ぐ．

ロジックの重複は抽象化で防ぐ

関連する原則

関連記事

MyEnigma Supporters

29. DRY原則スティーブ・スミス (Steve Smith)：『プログラマが知るべき97のこと』