- - PR -
ソフト開発を成功させる1つの方法の感想
| 投稿者 | 投稿内容 | ||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
投稿日時: 2001-11-18 19:19
今手元に無くて、うろ覚えですが、「いつリファクタリングすべきか」というような章があったと思います。 リファクタリングしてみて、「かえって回りくどく、分かりにくく」なってしまった (と思える) のなら、それは、すべきではない時にしてしまったということだと思います。 リファクタリングに示されているサンプルは、サンプルであるがゆえに単純になっています。 そのため、リファクタリングの必要がないのに、むりやりリファクタリングしているように見えるのだと思います。 私も、10行くらいのメソッドでローカル変数を除去する必然性は感じられませんし、switch 文を一つ減らすためだけにポリモーフィズムを使う必然性も感じられません。 XP 的に言うなら、コードをより明晰にするためにリファクタリングせよ、ということではないでしょうか。 すなわち、ローカル変数をメソッドとして括り出してメソッド数を増やしたほうが「設計が単純になる」、ポリモーフィズムを導入してコードが複雑になったとしても「意図が明確になる」、といったような場合にリファクタリングすべきなのだと思います。 ※ ローカル変数を問い合わせメソッドで置き換える (Replace Temp with Query) 場合、次のような効果も挙げられていますね。
私には、こういう効果があるときに積極的に使いなさい、と読めてしまいました。 | ||||||||||||||||||||
|
投稿日時: 2001-11-19 13:29
あります。ですが、 ・ 機能追加の時 ・ バグフィックスの時 ・ コードデビューの時 と3種類説明されていて、事実上「コードを理解したいとき」と同義語です。 分かりにくいコードを理解するためにリファクタリングする、ということは問題を感じません。それはやるべきことでしょう。 問題は、ローカル変数やswitch文を追放することが常に理解しやすさを向上させるとは思えないことです。
いや、サンプルはサンプルでしょう。それが無意味に見えるとしても、解説書なんだからしょうがありません。本当に読めないソースをリファクタリングする例を書いたら、読者が付いてこられませんよ 
この本では前提条件を付けずに、ローカル変数を追放するのは良いことだ、というような雰囲気で書かれているように読めます。「設計が単純になる」かどうかを吟味するというニュアンスは読みとれませんでした。 念のために書くと、ローカル変数を減らすことは賛成。込み入ったローカル変数の利用を避けるのも賛成。たとえば「制御フラグの削除」は私も昔からやってきたことで、自分の考えは間違いではなかったと思うことが出来て収穫でした。
この本では、switch文の存在は不吉な匂いとしています。まず、ポリモーフィズムが使えないか試してみること。それから、わずかなケースに分岐し、条件が追加されないようなケースは「明示的なメソッド群による引数の置き換え」を適用するように指示されていて、適用後のコードが、より意図を明確に表現しているかどうか、という価値基準は出てきません。
これは、時と場合によりけり、だと思います。もし、ただ単に「他のメソッドからも利用できるから良いのだ」ということなら、それは「過剰な汎用化」の疑いがあります。繰り返し利用される確実な見込みがあるなら、その処理をメソッドに独立させる意味がありますが、それは「重複処理の削除」のために行われるべきであって、そちらの方が重要な意味を持つと思います。 ただ、この本が本当に言いたいのは、そんなこっちゃなくて、長いメソッドはあかんので、短いメソッドに分けろってことだと思うのですよ。長いメソッドを短くて読みやすいソースに変えるためにローカル変数減らしは有効だと思います。switch文も、ソースをごちゃごちゃにするために使われることが多いのも事実。それらの整理して、ソースを読みやすくするのに、こういう原則を活用すると良いことも多いでしょう。 ですが、短いメソッドを書くことを習慣づけている場合でも、リファクタリングしたいときもあるわけで、そういう場合に、これらのルールはむしろ悪影響を及ぼす恐れがあるのではないかと感じるわけです。おそらく、大半のプログラマは、この本に書かれた原則を、機械的に適用してリファクタリングを試みると思いますので。 _________________ | ||||||||||||||||||||
|
投稿日時: 2001-11-25 15:54
すいません。
実際にコードを書いている内に、意見が変わりました。 switch文のポリモーフィズムへの置き換え、賛成します。 あと、オピニオン記事に「継承は現代のgoto文」のように書いたのも取り消します。 継承には悪い継承と良い継承があります。 追放すべきは、悪い継承で、良い継承は使うべきです。 悪い継承とは、どのクラスのメソッドが呼び出されるかソースから一目瞭然ではない継承だと思います。これが起こりやすいのは多重継承を使った場合と、virtualを無秩序に使用した場合が多いと思います。しかし、Java以降多重継承はすたれ、C#ではoverrideキーワードなどによって、明示的な関係をソース上に示すようになったので、継承を使っても悪い継承になりにくくなったと思います。 C++あたりで考え無しに行き当たりばったりに継承を繰り返すと混乱する恐れは大だと思いますが、C#では状況は違うように思います。 _________________ | ||||||||||||||||||||
|
投稿日時: 2002-03-10 00:07
ものすごい遅レスでごめんなさい。
大学の休みの間に企業研修をしたのですが、「ソフト開発を成功させるため」に一番大事なことは営業とエンジニアの方々の意思疎通だと思いました。ここの投稿はプログラムをどう書くかにしぼって議論をしていたようですが、その前提に必要なのはやはり営業の方々と開発する方々のコミュニケーションの方が大事なような気がしてきます。 営業が仕事を取ってきてもエンジニアにとって実現可能ではないと困るわけですし、エンジニアがいくらよくできても営業が仕事を取って、仕様をまとめないと困るわけです。 エンジニアは営業が取ってきた仕事に対し、完璧にやる義務があり、営業はエンジニアができることを仕事としてとって初めて成功するソフト開発ができるのだと思います。 営業は自社が売る製品もしくは自社でできうることを熟知していなければいけなく、逆にエンジニアは、営業にとって売りやすく、柔軟性の高い製品を開発していかないといけなわけです。営業とエンジニアの二つが協調して初めて成功するソフト開発ができるのではないでしょうか？ [ メッセージ編集済み 編集者: H2 編集日時 2002-03-10 01:07 ] | ||||||||||||||||||||
|
投稿日時: 2002-03-10 12:24
正確には、顧客とエンジニアの意志疎通だと思います。営業は、両者のコミュニケーションを仲立ちする役割を持っているに過ぎません。 顧客とエンジニアがどうコミュニケーションするか、という問題は最も本質的な問題を孕んでいます。というのは、顧客自身が自分が必用としている機能を正確に理解していないことも多く、顧客が必用だと主張する機能と、本当に必用な機能が食い違っているケースがよくあるからです。この場合、顧客が言うとおりのものを完璧に完成させても、それは失敗作となります。 本当のプロのエンジニアは、この問題をきちんと把握していて、顧客の要望と、顧客の必用を切り離して考えることができます。 顧客が熱烈に欲している機能であっても、それが必用とされていない機能なら、それは作らなくても良いのです。まあ、余裕があれば作ってもいいですけど、より必要度の高い機能のスケジュールを削ってまで作るべきものではありません。それが、結局は、顧客の満足度を高めます。 そういう態度を、はっきりとルール化して持っているという意味で、エクストリーム・プログラミングは秀逸だと思います。 _________________ | ||||||||||||||||||||
スキルアップ／キャリアアップ（JOB@IT）
Copyright © ITmedia, Inc. All Rights Reserved.
著作権はアイティメディア株式会社またはその記事の筆者に属します。
当サイトに掲載されている記事や画像などの無断転載を禁止します。
著作権はアイティメディア株式会社またはその記事の筆者に属します。
当サイトに掲載されている記事や画像などの無断転載を禁止します。