- - PR -
VB.NetにおけるメソッドのSTEP数について
| 投稿者 | 投稿内容 | ||||||||
|---|---|---|---|---|---|---|---|---|---|
|
投稿日時: 2004-11-28 22:35
> みなさんは、実際に20〜30stepぐらいでメソッドを作成されているのですか？
いいえ。私の場合、メソッドに分離するとき、長さを基準にすることはあまりありません。 １０行程度のことも、１００行以上のこともあります。 私の場合の基準は、そのプロシジャの目的を的確に表現することができる処理の集まりになっているかどうかですねぇ。 _________________ たつごろー codeseek こみゅぷらす | ||||||||
|
投稿日時: 2004-11-29 09:59
たくさんの返答ありがとうございます。
自分がこの疑問を感じたのは、 現プロジェクトの前に、C#のテスト要因としてテストから参加したのですが、クラス図はあったのですが、詳細なシーケンス図等動的な側面の設計書が無く、かつ、コーディング担当者がプロジェクトを抜けていたため、自分でソースを追っかけて、仕様を把握しようとしたときに、あまりにもメソッドからメソッドを呼びすぎていて、処理の流れの全く分からないソース（しかもコメントなし）だったために、メソッドの多さっていうのが、懸念になりました。 そこで、参考書を読んでみると『絶対にメソッドの長さは20〜30step』と受け取れる書き方をしていたので、実際はどうなのかと思い質問しました。 ただ、自分も100stepを超えるようなメソッドを作成する気はありませんので、基本的にはあまりstep数を気にしなくてもよいのかなと思っています。 皆さんの話を聞いて、あたりまえですが、設計書をきちんと作成していれば、問題は無いと感じています。 初歩的な質問に、ご回答いただきありがとうございました。 | ||||||||
|
投稿日時: 2004-11-29 21:58
こんな考え方はどうでしょう。
処理として、「グラフを描く」という処理があります。ここでこのまま「グラフを描く」をメソッドとして実装すると、そのメソッドでは、
というような処理をしなければなりません。おそらく、数百行のメソッドになるでしょう。しかし、描かなければならないグラフが１種類で、かつ変更が入る余地がないなら、これを１メソッドで行ってもよいでしょう。クラス図上では「グラフを描く」と表記され、必要な責務を満たしているからです。 ところが、「要求」というものは生もので、どんどん変化します。描画しなければならないグラフが追加されたり、凡例を描かないようにしたり、線の色を変えたり、プロットする点の形を変えたりといった要求が入ってきそうですし、また、それらに対応できる作りにしておけば、他のプロジェクトへも使い回しができそうです。 そういうことを考えると、メソッドを分割することで、ifブロックやswitch...case文の嵐になったり、たくさんの引数を指定する必要や、あるいは引数にするためだけの構造体の宣言をしなくて良さそうです。 ・・・そうやって分割していくと、結果的に数十行ごとのメソッドに分割されると思います。 それで、ここから2004-11-29 09:59を受けて
う〜ん、今の私の課題と、ラップするところがあるので。 気になったのが、『自分でソースを追っかけて、仕様を把握しようとしたとき』です。仕様は仕様書で定義されているのではないでしょうか？また、テスト要員ということは、テストだけすればいいのでは？えっと、差別的な意味ではなく、役割分担という意味で。 それで、今の私の課題ですが、「仕様がテスト項目である」ということです。例えば、先に出したグラフの例で行くと、「グラフを描く」という仕様がある時点で、「グラフが描けること」というテスト項目ができます。そのグラフについて、「商品の１ヶ月ごとの売り上げを、折れ線グラフで描く」と決まれば、「毎月の売上高が計算されていること」「売上高がプロットされていること」「プロットされた点が結ばれていること」などのテスト項目が、暗黙のうちに決まっているはずです。テスト項目は、機能仕様書などの内容を、その条件が満たされていることを確認できる形であらわしたもので、テスト項目から"プログラムを経ずに"仕様をたどれるようにしないと、プログラムが仕様を満たしていることを、どうやって判断するのでしょう？ 逆に、テストはプログラムが仕様に沿っていることを確認するためのものであるはずで、なぜ仕様を把握するためにプログラムを読む必要があるのでしょう？テスト項目に対する結果と、仕様書をつきあわせればいいのでは？結果と仕様書の違いを、仕様かバグか判断するのは、テスト要員ではなく、プログラムの作成者か、プロジェクトリーダなどの全体の仕様を把握している人のはず。 確かに、自分のソースを見ていると、多重ループになったらメソッドを分けたりしていますので、"メソッド呼び出しのスパゲッティプログラム"になっている感は否めません。う〜ん、これも課題だ。。。 _________________ | ||||||||
|
投稿日時: 2004-11-30 12:55
確かにそうですね。『仕様変更がある』という前提で作成すると数十行ぐらいのメソッドになりそうですね。今まで、ウォータフォール型の開発がほとんどだったもので、そのことを念頭においてませんでした。
理想的にはそうだと思います。ただ、自分の場合はテスト要員としてというよりは、『テスト以降このプログラムの面倒みて下さい』って感じで入ったので、バグが発覚した場合、自分で直さなくてはならなく、上記のようなことになりました。 バグが出た場合は、PLに仕様を確認するのですが、ソースの内部までは把握していなく、また、ドキュメントも残っていないので、自分で解析するしかない状況でした。 自分の境遇は、たぶんマレなものだと、思います。 自分がそこに入ったのも、前任者がやめてしまったため、急遽といった感じでしたし。 仕様書って大切だなって当たり前のことをしみじみと感じました。 | ||||||||
|
投稿日時: 2004-11-30 12:58
エディタの１画面にメソッド全体を収めると、一目で処理の流れがつかめるので結構可読性が上がると思います。環境によりますが、せいぜい４０行程度ですかね。
適切な範囲の処理を適切な名称でメソッド分割していけば、メソッドが多すぎて困るということはそれほどないと思います。メソッドが多すぎて分かりにくい場合は、処理の分割単位や名前がまずいのではないでしょうか？ | ||||||||
|
投稿日時: 2004-11-30 19:02
ぐぅ！耳が…もとい、目が痛い、心も痛い。。。 私も「課題」なのよく見ます。っつうか、「前任者が辞めてしまったため」というのは、身に覚えが(^o^; まぁ、希ではない、むしろ大勢だと思いますよ(~o~; そういうことへの反省があってこそ、"次"へつながるのではないでしょうか。 例えば、VS2005では、クラス図を描く機能はIDEが備えるようです。Togeherでは、遷移図やシーケンス図からプログラムが作成されるとかされないとか？Rational Roseでも、VS6と連携して実行中のシーケンスがリアルタイムに表示される（なんか、誤解していそう）デモを見ました。 | ||||||||
|
投稿日時: 2004-12-01 10:02
確かに『次につながっている』気がします(笑 Togetherの体験版をこの前入れてみたのですが、重いですね・・・・ これはマシンのスペックが相当いるのではと思いました。 リファクタリングとかもしてくれるみたいで、 『スゴい！！』って思いました。 マシンを買い換えてくれないかなっと思う今日この頃でした。 | ||||||||
スキルアップ／キャリアアップ（JOB@IT）
Copyright © ITmedia, Inc. All Rights Reserved.
著作権はアイティメディア株式会社またはその記事の筆者に属します。
当サイトに掲載されている記事や画像などの無断転載を禁止します。
著作権はアイティメディア株式会社またはその記事の筆者に属します。
当サイトに掲載されている記事や画像などの無断転載を禁止します。