山根です。
＃僕が好意的に読みすぎてるんでしょうか・・・
＃それとも、そもそもＸＰを理解していない？(T_T)
On Mon, 19 Nov 2001 19:25:07 +0900
"nyonyoru" <fwii7128@....jp> wrote:
> にょにょると申します。
>
> 行数が多いプログラム＝わかりやすい
> というのは妙ですし、短くするためにトリッキーなコードを書かれても
> 困ります。
前者の
> 行数が多いプログラム＝わかりやすい
という件に関しては、特に妙だとは僕は思わないです。
と言うか、古いプログラマ世代の人は分かるかと思います。
＃歴史の変遷ですかね？f(^_^;
まだ、ハードウエアスペックがプアな時代は、
ソースの可読性を犠牲にしてでも、メモリの使用効率や、
速度を優先するように教わり、かつその奥義(?)を
先輩から伝授されていました。f(^_^;
でも、そのコードは当然奇妙奇天烈でそのテクを知らない人には、
さっぱり分からないようなコードだったりしました。
その後、メモリも潤沢で、性能も天文学的な物が手に入れられるようになって
可読性とか、保守性とかの重要性が認められるようになったんです。
で、可読性を上げる方法もどんどん変わっていってます。
昔は、コメントを大量に書いて可読性を上げると言う時代もあったのです。
＃そんな時代は無い？じゃぁ、自分の周りだけなのかもしれません。(T_T)
時代時代で求められていることが変わってきているのです。
だから、
短くトリッキーなコードを書く人：アセンブラ世代の人
トリッキーなコードを排除した長いプログラム：Ｃ全盛の人
と言うことで、その先に、ＸＰでというか本来あるべき、
シンプルさがあるのだと思います。
＃上記表現は、かなりＣerや、アセンブラーな方には
＃失礼な文章かも知れません。
だから、この記事では、この変遷を述べずに、
「長く読みやすいコードより、短いコード」という事を
述べているから誤解が生じてるのであって、
決して先祖帰りを容認しているわけではないと思います。
＃容認しているように読めるのは事実ですが。f(^_^;
> ”短い”というのは、Simpleの一要素に過ぎないのに、これだけを
> 大きく取り上げているのがそもそもの間違いでしょう。
えぇ、そうですね。
ＸＰ本や、「達人プログラマー」には、シンプルであることの
定義がなされていますね。
> ・顧客に要求を変えさせるのである
> この文は、開発側がストーリーの重要度を見積もって、開発側が
> 重要度の低いストーリーを切り捨てる、というように読み取れます。
そう読めした？
確かに、そう読めるかも知れません。f(^_^;
> それに、基本的にストーリーの重要度は
> 顧客しか知らないように思えます。
そんなことは無いと思いますよ。
少なくとも、計画ゲームの過程でストーリの優先度は共有している
必要はあるでしょう。
顧客しか「知らない」のではく、「定義できない」ということですね。
> ただ、上の一文だけ抜き出せば、ある意味正しいのでしょう。開発速度を
> 顧客に提示することによって、重要度の低いストーリーを後回し、ある
> いは破棄してもらうのですから、結果的には顧客に要求を変えさせている
> ともいえるはずです。
おっしゃる通りで、
選択権は顧客にあるものの、その裏にプログラマが見積もったコストが
ある以上、「変えてもらう」シグナルを発するのはプログラマー側だと
思います。
だから、「変えてもらう」か、「変えさせる」は語調の強さは
違えど、僕は同じだと思います。
> ＃ただ、顧客にそう思わせた時点で、顧客との一体感が無くなり、その
> ＃XPプロジェクトは失敗に向かう気もします^^;
だから、事前にその旨を説明しないといけないんですね。
実装するスコープを決定するのは顧客の権利ですが、
その見積りを行い、オーバーワークの部分を顧客に伝えるのは、
プログラマの権利で、そのため、マネージャが間で人間関係が
壊れないように取り持つんだと思いますよ。f(^_^;
＃ガンバ、マネージャp(^o^)q。僕には出来そうに有りません。f(^_^;
> ・処理の流れを追いやすいように同じ処理が繰り返し出てくるようなソース
> これ非常に疑問です。
> 同じ処理がなんども繰り返されるよりも、Extract Methodを適用して、
> すっきりしたコードの方が分かりやすいはずです。
確かに、疑問ですが人それぞれということじゃないですかねぇ？
＃ごめんなさい。逃げてます。
＃僕もにょにょるさんと同感なんで。
例えば、いろいろなオブジェクトに処理を委譲するような
コードは、メソッドジャンプばっかして追いにくい
という人は世の中に*確かに*います。
そうなると、そのプロジェクトメンバーにそった方式と言うのを
取らないとコスト増に繋がるのも確かです。
最近、短期のプロジェクト多いからねぇ。
みんなで、お勉強しながらって言うのもなかなか難しいんですよ。
（と、現場の愚痴を言ったりしてみるf(^_^;）
＃実際、Javaで構造化でってプロジェクトいくつか
＃観てきました。f(^_^;
技術的・論理的に正しい＝正道って訳に行かないのが、
この業界のおもろい(?)ところだと思います。f(^_^;
まぁ、当然目に付く範囲はいろいろ啓蒙して言って、
自分の周り*だけ*は、住みやすくしていこうとは思ってますけど。
> ところで、
> to 山根さん
> ＞（というか、開発方法論と再利用は、別次元の問題だと思ってます）
> これを疑問に感じた人が作った方法論”Drop”というものがあります。
> 関係ないですが、参考までに。
> http://www.njk.co.jp/otg/Drop/Drop_v20/
>
> ＃すでにご存知でしたらすいませんm(__)m
いえ、存在だけは大昔（まだ、オブジェクト指向し始めた頃）から
知ってたのですが、深くは入り込んでいません。
が、私が言いたいのは、
「再利用性は知識の領域でなされる物で、開発方法論の中に答えは無いのでは？」
と言うことです。
＃私見です。
＃この私見に対する元ネタは無いです。
＃個人的な稚拙な経験則です。ごめんなさい。
今、さっと再利用に関係してそうなところをはしょってみてみました。
＃「第１８章 再利用基盤モデル」と
＃「第４章 Dropの目指すもの」の中の、
＃「再利用性、そして拡張性・保守性の問題」
なるほど、確かに「再利用」に関する記述はあります。
が、Dropは、開発方法論と共に設計方法論も多少入っていますよね。
再利用に関する記述は、どちらかと言えば設計方法論に近いように思えます。
ここでいう開発方法論と、設計方法論の違いは、
開発方法論＝プロジェクトをどのような形態で
進めていくかを形式化(?)したもの
設計方法論＝与えられた命題（＝システム）をどのように分析/設計
コード化していくかを形式化(?)したもの
です。
＃で、ＸＰにしろ、ウォーターフォールにしろ僕は、
＃開発方法論でしかないと認識しています。
開発方法論としては、「再利用に関するフェーズが無いことが問題」とも
言っていますが、仮に有っても、そこでパターンや、パターニングのスキル、
そして、業務ドメインに対する知識が無ければ、とてもまともな、
再利用化なんて出来ないと思います。
逆にいえば、すーぱーなオブジェクトモデラーがいれば、
開発方法論に因らず、再利用可能な物が導き出せるのではないかと
言うことです。
＃さすがに、ウォータフォールでは無理かもしれませんが。。。f(^_^;
長くなってしまいました。（文才無いんですね）
ごめんなさい。
Eiji Yamane（山根 英次）
E-Mail:e-yamane@....jp (Official)
e-yamane@....com (Private)
URL:http://www.ne.jp/asahi/e/yamane/index.html