nDiki : ソフトウエア開発 55の真実と10のウソ

2004年5月30日 (日)

スポンサード リンク
[ 5月30日全て ]

2004年6月3日 (木)

Perlプログラムのコードカバレッジ解析

真実32 充分テストをしたとプログラマが自信を持つソフトウェアでも、全パスの50〜60%程度しか網羅していない。 パス・カバレージ・アナライザのような自動化ツールを使うと、網羅率が85〜90%に上がる。しかし、100%のパスを網羅するのは不可能だ。

真実34 ツールを使わないと、不良除去はうまくいかない。デバッガはみんな使うが、カバレージ・アナライザは、ほとんど使わない。

ソフトウエア開発 55の真実と10のウソより。

ということで、Perl 用のカバレッジ分析ツールを探してみる。 CPAN にある Devel::Cover が良さそげ。

Debian BOX にインストール

 apt-get install libtest-differences-perl \
                 libpod-coverage-perl \
                 libtemplate-perl

してから Devel::Coverインストール

 dh-make-perl --cpan Devel::Cover --build
 dpkg --install libdevel-cover-perl_0.45-1_i386.deb

WiKickerコードカバレッジをチェックしてみる。

WiKickerExtUtils::MakeMaker を使ってパッケージ化しており、テストは t/*.t を使用するようになっているので、そのまま分析をする事ができる。

 perl Makefile.PL
 make
 cover -delete
 HARNESS_PERL_SWITCHES=-MDevel::Cover make test
 cover

出力はこんな感じ

 Reading database from /path/WiKicker/source/cover_db


 ---------------------------- ------ ------ ------ ------ ------ ------ ------
 File                           stmt branch   cond    sub    pod   time  total
 ---------------------------- ------ ------ ------ ------ ------ ------ ------
 blib/lib/WiKicker.pm          100.0    n/a    n/a  100.0    n/a    0.0  100.0
 ...cker/App/Configuration.pm   44.1    0.0    n/a   62.5    n/a    0.0   41.7
 ...icker/App/MarkUpAsHtml.pm   38.1    0.0    0.0   66.7    n/a    0.0   34.8
 ...CGI/AbstractController.pm   24.8    0.0    n/a   47.4    n/a    0.0   23.6
 [snip]
 ...ageHtmlFragmentVisitor.pm  100.0    n/a    n/a  100.0    n/a    0.0  100.0
 ...icker/WikiPage/WriNode.pm   96.4   83.3    n/a   88.9    n/a    0.9   93.0
 .../tDiaryFragmentVisitor.pm   32.3    0.0    n/a   33.3    n/a    0.0   29.8
 Total                          59.2   41.3   31.4   67.5  100.0  100.0   56.7
 ---------------------------- ------ ------ ------ ------ ------ ------ ------


 Writing HTML output to /path/WiKicker/source/cover_db/coverage.html ...
 done.

cover_db/coverage.html に各モジュール毎のコードカバレッジが表示される。 また、各モジュールファイル毎のレポートもHTMLで作成され、プログラムの各行毎のカバレッジがプログラムとともに表示される。

なかなかいい感じ。さすがにパスカバレッジはサポートしていない。

コードカバレッジを上げてもバグ0にはなるとは全然言えないのは承知しているが、テスト漏れを減らすための情報として結構使えそうだ。

[ 6月3日全て ]

2004年6月8日 (火)

ソフトウエア開発 55の真実と10のウソ読了

いろいろ考えさせられる本。

ウソ5 - ソフトウエアには、もっと開発方法論が必要である。

というのはかなりドキっとさせられる。開発方法論が駄目だとどうすればいいのか。 (状況に応じて)自分なりのパターンを作って適用していくのも意味がないのか。 毎回毎回うんうん唸ってその場限りの作戦を立てなければならないのか…。

よく読むと

筆者の意見は、小文字の m の methodology は善である。 大文字の M の Methodology は悪であり、使う場合は相当の注意を払うべきだ。

とあり、なるほどと。

アジャイル開発エクストリーム・プログラミングに対する話も随所で述べられていて興味深い。

真実23 - プロジェクトが途中打ち切りになる二つの原因のうち、一つは、仕様を凍結できないことだ。

もかなり納得。

技術者もそうだが、ぜひ上層部の人たちに読んでもらいたい。 「見積もり」とか「要求仕様」とか「保守」とか。


[ 読書ノート ] [ お薦めの本 ] [ コンピュータ書籍 ]

[ 6月8日全て ]

2005年5月16日 (月)

どうみても、そのままでは失敗しそうなプロジェクト

欲しい機能と完成予定日とを考えると、どう考えても無理なプロジェクトの話が出ているようだ。

真実10. 見積もりは、上層部か、マーケティング部門が実施する場合がほとんどだ。実際にプログラムを開発したり、開発プロジェクトの直接のマネジャーが見積もることはない。結局適切な人が見積もっていないのだ。-- ソフトウエア開発 55の真実と10のウソ p.51

(Fact 10. Software estimation is usuall done by the wrong people.)

まだきちんと見積もりが行われていない。もちろんきちんと見積もるべきである。 きちんとした見積もりを見れば現状の予定は無理すぎ(というか不可能)で、期間をのばして段階的に機能を提供していくべきだということを理解してもらえるであろう。 ……理解してもらえるよね? 不可能がわかっていて無理やり走っていつか闇に葬られるよりいいよね……。

真実9. ソフトウェア開発見積もりは、プロジェクトの開発時に実施する場合が非常に多い。これだと、要求定義が固まる前に見積もることになり、どんな問題がどこにあるかを理解する以前に予測するので、意味がない。従って、見積もり時期として適切ではない。-- ソフトウエア開発 55の真実と10のウソ p.48

(Fact 9. Software estimation usually occurs at the wrong time.)


[ ソフトウェアプロジェクトマネジメント ]

[ 5月16日全て ]

2009年11月12日 (木)

今日のさえずり - 夜の遊び場がヤマダ電機

2009年11月11日

  • 08:38 京浜東北線北行が思ったより運転間隔が開いてしまっていて電車がこない。ちょっと間に合わないな。 [mb]
  • 09:00 @nyafuru あちゃー。ぎっくり腰やっちゃった? 無理しないでね。 [mb]
  • 13:10 2009年11月9日の歩行: 4954歩、3.85km、41分、5.58km/h、消費 186.6kcal、脂肪燃焼 26.7g、2.7エクササイズ。
  • 13:12 2009年11月10日の歩行: 6435歩、4.99km、54分、5.46km/h、消費 245.9kcal、脂肪燃焼 35.1g、3.6エクササイズ。
  • 14:20 真実3: 遅れているプロジェクトに人を追加すると、もっと遅れる。 -- ソフトウエア開発 55の真実と10のウソ http://bit.ly/2j9npX
  • 17:06 退社。これからサントリーホールへ。 [mb]
  • 17:18 「ぢ鎮祭」とはこりゃまたすごいネーミング。祭りだよ、祭り。 [mb]
  • 17:32 イマココ! L:神谷町駅 [mb]
  • 17:43 サントリーホール到着。 [mb]
  • 21:18 溜池山王駅にこれでもかというぐらい警官がいた。 [mb]
  • 24:20 2009年11月11日の歩行: 8456歩、6.49km、76分、5.08km/h、消費 319.0kcal、脂肪燃焼 45.6g、4.4エクササイズ。
  • 25:21 やっぱり喉ちんこがだらしなくなってる。 [mb]

2009年11月12日

[ 11月12日全て ]

About Me

Naney Naney (なにい)です。株式会社ミクシィでマネージャー・プロダクトオーナーをしています。

nDiki1999年1月に始めたコンピュータ日誌を前身とする NaneyWeb 日記(兼パーソナルナレッジベース)です。ちょっとしたノートは nNote にあります。

follow us in feedly

※内容は個人的見解であり所属組織とは関係ありません。

月別インデックス
Process Time: 0.055605s / load averages: 0.56, 0.50, 0.54
nDiki by WATANABE Yoshimasa (Naney, Google profile)
Powered by DiKicker