塚本です。
みなさんありがとうございます。最初に結論めいたことを言っておくと、
Refactoring は必要条件ではあっても十分条件ではない気がしたのです。
>>>>> "firo" == 矢崎 博英 <firo@....jp> writes:
firo> ここがまたXPのおもしろいところで、Refactoringは悪ではなく、
firo> むしろ開発の中でごく普通に行われる活動の１つだと考えられ
firo> ています（と私は解釈しています）。ですから、Refactoringの必要
firo> なユニットだらけになるのは、それは特に問題ではないと、考え
firo> られているようです。
前半はすごく納得ですが、Refactoring そのものが悪でなくても、過度の
Refactoring が発生する開発プロセスには問題がないといえるでしょうか。
firo> そしてさらにいえば、Refactoringに要する時間（コスト）と、将来
firo> に機能が追加されても簡単に対応できるために、今、そのための
firo> 柔軟性を確保するための時間（コスト）とを秤にかけた場合、
firo> Refactoringにかかるコストのほうが低くてすむと主張していると
firo> 思います。Refactoringは実際に短時間でできるし、またそうでな
firo> ければならないということです。
こうしたコスト比較についても、ケースバイケースな気がします。
>>>>> "佃" == 佃 軍治 <tsukuda@....jp> writes:
佃> 今開発すべきことだけを開発する。将来（次のイテレーションであ
佃> っても）開発するであろうことには備えない。
「今すべきことを今する」には賛成ですが「将来には備えない」ではなくて、
「将来すれば済むことは将来する」だと思うのです。
佃> 開発の順番は要件の着順次第ではなく、リスクの高いユースケース
佃> の順番になると思います。
暫定仕様での緊急性が低くても、本番に向けてのリスクが高いために今すべき
こともあるのではないですか?
>>>>> "石井" == 石井 勝 <mishii@....jp> writes:
石井> 塚本さん，こんにちは．石井です．
石井> 塚本さんは，XPを導入すれば，変更コストのカーブがほとんどフラットな開発
石井> プロセスになると信じてますか？
石井> もしこれが成り立つのなら，初号機の仕様できちんと動くものをしっかり作って
石井> 例えば半年後次期開発が来たときにRefactoringを行ってもあまり問題では
石井> ないと思うのです．
単に「いつも Refactoring してさえいれば、緊急性の高い機能から順に実装
しても変更コストはほとんど線形になる」と主張されると不信感がわきます。
>> MVC にしても、フレームワークとして提供されているものを「使う」ぶんには
>> MVC なしの実装をスクラッチで書くよりもむしろ、アプリケーションコードは
>> シンプルになり得ると思います。
石井> そうですね，フレームワークのことは考慮にいれてませんでした．
石井> 申し訳ありません．
いえいえ、こちらこそ話のきっかけにしてしまってごめんなさい。
>> 話は変わりますが、「シンプル」と「拡張性」の両立というと、XP が OCP
>> (Open-Closed Principle) とどのように協調できるかにも興味があるのですが、
>> そのあたりはいかがでしょう?
石井> うっ，これを僕に聞いてくるということは僕のホームページをご覧になったん
石井> ですか？^^;;．
はい、そうです。それ以前にたしか雑誌記事でも拝見したような気がします。
石井> XPの場合，OCPもデザインパターンと同じく到達点の一つと考えています．
石井> 仕様が複雑になってきて対応していたらいつのまにかOCPを満たすような
石井> 設計になっていた，という．
到達点は、手探りで偶然に見つかることもあるでしょうが、経験を積んできた
人は必然的に似たような目印を見つけようという意志を働かせるでしょうね。
個人的な見解として、ソフトウェア習熟度の向上とは、そうした到達点を偶然
から必然に移行させる過程のような気がします。XP で未開の道を開く際には、
やはりパターンや OCP など先人の知恵を借りることになるかと。
--
Yoshihiro Tsukamoto