Index: [Article Count Order] [Thread]

Date:  Tue, 20 Nov 2001 09:56:04 +0900
From:  k-hamai@....com
Subject:  [XP-jp:02808] Re: XP に関する誤解
To:  extremeprogramming-jp@....jp
Message-Id:  <200111200056.JAA18038@....jp>
In-Reply-To:  <20011119165348.2E98.E-YAMANE@....jp>
References:  <20011119165348.2E98.E-YAMANE@....jp>
X-Mail-Count: 02808

濱井です。
2001/11/19 17:10:27 +0900にe-yamane@....jpさんが送られた
メールに関する返信です。

>> XPの名前が広まると誤解する人も増えるようです。
>> 
>> http://www.atmarkit.co.jp/fdotnet/opinion/kawamata/2001_11.html
>まだまだ、未熟者の自分としては、そんなに大きく逸脱しているとは
>思えないのですが・・・
>
>濱井さんご自身は、どこを「誤解」と感じたられたのでしょうか?
>ご教示いただければ嬉しく思います。

私もXPに関しては未熟もいいとこですが。
私が理解したかぎりでは、良いプログラムと短いプログラムの
関係において、記事の筆者の川俣さんの主張は「短いプログラムは、
良いプログラムである」というもので、XPの考え方は「良いプログラム
は、(単純な、無駄のない、)短いプログラムである」というものです。

論理的には逆であり、「逆は必ずしも真ならず」という言葉通り、
命題の真偽は必ずしも一致しません。「ヒトは哺乳類である」は真です
が、「哺乳類はヒトである」は偽です。

XPでは、単純でわかりやすいプログラムを書こうとする結果、短い
プログラムになるのです、短いプログラムを目指すのではありません。

かなりの程度まで単純さと短さは両立しますが、限界まで短さを
追求していくと複雑でわかりにくいプログラムになりがちです。

Java コーディング標準(オブジェクト倶楽部バージョン)
http://objectclub.esm.co.jp/download.html#coding

で「トリッキーなコードは悪」として挙げられている例など、その
典型です。

	for (int i = 1; i <= N; i++)
		for (int j = 1; j <= N; j++)
			M[i-1][j-1] = (i/j)* (j/i);


>個人的に上記サイト(並びに、その前段の記事)で
>・短いコード=シンプルデザインではないと思う。
> (三項演算子が多用されているコードなんて、嫌々。
>  メンバがpublicなのも、追うのが面倒なので嫌々。)
>・不要なコードが無い=再利用性が無いとは言えないんじゃないか。
> (というか、開発方法論と再利用は、別次元の問題だと思ってます)
>・ペアプロのペアはデバッグ(だけを)するんじゃないよ。
>
>という三点について、紙面の都合で説明し切れてないのかもしれませんが、
>ちょっと強引かなぁと感じました。

あの短い記事で3ヶ所もあれば、充分だと思いますが、他に私がおかしい
と思ったのは、にょにょるさんが指摘された。

>・顧客に要求を変えさせるのである

のところです。また、XPとは矛盾しませんが。

>・処理の流れを追いやすいように同じ処理が繰り返し出てくるようなソース

のところもおかしいと感じました。


短いコードについて言うと、既に述べたように、XPは単純なプログラム
を目指してはいても、短いプログラムを目指してはいないと思います。

再利用性について、私の乏しい経験から言うと、再利用の障害になる
のは、コードが不足していることではなく、余分なコードがあること
です。
足りない機能の追加は簡単ですが、邪魔な機能の削除は困難です。

ペアプログラミングについて言うと、レビューの極端な形であり、
他人がバグを見つけるのが早いか遅いかの違いだと思います。
もちろん、ペアプログラミングには、二人が助言し合うといった
効果もあります。

要求については、XPは顧客に変えさせるのではなく、優先度を明確に
させるだけです。顧客の優先度の高い機能から実現していくだけです。
顧客にとって優先度の高い機能が確実に実現されていく、要求の変更に
柔軟に対応する等の点で、all or nothing のウォーターフォール型
開発より、XPは顧客を大事にする手法です。


また、同じ処理が繰り返し出てくるようなソースはわかりにくいソース
です。同じ処理が、2、3ヶ所ならともかく、何十ヶ所と出てくると、
本当に同じかどうか、細心の注意をはらう必要があります。違う箇所が
あったりすると、ミスによるものか、意図的に変えられたものか、
判断に苦しむことになります。
処理が適切に括り出されていれば、ブラックボックスとして詳細を
無視できるのでプログラムはわかりやすくなります。