アカウント名:
パスワード:
「動くこと」だけは保証するけど、コードの質を保証するもんじゃないでしょ。
コードレビューだって、自分の仕事とかかわってこない部分の他人のコードは、さほど真剣に読まないよな。書いた本人が取り組んでいる問題の深さのレベルに、そう簡単に到達できるとは思えないし。そんな暇あったら自分の仕事を進める。
それが「コードの品質」ってことなんだよね。ソフトウェア開発における「品質」ってのは、一般に理解されている品質とはちょっと意味が違っていて、仕様通りに実装されているかどうか、を指す。達人的に超絶コーディングされている、という意味ではない。
テスト自体が仕様なのであれば、テスト駆動で「品質」を保証できるってことになる。一方、仕様自体にバグがあれば、コードの「品質」はクリアしてるのに動かないってこともありうる。
もっとも、テストに書ききれない仕様やコーディング規約ってのはあるかも知れないので、テスト駆動だけで「品質」をすべてカバーできるわけじゃないだろうね。
>ソフトウェア開発における「品質」ってのは、一般に理解されている品質とはちょっと意味が違っていて、>仕様通りに実装されているかどうか、を指す。達人的に超絶コーディングされている、という意味ではない。むしろ逆じゃね?仕様書通りに作ってさえいれば、どんなに糞コードでも「高品質」であるなんて行ってる奴の方が珍しいと思う。あなたが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の制御は、ソフトウェア作成のプロジェクトの各段階で制御されるものだよ。
そうだね。コードを書く段階では、仕様を正確に満たすことが求められるね
> ソフトウェア開発における「品質」ってのは...
「品質」を正確に定義しないで使っているから、なんか曖昧模糊な文章になってしまうんだよね。
・ソフトウェア品質特性・外部品質/内部品質/利用品質の違い・ソフトウェア品質特性の品質特性/品質副特性が外部品質/内部品質/利用品質のどれに含まれるか
なんてのを把握すると、明確な言い方が出来る様になると思う。
まあ、試験で担保出来るのは、外部品質のほとんどと、内部品質や利用品質の極一部だわね。内部品質や利用品質に含まれる品質副特性には、有効なメトリックスが存在しなくて主観的な判断をせざるを得ないものも少なく無い。有効なメトリックスが存在しないものは有意な試験なんか出来ないしね。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
ソースを見ろ -- ある4桁UID
テスト駆動って (スコア: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)
> ソフトウェア開発における「品質」ってのは...
「品質」を正確に定義しないで使っているから、なんか曖昧模糊な文章になってしまうんだよね。
・ソフトウェア品質特性
・外部品質/内部品質/利用品質の違い
・ソフトウェア品質特性の品質特性/品質副特性が外部品質/内部品質/利用品質のどれに含まれるか
なんてのを把握すると、明確な言い方が出来る様になると思う。
まあ、試験で担保出来るのは、外部品質のほとんどと、内部品質や利用品質の極一部だわね。内部品質や利用品質に含まれる品質副特性には、有効なメトリックスが存在しなくて主観的な判断をせざるを得ないものも少なく無い。有効なメトリックスが存在しないものは有意な試験なんか出来ないしね。