読者です 読者をやめる 読者になる 読者になる

MyEnigma

とあるエンジニアのブログです。#Robotics #Programing #C++ #Python #MATLAB #Vim #Mathematics #Book #Movie #Traveling #Mac #iPhone

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

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

プログラマが知るべき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が,

著書『達人プログラマー

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

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

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

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

開発者は,

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

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

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

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

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

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

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


重複は無駄である.

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

保守を必要とします.

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

重複があると,

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

それにつれて,

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

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

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

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

開発に携わる人間が

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

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

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

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

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

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:単一責任原則)という

有名な原則もあります.

これは,

「クラスに変更を加える理由は2つ以上存在してはならない

(一つの変更の理由は常に一つでなければならない)」

という原則で,やはりDRY原則が守られている場合にのみ有効です.



DRY原則は,

構造,ロジック,プロセス,機能などのあらゆる面で,

開発者がシンプルなアプリケーションを作るうえでの基本的な指針です.

この原則を守ることで,

シンプルで,品質が高く,保守もしやすいアプリケーションが

作りやすくなるのです.

状況によっては,パフォーマンスを上げるため,

あるいは何らかの要件

(データベースを非正規化しなくてはならないなど)

を満たすために,

重複がどうしても必要ということはあり得ます.

ただし,現実にすでに目の前にある問題に対処する以外の目的で,

DRY原則を破ってはいけません.

「こういう問題が起きそうだから,

原則をあらかじめ破っておこう」

ということをしてはいけないのです.



■著者データ

[スティーブ・スミス (Steve Smith)]

ソフトウェア開発者やメンターとしての仕事をする傍ら,

執筆や講演活動にも取り組んでいる.

プロとしてソフトウェア開発の世界で働き始めたのは1997年.

それ以降,主にASP.NETの分野で書籍への寄稿などもしている.

ユーザグループや,DevConnections,Microsoft TechEdなどの

カンファレンスでの講演も数多くこなす.

元アメリカ陸軍技術大尉で,イラク戦争で従軍し,

不発弾等,爆発物除去を行う小隊を率いていた.

オハイオ州で,妻と二人の子供とともに暮らす.

オハイオ州ハドソンのHudson Software Craftsmanshipの

コーディネータの一人でもある.


関連記事

1.分別のある行動 Seb Rose:『プログラマが知るべき97のこと』 - MY ENIGMA

2.関数プログラミングを学ぶことの重要性 Edward Garson:『プログラマが知るべき97のこと』 - MY ENIGMA

3.ユーザが何をするかを観察する (あなたはユーザではない) Giles Colborne:『プログラマが知るべき97のこと』 - MY ENIGMA

4.コーディング規約を自動化する Filip van Laenen:『プログラマが知るべき97のこと』 - MY ENIGMA

5.美はシンプルさに宿る Jorn Olmheim:『プログラマが知るべき97のこと』 - MY ENIGMA

6.リファクタリングの際に注意すべきこと Rajith Attapattu:『プログラマが知るべき97のこと』 - MY ENIGMA

7.共有は慎重に Udi Dahan:『プログラマが知るべき97のこと』 - MY ENIGMA

8. ボーイスカウト・ルール Robert C. Martin:『プログラマが知るべき97のこと』 - MY ENIGMA

9. 他人よりまず自分を疑う Allan Kelly:『プログラマが知るべき97のこと』 - MY ENIGMA

10. ツールの選択は慎重に Giovanni Asproni:『プログラマが知るべき97のこと』 - MY ENIGMA

11. ドメインの言葉を使ったコード Dan North:『プログラマが知るべき97のこと』 - MY ENIGMA

12. コードは設計である Ryan Brush:『プログラマが知るべき97のこと』 - MY ENIGMA

13. コードレイアウトの重要性 Steve Freeman:『プログラマが知るべき97のこと』 - MY ENIGMA

14. コードレビュー Mattias Karlsson:『プログラマが知るべき97のこと』 - MY ENIGMA

13. コードレイアウトの重要性 Steve Freeman:『プログラマが知るべき97のこと』 - MY ENIGMA

14. コードレビュー Mattias Karlsson:『プログラマが知るべき97のこと』 - MY ENIGMA

15. コードの論理的検証 Yechiel Kimchi:『プログラマが知るべき97のこと』 - MY ENIGMA

16. コメントについてのコメント Cal Evans:『プログラマが知るべき97のこと』 - MY ENIGMA

17. コードに書けないことのみをコメントにする Kevlin Henney:『プログラマが知るべき97のこと』 - MY ENIGMA

18. 学び続ける姿勢 Clint Shank:『プログラマが知るべき97のこと』 - MY ENIGMA

19. 誰にとっての利便性か Gregor Hohpe:『プログラマが知るべき97のこと』 - MY ENIGMA

20. すばやくデプロイ,こまめにデプロイ Steve Berczuk:『プログラマが知るべき97のこと』 - MY ENIGMA

21. 技術的例外とビジネス例外を明確に区別する Dan Bergh Johnsson:『プログラマが知るべき97のこと』 - MY ENIGMA

22. 一万時間の訓練 Jon Jagger:『プログラマが知るべき97のこと』 - MY ENIGMA

23. ドメイン特化言語 Michael Hunger:『プログラマが知るべき97のこと』 - MY ENIGMA

24. 変更を恐れない Mike Lewis:『プログラマが知るべき97のこと』 - MY ENIGMA

25. 見られて恥ずかしいデータは使わないこと Rod Begbie:『プログラマが知るべき97のこと』 - MY ENIGMA

26. 言語だけでなく文化も学ぶ Anders Noras:『プログラマが知るべき97のこと』 - MY ENIGMA

27. 死ぬはずのプログラムを無理に生かしておいてはいけない Verity Stob:『プログラマが知るべき97のこと』 - MY ENIGMA

28. 「魔法」に頼りすぎてはいけない Alan Griffiths:『プログラマが知るべき97のこと』 - MY ENIGMA