＠IT情報マネジメント会議室は、2009年4月15日に新システムに移行しました。
新たに書き込みを行う場合には、新しい会議室をご利用ください。
- PR -

コードカバレッジに関して

«前のページへ 1|2|3
投稿者投稿内容
はゆる
ぬし
会議室デビュー日: 2004/02/16
投稿数: 1008
お住まい・勤務地: 首都圏をウロウロと
投稿日時: 2005-11-10 01:07
こんばんは。

以前、雑誌で見ていた記事が、（会員限定ですが）公開されているようなので、
リンクを貼ってみますね。
# 「図2（制御パステスト）」 は見えますので

　・ 知っておきたいテストの“イロハ”（1） （IT Pro さんより）


制御パステストについては、夏に出た 「ソフトウェア・テスト PRESS Vol.1」 でも
説明があったと思うので、よろしければ書店などでご覧になってみてください。
ねろ
会議室デビュー日: 2006/03/16
投稿数: 3
投稿日時: 2006-03-16 17:08
こんにちは
遥か昔のスレの為、もう誰も見る人はいないかもしれませんが・・・
今、ちょうど、C0/C1のテストカバレッジについての検討をしていたところなので、皆様の意見本当に役に立ちました。
とても感謝しております。

今日投稿させていただいたのは、１関数のステップ数の話・・・
この件については、私的にひとつの結論を出しています。
まず、コード量ですが、関数の開始から終了までの行数ですが、コメントを含めて私のプロジェクトでは"24行"までと制限をしております。

この24行・・・お分かりかと思いますが、標準的なエディタのデフォルトのライン数です。昔のダム端末はもとより、例えばVisualStudioの画面でさえ、デフォルトのエディタのサイズは、24行（25かも・・・）です。

ここで注意したいのが、”じゃんぬねっと”さんがおっしゃるとおり、画面の大きさに依存するんじゃないの？・・・です。

私も最初はそう考えていました。
例えば、最近の画面ですと、50〜100行は平気で表示できるでしょうから、その位までは許容できていいのでは？という事です。
しかし、実際は違います。
この25行や一般的に言われている30行ですが、これを守って設計を行うと、驚くほどバグが少なくなります。
問題になっている、C1カバレッジに対しても、構造化が完全にされているとそれほど苦にはなりません。また、処理が関数で表せることよりその名称を判りやすいものにする事により、直感的なコードになってきます。

私が携わったプロジェクトで、同じようなプログラムを何チームかに分かれて作る事がありました。
全体的なコーディング規約とは別にローカルコーディングルールを起こしたのですが、その時に関数のステップ数制限をかけてみました。

他のチームが、平気で0.1K以上のコード1関数に書いているのに、うちのチームは、ほぼ9割（SQL文の記述部がどうしても長くなるので・・・100%にはなりませんでした）が、24行以下で作成しました。

その結果、うちのチームでのバグはほとんどが仕様面から来る行き違いによるものだったに比べ、他チームで発生するバグは、コードレビューに立ち返らないと品質確保できないというもでした。
私は、この差はコードのステップ数制限をかけているかかけていないかだと今でも考えています。
私のチームのコードレビューでは、関数のステップ数の制限のおかげで、製造レベルがほとんど同列になり、スキルの差を埋めるほどの効果もありました。また、どんどん、共通関数も増えていき、総ステップ数も他チームと比べると、2/3程度にまで少なくする事もできました。

その他にも、
　・変数宣言は必ず関数の先頭でしなければならない
　・コピペ禁止
　・意味のないコメントの禁止
など、ほんの些細な制限をかける事で驚くほど品質の良否が変わってきます。
結局、制限をかければかけるほど設計をきちんとしていなければ物を作る事ができず・・・これは、文章を書く為にまずアウトラインを作る・・・とか、絵を描く為に下書きをする・・・とか、それに似ているのではないでしょうか。

最近は、JavaやC#での開発がほとんどですが、厳密な数値を指定しないまでも、クラスやメソッドのコードレビューの最初のチェック観点はステップ数にしています。

一点注意したいのは、その行数は絶対的な行数ではなく、基準値という事です。
例えば数値計算をするプログラムで、ロジックの部分を長くなるからと関数分割してしまうと・・・わかるものも判らなくなってしまうこともあります。

私のプロジェクトでは、
　〜24行　許容
25〜50行　事後申告必要
51〜　　　事前申告必要
を絶対条件にしております。

最後に、あるカーネルのコードを紐解いてみると、約7000個もある関数のうち、約70%が30行以下、85%が50行以下となっています。

というわけで、関数は短く作るほうがいいですよ〜〜〜
ぶさいくろう
ぬし
会議室デビュー日: 2005/11/22
投稿数: 1232
お住まい・勤務地: 川崎市（は俺も含めてロクな人間が住んでないよｗ）
投稿日時: 2006-03-16 17:37
>例えば、最近の画面ですと、50〜100行は平気で表示できるでしょうから、その位までは許容できていいのでは？という事です。
>しかし、実際は違います。
>この25行や一般的に言われている30行ですが、これを守って設計を行うと、驚くほどバグが少なくなります。

相対的に行数が短い方がバグが減るのは至極当たり前のことなんだが・・・

・50行程度の関数を脳内設計できないレベルの人が多ければ効果は高いと思う。
・50行先読みできて打っているだけの人間が多ければ30行も50行も大差ないと思う。

というのもうちで試した時は新人連中以外はさして変わらなかった。
むしろ生産性が落ちてしまって制限を緩くした経緯がある・・・
バグなんて出ても50行程度ならすぐ発見して潰せるだろうし。それと問題なのは保守。
30行だと分散されすぎてビューで見ても醜い。関数が多くなると命名にも困る。
それとクラスを使っているきゅうび、外から見た時にあまり問題にならないことが多い。

今の言語で30行だと業務にいってはつらいことが多く考えるのに時間がとられることも。
これが100行となるとまた違うと思う。100行とかであれば賛成。
50程度くらいまでは許容 してもええってことが言いたかっただけだけどね。
やるなら50は超えちゃダメって感じで。まあ会社によってまた微調整すると変わるかも。
«前のページへ 1|2|3

スキルアップ／キャリアアップ（JOB@IT）