アカウント名:
パスワード:
「動くこと」だけは保証するけど、コードの質を保証するもんじゃないでしょ。
コードレビューだって、自分の仕事とかかわってこない部分の他人のコードは、さほど真剣に読まないよな。書いた本人が取り組んでいる問題の深さのレベルに、そう簡単に到達できるとは思えないし。そんな暇あったら自分の仕事を進める。
それが「コードの品質」ってことなんだよね。ソフトウェア開発における「品質」ってのは、一般に理解されている品質とはちょっと意味が違っていて、仕様通りに実装されているかどうか、を指す。達人的に超絶コーディングされている、という意味ではない。
テスト自体が仕様なのであれば、テスト駆動で「品質」を保証できるってことになる。一方、仕様自体にバグがあれば、コードの「品質」はクリアしてるのに動かないってこともありうる。
もっとも、テストに書ききれない仕様やコーディング規約ってのはあるかも知れないので、テスト駆動だけで「品質」をすべてカバーできるわけじゃないだろうね。
＞ソフトウェア開発における「品質」ってのは、一般に理解されている品質とはちょっと意味が違っていて、＞仕様通りに実装されているかどうか、を指す。達人的に超絶コーディングされている、という意味ではない。むしろ逆じゃね？仕様書通りに作ってさえいれば、どんなに糞コードでも｢高品質｣であるなんて行ってる奴の方が珍しいと思う。あなたがSI的オレオレ品質定義に染まってるだけではないかと。
普通はもっと広義で品質という単語を使ってると思いますよっと。
あなたがSI的オレオレ品質定義に染まってるだけではないかと。普通はもっと広義で品質という単語を使ってると思いますよっと。
はい。私も最初からその様に言ってますね。「普通は」「達人的に超絶コーディングされている」ようなものを品質が高いと評する、と。
しかしながら、SI業界をはじめとするISO 9000 [atmarkit.co.jp]が通用するような業界では、「品質」と言えば、仕様通りにモノが作られていることを指します。敢えて言うなら、「SI的オレオレ品質定義」ではなく、ISO 9000的定義でしょうか。
なお、ISO 9000的定義では、場合によっては、仕様よりも精度が高すぎることすら高「品質」ではない、と判断されます。精度は費用に返ってきますし、費用も含めて設計されているからです。
仕様書通りに作ってさえいれば、どんなに糞コードでも｢高品質｣であるなんて行ってる奴の方が珍しいと思う。
それならば、どう書けば「糞コード」でないかを明示すべきですね。普通は、コーディング規約とかでやるんじゃないですか。職人みたいに「見て盗め」じゃダメです。個人的にはそうしてほしいですが。
> しかしながら、SI業界をはじめとするISO 9000が通用するような業界では、「品質」と言えば、仕様通りにモノが作られていることを指します。もうちょっとちゃんと読んだらどうかな、ISO9000とかをさ。そういう半可通がソフト業界をダメにしてるんだと思うよ。出来上がりのプログラムが機能要件を満たしている、なんてのは当たり前の話。だけど、機能要件を満たしている、なんかじゃTCOとかを制御出来ないんだね。
> どう書けば「糞コード」でないかを明示すべきですね。これは言うのは簡単。信頼性、効率性、保守性、移植性の品質特性が高い事。だがね、こ
もうちょっとちゃんと読んだらどうかな、ISO9000とかをさ。そういう半可通がソフト業界をダメにしてるんだと思うよ。
原典は読みはしませんが(笑)、それなりに学習しましたよ。で、何がどう問題だと言っているんですか?
出来上がりのプログラムが機能要件を満たしている、なんてのは当たり前の話。
そうですね。その当たり前のことを当たり前に実行する。それが「品質」ってものです。
だけど、機能要件を満たしている、なんかじゃTCOとかを制御出来ないんだね。
TCOのは、「コードの品質」とは別次元の話です。それはそれで別に保証されるべきです。コーディング段階で勝手にTCOを妄想されて実装されたのでは、それこそTCOを制御できません。まあ、現場レベルからTCO改善策を提案することはあってしかるべきです。
これは言うのは簡単。信頼性、効率性、保守性、移植性の品質特性が高い事。だがね、こういうのは有効なメトリックスが無い場合もあるんだね。だから、機能性品質特性みたいには簡単に行かない。
そう言うものは当然ありますね。
有効なメトリックスが無い⇒主観的でも何でも良いからともかく基準を作ろう、なのか、有効なメトリックスが無い⇒メトリックスが無いものは無視無視、なのかで、出来るもんがずいぶんと違うわね。
「ともかく基準は作る」んですよね。つまり仕様化するってことです。だったら、私の言っていることと大差ありませんね。何が気に食わないんでしょうか?
ロイ君は多数派の無視無視の方だろうけど、そういう考えでやってると未来は無いと思うよ。
誰ですか、「ロイ君」って。＃私の名前をそんな風に間違うなんて、新人さんでしょうか(笑)。
コーディング規約で制御出来るのはコーディングだわな。コーディング規約で、アルゴリズムとかアーキテクチャを制御出来るって、もしかして考えてる？
いいえ。アルゴリズムやアーキテクチャは、当然明示的に仕様化されているものだと思いますが、あなたの職場では違うんですか?テストをコード単体の仕様を完全に反映したもの、と考えると、内部の実装はどうでもいい、ってことになるわけですが、私は最初から、「テスト駆動だけで「品質」をすべてカバーできるわけじゃない [srad.jp]」と言っていますね。
全体として、特に意見の相違が見つからないんですが、何が気に入らないんでしょうか?
>> 出来上がりのプログラムが機能要件を満たしている、なんてのは当たり前の話。> そうですね。その当たり前のことを当たり前に実行する。それが「品質」ってものです。
ほらほら、やっぱりだ。機能要件を満たしているのは品質そのものじゃなくて品質の一部、外部品質を満たしているだけね。仕様通り＝外部品質＝ソフトウェア品質とか思いこんでいる輩特有の臭い、外品臭がロイ君からしたんだけど、やっぱりね。
> TCOのは、「コードの品質」とは別次元の話です。それはそれで別に保証されるべきです。コーディング段階で勝手にTCOを妄想されて実装された
機能要件を満たしているのは品質そのものじゃなくて品質の一部、外部品質を満たしているだけね。
んー、機能要件だけが仕様だ、と言ったことはないんだけど、なんでそんな風に思い込んでるの?最初から「テストに書ききれない仕様やコーディング規約ってのはある [srad.jp]」と書いてるんだけど、読めないわけじゃないんだよね?
外品臭がロイ君からしたんだけど、やっぱりね。
「ロイ君」って誰さ？君自身の品質は実に低そうだね。単純ミスを指摘されても直せないのでは。
TCOの制御は、ソフトウェア作成のプロジェクトの各段階で制御されるものだよ。
そうだね。コードを書く段階では、仕様を正確に満たすことが求められるね
> ソフトウェア開発における「品質」ってのは．．．
「品質」を正確に定義しないで使っているから、なんか曖昧模糊な文章になってしまうんだよね。
・ソフトウェア品質特性・外部品質/内部品質/利用品質の違い・ソフトウェア品質特性の品質特性/品質副特性が外部品質/内部品質/利用品質のどれに含まれるか
なんてのを把握すると、明確な言い方が出来る様になると思う。
まあ、試験で担保出来るのは、外部品質のほとんどと、内部品質や利用品質の極一部だわね。内部品質や利用品質に含まれる品質副特性には、有効なメトリックスが存在しなくて主観的な判断をせざるを得ないものも少なく無い。有効なメトリックスが存在しないものは有意な試験なんか出来ないしね。
で、テストコードが適切に書かれているか確認するためのテストコードを、それを確認するためのテストコード・・・。
「ねぇこのパラメータ群の組み合わせでテストケースはいくらぐらいになるの？」「10の27乗ぐらいかな。1秒に100万ケースチェックするとしてぇ・・・」
SQLiteのテストコードは4567万8000行！ 本体のコードは6万7000行http://www.publickey1.jp/blog/10/sqlite45678000_67000.html [publickey1.jp]
結局本体のコードもテストコードも、仕様をもとに人が作るんで、作るのがテストコードだって自身が品質の問題から逃れられるわけではないと思うけどなぁ。
>なんでもかんでもテストコードにすればいいというわけではないです。
抜けがあるんじゃテスト駆動開発って言わないんじゃないの？
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
最初のバージョンは常に打ち捨てられる。
テスト駆動って (スコア:0)
「動くこと」だけは保証するけど、コードの質を保証するもんじゃないでしょ。
コードレビューだって、自分の仕事とかかわってこない部分の他人のコードは、さほど真剣に読まないよな。
書いた本人が取り組んでいる問題の深さのレベルに、そう簡単に到達できるとは思えないし。
そんな暇あったら自分の仕事を進める。
Re:テスト駆動って (スコア:3, 参考になる)
テスト駆動は、
仕様をテストという形でコードに起こす。
テストは自動化されているのでいつでも繰り返しテストができる。
テストがいつでもできるので、リファクタリングというコード品質改善プロセスを安心して行える。
リファクタリングが済んだら次の仕様をテストに起こす。
次の仕様をクリアする段階で既にあるコードに手が入り、問題が発生しても（既にあるコード向けの）テストを実行すればクリアできる。
です。
コード書いてて、これちゃんとうごくんだっけと別窓で簡単な確認コード書いた経験があるなら、それをもっと体系的に製造プロセスに盛りこまれたような感じです。
そしてその確認コードが動く限りメソッドの抽出などのリファクタリングを行っても、自分の欲しい部品であり続けてる（壊れてない）。壊れてないことが確認できる方法があるんだからリファクタリングに取り掛かりやすい。リファクタリングしているからメンテナンス性が向上される。ここまで含めなければテスト駆動開発とは言えません（習熟中で不完全な場合は仕方ないですけどね）。
あと、テスト駆動用に書いたテストですべてがテストされるわけではないので、普通のテストもしますね。（『そこを指して「動くこと」だけは保証するけど』なんでしょうが。）
誤解を恐れず言えば、アプリケーションが動くことまではカバーしません（どこまでのテストコードを書くかはチームによるでしょう、最近はメソッド単体ではなく、併せて一連の動作のテストも書くといいという話も出てますし）。
もちろん理想と現実はありますが、それでもテストコードが少しでもあると全くないとでは全然違うと最近よく思います。
# 中途半端だと全部グリーンじゃない状態で放置されてたりすることもあったり。
# yes, fly. no, fry.
Re:テスト駆動って (スコア:1)
それが「コードの品質」ってことなんだよね。ソフトウェア開発における「品質」ってのは、一般に理解されている品質とはちょっと意味が違っていて、仕様通りに実装されているかどうか、を指す。達人的に超絶コーディングされている、という意味ではない。
テスト自体が仕様なのであれば、テスト駆動で「品質」を保証できるってことになる。
一方、仕様自体にバグがあれば、コードの「品質」はクリアしてるのに動かないってこともありうる。
もっとも、テストに書ききれない仕様やコーディング規約ってのはあるかも知れないので、テスト駆動だけで「品質」をすべてカバーできるわけじゃないだろうね。
Re:テスト駆動って (スコア:1)
＞ソフトウェア開発における「品質」ってのは、一般に理解されている品質とはちょっと意味が違っていて、
＞仕様通りに実装されているかどうか、を指す。達人的に超絶コーディングされている、という意味ではない。
むしろ逆じゃね？
仕様書通りに作ってさえいれば、どんなに糞コードでも｢高品質｣であるなんて行ってる奴の方が珍しいと思う。
あなたがSI的オレオレ品質定義に染まってるだけではないかと。
普通はもっと広義で品質という単語を使ってると思いますよっと。
Re:テスト駆動って (スコア:1)
あなたがSI的オレオレ品質定義に染まってるだけではないかと。
普通はもっと広義で品質という単語を使ってると思いますよっと。
はい。私も最初からその様に言ってますね。「普通は」「達人的に超絶コーディングされている」ようなものを品質が高いと評する、と。
しかしながら、SI業界をはじめとするISO 9000 [atmarkit.co.jp]が通用するような業界では、「品質」と言えば、仕様通りにモノが作られていることを指します。敢えて言うなら、「SI的オレオレ品質定義」ではなく、ISO 9000的定義でしょうか。
なお、ISO 9000的定義では、場合によっては、仕様よりも精度が高すぎることすら高「品質」ではない、と判断されます。精度は費用に返ってきますし、費用も含めて設計されているからです。
仕様書通りに作ってさえいれば、どんなに糞コードでも｢高品質｣であるなんて行ってる奴の方が珍しいと思う。
それならば、どう書けば「糞コード」でないかを明示すべきですね。普通は、コーディング規約とかでやるんじゃないですか。
職人みたいに「見て盗め」じゃダメです。個人的にはそうしてほしいですが。
Re: (スコア:0)
> しかしながら、SI業界をはじめとするISO 9000が通用するような業界では、「品質」と言えば、仕様通りにモノが作られていることを指します。
もうちょっとちゃんと読んだらどうかな、ISO9000とかをさ。そういう半可通がソフト業界をダメにしてるんだと思うよ。
出来上がりのプログラムが機能要件を満たしている、なんてのは当たり前の話。だけど、機能要件を満たしている、なんかじゃTCOとかを制御出来ないんだね。
> どう書けば「糞コード」でないかを明示すべきですね。
これは言うのは簡単。信頼性、効率性、保守性、移植性の品質特性が高い事。だがね、こ
Re:テスト駆動って (スコア:1)
もうちょっとちゃんと読んだらどうかな、ISO9000とかをさ。そういう半可通がソフト業界をダメにしてるんだと思うよ。
原典は読みはしませんが(笑)、それなりに学習しましたよ。で、何がどう問題だと言っているんですか?
出来上がりのプログラムが機能要件を満たしている、なんてのは当たり前の話。
そうですね。その当たり前のことを当たり前に実行する。それが「品質」ってものです。
だけど、機能要件を満たしている、なんかじゃTCOとかを制御出来ないんだね。
TCOのは、「コードの品質」とは別次元の話です。それはそれで別に保証されるべきです。コーディング段階で勝手にTCOを妄想されて実装されたのでは、それこそTCOを制御できません。
まあ、現場レベルからTCO改善策を提案することはあってしかるべきです。
これは言うのは簡単。信頼性、効率性、保守性、移植性の品質特性が高い事。だがね、こういうのは有効なメトリックスが無い場合もあるんだね。だから、機能性品質特性みたいには簡単に行かない。
そう言うものは当然ありますね。
有効なメトリックスが無い⇒主観的でも何でも良いからともかく基準を作ろう、なのか、有効なメトリックスが無い⇒メトリックスが無いものは無視無視、なのかで、出来るもんがずいぶんと違うわね。
「ともかく基準は作る」んですよね。つまり仕様化するってことです。だったら、私の言っていることと大差ありませんね。何が気に食わないんでしょうか?
ロイ君は多数派の無視無視の方だろうけど、そういう考えでやってると未来は無いと思うよ。
誰ですか、「ロイ君」って。
＃私の名前をそんな風に間違うなんて、新人さんでしょうか(笑)。
コーディング規約で制御出来るのはコーディングだわな。コーディング規約で、アルゴリズムとかアーキテクチャを制御出来るって、もしかして考えてる？
いいえ。
アルゴリズムやアーキテクチャは、当然明示的に仕様化されているものだと思いますが、あなたの職場では違うんですか?
テストをコード単体の仕様を完全に反映したもの、と考えると、内部の実装はどうでもいい、ってことになるわけですが、私は最初から、「テスト駆動だけで「品質」をすべてカバーできるわけじゃない [srad.jp]」と言っていますね。
全体として、特に意見の相違が見つからないんですが、何が気に入らないんでしょうか?
Re: (スコア:0)
>> 出来上がりのプログラムが機能要件を満たしている、なんてのは当たり前の話。
> そうですね。その当たり前のことを当たり前に実行する。それが「品質」ってものです。
ほらほら、やっぱりだ。機能要件を満たしているのは品質そのものじゃなくて品質の一部、外部品質を満たしているだけね。仕様通り＝外部品質＝ソフトウェア品質とか思いこんでいる輩特有の臭い、外品臭がロイ君からしたんだけど、やっぱりね。
> TCOのは、「コードの品質」とは別次元の話です。それはそれで別に保証されるべきです。コーディング段階で勝手にTCOを妄想されて実装された
Re: (スコア:0)
機能要件を満たしているのは品質そのものじゃなくて品質の一部、外部品質を満たしているだけね。
んー、機能要件だけが仕様だ、と言ったことはないんだけど、なんでそんな風に思い込んでるの?
最初から「テストに書ききれない仕様やコーディング規約ってのはある [srad.jp]」と書いてるんだけど、読めないわけじゃないんだよね?
外品臭がロイ君からしたんだけど、やっぱりね。
「ロイ君」って誰さ？
君自身の品質は実に低そうだね。単純ミスを指摘されても直せないのでは。
TCOの制御は、ソフトウェア作成のプロジェクトの各段階で制御されるものだよ。
そうだね。コードを書く段階では、仕様を正確に満たすことが求められるね
Re: (スコア:0)
> ソフトウェア開発における「品質」ってのは．．．
「品質」を正確に定義しないで使っているから、なんか曖昧模糊な文章になってしまうんだよね。
・ソフトウェア品質特性
・外部品質/内部品質/利用品質の違い
・ソフトウェア品質特性の品質特性/品質副特性が外部品質/内部品質/利用品質のどれに含まれるか
なんてのを把握すると、明確な言い方が出来る様になると思う。
まあ、試験で担保出来るのは、外部品質のほとんどと、内部品質や利用品質の極一部だわね。内部品質や利用品質に含まれる品質副特性には、有効なメトリックスが存在しなくて主観的な判断をせざるを得ないものも少なく無い。有効なメトリックスが存在しないものは有意な試験なんか出来ないしね。
Re: (スコア:0)
で、テストコードが適切に書かれているか確認するためのテストコードを、それを確認するためのテストコード・・・。
「ねぇこのパラメータ群の組み合わせでテストケースはいくらぐらいになるの？」
「10の27乗ぐらいかな。1秒に100万ケースチェックするとしてぇ・・・」
Re:テスト駆動って (スコア:1)
現状でテストの確認をするためのテストを、それを確認するためのテスト…をしているならテストコード導入してもそれが求められるかもしれませんね。
> 「10の27乗ぐらいかな。1秒に100万ケースチェックするとしてぇ・・・」
「するとしてぇ・・・」どうなったかは知りませんが、
1秒に100万ケースチェックできるっていいですよね。
もちろんテストコードじゃなくても同じ数を手でテストしようとしてたんですよね？
# どうせなら現実的な問題のテストコードのメンテナンスとか突いて来ればいいのにね。
# yes, fly. no, fry.
Re: (スコア:0)
SQLiteのテストコードは4567万8000行！ 本体のコードは6万7000行
http://www.publickey1.jp/blog/10/sqlite45678000_67000.html [publickey1.jp]
Re: (スコア:0)
結局本体のコードもテストコードも、仕様をもとに人が作るんで、
作るのがテストコードだって自身が品質の問題から逃れられるわけではないと思うけどなぁ。
Re:テスト駆動って (スコア:1)
レッドになっても何が原因か即座にわからなかったり。コードにすると割に合わないテストコードも存在します。なんでもかんでもテストコードにすればいいというわけではないです。
ただそれがテストケースであっても結局人が作るので、その品質もありますよねケース不良とか。
「人が介在するのだから」という部分はテストコードにしたところで変わりません。仕様を誤解していればテストコードだって誤解されたものができるでしょうし。
いつでも繰り返しテストできるとかそういうところがメリットです。
まずは特定のフィールドのチェックメソッドとか、書式変換メソッドとか、いつ呼んでも期待値が変わらない軽量のメソッドに対してだけテストコード書いてみるといいですよ。
ごく単純なテストメソッドでは
var target = new MyStringValidator();
Assert.AreEquals(true, target.HasDotCharacter("Ubuntu 12.04"));
Assert.AreEquals(false, target.HasDotCharacter("Windows 8"));
のようにインスタンス化含めて 10行以内になることも多いですので、品質がどうのこうのなることはあまりありません。
テストコードもテスト駆動も道具ですから、うまく使えるところに使えばいいんです。
# yes, fly. no, fry.
Re: (スコア:0)
>なんでもかんでもテストコードにすればいいというわけではないです。
抜けがあるんじゃテスト駆動開発って言わないんじゃないの？
Re:テスト駆動って (スコア:1)
「この層はテスト駆動開発でやりました」でもいいでしょう。
どんな手法でも、怖いのはなんでもかんでも「それだけでやれ」という考え方ですよ。
古い言い方なら銀の弾丸などないです。
# yes, fly. no, fry.