アカウント名:
パスワード:
少し前までは、 コードカバレッジというのがもてはやされていました。要はプログラムの全箇所テストしたらバグは無い、とするものです。
NTのおかけでマルチスレッドが普通に使われてくるとプログラムのある箇所と別のある箇所が同時に走行すると間違える、というケースが出てきました。こうなるとカバレッジ解析だけでは不足してしまいます。
こういったマルチスレッド観点での試験方法が必要なのですが、なかなかやり方を変えようとはしてくれません。困ったものです。
怖いねぇ。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
あつくて寝られない時はhackしろ! 386BSD(98)はそうやってつくられましたよ? -- あるハッカー
ITでも (スコア:2, 興味深い)
新しい開発形態には新しいレビュー形態(視点)が必要
ってことだな。
例えばOOPコーディングを従来の手続きオンリーの視点で(だけ)レビューすると、的外れなレビュー結果が出かねない。
(だからOOPをやめる、ってのは適切とは限らないぞ)
Re:ITでも (スコア:1)
トピ名が「材料」に寄ってるから、ここはプロジェクトで採用するフレームワークやライブラリの話の方が広がるかも？
行数だけでプログラムの規模や品質測られるよーな笑い話も、減って来てる
と信じたい昨今ですしRe:ITでも (スコア:0)
何かある？
# ファンクションで測ろうったって「重み付け」で勘が入るし
# 機能の複雑さは普通行数に比例するべ？と言われちゃうし
Re:ITでも (スコア:3, おもしろおかしい)
逆に考えるんだ。
「言われちゃう」のが不味いと考えたらどうだろう？
つまり、その論拠の無い方法論に対して、
これまた論拠の無い別の方法論をぶつけてみるんだ。
「ためしに今日から関数の数でカウントすることにしまーす」
とかね。
そうするとあーら不思議、
みんなみんな、関数分割をやたらと積極的にやるようになるぞ！
もちろん昨日まで分割に消極的だったマネージャもだ！
そしてその方向性に難色を示していた老人たちは即効で首だ！
…なんか凄く幸せになるんじゃねーかこの方法論って？(ｗ
つまりさ。
品質(あるいは生産性でもいいよ)を測る基準として、
わざわざコードの質が実は下がることが経験的に判りきってる基準を
採用するのを止めればいいんだ。
実はコードの質を上げるかも知れない方法論に
こっそり摩り替えてしまえばいいんだ。
どーせ何で測ったらいいか判らないんだったら、
それを悪用というか口実にしてしまって
都合のよいやり方をやってしまえばいい。
もちろんお客だって何も損をしてない。
良いコードのほうが結果的にメンテしやすいという意味では
お客のためにもなっている。背信行為は全く無いぞ。
Re:ITでも (スコア:1)
MAXLENGTH = 256;
の代わりに、
int getMaxLength(){
return 256;
}
なんてのがはびこるならまだしも、
int syutoku256(){
return 256;
}
みたいのが大量に繁殖したコードが目に見えるようなんですが。
Re:ITでも (スコア:0)
しかも、zipなりlhaなりで圧縮後のサイズで。
コピペで同じコードの比率が高いと、その分、圧縮率も上がって、サイズは小さくなる。
あ、でも、オブジェクトだとコメントがサイズに影響しないから、
コメント皆無のソースで出来上がってきそうだな…。
コメントの無いソースはメンテしたくないなぁ…。
Re:ITでも (スコア:0)
多数のよく似た、しかし相互に少しずつ異なる処理を行う場合、
意図的にコピペを多用する場合があります。
下手にコードを共通化して複雑にするよりも、
似たやり方で個別に書いた方が分かりやすくなる場合もあるのです。
また一部のパターンにおいてより単純化できるとわかっている場合があっても、
あえて他と設計方針を揃えるために冗長な構造を採る場合もあります。
ボトルネックとなる箇所ならともかく、パフォーマンスに大差が無ければ、
より書きやすくメンテナンスのしやすいコードの方がむしろ高品質といえる場合も少なく無いのです。
Re:ITでも (スコア:0)
ただ、コピペの欠点である、
コピーしたことを後で忘れてしまう
↓
もし修正が必要になってもやり損ねてしまう
のコンボがネックになります。
これさえなければコピペだってそう捨てたもんじゃないと思うのですが。
あ。今ふと思ったんですが、
Subversionのsvn cpコマンドのように
コピーするのは自由だが、
そのコピー(どこからどこへコピしたか)は全て後からトレース可能である、
というコード支援環境をもし用意できれば、
それで結構幸せになれるんじゃないでしょうか？
ただし、これをやるのは結構覚悟がいります。
ファイル単位でのコピー管理では不十分で、
で
Re:ITでも (スコア:0)
コピペ＝低製造コスト
ってことで考えてました。
出来上がったものの品質を計るには、どうしたら良いですかねぇ？
品質を考えると、納品後のバグ率とかですかね？
品質の視点からすると、バグが少ない、変更が容易(短時間で済む)のが、良いコードかなと思うのです。
そうすると、コピペ三昧でも、関数大増殖でも、あまり構わない。
要は、バグが少なくて、変更しやすい(程度によるでしょうけど)のであれば、
コーディングがどんな華麗か！どんなに醜悪か？なんてどっちでも良いん
Re:ITでも (スコア:0)
というか、いざバグが出たときの修正費用を
どっちが持つか
(製造元か、それとも追加料金を頂くか)
っていう論点で
営業のかたがたは日夜奮闘なさってるようです。
よく判らないんだけど、
「それが」営業の仕事なんだろうか？とは日夜不思議に思います。
あと、「バグが少なくて」といっても、
バグの定義が問題になるんですよね。
つまり要求が何を言っていたか？の解釈を洗いなおす羽目になる。
それ次第でドッチが悪いかがコロコロ変わってしまう。
ついでにいえば、ちゃぶ台返
Re:ITでも (スコア:1)
少し前までは、 コードカバレッジというのがもてはやされていました。要はプログラムの全箇所テストしたらバグは無い、とするものです。
NTのおかけでマルチスレッドが普通に使われてくるとプログラムのある箇所と別のある箇所が同時に走行すると間違える、というケースが出てきました。こうなるとカバレッジ解析だけでは不足してしまいます。
こういったマルチスレッド観点での試験方法が必要なのですが、なかなかやり方を変えようとはしてくれません。困ったものです。
Re:ITでも (スコア:2, 興味深い)
そこだけ注視すればよいと理解されているからではないでしょうか？
あるいはスレッド同士のインタフェースを少くする(可能なら隠蔽する)よう
に設計せよということじゃないでしょうか？
Re:ITでも (スコア:0)
怖いねぇ。
Re:ITでも (スコア:0)
オブジェクト指向プログラミングコーディング？