おばら＠システムソフトといいます。
At Wed, 19 Jun 2002 00:39:49 +0900 谷野健一 wrote:
》谷野、というものです。
》
》At 09:48 02/06/18 +0900, you wrote:
》>はじめまして。片岡と申します。
》
》はじめまして。
わたしも、はじめましてです。
》>それを回避するためのテストでは？
》>欠陥が欠陥を生むのはむしろ
》>
》> > 信頼性を高めるためには、可能な限りソフトウェアを変更しないように
》> > すべきであり
》>
》>という従来の考え方だと思います。
》
》でもないと思います。その前提としては、「開発者の能力が「とても」高い」
》という前提が隠れていると思います。
》
》なぜなら、変更したら、どのようになるか、というのが分かるのは「とても」高い能力
》だと思うからです。
》#他の会社は違うのでしょうか。。。
というか、それはやり方が問題なのではないでしょうか。
マーチン・ファウラーさんは、ちょっとずつ変更し、
変更してはテストを行う事と著書の中で言ってますよね。
で、リファクタリングの利点として、コードを理解する
事をあげています。
コードを理解しつつ、ちょっとずつ変更し、変更した
コードによる問題を早期に見つけるためのテストなので
はないでしょうか。
》>また「動いているんだから触らないでおこう」という日和見主義では潜在的な欠
》>陥は永久に解消されませんが、XPではリファクタリングとテストを適切に実施す
》>ることで欠陥が解消される可能性があり、また現状より劇的に悪化することはあ
》>りません。
》
》「劇的に」はありませんが、ひとつもバグがあって欲しくない状態の場合は
》なかなか堪えるものがあります。
》
》例えば、5日後に納期の場合に、設計の問題が見つかったからと言って
》リファクタリングしますか?
》
》微妙だと思います。5日って。1〜2タスクだし。
》#前日なら絶対にやらない。
》5日が微妙じゃないというなら、2週間前だって、結局は同じことです。
》
》そーゆー場合、ウォーターフォール的にFIXしたほうがいい場合はあると思います。
》#要は適材適所だと思います。
そうですね。期間が迫っているときに、リファクタリング
を避けなさいと、これも同氏の著書で言っています。
ある機能を追加する場合に、下手に現在のコードを弄ると、
どんな影響が現在動作中のコードに影響を及ぼすかわから
ないようなコードの場合には、そこだけの修正で済むとは
限りませんよね。しかもバグを入れないで修正するなんて
とても無理じゃないでしょうか。結局リファクタリングし
た方が、コードの理解につながるし、変更もしやすくなる
という場合もあるでしょう。
》>XPは「変更はどうせ発生する」という前提において「変化ヲ抱擁セヨ」と主張し
》>ているのですから、変更のコストを惜しむとXPの利点は活かせないでしょうね。
》
》でも、ビジネスもあることですし、変更のコストも惜しみますよ。
》リーダとしては。
》
》でも、利点はある程度欲しい、ということで悩みどころではあります。
リファクタリングした時の見積もりがしにくい
というのはありますね。
現行のものを必要な分のみ変更するという考え
で見積もった方が簡単だと思いますし、その為、
先が見える方を選んでしまうという事になるの
ではないでしょうか。
リファクタリングを行ったときの見積もり方と
いうのは、経験しかないのでしょうかね。
わたしにはこの辺りが興味あるところなので、
識者の方々のご意見を聞いてみたいです。