にょにょるです。
#皆様展開が速い速い。追いきれません(-_-;)
どうも自然言語は意味が揺れてしまうのでいけません。
解釈ズレのトラブルが起こりますね。
クラス、メソッド名も然り、です。
#自然言語より自由度が無く、自然言語と同程度の
#表現力を持つ言語って無いのでしょうか^^;
さらに知識を共有していなくても、話が通じません。
デザパタを知らない人にとって、JUnitの設計も複雑です。
#”設計の終焉？”の”単純さとはいったい何か”参照
#http://objectclub.esm.co.jp/eXtremeProgramming/IsDesignDead.html
επιστημηさんのおっしゃられている通り、読み手に一体
どの程度の知識レベルを求めるのか、悩ましい問題ですね。
プロジェクトメンバーに合わせると、それによって便利なライブラリ、
設計技法が使えなくなって、その人の生産性が落ちるでしょうし、
メンバーにその人と同じ知識レベルを求めると、教育にコストが
かさむでしょうし。
to 山根さん
（部分部分にレスつけています）
>> 行数が多いプログラム＝わかりやすい
>という件に関しては、特に妙だとは僕は思わないです。
これに関しては、意味揺れが起きてるみたいなので深く突っ込めません。
とりあえず冗長なコードは悪いという点で同意していただいているので、
僕としては満足です。
#僕の満足なんてどうでもいい話ですが。
昔話についてはよくわかりません（まだ１８なモノで(^^ゞ）。そういう
時代があったのだな、と解釈しておきます。
>顧客しか「知らない」のではく、「定義できない」ということですね。
ですね。そちらのほうが正確です。
> ＃実際、Javaで構造化でってプロジェクトいくつか
> ＃観てきました。f(^_^;
>
グハ^^;
でも、確かに下手なOOよりもましかも知れません。
> 技術的・論理的に正しい＝正道って訳に行かないのが、
> この業界のおもろい(?)ところだと思います。f(^_^;
>
どこでも一緒のような^^;
> 「再利用性は知識の領域でなされる物で、開発方法論の中に答えは無いのでは？」
> と言うことです。
> ＃私見です。
> ＃この私見に対する元ネタは無いです。
> ＃個人的な稚拙な経験則です。ごめんなさい。
>
> 今、さっと再利用に関係してそうなところをはしょってみてみました。
> ＃「第１８章 再利用基盤モデル」と
> ＃「第４章 Dropの目指すもの」の中の、
> ＃「再利用性、そして拡張性・保守性の問題」
>
> なるほど、確かに「再利用」に関する記述はあります。
> が、Dropは、開発方法論と共に設計方法論も多少入っていますよね。
> 再利用に関する記述は、どちらかと言えば設計方法論に近いように思えます。
> ここでいう開発方法論と、設計方法論の違いは、
> 開発方法論＝プロジェクトをどのような形態で
> 進めていくかを形式化(?)したもの
> 設計方法論＝与えられた命題（＝システム）をどのように分析/設計
> コード化していくかを形式化(?)したもの
> です。
了解です。開発方法論は戦略的で、設計方法論は戦術的ということですね。
おっしゃっていることがようやく分かりました。そのような分類ならば、再利用性は
開発方法論の中にはないでしょうね。
> 開発方法論としては、「再利用に関するフェーズが無いことが問題」とも
> 言っていますが、仮に有っても、そこでパターンや、パターニングのスキル、
> そして、業務ドメインに対する知識が無ければ、とてもまともな、
> 再利用化なんて出来ないと思います。
>
同意です。再利用フェーズを設けても、プログラマがへたれだと、どうしようも
ありませんからね。
にょにょる
神戸大学情報知能工学科一回生
http://www.geocities.co.jp/SiliconValley-PaloAlto/5227/