アカウント名:
パスワード:
「動くこと」だけは保証するけど、コードの質を保証するもんじゃないでしょ。
コードレビューだって、自分の仕事とかかわってこない部分の他人のコードは、さほど真剣に読まないよな。書いた本人が取り組んでいる問題の深さのレベルに、そう簡単に到達できるとは思えないし。そんな暇あったら自分の仕事を進める。
それが「コードの品質」ってことなんだよね。ソフトウェア開発における「品質」ってのは、一般に理解されている品質とはちょっと意味が違っていて、仕様通りに実装されているかどうか、を指す。達人的に超絶コーディングされている、という意味ではない。
テスト自体が仕様なのであれば、テスト駆動で「品質」を保証できるってことになる。一方、仕様自体にバグがあれば、コードの「品質」はクリアしてるのに動かないってこともありうる。
もっとも、テストに書ききれない仕様やコーディング規約ってのはあるかも知れないので、テスト駆動だけで「品質」をすべてカバーできるわけじゃないだろうね。
>ソフトウェア開発における「品質」ってのは、一般に理解されている品質とはちょっと意味が違っていて、>仕様通りに実装されているかどうか、を指す。達人的に超絶コーディングされている、という意味ではない。むしろ逆じゃね?仕様書通りに作ってさえいれば、どんなに糞コードでも「高品質」であるなんて行ってる奴の方が珍しいと思う。あなたがSI的オレオレ品質定義に染まってるだけではないかと。
普通はもっと広義で品質という単語を使ってると思いますよっと。
あなたがSI的オレオレ品質定義に染まってるだけではないかと。普通はもっと広義で品質という単語を使ってると思いますよっと。
はい。私も最初からその様に言ってますね。「普通は」「達人的に超絶コーディングされている」ようなものを品質が高いと評する、と。
しかしながら、SI業界をはじめとする ISO 9000 [atmarkit.co.jp]が通用するような業界では、「品質」と言えば、仕様通りにモノが作られていることを指します。敢えて言うなら、「SI的オレオレ品質定義」ではなく、ISO 9000的定義でしょうか。
なお、ISO 9000的定義では、場合によっては、仕様よりも精度が高すぎること
> しかしながら、SI業界をはじめとするISO 9000が通用するような業界では、「品質」と言えば、仕様通りにモノが作られていることを指します。もうちょっとちゃんと読んだらどうかな、ISO9000とかをさ。そういう半可通がソフト業界をダメにしてるんだと思うよ。出来上がりのプログラムが機能要件を満たしている、なんてのは当たり前の話。だけど、機能要件を満たしている、なんかじゃTCOとかを制御出来ないんだね。
> どう書けば「糞コード」でないかを明示すべきですね。これは言うのは簡単。信頼性、効率性、保守性、移植性の品質特性が高い事。だがね、こ
もうちょっとちゃんと読んだらどうかな、ISO9000とかをさ。そういう半可通がソフト業界をダメにしてるんだと思うよ。
原典は読みはしませんが(笑)、それなりに学習しましたよ。で、何がどう問題だと言っているんですか?
出来上がりのプログラムが機能要件を満たしている、なんてのは当たり前の話。
そうですね。その当たり前のことを当たり前に実行する。それが「品質」ってものです。
だけど、機能要件を満たしている、なんかじゃTCOとかを制御出来ないんだね。
TCOのは、「コードの品質」とは別次元の話です。それはそれで別に保証されるべきです。コーディング段階で勝手にTCOを妄想されて実装されたのでは、それこそTCOを制御できません。まあ、現場レベルからTCO改善策を提案することはあってしかるべきです。
これは言うのは簡単。信頼性、効率性、保守性、移植性の品質特性が高い事。だがね、こういうのは有効なメトリックスが無い場合もあるんだね。だから、機能性品質特性みたいには簡単に行かない。
そう言うものは当然ありますね。
有効なメトリックスが無い⇒主観的でも何でも良いからともかく基準を作ろう、なのか、有効なメトリックスが無い⇒メトリックスが無いものは無視無視、なのかで、出来るもんがずいぶんと違うわね。
「ともかく基準は作る」んですよね。つまり仕様化するってこ
>> 出来上がりのプログラムが機能要件を満たしている、なんてのは当たり前の話。> そうですね。その当たり前のことを当たり前に実行する。それが「品質」ってものです。
ほらほら、やっぱりだ。機能要件を満たしているのは品質そのものじゃなくて品質の一部、外部品質を満たしているだけね。仕様通り=外部品質=ソフトウェア品質とか思いこんでいる輩特有の臭い、外品臭がロイ君からしたんだけど、やっぱりね。
> TCOのは、「コードの品質」とは別次元の話です。それはそれで別に保証されるべきです。コーディング段階で勝手にTCOを妄想されて実装されたのでは、それこそTCOを制御できません。
わかってないねえ。TCOの制御は、ソフトウェア作成のプロジェクトの各段階で制御されるものだよ。それらは内部品質と利用品質を制御する事で達成される。内部品質の話とすれば、基本、機能、詳細or実装の3つのフェーズを考えた場合、基本フェーズで制御するのはアーキテクチャ、機能と詳細or実装フェーズではアルゴリズム、詳細or実装フェーズではコーディングを、レビューを通して制御するんだわ。
で、こういうのに明確で明確なメトリックスがあると思う?レビューの件数なんてメトリックスは設定出来るけど、まあ糞だわな。レビューで実体化したアーキテクチャ/アルゴリズム/コーディングが承認されるかどうか、しかないんだよ。つまり、「この糞は何だ?やり直せ!」と言われるか、言われないかだけ。離散的な評価値はメトリックスとしては使用できないわな。
> 全体として、特に意見の相違が見つからないんですが、何が気に入らないんでしょうか?
どこが一緒?それはボクが外品厨だって事?やめてくれよ。一緒にしないでくれ。
機能要件を満たしているのは品質そのものじゃなくて品質の一部、外部品質を満たしているだけね。
んー、機能要件だけが仕様だ、と言ったことはないんだけど、なんでそんな風に思い込んでるの?最初から「テストに書ききれない仕様やコーディング規約ってのはある [srad.jp]」と書いてるんだけど、読めないわけじゃないんだよね?
外品臭がロイ君からしたんだけど、やっぱりね。
「ロイ君」って誰さ?君自身の品質は実に低そうだね。単純ミスを指摘されても直せないのでは。
TCOの制御は、ソフトウェア作成のプロジェクトの各段階で制御されるものだよ。
そうだね。コードを書く段階では、仕様を正確に満たすことが求められるね
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
Stay hungry, Stay foolish. -- Steven Paul Jobs
テスト駆動って (スコア: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改善策を提案することはあってしかるべきです。
これは言うのは簡単。信頼性、効率性、保守性、移植性の品質特性が高い事。だがね、こういうのは有効なメトリックスが無い場合もあるんだね。だから、機能性品質特性みたいには簡単に行かない。
そう言うものは当然ありますね。
有効なメトリックスが無い⇒主観的でも何でも良いからともかく基準を作ろう、なのか、有効なメトリックスが無い⇒メトリックスが無いものは無視無視、なのかで、出来るもんがずいぶんと違うわね。
「ともかく基準は作る」んですよね。つまり仕様化するってこ
Re:テスト駆動って (スコア:0)
>> 出来上がりのプログラムが機能要件を満たしている、なんてのは当たり前の話。
> そうですね。その当たり前のことを当たり前に実行する。それが「品質」ってものです。
ほらほら、やっぱりだ。機能要件を満たしているのは品質そのものじゃなくて品質の一部、外部品質を満たしているだけね。仕様通り=外部品質=ソフトウェア品質とか思いこんでいる輩特有の臭い、外品臭がロイ君からしたんだけど、やっぱりね。
> TCOのは、「コードの品質」とは別次元の話です。それはそれで別に保証されるべきです。コーディング段階で勝手にTCOを妄想されて実装されたのでは、それこそTCOを制御できません。
わかってないねえ。TCOの制御は、ソフトウェア作成のプロジェクトの各段階で制御されるものだよ。それらは内部品質と利用品質を制御する事で達成される。内部品質の話とすれば、基本、機能、詳細or実装の3つのフェーズを考えた場合、基本フェーズで制御するのはアーキテクチャ、機能と詳細or実装フェーズではアルゴリズム、詳細or実装フェーズではコーディングを、レビューを通して制御するんだわ。
で、こういうのに明確で明確なメトリックスがあると思う?レビューの件数なんてメトリックスは設定出来るけど、まあ糞だわな。レビューで実体化したアーキテクチャ/アルゴリズム/コーディングが承認されるかどうか、しかないんだよ。つまり、「この糞は何だ?やり直せ!」と言われるか、言われないかだけ。離散的な評価値はメトリックスとしては使用できないわな。
> 全体として、特に意見の相違が見つからないんですが、何が気に入らないんでしょうか?
どこが一緒?それはボクが外品厨だって事?やめてくれよ。一緒にしないでくれ。
Re: (スコア:0)
機能要件を満たしているのは品質そのものじゃなくて品質の一部、外部品質を満たしているだけね。
んー、機能要件だけが仕様だ、と言ったことはないんだけど、なんでそんな風に思い込んでるの?
最初から「テストに書ききれない仕様やコーディング規約ってのはある [srad.jp]」と書いてるんだけど、読めないわけじゃないんだよね?
外品臭がロイ君からしたんだけど、やっぱりね。
「ロイ君」って誰さ?
君自身の品質は実に低そうだね。単純ミスを指摘されても直せないのでは。
TCOの制御は、ソフトウェア作成のプロジェクトの各段階で制御されるものだよ。
そうだね。コードを書く段階では、仕様を正確に満たすことが求められるね