本当の問題にたどり着かない――思考の重複を起こさないための「DRY」原則：問題解決力を高めるコツはプログラミングの原則・思考にあり（5 ）（3/3 ページ）

本連載では、さまざまなプログラミングの原則・思考の中から、特に問題解決力を高めるのに役立つものをピックアップ。プログラマーは、その思考法をビジネスに応用し、そうではない人はプログラマーと一緒に働く際に思い出してほしい。「ヤクの毛刈り」のように、「本当の問題」になかなかたどり着かないということがある。今回は、プログラミングの「DRY」原則から思考の重複を起こさないための手法を学ぼう。

[上田勲，著]

　発展1　〜DRYの適用範囲

　本来、DRYの適用範囲は、コードに留まりません。ソフトウェア開発に関わる活動すべてに適用できます。

　例えば、ソフトウェア開発における作業には、「同じことの繰り返し」が多くあります。この作業の重複についても、DRYを適用するべきです。

　具体的には、繰り返し作業を「自動化」します。これにより、手作業の負担がなくなり、作業が正確になり、人によるバラツキがなくなります。

　自動化の対象とされる代表的な作業としては、継続的インテグレーションと呼ばれる、ソフトウェアのテスト・ビルド・リリース作業があります。これは、特定のタスクをこなすために設定したインテグレーション・サーバーの下で、ソフトウェアのビルド、テスト、デプロイ等を、確実かつ頻繁に自動実行するというものです。継続的インテグレーションは、繰り返しの手作業がなくなることのほかに、ビルドの品質が安定することや、ビルドが属人化しないこと、問題の早期発見など、多くのメリットが享受できます。

　発展2　〜DRYとプログラミング技術

　プログラミング技術の多くは、DRYを実現するための機能を備えています。というよりは、技術の多くは、コードの重複を排除することを目的の1つとしています。例えば、構造化プログラミングや、オブジェクト指向プログラミングの技術は、関数やモジュールを構成して、重複を排除するための手法を含んでいます。

　同様に、設計手法の多くも、重複を排除することを目的に含んでいます。代表的な設計手法に、デザインパターンがあります。デザインパターンは、コードを再利用可能（拡張可能）にするための、コード構造パターンを提供しています。これは、別の側面から見ると、同じような問題について何度も繰り返し解決策を考えるという「思考の重複」が起きないような手法とも言えます。

　一般に、技術や手法は、ある目的を持って編み出されていきます。手法を学ぶ時は、やり方そのものだけをなぞるのではなく、その目的を意識することが習得への近道です。

　発展3　〜やむを得ないDRY違反

　ソフトウェア開発においては、ある程度やむを得ない重複も存在します。

　例えば、インピーダンス・ミスマッチです。プログラミングと、それが使用するサービスの溝を埋める情報部分では、不可避な重複が発生します。

　インピーダンス・ミスマッチは、もともと電気分野の用語で、素材間の抵抗（インピーダンス）が異なる（ミスマッチ）ため、反射が起きてエネルギーがうまく伝わらないことを意味します。これを比喩として、構造の異なる2つのものをつなげる時の「困難さ」を表現しています。

　ソフトウェアの世界でミスマッチが発生しやすいのは、異なる抽象化スタイルの境目です。その最たる例が、オブジェクト指向プログラミングのクラスと、リレーショナルデータベースのテーブルです。リレーショナルデータベースと、それを扱うプログラミング言語があった場合、そのミスマッチを埋めるためには、リレーショナルデータベース側に「テーブル定義」、コード側に「テーブルマッピング設定ファイル」「ソースファイル」と、3箇所に同じ情報を持つことになります。このような重複は、ある程度仕方がないと言えます。

　ただし、対策がないわけではありません。例えば、情報はどこか1箇所に集中して持たせ、そこから他の情報を自動生成するような仕組みを作れば、情報を一元管理できます。

　関連1　〜WET

