アカウント名:
パスワード:
「動くこと」だけは保証するけど、コードの質を保証するもんじゃないでしょ。
コードレビューだって、自分の仕事とかかわってこない部分の他人のコードは、さほど真剣に読まないよな。書いた本人が取り組んでいる問題の深さのレベルに、そう簡単に到達できるとは思えないし。そんな暇あったら自分の仕事を進める。
それが「コードの品質」ってことなんだよね。ソフトウェア開発における「品質」ってのは、一般に理解されている品質とはちょっと意味が違っていて、仕様通りに実装されているかどうか、を指す。達人的に超絶コーディングされている、という意味ではない。
テスト自体が仕様なのであれば、テスト駆動で「品質」を保証できるってことになる。一方、仕様自体にバグがあれば、コードの「品質」はクリアしてるのに動かないってこともありうる。
もっとも、テストに書ききれない仕様やコーディング規約ってのはあるかも知れないので、テスト駆動だけで「品質」をすべてカバーできるわけじゃないだろうね。
＞ソフトウェア開発における「品質」ってのは、一般に理解されている品質とはちょっと意味が違っていて、＞仕様通りに実装されているかどうか、を指す。達人的に超絶コーディングされている、という意味ではない。むしろ逆じゃね？仕様書通りに作ってさえいれば、どんなに糞コードでも｢高品質｣であるなんて行ってる奴の方が珍しいと思う。あなたが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)に設定を変更する必要があります。
ハッカーとクラッカーの違い。大してないと思います -- あるアレゲ
テスト駆動って (スコア: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の制御は、ソフトウェア作成のプロジェクトの各段階で制御されるものだよ。
そうだね。コードを書く段階では、仕様を正確に満たすことが求められるね