その2引き続き、Copeが教えてくれた論文の紹介です。同じ人が書いた、続きの位置づけのような論文です。2008内容について誤解や勘違いをしている部分もあるかもしれません。この論文も有料で読めます。著者は、前回紹介した論文と同じ2人で、前の研究の続きという位置づけのようです。先行する5つの研究を紹介しています。それぞれ、TDDと非TDDの開発を比較して、メトリックスで評価したものです。した研究を踏まえた上で、メトリックスとしては確立した(議論はあるものの)ものを採用しています。名前だけ紹介します(わたしはあんまりよく理解できていない)。D'この研究では5つのプロジェクトを対象に調査をおこなっています。いずれも実ユーザーに提供するソフトウェアで、2プロジェクトはITL(テストラストのイテレーティブ開発)で、3プロジェクトはTDDです。開発期間は9週間、Mobile-Dというアジャイル手法を採用しました。メンバーは完全に均質とは言えないもの、同等の能力になっています。methodsのなかではDIT、RFC、循環的複雑度の3つについて統計的に意味ある差異が認められました。継承を測るDITは高く(悪く)、複雑度を測るRFCと循環的複雑度は小さい(良い)。Sequenceという評価値でTDDのほうが大きい(悪い)結果が出ています。これはパッケージの安定度と抽象度を測定するもので、TDDのほうがパッケージ構成が悪いという数字です。ITLのプロジェクトではパッケージが2つだけだったのに対し、TDDでは4〜8つのパッケージだったことが数値に影響している可能性に言及しています。結果の評価としては、DIT、RFC、循環的複雑度に差異が見られたもの、この結果は先行する研究と一致していない部分があります。DITは悪い数字が出ていますが、全体に継承はほとんど使われていないのではっきりした結論は出せないと述べています。Managementメトリックスではパッケージ構成がTDDのほうが悪い結果が出ており、TDDのほうがメンテナンスしにくいコードを産み出すと結論づけられます。これは一般にTDDの効果と謳われているものに反しています。そもそもパッケージ数にITLとTDDでは差がある点も考慮する必要があります。論文の結論では、TDDが内部品質を必ずしも自動的に、はっきりと改善するとは言えないと述べています。複雑度を下げる効果も見られるが、パッケージ構成を悪くする効果も見られます。外部品質を改善する効果があるとは言えるものの、著者らは、TDDを使わずに従来型のユニットテストをおこなうだけでも同じように外部品質が改善されるのではないかと疑義を呈しています。感想TDDを使うだけで設計が劇的に良くなるわけではないという話は、その通りかなと思えます。研究ではITLもTDDもそこそこいい設計ができているように思え(たとえばクラスのメソッド数はだいたい20まで、継承は最大3段階)、比較は別として、TDDでよい設計ができると言ってもよさそうに思います。Managementメトリックスの数値を取り上げてTDDのほうが設計(パッケージ構成)が悪いというのは、かなりこじつけだと感じました。ITLではパッケージ数が2のため、メトリックスの特性上(パッケージ内のクラスと外のクラスの依存が多いほど数字が悪くなる)、単純に比較できないのではないでしょうか。TDDではパッケージ数が4〜8というのは、パッケージ構成を意識している現れであり、むしろ良いことのように感じます。この研究ではメトリックスを使って複数のプロジェクトを比較しているのですが、どこまで有効なのか疑問を感じました。開発の進め方や内容やメンバーを揃えて、対照できる状態にしていると論文では主張していますが、ITLならITL、TDDならTDDで同じような数字になっているかというと、グラフを眺める限り必ずしもそうは見えません。プロジェクトの規模が小さい(5000〜7700LOC)からも、結果の有効性を疑いたくなります。同一のプロジェクトの中で、TDDを利用しているときとしていないときの比較ならば、メトリックスで明確に把握できると思うので、そういう研究があるといいなあ。福岡」をやってきました月別アーカイブはてなブログをはじめよう!yachさんは、はてなブログを使っています。ブログを報告するスターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。