　DRYに対して「WET」という概念があります。これは「Write Every Time」ないし「Write Everything Twice」の略語で、いずれも「同じことを繰り返す」という意味です。DRY（乾いた）とWET（湿った）という対比になっており、略語としても、その指し示す意味としても、DRYの対義語になっています。

　DRYになっていないコードに対する、皮肉的な表現として使用されます。

　関連2　〜One Fact in One Place

　「One Fact in One Place（OFOP）」は、「1つの事実は1つの場所にのみ存在させる」という意味で、データベース論理設計における、テーブル設計の要となる原則です。

　DRYがプログラミングにおけるコードの重複を禁じているように、OFOPはデータベースに格納されるデータの重複を禁じています。「1つの事実は、1つの場所のみに存在させる」ことにより、データの冗長性や不整合（更新異常）を防ぎます。

　OFOPを実現するためには、「正規化」を行います。プログラミングにおいて、重複を排除する方法は多種多様ですが、データベースにおいては、「正規化」が唯一無二の設計手法です。

　関連3　〜Once and Only Once

　「Once and Only Once（OAOO）」は「一度だけ、たった1度だけ」という意味です。要するに「重複を含んではならない」ということで、DRYと意味や目的は同じです。

　ただし、OAOOはDRYより適用範囲が狭く、プログラミングの文脈でのみ使用されます。コードに重複がないこと、不必要なコードがないことなどが強調されています。

　関連4　〜レガシーコード

　重複を持っているようなコードは、たいていの場合、テストがありません。テストがないコードのことを「レガシーコード」と呼びます。

　かつて「レガシーコード」と言えば、「昔に作られた、理解できず、変更の難しいコード」を揶揄する俗語でした。しかし、テストによる品質保護を重要視する目的で、「テストのないコード」と再定義されました。

　この再定義によると、テストのないコードは一律悪いコードとなります。コードが非常にきれいで、しっかりと構造化されていても、テストがなければレガシーコードです。

　この定義は、厳しすぎる印象があるかもしれません。しかし、確かにきれいなコードは有益ですが、それで十分というわけではありません。なぜなら、テストなしにコードを変更することは「危険な賭け」だからです。テストがあれば、検証しながらコードの動きを素早く変更することができます。コードを改善すると言っても、テストがなければ、コードがよくなっているのか悪くなっているのか、本当の意味ではわからないのです。

　したがって、レガシーコードと相対することになったら、まずテストを作成しましょう。エレガントでなくて構いません。どんな方法を使ってでも、まずテストを用意してから、修正を行います。品質を守る上で、この手順は必須です。

出典書籍

『達人プログラマー―システム開発の職人から名匠への道』アンドリューハント他, ピアソンエデュケーション（2000）

関連書籍

『レガシーコード改善ガイド』マイケル・C・フェザーズ, 翔泳社（2009）

『継続的インテグレーション入門』ポール・M・デュバル他, 日経BP社（2009）

『プログラマが知るべき97のこと』和田卓人他, オライリー・ジャパン（2010）

『良いコードを書く技術―読みやすく保守しやすいプログラミング作法』縣俊貴, 技術評論社（2011）

『ソフトウェア開発はなぜ難しいのか〜「人月の神話」を超えて』大槻繁, 技術評論社（2009）

『具体と抽象―世界が変わって見える知性のしくみ』細谷功, dZERO（2014）

書籍紹介

プリンシプル オブ プログラミング 3年目までに身につけたい 一生役立つ101の原理原則

上田勲著
秀和システム　2,200円

一通りプログラミングができるようになった。しかし、読みにくい、遅い、頻繁にエラーが発生する、書いたコードを修正すると動かなくなる等々、なかなか「よいコード」を書けないとお悩みではありませんか？ 本書は、よいコードを書く上で指針となる前提・原則・思想、つまり「プリンシプル」を解説するプログラミングスキル改善書です。初心者向けの書籍では絶対に説明しない、古今東西のプログラマーの知恵をこの一冊に凝縮しました！