連載
» 2017年08月22日 05時00分 公開

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

[上田勲,著]
前のページへ 1|2|3       

 発展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の原理原則

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

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

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


注文ページへ


前のページへ 1|2|3       

Copyright © ITmedia, Inc. All Rights Reserved.

RSSについて

アイティメディアIDについて

メールマガジン登録

@ITのメールマガジンは、 もちろん、すべて無料です。ぜひメールマガジンをご購読ください。