重複を発見し１つのコードに洗練させよう: Don’t Repeat Yourself
ソフトウェア業界には、より良くモノづくりを続けるために様々な原理原則が伝承されていますが、今日は、『達人プログラマー』で紹介された最も有名なDRY（Don’t Repeat Yourself）の原理ご紹介です。
c2.com では、DRYを次のように説明しています。
Every piece of knowledge must have a single, unambiguous, authoritative representation within a system.
http://c2.com/cgi/wiki?DontRepeatYourself
DRYは、対象ドメインやコードや各種ドキュメント類や開発時の暗黙的な身体知などなど、ありとあらゆる知識を整理整頓し、重複なく１つの、明瞭で、信頼できるカタチに洗練させることを強く推奨します。よく対比されるOnce And Only Once とは違ってコードの重複だけなく、幅広い重複に注意を払って取り除くのが特徴です。
知識の透明性の向上、変化への適応力を向上
DRY原則を守ることで、知識の透明性を向上させ、あとからの変更に適応しやすくなることが期待できます。
もしDRY原則を破って開発を続けてた場合、コードやドキュメントや作業のあらゆる箇所に重複が現れ開発作業の複雑性が増大し、変更の際に大きな痛みを伴います。重複が、ユーザからのフィードバックに応えることの大きな阻害要因になってしまうのです。
コードの重複
過去にコピー＆ペーストでつくったコード、正規化されていない混乱したコードでは、プログラマは理解に苦しみ、変更箇所の特定に頭を悩ませ、修正後の動作確認の手間を増やします。頻繁に継続してメソッドの抽出などのリファクタリングや、データの正規化を行ない、コードを洗練させることが肝要です。
重複に目を光らせる対象は、単にコードだけではありません。
ドキュメント類の情報の重複
チームの方針によっては、コードのほかに仕様書、設計書、テスト仕様書といったドキュメント類の成果物が指定されています。だけれども、要望の変更の際に成果物の情報の整合性を保つ作業に大きな労力がかかってしまうのであれば、なにか改善の余地があるはずです。
設計モデルからプロダクションコードを生成するアプローチや、逆にプロダクションコードからER図を生成しドキュメントに反映するアプローチが、複数の成果物間で情報の重複を減らす方法の典型例です。
FitやCucumberなどBDDやAcceptanceTestといったツールは、仕様書とテスト仕様書を、各々のロール別がバラバラに成果物を管理する代わりに、テスト仕様書（≒テストケース）に集約するアプローチを取っています。記述された仕様書は、単にプログラマやビジネスオーナやテスト専門家といった人だけが読めるではなく、コンピュータも読んで実行できる仕様書にまとめ上げている点が大きな特徴です。これもDRY原則を実践した具体例になります。
余談ですが、FitやCucumberなどのように、人と人と機械によるコラボレーションを加速させ、人がほんとに欲しかったものに近づくように設計されてた道具類が私は大好きです。
Great software requires collaboration and communication. Fit is a tool for enhancing collaboration in software development.
重複はコードや複数の成果物の情報だけではありません。
手作業の重複
コードやドキュメントの他に、繰り返し行われる手作業も取り除くべき重複となりうる対象です。暗黙的で混乱しがちのインフラ構築作業、デプロイ作業、データベースのマイグレーション作業、インテグレーション作業、テスト作業などなどもコードで明白に記述する道具が近年揃ってきました。
簡潔明瞭にコードで期待する状態や振る舞いを記述できれば、１人の暗黙的なりがちな各種作業の知識がコードによってノウハウが明瞭になり、また自動実行によって、より安全に、確実に、素早く実行できるようになります。
重複について、「達人プログラマー」では、そのほかにもチーム間の重複した作り込みなど触れています。「達人プログラマー」は、同僚や先輩などに借りて参考にしてみてください。
物理法則の発見とDRYと楽しみ
DRY原則が他分野の何に類似しているか考えたとき、ぼくは物理学での法則の発見を連想します。
天体観測で複雑な惑星運動、実は楕円軌道で簡潔明瞭な数学モデルで記述でき、未来を予測できる普遍的な法則の発見はある種の神秘的な美を感じます。あるいは、天と地は分かれて別々の法則が成り立つと考えていたことが、実は万有引力の法則で統一した数学モデルで明瞭に記述できることの発見は、当時の人達にとって、ある種の驚きと喜びを感じたことでしょう。アインシュタインにいたっては、エネルギーと質量と光速の関係性を簡潔明瞭な数式で表しました。複雑な物理現象が短い数式で表現できるのは驚きです。
プログラマも、目の前に繰り広げられる、混沌とした重複したコードや成果物の情報や作業を見つめ、複雑で混乱した中から本質的、普遍的なことを見つけだし、コードとして洗練させて簡潔明瞭に記述して動かせたまさにそのとき、プログラミングの美しさ、楽しさ、面白さを感じるはずです。
まずはコードの重複の発見から
過去の経験上、コードの形状と人の心には深い相関関係があるとぼくは考えます。重複を取りきコードの調和を保てば、プログラマの心の平穏を保つことができ、周囲からのプロダクトに対する予期せぬフィードバックにも落ち着いて対応できるようになるはずです。まずは、いま目の前にしているコードを読み、重複コードの発見し、取り除くところからはじめてはどうでしょうか。
一方、重複したコードの取り除くことに熱中するあまり、悪い意味でのメタプログラミングやマクロ等を駆使することで、あとでコードを引き継いだ人が理解できずに、混乱に陥ってしまう場合もあります。「リーダブルコード」に紹介された、人が読んで理解するまでの時間を最小にすることの原則も忘れてはいけません。「リーダブルコード」については、別の機会に紹介します。
