質の高いコーディングを身につける  

このエントリーをはてなブックマークに追加
1仕様書無しさん
方法を教えてください
2仕様書無しさん:04/11/20 07:00:18

カーネルを読め。
3仕様書無しさん:04/11/20 07:02:42
3万でどうだ?
4仕様書無しさん:04/11/20 07:07:03
4万なら。
5石黒 ◆VNX0nxDxEo :04/11/20 08:07:13
経験をつむことだろうね5
6仕様書無しさん:04/11/20 08:55:32
他人の作った鬼のような糞コードのメンテに従事する。
7名無しさん@お腹いっぱい。:04/11/20 11:14:13
>>2
素直なコードだとはとてもおもえんが。
8仕様書無しさん:04/11/20 13:18:06
まあプログラムなんざ、バグもなく仕様通りにきちんと動けばそれで十分だと
個人的には思うけどな。

読みやすさとか主観的な部分は、人によって基準は全然違うし。
C 言語の GNU スタイルも GNU なプログラムでは推奨されてるけど、
漏れにはキモくてしょうがなかったりとか。
9仕様書無しさん:04/11/20 13:58:18
質の高いって?
どういうものを作るときのことを言っているんだ?

OSや組み込み系などの場合は、
>>2のようにカーネルを読むとか>>8のようにC言語のGNUといった話しになるけれども

大規模アプリの場合は全然話しが違うな。

オブジェクト指向を勉強してデザインパターンを身につけつつ
リファクタリングを繰り返し、テストファーストまたはテスト駆動開発によってテストコードもしっかりと書く。
ようは、eXtreme Programmingやアジャイル開発ってところか。


また、デザインパターンも大事だけど基本的なアルゴリズムも理解しておいた方がテクニックとしては
良いことだと思う。

Code Readingを読んでみるのはどうよ?
10仕様書無しさん:04/11/20 14:08:22
>バグもなく仕様通りにきちんと動けばそれで十分

まぁバグなのか仕様通りなのか小一時間問い詰めたいものもあるが

で、 >>1 よ "質"ってなんだ?
11仕様書無しさん:04/11/20 14:41:02
質といえば

CMMレベルのことを思い出すけど
ちょっと違うかな?
12仕様書無しさん:04/11/20 14:50:38
全然違う
13仕様書無しさん:04/11/20 14:54:49
やっぱり可読性が高く、保守し易いソースだろ。
あとDocもしっかり改定しろ、ボケェ。
1469式フリーPG ◆hND3Lufios :04/11/20 14:59:46
とりあえず、"Code Complete"を読んでみる。
15仕様書無しさん:04/11/20 15:00:03
>可読性が高く、保守し易いソース

意味ねぇな、そんな基準
16仕様書無しさん:04/11/20 15:01:49
>>15
なんで?
17仕様書無しさん:04/11/20 15:03:41
ひきこもりだから。
18仕様書無しさん:04/11/20 15:04:54
例えば「こんにちは世界!」プログラムがその基準を満たすだろが意味ねぇだろ?
19仕様書無しさん:04/11/20 15:24:12
釣りにしてはつまんないし、煽りにしてもパンチがないから
18はリアルアフォなんだろうなw


20仕様書無しさん:04/11/20 15:32:26
>>18はそれしか知らないんだから、仕方がない。
21仕様書無しさん:04/11/20 16:28:09
>>12
ちがわねえよ。

CMMレベルはソフトウェア管理品質を定める基準だろ
22仕様書無しさん:04/11/20 16:34:51
まてよ
「一方向」から見るのでは答えが出ないかも知れない
しかし、ニ方向から見れば少なくとも正反対でない限り答えの接点が見つかるかもしれん。

質の低いコーディングとは何だ?
23仕様書無しさん:04/11/20 16:35:24

「質」=「管理品質」

ってこと?
そうなのか?
24仕様書無しさん:04/11/20 16:36:19
質の上のやつって猫の耳に見えるよな
25仕様書無しさん:04/11/20 16:51:11
>>22
質の低いコーディング = 21みたいな思い込みの激しいアホのコーディング
26仕様書無しさん:04/11/20 16:58:59
>>22
唯一絶対的な基準を求めること自体、無謀だと気づけ。
27仕様書無しさん:04/11/20 17:08:44
何やってるのかがわかりにくいコードは質が低い
28仕様書無しさん:04/11/20 17:28:30
>>26
誰がいつ、唯一絶対的な基準があるって言った?
29仕様書無しさん:04/11/20 17:29:22
>>21
知らないんならしゃべらなくていいよ
30仕様書無しさん:04/11/20 17:36:42
機能と構造がきちんと別れていて、
構造が整然としているコード。
ごっちゃなコードは、なにがドキュメントされてようが、
捨てて作り直したほうが早い。
31仕様書無しさん:04/11/20 17:57:58
>>28
じゃ、>>22のいう「答え」って何よ?
どう見ても一つの定義に結論付けたがってるのだが?
32仕様書無しさん:04/11/20 18:06:26
「答えの接点が見つかるかもしれん」(原文のまま)

という表現が、なぜ一つの定義に結論付けたがってると読めるんだ?
33仕様書無しさん:04/11/20 18:18:08
それは「答えの接点」であって「答え」そのものじゃないな。
34仕様書無しさん:04/11/20 19:06:22
俺が本を書くしか無いか。
3年くらいかかるけど待っててくれ。
35仕様書無しさん:04/11/20 19:11:38
「プログラムは書いてしまえば終わり。保守性なんざ知ったこっちゃねぇ。動けばいいんだろ動けば」
という人間を軽蔑すること。態度に出してもよい。
36仕様書無しさん:04/11/20 20:40:38
>>14
(・∀・)イイネ!!
古い本だけど読む価値アリ。
37バリバリの初心者:04/11/20 22:30:56
とりあえず、動くように作ってみよう!動かなきゃ話にならん!
と思って、ごにょごにょ作って、おー動いた!結果も正しい!
じゃー、綺麗に書き直すか・・・と思ってたらもう納品?
あれ?えーーと。。。まーいいか。動くし・・・。
38仕様書無しさん:04/11/20 22:33:25
>>37
それは現場の真実だ!!
解決すると思うなよ!!
39仕様書無しさん:04/11/20 22:51:14
イケメンの作るソースは美しい。
ブサイクの作るソースは醜い。
これ定説。
40仕様書無しさん:04/11/20 22:56:40
俺は最近悟ったね
コードなんてのは読みにくいのが普通

GNUとかのソース見てみろよ
41仕様書無しさん:04/11/20 23:17:06
面倒見の良い高スキル者とペアプロすると一気にスキルが跳ね上がるよ。
42仕様書無しさん:04/11/20 23:25:34
吸収できる器量がないと、ペアプロしても得るものは乏しいよな。
43仕様書無しさん:04/11/20 23:28:31
>>40
思考停止いくない
44バリバリの初心者:04/11/20 23:29:01
>>41
そう!それGOOD。
でも、そんな先輩がいないの・・・。
あーもうはやく就職先変えよ。
45仕様書無しさん:04/11/20 23:29:07
面倒見のいい高スキルがどこにいるんですか?
4645:04/11/20 23:29:31
かぶった
47仕様書無しさん:04/11/20 23:34:07
>>43
別に思考停止じゃなくてさ、もちろんすっきり書こうと努力するけど
それだけじゃだめだな、と思うようになったわけ

GNUは汚いかも知れないけど、有用でもあるわけだから
48仕様書無しさん:04/11/20 23:43:27
Simple Design
49仕様書無しさん:04/11/20 23:44:32
>>1
まずは使用する言語の全仕様を把握する事だよ。
50仕様書無しさん:04/11/20 23:49:39
何が良くて、何が悪いかを判断できるようになるまで、とりあえずガンガレ。
51仕様書無しさん:04/11/20 23:55:33
元々数学とか苦手な奴はキツいかもね。
52仕様書無しさん:04/11/21 00:11:27
GNUは集団でソース弄繰り回すから凄い事になってるよな、
もっとも、それがポリシーみたいなものだから、それが無くなって綺麗になっても
なんだかなーって感じだしね。
53仕様書無しさん:04/11/21 01:27:24
読み手もある程度すんなり読める技術が必要だよな
54仕様書無しさん:04/11/21 02:05:05
自分の思い入れの強いアプリ(といってもツールです)を書いて、それをひたすらメンテするというので、私は身についた。
いろいろ機能追加もしたいし、思い入れもあるので、些細なバグや、奇妙な仕様も許せなくなってくる。
他人も使うようになってきたので、一度書き直した。(しかも、GUIを入れるということで、C++ から Visual Basic + C にした)
そしたら、メンテしやすいコードになっていた。
もちろん、その前に、その手の本をすこしは読んでいましたが、
身に着けるには長くメンテするアプリとの出会いが必要だと思う。
55仕様書無しさん:04/11/21 03:48:30
ソフトの質に直結するという意味で、「コードの質」イコール「バグを誘わないコーディング」ですよ。
保守性や可搬性はあったほうがいいが、「コードの質」としてのそれは、仕様変更を加えることによって
バグを仕込んでしまう、という事態を避けるようなコーディングということ。
56仕様書無しさん:04/11/21 09:48:08
>>55
あなたが主張しているのは保守性に関してですよ。
57仕様書無しさん:04/11/21 10:00:18
建設的な意見ゼロw
58仕様書無しさん:04/11/21 10:03:13
リファクタリングにリファクタリングを重ねろ。
59仕様書無しさん:04/11/21 11:39:10
元が糞だといくらリファクタリングしても糞のまま
地面に落ちてるゲロと、茶碗に盛られたゲロほどの差でしかない
60仕様書無しさん:04/11/21 16:32:43
>>56
プログラムは開発する時間よりも、使われる(保守される)期間のほうが遥かに長い。

その長い期間、保守は続けられる訳だが、保守性を軽視して作られたモノは、当然保守に高いコストを要求することになる。


「質の高いコーディング」について、保守性が挙げられるのは当然だ。
漏れは、プログラムの質=保守性、とすら思っているくらいだ。
61仕様書無しさん:04/11/21 17:50:35
>>37
マジでそれが真実だな
62仕様書無しさん:04/11/21 18:57:34
>>60
>>56は「コードの質は保守性じゃなくて保守性ですよ。」
みたいな主張してるから突っ込んでみました。

アジャイルな環境だと保守性は最優先事項だと思ってます。
63仕様書無しさん:04/11/21 19:02:24
アジャイルってなに? 職場にアジャがいるの?
変なコード書いてると垂直落下式ブレーンバスターなのかな
それなら保守性が最優先事項にもなるな・・・
64仕様書無しさん:04/11/21 19:05:59
>変なコード書いてると垂直落下式ブレーンバスター
是非そうしてくれw
65仕様書無しさん:04/11/21 23:04:28
// 変数aに0を代入
a = 0;

こういうコメントだけはやめてくれ。
66仕様書無しさん:04/11/22 23:38:35
何のために0を入れてるか書けって漢字だよな
67仕様書無しさん:04/11/22 23:42:56
そもそもaとかいう変数名使う時点で駄目だな。
68仕様書無しさん:04/11/22 23:59:01
aはだめだけどiは許す。
69仕様書無しさん:04/11/23 01:02:09
93 :仕様書無しさん :04/11/20 02:54:53
・事前にテストの設計を行うので,自分がどんなプログラムを作るべきかがよく分かる
 やめてくれ。
 どんなプログラムを作るべきか分からないから,プログラミングは楽しいのだ。
 そのだいご味を奪うな。

・単体テストを頻繁に繰り返すことで早期にバグが見つかる
 何を言っているんだ。
 誰もが自分のプログラムの中にバグがないことを願っているのだ。
 バグなんて見つからないほうがいい。余計な仕事が増えるだけだから。

・早期に問題が解決することで,後工程からの手戻りが減って開発スケジュールが円滑に進む
 おいおい,手戻りが減ったら開発が予定より早く終わっちゃうかもしれないじゃないか。
 人月計算でやっている限り,少しでも開発期間を延長して開発費をいただかないと
 赤字になるぞ。
 それに,開発途中の品質の低さが,ハラハラドキドキしてたまらないのに。

・テスト・プログラムを先に作っておけば,本体のプログラムを変更(リファクタリング)しやすい
 リファクタリングだって?
 なんでわざわざ動くプログラムを修正する必要があるんだ。
 動いてるものには触るな,と習わなかったのか?
 プログラムなんて動けばいい。中身がスパゲッティでも構わない。
 メンテナンス? どうせそのプログラムを修正するのは私じゃないさ。

・テスト・ファーストを行えば,品質に対する安心感とテストをパスする達成感が得られる
 安心? 達成感? 何を寝ぼけたことを言っている。
 劣悪な環境で不安を抱えながら仕事をするのがソフトウエア開発じゃないか。
 私なんかもう1週間も家に帰っていないぞ。
 いつもニコニコしてプログラミングするような奴と一緒に仕事をするのは願い下げだ。

94 :仕様書無しさん :04/11/20 03:04:42
プログラムをどのようにテストすればよいかという点を欠いたままの今のテストファーストではバグは減りません。
70仕様書無しさん:04/11/23 10:32:34
確かにツールが先という風潮は宜しくないね。
71仕様書無しさん:04/11/23 14:53:32
>>68
なんでiとかjがfor文とかの一時変数に使われるようになったの?
新人っぽい質問だが。
72仕様書無しさん:04/11/23 15:08:22
>>71
ヒント:フォートラン
73仕様書無しさん:04/11/23 15:27:35
>>68
そうそう。
愛さえあればなんでもうまくいく品。
7469式フリーPG ◆hND3Lufios :04/11/23 15:37:29
>>71
高校の数学で数列や行列を習ったじゃろ。
あと、物理とか化学で習う電子殻とか。
75仕様書無しさん:04/11/23 16:00:34
for(int loopCounter = 0; loopCounter < MAX_LOOP_COUNT; loopCounter++)
76仕様書無しさん:04/11/23 16:16:17
void main(void){

for(int i=0;i<10;i++) { } //これはイイ
for(int a=0;a<10;a++) { } //(´Д`三´Д`)ヒィィ

}
77仕様書無しさん:04/11/23 16:29:06
IMPLICIT REAL*8 I-N
78仕様書無しさん:04/11/23 16:31:30
for(String s : list)
79仕様書無しさん:04/11/23 16:53:05
わたしが高品質コーディング教官のハートマン先任SEである
エディタにクソたれる前と後に“Ctrl+Z”を押せ
分かったか、ウジ虫ども!
80仕様書無しさん:04/11/23 17:33:47
>>79
Sir!!Yes Sir!!
81仕様書無しさん:04/11/23 18:05:01
>>79
Z^Y^Ze^Zs^Z
82仕様書無しさん:04/11/23 18:10:45
DEFDBL A-Z
Ok
83仕様書無しさん:04/11/23 18:24:02
>for(int a=0;a<10;a++) { } 

...ここまで明確にループってるなら無問題
84仕様書無しさん:04/11/23 19:38:38
for(double r = 0.0; r < 10.0; r++){

}
85仕様書無しさん:04/11/23 20:01:41
>84

整数型以外をループに使うのはダメぽ
86仕様書無しさん:04/11/23 20:17:24
>>85
この場合は用途によってはいいんじゃない?
r!=10.0 とかやってたら話は別だが
87仕様書無しさん:04/11/23 20:34:22
>86

いや、ダメだ。
内部が2進数である限り、小数点以下を含む計算でループしてはいけない。
88仕様書無しさん:04/11/23 20:37:03
>>87
どうして?
0.0以上10.0未満を +1.0ずつ増加でループ
は、全く問題ないと思うけど。
89仕様書無しさん:04/11/23 20:38:20
あ、わかった
>>85がダメって言ってるのは r++ の部分か
r+=1.0 と書かなきゃダメだな
90仕様書無しさん:04/11/23 21:10:06
実行してごらん。
10回か?11回か?
91仕様書無しさん:04/11/23 21:10:50
r++がだめなんだろう、多分。
なんとなく、そんな気がする。
for文の中の処理でrが増えていくなら>>86の言ってることも当たってそうな予感。
92仕様書無しさん:04/11/23 21:15:26
>>90
だから、回数ではなく範囲指定だろ
用途を考えろよ低脳
93仕様書無しさん:04/11/23 21:27:19
>範囲指定だろ

...もまえも低脳っぽいなw
94仕様書無しさん:04/11/23 22:06:43
お前ほどじゃないけどな
95仕様書無しさん:04/11/23 22:32:29
>>93
バーカ
96仕様書無しさん:04/11/23 23:21:53
>>95
おめえ・・・・俺の隣でdoubleでループ回してはまってたYだろ?
97仕様書無しさん:04/11/23 23:24:37
いずれにせよ十分なテストだけは行って下さいね。
9890:04/11/24 12:47:38
>>93
範囲指定とは何か?
反復構文で、反復回数が問題にならないことなぞ無いぞ。
処理系によって反復回数が安定しないコードが良くないのは明らかだ
どうしてもfor文を使いたければ
esp =1.0e-06: // 一例
for(r = 0.0; abs( 10.0 - r ) > eps; r+=1.0 ){
のように書くものだ
99仕様書無しさん:04/11/24 13:23:31
>>68
なぜなら、彼女もまた特別な存在だからです。
100仕様書無しさん:04/11/25 16:21:56
変数に性別があったのか。
101仕様書無しさん:04/11/26 06:10:42
man c = 0;
woman b = 0;
newhalf a = 0;
102仕様書無しさん:04/11/26 10:58:04
変数にも女性変数と男性変数くらいあるだろ
103仕様書無しさん:04/11/26 16:45:32
man co
104仕様書無しさん:04/11/26 20:46:15
co - RCS ファイルからリビジョンをチェックアウトする
105仕様書無しさん:04/11/30 00:35:17
質って何だ?
106仕様書無しさん:04/11/30 00:35:36
「ドラクエ8のラスボスは主人公の兄イリアス」
107仕様書無しさん:04/11/30 15:39:01
「はんにんはヤス」
108仕様書無しさん:04/12/01 23:55:51
  ,j;;;;;j,. ---一、 `  ―--‐、_ l;;;;;;   質の高いコーディングを身につける
 {;;;;;;ゝ T辷iフ i    f'辷jァ  !i;;;;;   
  ヾ;;;ハ    ノ       .::!lリ;;r゙    
   `Z;i   〈.,_..,.      ノ;;;;;;;;>  そんな風に考えていた時期が
   ,;ぇハ、 、_,.ー-、_',.    ,f゙: Y;;f     俺にもありました
   ~''戈ヽ   `二´    r'´:::. `!
109仕様書無しさん:04/12/03 00:40:42
>>105
とても良い質問だ。
「品質の定義は、定義する人間の(立場の)数だけある」
という事実から帰納するとだな。
書く人間が「質が高い」と判断すればそれは質が高いのだよ
110仕様書無しさん:04/12/05 10:08:48
金払ってる人間が判断しないと駄目だろ。
逆に言えば、金払わない人間がどれだけ評価しても無意味。
111仕様書無しさん:04/12/06 18:29:57
>>110
そうかな?
「金を払う人間」とは最終的にはユーザーではないか?
ユーザーの関心事は、「払った金に見合う効果がそのソフトを使うことによって得られるか否か」
であって、ユーザーがコードの質に関心を持つことは稀だと思うが
112仕様書無しさん:04/12/07 14:50:58
>>111
だがおれらにとって「金を払う人間」はあくまで顧客だからな
113仕様書無しさん:04/12/08 01:54:01
2次請けのやつは元受けのことを「顧客」っていうんだな・・・
ということに最近気付いた。
114仕様書無しさん:04/12/08 10:48:36
>>111
つまりその例なら「コードの質=ユーザにとっての価値」って事だよ。
それ以外に必要な事があるならそれは嘘だよ。

まー>>113みたいなケースで元受とエンドユーザどっちを大事にするかはプロマネの裁量だけど。
切られるの怖いけど、後者を選んで無能な元受排除した事もあるし、気合次第w
115仕様書無しさん:04/12/12 10:48:18
goto使っちゃいけないって言われたんですけど何でですか?
116仕様書無しさん:04/12/12 10:57:31
>>115
それは言った奴が「goto使っちゃいけない」と思っているだけ。
もちろんそういう規約が存在すればべつだけど
117仕様書無しさん:04/12/12 11:08:35
goto使っちゃ駄目だろ。
118仕様書無しさん:04/12/12 11:14:30
>goto使っちゃいけない

まぁほらあれだ、プログラムを組むときのお作法のようなもんだ
別に使いたければ使えばいいし、gotoを積極的に使った方がいいと主張する香具師もいるし
「あら、gotoですか(プ」ってこと
119仕様書無しさん:04/12/12 11:19:31
goto使わないと論理的に不可能なプログラムもあるしね。
120仕様書無しさん:04/12/12 11:30:39
>goto使わないと論理的に不可能

んなこたーない
121仕様書無しさん:04/12/12 11:44:18
119は釣りだとみんな思ってるだろうが、実はマジでアフォ
122仕様書無しさん:04/12/12 11:46:50
>>119
具体例キボン
123仕様書無しさん:04/12/12 12:18:35
フラグで制御構造を作るくらいなら
goto文使ったほうが早くねぇ?
124仕様書無しさん:04/12/12 12:25:45
「早い」って処理の速度のことではないからね(ってそれなら「速い」だが)

そのほうが、やりたいことをダイレクトに表現している。
っていう意味ね。
125仕様書無しさん:04/12/12 12:26:52
Java使えば全て解決
126仕様書無しさん:04/12/12 12:44:17
VBやってるんだが、たまに

For i = 1 To 10
If i = 3 Then Goto EXIT_PROC
Next i
EXIT_PROC:

みたいなソースに出くわすことがある。
ループをちゃんと終わらせないでポーイと投げてる感じがして、
ジャイアントスイングが頭をよぎる。
127仕様書無しさん:04/12/12 12:52:05
VBやってる人が生意気言わないでください
128仕様書無しさん:04/12/12 13:17:10
VBには、Cのbreakみたいなのはないの?
129仕様書無しさん:04/12/12 14:45:42
まぁ「たたい」とか「れいがい」とか知んねぇんだろーなぁ
130仕様書無しさん:04/12/12 14:50:17
>128
exit ほにゃらら ってのがある

Cの continue に相当するものは無かった希ガス
131仕様書無しさん:04/12/12 15:03:37
>>129
多胎
冷害
132仕様書無しさん:04/12/12 15:12:33
For i = 1 To 10
If i = 3 Then Goto EXIT_PROC
Next i
<- この行に何かあるなら普通のgotoの使い方だな。っていうかgotoはgotoスレでやれ
EXIT_PROC:
133仕様書無しさん:04/12/12 15:40:20
Exit For
で充分なんだが。
134仕様書無しさん:04/12/12 19:10:57
意味わかってない奴
135仕様書無しさん:04/12/12 22:32:45
>>132
For i = 1 To 3
に書き換えろよ!と叫ぶのが普通じゃないのか?
136仕様書無しさん:04/12/13 00:10:12
for(int i = 1; i < 3; i++)

に書き換えろよ!
137仕様書無しさん:04/12/13 23:02:22
例外処理ってあるけど、結局gotoと一緒だろ?
何でJavaとか偉そうにしてるの?
138仕様書無しさん:04/12/13 23:04:48
>>137
へたくそな釣りですね
139仕様書無しさん:04/12/13 23:05:35
>>137
longjmp() と一緒と逝ってクレ。
140仕様書無しさん:04/12/13 23:06:25
>>138
違いを教えろ。
141仕様書無しさん:04/12/13 23:10:52
>>140
まともなクラスライブラリの例外処理でも見てください
142仕様書無しさん:04/12/13 23:31:57
>>141
理解してないなら偉そうなレス付けるなよw
143仕様書無しさん:04/12/14 00:14:51
てか、VBのエラー処理語ってどうするの?
Javaのエラー処理と別物であることくらい、ぐぐって理解すれよ。バーカ!
VBじゃ、Javaみたくエレガントに処理できねんだよ!バーカ!シクシク。。。
144仕様書無しさん:04/12/14 00:22:48
>>137
どちらも単なるジャンプ命令だと思うが、Javaとかの例外は、言語レベルでエラー処理を
行う為の仕組みとして規定されてるだけだと思ってる。
使い方を規定しているから、偉いのかな?

例外処理の利点は、正常なシーケンスがエラー処理に埋もれないって所だと思ってるから
分かっててgoto使うなら問題ないと思ってる。
145仕様書無しさん:04/12/14 10:49:37
goto禁止なら例外禁止だもんな
146仕様書無しさん:04/12/15 02:40:49
gotoは本質的にプログラムの意味付けにおける合成性の仮定
(プログラムの意味は、部分プログラムの意味を合成したものになる)
をぶち壊すものだけど、例外処理はそれを最小限に留めつつ
有用な制御構造を提供している。
147仕様書無しさん:04/12/15 13:14:35
>>146
つまり、Cでも「例外」を実装すると言う意味では
goto使ってもいいということになるね
148仕様書無しさん:04/12/15 13:42:01
>>146
「仮定」ではわからんなぁ。誰がいつ仮定したんだ?君か?
149仕様書無しさん:04/12/16 17:15:15
どんな言語だろが、ロジックが簡潔になるのなら
gotoもありだと思うが、なんでそんなにgotoが嫌いなのだ?
汚いBASICやCOBOLのスパゲッティーは論外として、
構造化言語の場合、goto使っても破綻は少ないし、
例外処理やエラー回復処理は、メインの外にあった方が
後のプログラムメンテナンスが楽な場合が多いぞ



150仕様書無しさん:04/12/16 20:37:28
>149

この会社辞めようと思ったソースコード#10
http://pc5.2ch.net/test/read.cgi/prog/1097676086/
151仕様書無しさん:04/12/16 22:48:00
goto fatal_error

ならまー許すけど、

goto label1

は小一時間説教
152仕様書無しさん:04/12/17 01:30:06
でも break label とかありますから、残念!
153仕様書無しさん:04/12/17 15:32:47
>>152
残念だ。。。
154仕様書無しさん:04/12/20 00:24:36
TDDにおけるユニットテストは「具体的な目標(=どういう振舞いにするかをコードで表現する)」
を事前に作成し、そこに向って実装をし、目標の通りか「検証」することで開発を進める。
具体的な目標とは「近い将来のあるべき姿」であり、検証とは「目標に合致しているか?」
を判断することである。
目標を明確にして作業しないと時間の波に流されてあらぬ方向に行きがちな人間の弱さを
補完するプロセス、つまり目標駆動であると言ってもよいのではないか。
結果的にTDDで作成したテストは自己検証可能な仕様書になるのだが、そこまでの過程を
目標駆動 で行なうことがTDDの最大のメリットであるという気がする。

PDCA(Plan-Do-Check-Action)サイクルにも似ている。
155仕様書無しさん:04/12/20 23:31:08
>>154
似てないだろw
156仕様書無しさん:04/12/21 01:15:28
157EK:04/12/22 13:37:56
theSpokeってどうよ?
158仕様書無しさん:04/12/22 15:34:11
美しいソースコードを書いても給料は上がらないし会社は評価してくれない。
プログラムで一番重要なのは「ちゃんと動く」こと。次に手を抜くこと。
159仕様書無しさん:04/12/22 19:09:42
美しいコードなんかかかれても迷惑だ。
とりあえず、ちゃんと動くわかりやすい最低限のコードを書いてくれ。
記述行数が増えて、守られたり守られてなかったりするコーディング標準なんか不要。
160仕様書無しさん:04/12/23 01:05:20
>>156
似てないじゃんw
161仕様書無しさん:04/12/23 10:18:25
>>149
BASICやCOBOLも随分と昔から構造化言語になってるし
最近はどちらもOO化してるぞ。w
162仕様書無しさん:04/12/23 11:30:30
人がOO化してるかは別問題
163仕様書無しさん:04/12/23 11:37:31
>>158
評価されないのは効用を説明しないからだよ。
そして対価を払う人間の承認も必要だな。
勝手に作って脳内で「俺スゲー」って奴は単なる自己満足。
164仕様書無しさん:04/12/25 10:59:00
>効用を説明
しないとダメなもんは評価に値しないんだが...
165仕様書無しさん:04/12/25 11:02:59
>>164
それは認識が甘いだろ。
顧客やプロマネがソースコードの質を正確に評価出来るとでも思ってるの?
166仕様書無しさん:04/12/25 11:48:10
>しないとダメなもんは評価に値しないんだが

ドカタ発見!(藁
167仕様書無しさん:04/12/25 12:01:35
>>158
それって一番最初に綺麗なソースコード作れば(概ね)満たされるジャン。
>>163
効能は理解されるよ。でも評価はされない当たり前だという認識。
現役の頃はやってなかったくせに。
168仕様書無しさん:04/12/25 12:44:22
>>167
そんなあなたには転職をオススメ!
169仕様書無しさん:04/12/25 12:49:49
理解させるのは自分の価値
170仕様書無しさん:04/12/25 12:55:23
Javaで使い終わった変数にnullを代入してる人が居ましたが意味ありますか?
171仕様書無しさん:04/12/25 12:57:08
使い終わったことを誇示するという満足感を味わえます。
お風呂上りにタオルでオマタをパンパンするのと同じです。
172仕様書無しさん:04/12/25 13:15:17
>>170
ローカル変数なら無意味だけどクラスのメンバならnull代入して
その参照先のインスタンスをGCの対象にするというのは普通にやるだろ。
173164:04/12/25 13:44:10
>165
だから、なぜ顧客やプロマネがソースコードの質を正確に評価しなけりゃならいんだ?
違うだろ?
質の高さが説明しなくてもすむ別の明らかな尺度で測れなきゃ評価するまでもない
174仕様書無しさん:04/12/25 13:47:29
>>172
クラスのメンバに対して「使い終わる」という事態が発生するのは、よくないと思うぞ。
175仕様書無しさん:04/12/25 14:07:33
174のコードでは一旦クラスのメンバに保持した参照は
プログラム終了時まで決して使い終わらないのか・・・
176仕様書無しさん:04/12/25 14:09:13
...まるで全出演者が一斉に画面に出てくるモブシーンオンリーな映画w
177仕様書無しさん:04/12/25 15:00:06
>>175
>>170のような文脈の「使い終わった」という理由でメンバにnullを入れることは、ないなぁ。

>>176
Webアプリケーションの場合は、全出演者が一斉に舞台にのってて、ユーザーによって見える出演者が違うだけだからね。
あとは、リクエスト処理中で生成するオブジェクトだから、メンバにnullを入れる必要が出る前に自分自身がいなくなる。
178仕様書無しさん:04/12/25 15:03:17
>>174
>クラスのメンバに対して「使い終わる」という事態が発生するのは、よくないと思うぞ。

ファイルをクローズするのも駄目ですか?
179仕様書無しさん:04/12/25 15:08:01
>全出演者が一斉に舞台にのってて、ユーザーによって見える出演者が違うだけ

( ゚д゚)

(つд⊂)ゴシゴシ
 
(;゚д゚)

(つд⊂)ゴシゴシ
180仕様書無しさん:04/12/25 15:41:42
>>178
そんなもん、使い終わった変数にnullを代入してることに疑問をもたれるような使い方でメンバに持っちゃイカンだろ。
181仕様書無しさん:04/12/25 15:43:32
>>179
リクエストとかセッションとかほっときゃ消えるオブジェクト以外は、コンテナがずっと保持してるよ。
182仕様書無しさん:04/12/25 16:23:10
>>177
>文脈
どういう文脈を設定したら特定の状態の間だけ
メンバにオブジェクトをぶら下げておくような使い方は一切存在しないことになるんだろう・・・
まさか170の「変数」はメンバじゃないとかトンデモ文脈を設定したりしてないよねw
183仕様書無しさん:04/12/25 16:52:14
>>182
使い終わってnullを代入していることに意味があるのか疑問を覚えるという文脈。
184仕様書無しさん:04/12/25 17:16:24
質の高いコーディングは自己防衛のために存在するんだよ。
どうせ、評価されないだろ?仕変が予測つくなら、それなりに綺麗にしておくだろ?
その程度でいんだよ。手を抜くために努力すんだよ。(結局、パクリか。。。)
185仕様書無しさん:04/12/25 17:33:43
使い終わったインスタンスは属性にnullを代入するまでも無く
参照が無くなりGCの対象になるはず。必要性を感じるなら、多分設計が悪い。

そもそも「使い終わり」ってどこで実装する気だよ。finalize?
後で使いたくなったら使い終わり時の処理も変更するの?
186仕様書無しさん:04/12/25 17:37:19
>>173
開発者が説明不要な、顧客やPMにとっての明らかな尺度って何ですか?
187仕様書無しさん:04/12/25 17:49:50
null使わない人ってパフォーマンスチューニングは無視ですか?
188仕様書無しさん:04/12/25 18:40:49
>>186
労働時間。たのみごとしたときの嫌そうな顔。
189仕様書無しさん:04/12/25 18:41:17
>>185
その"使い終わった"というのはどういう状態の事を指してるんだ?
そのインスタンスをどの変数も指さなくなったときか?
190仕様書無しさん:04/12/25 18:41:41
>>187
nullでパフォーマンスチューニングになるですか?
191仕様書無しさん:04/12/26 22:38:59
最後が?で終わる奴に限って会社ではGC対象になるのだよ
まさに組織単位でのパフォーマンスチューニング
192185:04/12/26 23:00:43
193185:04/12/26 23:01:44
ミスった。

>>189
俺が聞いてる事を聞き返さないで下さい。
194仕様書無しさん:04/12/26 23:15:01
>>188
それじゃ嫌だから色々試みるんじゃん・・・
195仕様書無しさん:04/12/26 23:41:02
>>194
金。
196仕様書無しさん:04/12/27 10:49:57
>>195
低単価で過剰勤務で、納期直前の仕様変更をニコニコしながら
引き受ける事で評価を上げて満足して下さい。
197仕様書無しさん:04/12/27 12:14:23
このスレ見ても質の高いコーディングは身に付かないね。
198仕様書無しさん:04/12/27 12:15:34
>>197
結論を急ぐな。
199仕様書無しさん:04/12/27 22:07:35
>>197
せめてあと800レスまってからその結論を出せ。
200195:04/12/27 22:08:42
>>196
オレは別に評価で困ってないから、>>194に言ってあげて。
201仕様書無しさん:04/12/30 02:39:35
>どのようにテストすればよいかという点を欠いたままの今のテストファーストではバグは減りません。

減らない?
増えないが正解だ
202仕様書無しさん:04/12/30 05:22:27
どこから引用してきたんだろう・・・・
ま、考えなく書きやすいところだけユニットテスト書いてテストしたつもりになっても、普通に動作確認で気づくような不具合しか対処できないってことじゃないかな。
テストファーストしないときにバグとして報告されていたものに関しては、相変わらずテストされずバグとして報告される、と。
203仕様書無しさん:05/01/05 01:32:01
???
テストファーストってやったりやらかったりすんの?ありえねー
ってゆーか意味無いじゃん
204仕様書無しさん:05/01/05 01:44:35
>>201
やっぱり「減らない」の方が適切だよね?「増えない」は語弊がありそう。
バグをテスト段階での発生件数として論じたいのかもしれないけど、
そもそもがバグ減らすのが目的だし、発見→修正 でバグ減るわけだし。
205仕様書無しさん:05/01/05 02:30:23
>204
>やっぱり「減らない」の方が適切

んなわきゃねー

206仕様書無しさん:05/01/05 02:33:38
>>203
全部できてるつもりになってるの?
そっちの方が怖い。
207仕様書無しさん:05/01/05 02:42:10
できたりできなかったりするのが、特別なプロセスや個人の能力なしにはありえないことをわかってないのも怖いな。
208仕様書無しさん:05/01/05 02:42:28
>206
>全部できてる

もれも203に賛成
テストファーストって先にテストを作ってから本体を作る手法だよ、わかってる?
できたりできなかったり、ってものではないぞ

(もっともGUIとかはテストファースト対象外だけどね。その話を一点のかな)
209仕様書無しさん:05/01/05 02:45:15
>>208
だから、それで保証できるのはとりあえずテストがあるということだけで、全部テストできたことにはつながらんでしょ。
テストファーストでテスト書いたら、全部テストできたつもりになるのが怖い。
210仕様書無しさん:05/01/05 02:51:06
>209

もまえユニットテストとその上位のテストをごっちゃに考えてないか?
そもそもテストファーストはユニットを作るときの手法であってテスト手法ではない
211仕様書無しさん:05/01/05 02:54:19
>>210
ということは、藻前の意見は、>>201から続く今の流れとは関係ないってことだな。
テストファーストはユニットを作るときの手法であってテスト手法ではないのに、テストしたつもりになっていては工程の終盤以降に報告されるバグは減らない、ってことじゃないのか?
212210:05/01/05 02:58:35
とりあえずテストファーストしとけば「増えない」んだって話じゃねーのか?
そもそもテスト手法ではないんだってば
213仕様書無しさん:05/01/05 03:00:55
「どのようにテストすればよいかという点を欠いたままの今のテストファーストではバグは増えません。」
説明なしで意図どおりに解釈できる文章ではないと思うが。
214仕様書無しさん:05/01/05 03:03:05
>>212
いまは、テストファーストがテスト手法かどうかという話をしてるのではなくて、テストファーストをすることでテストをした気になって妥当なテストが行われないことがあるんじゃないのかって話だよ。
215仕様書無しさん:05/01/05 03:04:19
もまえバカか?
あえて書けば

「どのようにテストすればよいかという点を欠いたままの今のテストファーストでもバグは増えません。」
そもそもテストファーストはテスト手法ではないし

216仕様書無しさん:05/01/05 03:04:44
>>212
テストファーストがテスト手法ではないなら、とりあえずテストファーストするだけならバグは増えも減りもしないね。
217仕様書無しさん:05/01/05 03:07:29
>>215
> 「どのようにテストすればよいかという点を欠いたままの今のテストファーストでもバグは増えません。」

ただ意味がない文章にしただけじゃないか。
減らないというのが論点なんだろ。
218仕様書無しさん:05/01/05 03:09:06
「コーディング前にサルサを踊っても、バグは増えません」
と同じレベルの文章にしただけだね。
219210:05/01/05 03:10:53
>214
だからテストファーストは 減らすって観点ではなくて
増やさないって観点だろって事

220仕様書無しさん:05/01/05 03:11:02
>>215
だから、テストファーストでテストした気になって妥当なテストが行われないということが起きる可能性があるということを話してんじゃねぇの?
221仕様書無しさん:05/01/05 03:13:01
>>219
デグレードしないってこと?
それはただ論点をずらしただけだろ。
それに、テストファーストがテスト手法ではなくて妥当なテストが行われていなければ、デグレードも起きうるよ。
222仕様書無しさん:05/01/05 03:14:11
テストファーストしただけで、デグレードが起きないっていいたいの?
すごく危険な妄想だと思うけど。
223210:05/01/05 03:21:18
>デグレード
まぁそういう観点もあるが、とりあえず今の話の流れとは違う

コーディング時に埋め込まれてしまう類のバグを増やさない、って話だよ
例えば複数のユニットが絡み合う動作時の不具合などはほとんど関係ない
だからこっちは減らない
224仕様書無しさん:05/01/05 03:26:14
>>223
じゃあ、増えないともいえないよ。
コーディング時に埋め込まれてしまう類のバグを増やさないためには、ただテストファーストしただけではだめで、どのようにテストするかという観点が必要だと思うが。
225210:05/01/05 03:28:14
いやどのようにって観点がなくても増えないよ
テストケースにパスするだけのコーディングしかしないんだから
226仕様書無しさん:05/01/05 03:28:59
それに、「バグが増えない」という話は、>>218のようなサルサファーストでもバグはいままでどおりで増えないわけだし、意味がない。
227仕様書無しさん:05/01/05 03:30:11
サルサファーストだと疲れちゃってケアレスミスが増えるかもw
228仕様書無しさん:05/01/05 03:30:29
>>225
そのテストケースの中身が問題なんだろって。
229仕様書無しさん:05/01/05 03:31:30
>>227
コーディング始めるたびに、あっちこっちでサルサが踊られる様子を想像してみろ。
なごむぞ。
230仕様書無しさん:05/01/05 03:35:15
テストファーストはコストがかかるので、バグが減るっていう効果がないならやらないほうがいい。
アフターテストが不要になるわけではないし、それなら、普通にテストアフターだけやったほうがいい。
231仕様書無しさん:05/01/05 03:37:34
実装を先に書いてからテストを書く場合テストの完全性を保障することは困難です
232仕様書無しさん:05/01/05 03:39:01
テストを先に書いたとしても
テストが不足していることを発見することが難しいですけど
233仕様書無しさん:05/01/05 03:44:15
>>231
テストを先に書くにしても、どのようにテストするかという観点がなければ、完全なテストに近づくことはできないと思うが。
234仕様書無しさん:05/01/05 03:45:29
>230

後が違ってくる
デグレいわゆるエンバグが無かった事を確認汁!とかで
235仕様書無しさん:05/01/05 03:51:10
それも、テストファーストでバグが減るって効果がないときには役に立たんよ。
その場合は、ふつうにアフターテストだけ繰り返した方が、コスト的に安くつく。

くれぐれも言っておくけど、どのようにテストするかという観点なしに、ザルのようなテストケースかいた場合だよ。
236仕様書無しさん:05/01/05 03:53:49
ザルのようなテストケースで、デグレードしたときによく見られるようなちょっとむずかしめのバグが発見できるとも思えないし。
デグレードって、なんか必要な条件を忘れたときに起きることが多いからね。
どのようにテストするかという観点なしに書いたテストでは、その条件をテストしてないことが大いにありうる。
237仕様書無しさん:05/01/05 03:56:14
>235

デグレの発見でもアフターテストの方が安くつく?ありえねー
アフターテストで見つかるバグとテストファーストで予防されるバグは異なるんだって
238仕様書無しさん:05/01/05 03:58:57
>デグレードって、なんか必要な条件を忘れたときに起きる

それはデグレードとは言わないな。単なる新しいバグ埋め込みでそ。
いじってないと思っている箇所の動作がおかしくなるのがデグレだよ。
239仕様書無しさん:05/01/05 03:59:40
>>237
だから、テストファーストで書いたテストケースがザルでバグが予防できてない場合だって書いてるでしょ。
240仕様書無しさん:05/01/05 04:00:57
>>238
いじってないと思ってる箇所があるということは、必要な条件を忘れたことにはならんのか?
241仕様書無しさん:05/01/05 04:09:09
テストファーストって、仕様書からテスト項目を作成しようってぐらいの事と
思ってた。
コードを基にテストしちゃアカンって事と。

テスト項目をプログラム言語で書くとにより、テストの実施・結果にブレを
出さないって手法は、よくテストファーストで用いられるが、テストファー
ストの概念そのものとは関係ないかなと思う。
だがら、>>216氏が言ってるように、テストファーストでもバグは増えも減り
もしないと思う。
242238:05/01/05 04:09:26
いじってないと思っている、のは追加修正とは関係ない箇所の意味です。

手を入れる必要がある箇所の洗い出しが不十分である、という意味が
"必要な条件を忘れた"に含まれているのでしょうか?
(必要な...ってのは追加修正をした箇所の意味で捕らえてました)

もっとも"手を入れる必要がある箇所の洗い出しが不十分である"場合は
デグレードではありませんけど
243仕様書無しさん:05/01/05 04:18:12
いじったところとは関係ないと思ってたのに関係あったってことだろ。
そこを関係があることを考慮するというのは、必要な条件であって、それを忘れたのだったら必要な条件を忘れている。
どこがどこと関係あるか把握できない不思議なプログラムを書いてるってんなら別だけどね。
その場合は、テストうんぬん以前に考えることがあると思う。
244仕様書無しさん:05/01/05 04:20:41
"テストファースト"って
1.実装しようとする動作の検証テストを作る
2.そのケースに合格する実装を行う
って事なんだけど
その"テストケースがざる"とか言ってる意味がわかんないな
実装しようと思っていないテストを作るって事?
245238:05/01/05 04:22:15
>243
だからそれはデグレードではないってw
246仕様書無しさん:05/01/05 04:23:35
> 1.実装しようとする動作の検証テストを作る

このときに、どのようにテストするかという観点なしにテストを書いたらテストケースがザルになるだろ。
247仕様書無しさん:05/01/05 04:25:17
それはどこの定義なんだ?
248仕様書無しさん:05/01/05 04:26:08
つうか、どんな経過でバグ修正のときに別のバグが埋め込まれたとしても、それはデグレードだと思うのだが。
249仕様書無しさん:05/01/05 04:26:55
まあ、ここでデグレード談義しても意味がないので、今までのデグレードはエンバグにしておいてくれ。
250仕様書無しさん:05/01/05 04:31:27
>246
>どのようにテストする

実装したい事とテストで確認したい事が全くあってない、って事?
それこそ頭悪すぎ

251仕様書無しさん:05/01/05 04:34:28
世の中きみのように頭がよくいつでも完璧な仕事ができるやつばかりじゃないし、実装したいことを思い浮かべただけで妥当なテストケースが書けるような単純な処理ばかりではない。
252仕様書無しさん:05/01/05 04:35:47
テストファーストさえすれば、いつでもだれでも自然に妥当なテストケースが書けると思ってるんなら、それはそれで危険だな。
253仕様書無しさん:05/01/05 04:38:54
テスト項目が全てパスする絵をみてしまうと作業が完璧なのだと勘違いしてしまう罠
254仕様書無しさん:05/01/05 04:43:01
>251
それは逆じゃないか?
テストケースなしに妥当な実装できるのが
頭が良い香具師か単純な処理という事では?
255仕様書無しさん:05/01/05 04:45:12
>>254
どっちにしろ妥当な実装するには頭がいいか単純な処理である必要がある、という結論になってもいいですか?
256仕様書無しさん:05/01/05 04:47:54
スレの流れとは関係ないけど
以前は動作していた機能が動かなくなること、がデグレードだと思う
そういう意味で新たにバグを埋め込む事とイコールではない希ガス
(たとえ直接のデグレード原因がそのバグであったとしても)
257仕様書無しさん:05/01/05 04:51:18
>>256
新たなバグを埋め込むことと、以前は動作していた機能が動かなくなることは、表裏一体だと思うが。
258仕様書無しさん:05/01/05 04:52:49
そして、ここでは、バグが埋め込まれたととらえるか、以前は動作していた機能が動かなくなったととらえるかは、問題にはならないと思うが。
259仕様書無しさん:05/01/05 04:53:30
>257
新たにバグを埋め込んでも、以前動作していた機能に影響がないこともあるし
バグの埋め込みによらずに、以前動作していた機能が動かなくなる事もある
だから違う
260仕様書無しさん:05/01/05 04:56:37
ある機能が動作しないというのが、そもそもバグだ。
だから、以前動作していた機能が動かなくなること自体がバグの埋め込みだ。
発生要因とは関係がない。
261仕様書無しさん:05/01/05 05:00:04
書いたコードが意図と反していてある部分が動かなくなったとしても、意図したコードを書いたにもかかわらずある部分が動かなくなったにしてもコーディングした本人以外から見れば、不具合は不具合、バグはバグ、デグレードはデグレード。
262仕様書無しさん:05/01/05 05:00:37
>260
最初っから埋め込まれているバグはどう解釈しても"デグレード"ではないが、何か?
263仕様書無しさん:05/01/05 05:06:26
そのバグはいままでテストを通っていて、発現していなかったんだろ?
いままでは問題なかったと。
そういう設計のほころびのようなものが、一番のデグレードの原因だと思うのだが。
っつうか、わけのわからない信念持ってる人と議論しても意味がないので、これでやめる。
264仕様書無しさん:05/01/05 05:07:20
これでやめる
265仕様書無しさん:05/01/05 05:12:18
デグレード、「更新による品質の低下」って感じage
266仕様書無しさん:05/01/05 05:18:06
「更新による品質の低下」の要因は問わないと思うんだがね。
267仕様書無しさん:05/01/05 05:29:03
退化[退行]する、なのだから「更新による」ってのが重要なのであろう
268仕様書無しさん:05/01/05 05:36:22
更新時に書いたコード自体が誤っていたのか、更新時に書いたコードによって正しい部分がうまく動かなくなったのか、更新時に書いたコードによって潜在的なバグが発現したのかは、重要ではないってことだな。
269仕様書無しさん:05/01/05 05:39:41
ソフトウェアの欠陥の多くは、ソフトウェア修正時に発生する。
ある証券会社の第2次オンラインシステムの際のデータでは、欠陥の50%が修正に起因していた。

回帰テストを行う場合、前提として必要となるのは、テスト結果を予測してそれをプログラムとして記述することである。
この作業を支援する回帰テスト支援ツールは、各種のプログラミング言語毎に揃っている。
しかし、テスト結果を予測し記述することは、骨の折れる仕事である。
そのかわり、テスト結果の確認はほぼ自動的にできる。

多くのソフトウェア開発現場では、「面倒だ」という理由でテスト結果の予測を記述せず、
テスト結果の出力を人手で目で検証するということが、未だに行われている。
結果として、多くのプロジェクトで多くの欠陥がリリース後に発見され、多くの技術者が夜遅くまで働いている。
270仕様書無しさん:05/01/05 05:42:09
で、それは、どのようにテストするかという観点なしにテストファーストによるテストを書いても、結果として多くの欠陥がリリース後に発見されるってことだろ。
271仕様書無しさん:05/01/05 05:43:50
テストのカテゴリ

ユニットテスト
統合テスト
システムテスト
検収テスト
保守テストと回帰テスト


テストファーストの範囲は基本的にユニットテストだけだが、何か?
272仕様書無しさん:05/01/05 05:44:05
>>269
これって、テストファーストでもテストアフターでもどっちでもいいから、テストを自動化しろってことだよね。
273仕様書無しさん:05/01/05 05:45:47
>>271
ユニットテストでどのようにテストするかという観点なしにテストケースを書いたとしてもバグは減らないということとどういう関係が?
274仕様書無しさん:05/01/05 05:51:21
>273

>271 は >270 へのコメントだと思うが
>統合テスト
>システムテスト
>検収テスト
で発見できてないのが問題だろ、って事

そもそもテストファーストはテストの話ではないし
275仕様書無しさん:05/01/05 05:59:13
>>274
>そもそもテストファーストはテストの話ではないし

だから、テストファーストで、テストをどうするかという観点で考えてないテストケース書いてテストしたつもりになってるのが問題だと何度・・・
276仕様書無しさん:05/01/05 06:02:19
>275

>250
277仕様書無しさん:05/01/05 06:05:21
>>276
そう続くなら
>そもそもテストファーストはテストの話ではないし
という主張がおかしくなるよ。
278仕様書無しさん:05/01/05 06:06:54
>>271
> テストファーストの範囲は基本的にユニットテストだけだが、何か?

も、テストファーストをテストの話としているわけだし。
都合のいいようにテストファーストをテストの話にしたりテストの話ではないことにしたり、たまらんなぁ。
279仕様書無しさん:05/01/05 06:07:23
>277

>244-
(250)
280仕様書無しさん:05/01/05 06:09:24
>> 1.実装しようとする動作の検証テストを作る

テストファーストがテストの話ではないなら、どうしてここで「検証テストを作る」と出てくるんだ?
281仕様書無しさん:05/01/05 06:09:57
>278

だから テストはするけど、開発手法なんだっつーの
おまけにテストの観点が重要なのはもっともなんだけど、無くてもどうにかなるんだってば
282仕様書無しさん:05/01/05 06:11:20
>>281
なんか、支離滅裂だなぁ・・・。
テストはするけどテストの話ではないのか。
283281:05/01/05 06:12:48
>280

偶然だが >281 も >280 宛になるか
タイヤキが鯛とはあんまり関係ないってこと
(少しは関係するけど)
284281:05/01/05 06:13:36
>282

偶然だが ... (ry
285仕様書無しさん:05/01/05 06:15:12
鯛の形をした饅頭をタイヤキと呼ぶのと、検証テストを先に記述することをテストファーストと呼ぶのと、関係なさが全然違う。
ほんとにそういう認識なら、テストファースト自体を考え直したほうがいい。
286仕様書無しさん:05/01/05 08:09:19
>>281
> おまけにテストの観点が重要なのはもっともなんだけど、無くてもどうにかなるんだってば

どうにかされたほうにしてみればガクブルものだな。
287仕様書無しさん:05/01/05 09:07:31
>>244
>1.実装しようとする動作の検証テストを作る

っていうのが比較的高スキルな作業で、
経験3年くらいの人でも無指導で完璧にこなす人は割合的に少ないし、
半分くらいはザルに近いテストケースしか書けない。

っていう価値観は前提としてもOKだよね?
288204:05/01/05 10:14:31
保守ageして寝て起きたら乗り遅れた・・・orz
まああれだ。>>281ガクブルには同意だな。
結局テスト作るのは>>287くらいには難しいよな。
あとテストファーストはテストの話だよな。
それにユニットテスト以外のテストファーストもあるよな。
でももうどうでもいいよな。はは。は。
289仕様書無しさん:05/01/05 13:50:54
>>288
いや、乗り遅れて正解だったと思われ。
290仕様書無しさん:05/01/05 22:47:36
201からの流れがよーわからん。誰かまとめてくれ。
291仕様書無しさん:05/01/05 23:14:02
>201 お前の物は俺のもの発言
〜   ドラえもんに泣きつく
〜   秘密道具で復讐成功
〜   秘密道具がばれて>201に殴られる
>290 現在に至る
292仕様書無しさん:05/01/05 23:30:47
>>290
テストファーストはテストじゃない
--じゃあなに?
テストしてコーディングすること
--そのテストはちゃんとやんないといけないんじゃない?
テストファーストはテストじゃない
--じゃあなに?
テストしてコーディングすること
--そのテストはちゃんとやんないといけないんじゃない?
テストファーストはテストじゃない
--じゃあなに?
テストしてコーディングすること
--テストファーストはテストじゃないのにどうしてテストしてとなるの?
テストファーストとテストはタイヤキと鯛の関係だ
--あほちゃう?
293仕様書無しさん:05/01/05 23:37:11
わかりやすくて改修しやすくて分離可能で再利用しやすくしとけばいいんじゃないの

単純なことだろ  意味わかるよね。
294仕様書無しさん:05/01/05 23:38:01
おまいら、むつかしく考えすぎ。 単純なものをうまく組み合わせる ただそれだけでしょ。
295仕様書無しさん:05/01/05 23:44:50
急に流れが戻ったのは明け方の馬鹿が反省したから?
296仕様書無しさん:05/01/05 23:56:58
>>294
賢いな。シンプルイズベスト(←なぜか英語に変換されない)だな。
297仕様書無しさん:05/01/06 00:55:02
テストファーストとはテスト項目に重点をおいてコーディングを行う開発手法のこと。
テストを通ることを最優先して実装を行う。
モジュールの品質はテストによって保障されるが、
最初からテストを通ることを主目的にしているため、品質の確保がしやすい。

利点として
・テストケースにない機能は実装しないので
「将来発生するかもしれない」とか「仕様書にない機能」のような余分なことをしないので、
余計なバグの混入を防ぐ
・あらかじめテスト項目を作成するため、PGの頭の中でロジックが整理しやすい
などがある。

「テスト」とひとくくりにすると混同しやすいが、
「テスト工程をクリアしたら品質が保障される」ということを逆手にとって
「では最初からテスト工程を通ることを重視する」だけであり、
テスト工程でのテスト作業そのものを指すわけではない。
298仕様書無しさん:05/01/06 01:03:16
もちろんテスト作業の質を上げる工夫もされているが、
テスト作業(テストケースの作成、結果確認など)がタコなら品質は保証できない。
(これはアフターテストでも同じだが)

アジャイル開発などでは、コードの修正を行ったら回帰テストを全項目行うことを
推奨していたはず。全項目を確認しなおすことで、ソースに対する信頼性を
保障することが出来る。ただし、これを人手やるのは大変なので回帰テストの自動化が
求められている。
299仕様書無しさん:05/01/06 01:11:41
>>297>>298は何に対するレス?
300仕様書無しさん:05/01/06 02:30:44
テストファーストでやると1つのクラスに対して
テストコード→実装コード→テストコード→実装コードと
かなりの回数繰り返さないと質の高いテストを記述することができないのが問題

なぜなら実装コードを書く前からすべてのテストを記述することは非常に難しいから。
異常処理・例外の類などは特にね
301仕様書無しさん:05/01/06 03:51:53
俺が思うに「最初にテストケースを考える」ことこそ
テストファーストの真髄だと思うんだ。
(テストファーストを唱えてる人がどう思ってるか知らんけど)
そこで生まれたテストケースが貧弱かどうかは実はどうでもよくて
発想の転換でテストケースを濃くする事と
コード書く時に外部条件を意識して書くようにする事
要するに熟達したプログラマが普通にやってるこの2点を
システマチックにやる事で品質向上を狙うモノではないかと。
302仕様書無しさん:05/01/06 09:55:02
>>294
作るものが単純じゃないから、そう一筋縄にはいかないんだよ。
複雑なものを作るときに単純なものを組み合わせると、その組み合わせが単純ではなくなるから、全体として結局複雑になる。
そのとき、部分部分が単純なものでしかないと、複雑な組み合わせを追わないといけない。
そしたら、場合によっては複雑なものを単純に組み合わせたほうがよくなる。

単純なものを組み合わせるのがいいんだったら、アセンブリ最強ってことになるな。
303仕様書無しさん:05/01/06 14:30:41
つか、質の高いコード = テストファーストなの?
他の話題は無いのかよ、と。
早く話題変えないと、あと700レスで埋まっちゃうYO
304仕様書無しさん:05/01/06 20:06:52
>>302
RISCなんかは、アセンブリ最強と同じ発想で作られてんだが?
305仕様書無しさん:05/01/06 20:28:48
>>304
違うよ
306仕様書無しさん:05/01/06 20:48:58
>>305
バカ?
307仕様書無しさん:05/01/06 21:45:17
>>304
それはプログラマにとってじゃなくCPUにとってだと思われ。
308仕様書無しさん:05/01/06 23:21:51
>>303
テストファーストは要求を満たすシンプルなコーディングを促進するから、
あながちスレ違いとは言えない。でもやっぱりテストの話で、鯛の話じゃないよなぁ。
309仕様書無しさん:05/01/06 23:23:19
>>302
良く設計された単純なものを単純に組み合わせるという選択肢もある。
310仕様書無しさん:05/01/07 00:17:59
>>309
エントロピー保存の法則というものがあって、全体的な複雑さにはそれ以上単純にできない限界があるから、それは無理。
311310:05/01/07 00:27:45
×無理
○非常に難しいか、特別な場合に限られる
312仕様書無しさん:05/01/07 00:32:13
たとえば、GoogleのPageRankが行列の固有値を求めればいいだけになっているみたいに、理論をちゃんと構築すれば、プログラム自体は単純になるね。
その場合は、設計作業がページの重要度を行列の固有値問題に変換するという複雑な作業になっているので、全体の複雑さは保たれてるわけだ。
313仕様書無しさん:05/01/07 00:49:40
>>312
複雑さが1000だとして、
10×10×10 というバランスで進める開発と
2×20×25 というバランスで進める開発に優劣は無いって事?
そんなことないだろ。
314仕様書無しさん:05/01/07 01:19:59
>質の高いコーディングを身につける方法

質が高いと評価されるソースを作成するための技法習得
って事かな?
だとするとまず設計がきっちりできる事が要求される
いいかげんにてきとーに設計して作ったものの質が高いはずが無い
もっともそのためにはそもそも何を作ればよいかというレベルでの
要求分析(要件定義)がきっちりできている事が前提だが、、、
315仕様書無しさん:05/01/07 01:32:59
質の高いコーディングを身につける方法

それは

  早 寝 早 起 き



わかったらさっさと寝ろ。
316仕様書無しさん:05/01/07 01:38:16
>だとするとまず設計がきっちりできる事が要求される
>要求分析(要件定義)がきっちりできている事が前提だが、、、

…もういいよ。
317仕様書無しさん:05/01/07 01:41:16
その前に契約が(ry
318仕様書無しさん:05/01/07 01:53:06
1 :デフォルトの名無しさん :04/12/05 14:50:20
良いコードを書きたいです。でも、書けないです。
良いコードを読めばよいと聞きますが、どれがよいコードなのか分かりません。
長くないけど、良いコードと悪いコードを比較して、わかり易く教えてください。
デザインパターン適用するといいと聞きますが、どれだけいいのか分かりません。
異常処理書くと汚くなってしまいます。
例外処理はtry{}catch(Exception e){}としてしまいます。
言語や環境、職場によって良いとされる書き方は変わります。
例えば、携帯Javaは容量を少なくするコードが良くなります。
スピードを徹底的に重視すれば、オブジェクト指向は邪魔なだけです。
関数型言語では、再帰呼び出しを使うのが上等です。
コードリーディングとか、達人プログラマーとか、
本買って読むといいらしいけど、お金ないし、
買いに行くのめんどくさいし、ウェブで見たいです。
そういうサイトつくりたいけど、頭悪くて作れません。
てことで、まとめWiki作って、勝手に書き込んで欲しいです。
トヨタ式的なものがソフトウェア産業でできてないと言うし悔しいです。
てことで、良いプログラムを書くためのやり方、良いソースの書き方を議論して、
最強のソフトウェア開発方法をまとめてください。
319仕様書無しさん:05/01/07 01:56:55
コードを書くことは目的ではなく手段なのだ。
と言ったら煽りかのぅ
320仕様書無しさん:05/01/07 02:05:55
321 :デフォルトの名無しさん :05/01/04 19:12:06
これまでの成果
---
・公開されているよいソースコードを読むとよい
・assert文を使うとよい
・よい本を読むとよい
・コード量が少なくなるようにする
・メソッドの数をできるだけ少なくする
・クラスはできるだけ作らないようにする?
・リファクタリングする
・素早く頭働かす?
・メンタルの健康を保つ?
・ネストはできるだけ下げないようにする?
・変更履歴にはwhat i didではなく why i did itを書け?
---

この先続けてもたいした成果は得られないような…


321仕様書無しさん:05/01/07 02:27:19
昔、とんでもなく品質の悪いプログラムのメンテ引き継ぐことになった。
そのソフトは実際に運用が続けられているものだったから、当然仕様変更の要求がくる。
しかし、ほんの少し処理の流れを変えるだけで、不具合がボロボロと・・・
こんなプログラムに丸一年ほど付き合わされて、どうしたら保守性のいいプログラムに
なるのか真剣に考えるようになり、ソフトウェア工学の本とか、論文とかを読みあさり、
ソフトウェア開発において、ソースコードの質というものを意識するようになった。

こういう人って結構いるのでは?
322仕様書無しさん:05/01/07 02:55:29
>昔、とんでもなく品質の悪いプログラムのメンテ引き継ぐことになった。

んで結論は 品質=保守性 なのか?
質の高いコーディングとは メンテナンスしやすいコードを書くということなのか
323仕様書無しさん:05/01/07 08:18:26
>>310
309ではないが、
そんな物理法則を持ち出されてもな。
それにその単純さの限界を示さなで無理と一言で片付けられてもな。
324323:05/01/07 08:19:51
すまん。
>>311で無理という部分は訂正されていたな。
325仕様書無しさん:05/01/07 10:15:55
>>313
複雑さ10のクラスが100あるのと、複雑さ100のクラスが10あるのとあって、全体的な複雑さが一緒だとするね。
クラスが100あると追うときにあちこち飛ぶことになるけど、複雑さ100のクラスは同じところに記述されているから追うのが楽。

ってことが考えられる。
優劣がないわけじゃなくて、優劣はあるけど場合によるから一概に言えないということ。
326仕様書無しさん:05/01/07 10:29:27
>>323
物理法則じゃなくて、ここでは情報の法則ね。エントロピーは平均情報量のこと。

複雑さは一定っていうことは頭に置いておいた方がいいと思う。
じゃないと、無邪気に目に見えるところだけ単純化して、目に見えないところに追いやられた複雑さに足をとられることになる。
327仕様書無しさん:05/01/07 10:46:07
いや、エントロピーの法則って、熱力学第二法則をソフトウェア工学に転用したものだろ?

「エントロピーは増大する。」

この場合、エントロピー自体が複雑さ、というか乱雑さを表す。もっと具体的にいうと部分部分で
きっちり分かれていたものが、だんだんと混ざり合って均等になってしまうということ。

転じて、ソフトウェアも改変を重ねるうちに、だんだんぐちゃぐちゃに崩れ去っていってしまう
ことは避けられない、ということを指す。
328仕様書無しさん:05/01/07 11:01:02
ソフトウェア工学以前に情報理論の根幹やん>エントロピ
「bit」の定義とかとも関係深いし。
329仕様書無しさん:05/01/07 11:03:04
>>327
少なくともソフトウェア工学にはそういうのはないと思うが・・・。
情報工学の情報量の話。

で、それは改変というエネルギーを与えるとエントロピーが増大するという話だから、とりあえず今の話題とは関係ないよ。
330仕様書無しさん:05/01/07 11:08:51
ソースコードのエントロピーという考え方は面白いな

ただ、質の高いコーディングっていうのは、保守とか可読性とかが重視されて
冗長な部分があった方がいいと思うので、エントロピーでは全く測れないと思う

コピペばっかりだと、エントロピーが、ある特定の値以上になるだろうから
その辺を統計とって、判断するのには、使えるだろうけど。
331仕様書無しさん:05/01/07 11:14:56
>>330
コピペは情報量をふやさないよ。
だって、コピペには、オリジナルの部分を除けば、コピペされているという情報程度しかないからね。

で、話題的には、目に見えるところだけ単純にしても、結局それはどこかに複雑さを追いやっただけだよ、って話がしたかったわけさ。
だから、保守とか可読性を考えると、一部分だけ複雑にしておいて、コード上に分散させないほうがいいこともある、って言いたかった。
332仕様書無しさん:05/01/07 11:22:13
>>331
エントロピーの基礎を勉強した方が良いと思われ
333仕様書無しさん:05/01/07 11:23:36
設計書こねくりまわして「きれいな設計」して、コードが単純になったとしても、その設計がなんのことかわからなくなることがあるから、素直に複雑なままコーディングしたほうがいいってこともある。
難しい設計や難しい数式より、難しいコードの方が追いやすい。
334仕様書無しさん:05/01/07 11:24:47
>>332
そちらこそ。
335仕様書無しさん:05/01/07 12:08:06
イキの良い新人君って綺麗で効率よくてカッコイイコードを書こうとして
意図してか無意識にか知らんが仕様の一部を勝手に無視してくれることがあって
出来てきたものが使えんこともしばしば
新人教育の第一歩がこのへんの矯正になることが少なくない
336仕様書無しさん:05/01/07 12:25:59
リファクタリングしまくったらクラス爆発した。
しかも命名規則が糞だから機能追いにくい。

とか、

JSPなんて追いきれねーよ。

とか。

漏れはjavaにおいてはeclipseの登場以降 xml や JSP はソースコードの可読性を
下げるだけの存在だと感じている。

どうよ?
337仕様書無しさん:05/01/07 12:58:25
>漏れはjavaにおいてはeclipseの登場以降 xml や JSP はソースコードの可読性を
>下げるだけの存在だと感じている。

>>336 具体的にはどういうこと?
338仕様書無しさん:05/01/07 13:14:17
バカとハサミは使いよう。
339仕様書無しさん:05/01/07 18:55:24
保守性たったの5か・・・ゴミめ
340仕様書無しさん:05/01/07 19:17:21
>>339
要AA
341仕様書無しさん:05/01/07 22:23:06
それって道具に使われる人?
342仕様書無しさん:05/01/07 22:39:49
>>333
>難しい設計や難しい数式より、難しいコードの方が追いやすい。

俺は簡単な設計の簡単なコードの方が追いやすいと思うけど。
343仕様書無しさん:05/01/07 23:03:32
>>342
流れ嫁
簡単なシステムが追いやすいのは当たり前。
344仕様書無しさん:05/01/07 23:40:45
>>343
複雑さの限界を前提にしてる時点でズレてるんじゃないかと思って。
そもそも神の創造する最高にシンプルな設計・コードを100%として、
人類が現在到達しているレベルは30%に満たないくらいだとは思えないか。
ましてやお前等なんて10%に到達してるかどうか。

って考えると、複雑さに対する諦めよりも、
よりシンプルさ(可読性も高く初心者でも理解可能なほどの単純さ)
を目指す方が現実的ではないかと思う。次第です。
345仕様書無しさん:05/01/08 00:55:15
346仕様書無しさん:05/01/08 01:43:11
質が高いとは、バグが少ないことと、メンテナンスしやすいことだと
言い換えることができる
347仕様書無しさん:05/01/08 02:26:19
つーか、メソッドやクラスを分割しまくると、コーディング能力に
ネーミングセンスという新しいセンスが要求されるようになる
348仕様書無しさん:05/01/08 02:29:55
単純なメソッド分割は、賢いコメント以上の意味はないしな。
349仕様書無しさん:05/01/09 10:21:18
350仕様書無しさん:05/01/09 14:19:01
>>349
つまり、複雑さとか情報量とかの意味がわからないってことね。
351仕様書無しさん:05/01/09 15:26:31
>>350
頭痛が痛い
頭痛がする

どちらが複雑な文章ですか?
どちらの情報量が多いですか?
352仕様書無しさん:05/01/09 16:46:26
>>351
「頭痛が痛い」の方が、「痛」が2回含まれてるので情報量が低い。

情報量って、意味わかってる?
353仕様書無しさん:05/01/09 16:54:50
「頭痛がする」はすべて違う文字なので、情報量が高く「頭痛が痛い」より複雑。

なんの前提条件もあたえられず情報量とか複雑さとかを判定するなら、こうなる。
354仕様書無しさん:05/01/09 18:58:27
>>352-353
へーそういう考え方なんだ。知らなかった。
質の高いコーディングとは無関係だとは気付かずマジレスしちゃったよ。
355仕様書無しさん:05/01/09 19:21:48
>>354
>>351の文章が質の高いコーディングと無関係なだけだな。
356仕様書無しさん:05/01/09 19:33:12
>>355
日本語としての情報量は同じだけど、上の方が文法的に複雑。
こっちの方がだいぶ近いと思うんだけど。
357仕様書無しさん:05/01/09 19:50:08
>>356
頭痛が痛いのはあたりまえなので、ことばとしての情報量もない。
文法的に複雑というのも意味不明。
そして質の高いコーディングと無関係。
358仕様書無しさん:05/01/09 20:09:21
>>344
情報量とかエントロピーとか複雑さとかの関係をしらないで、単純にそういうことを夢見てたら、目に見えにくい複雑さに足すくわれるよ。
359仕様書無しさん:05/01/09 21:48:32
>>356
複雑以前に不具合だろ。
360仕様書無しさん:05/01/09 22:02:21
>>359
意味が変わるわけじゃないから不具合じゃないだろ。
1処理で同じチェック2回しても不具合じゃない。2回目が意味無いだけで。
ただし品質は低いという。
361仕様書無しさん:05/01/09 22:12:22
>>360
推奨された文法じゃないけどね。
362仕様書無しさん:05/01/10 00:03:34
>品質は低い

別に品質には影響ないだろ?保守性が悪いけど
363仕様書無しさん:05/01/10 01:58:23
>>362
保守性も品質だよ。
364仕様書無しさん:05/01/10 12:42:10
>>363
保守性を品質に入れるかは微妙だな。
評価対象にするとして、保守性なんてどうやって数値化するんだろう?
評価できない性質を品質の対象に入れていいんだろうか?
365仕様書無しさん:05/01/10 13:17:52
>>364
逆に評価出来る品質って何ですか?
366仕様書無しさん:05/01/10 15:10:34
>>365
ISOのなんちゃら
367仕様書無しさん:05/01/10 15:47:53
ソフトウェアの品質として定義されたものといえば、ISO9126ってことになるな。
ttp://www.cam.hi-ho.ne.jp/adamosute/kyotu/iso9126.htm
368仕様書無しさん:05/01/10 16:31:35
>>367
保守性おもくそ入っとるやん
369仕様書無しさん:05/01/10 16:52:18
つか、今フリーで入手できるソースコードのうち
喪前等が質の高いコードだと思ってるのって、どれよ?

それを議論すれば、答えにたどり着けると思われ
370仕様書無しさん:05/01/10 17:05:46
>>368
定義見たけど、これって変更するときとか障害が発生したときに
初めてわかる項目だよね?
ISOの定義はおいとくとして、客先に納入するときに保守性の保障なんて
どうやってやるんだろう?
37169式フリーPG ◆hND3Lufios :05/01/10 17:05:54
保守性は重要だけど、保守性を一般化するのは難しい。

分割の上手く取れているコードは読みやすいが、仕様変更の要求が当初の
設計で分割した境界線を跨ぐ形だと、それは大幅な仕様変更を要求される。
372仕様書無しさん:05/01/10 17:57:02
ここの文章を見ればわかるけど、ここに挙げられたすべてをソフトウェアの品質として採用する必要はなくて、必要に応じて取捨選択しろ、と。
保守性が重要になるなら、保守性もソフトウェアの品質として考慮せよ、と。
重要にならないなら、考慮する必要はなし、と。

>>369
それは、そのフリーウェアの分野のその機能のその規模のコードでの基準にしかならないよ。
373仕様書無しさん:05/01/10 20:14:20
>1の言う 質の高い...って
a.品質の高いソース
b.品質の高いソースを作るコーディング方法
で言うところの b. だろ?
b.の話はテストファースト以外に何かでた?サルサファースト?w
374仕様書無しさん:05/01/10 20:25:23
    |:::::::::::::::::::/ ̄ヽ::::::::::::::::::::::::::::::::::::::::::::::::::\
    |/ヽ:::::/      |:::::::::::::::::::::::::::::::::::::::::::::::::::::::\
    |   V       |:::::::::::::::::::::::::::::::::::/ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄
   ノ   l  ___ <, ---、::::::::::::::::::::| しょうがねぇな。
   ヾ=。'l`| cロ ュ   T   : 日|:::::::::::::::::::| お前等のコードをスカウターでテストしてやるよ
  ∠,「 ラ ヽ__√ ̄| : 日|:::::::::::::::<  相当質が高いはずだポチッ
  /::::|く、  _,、     `ー、‐'::::::::::::::::::::|  キロあたりのバグが・・10・・20・・30・・40・・50・・バ・・バカな!
∠-::::::::l、  ̄       //   \:::::::::::::::::::|  まだあがっていく!?
 /__ ,\    //     `ー--二\________
 / / / / ヽ-‐ /   __      // |  |  |
 | |  | l、  ̄ー' ̄ ̄ ̄____//  |  |  |
375仕様書無しさん:05/01/10 20:31:50
>キロあたり
グラムですか?
376仕様書無しさん:05/01/10 20:34:02
>>373
テストファーストに則ればまずaを議論すべきだな。
377仕様書無しさん:05/01/10 20:35:58
>373
ぺよんじゅんさまアプログラミングとか?
37869式フリーPG ◆hND3Lufios :05/01/10 20:38:08
保守性を問うなら読みやすさ、理解しやすさまでだね。
改造しやすさとなると、その要求次第になる。
379仕様書無しさん:05/01/10 21:23:39
>>375
印刷した紙の1kgあたりのバグだよ。
380仕様書無しさん:05/01/10 22:50:41
>>378
汎用性かシンプルデザインか、みたいな議論もあるぞ。
381仕様書無しさん:05/01/10 23:02:48
質が高いとは、バグが少ないことと、メンテナンスしやすいことだと
言い換えることができる
382仕様書無しさん:05/01/10 23:07:24
>>375
どう考えてもマ板ではkbだろ。
こういうボケの幼稚さからしても漏れはこの板の品質の低さほうが心配だよ。
383仕様書無しさん:05/01/10 23:07:30
勝手に言い換えると>>367あたりの立場がなくなってくるぞ。
384仕様書無しさん:05/01/10 23:08:33
>>382
釣りだろうがライン数だろ。
385仕様書無しさん:05/01/10 23:25:11
>ライン数

前時代の方でつね ライナー
386仕様書無しさん:05/01/10 23:34:11
ライン数なんて信じられんね。
ステップ数だろ。
387仕様書無しさん:05/01/10 23:36:01
まあ、質をどう定義したところで、質が高いプログラム書くやつの品質は高いし、質が低いプログラム書くやつの品質は低い。
388仕様書無しさん:05/01/10 23:42:40
で、質の高いプログラム書くには?
389仕様書無しさん:05/01/11 00:03:21
ちがうよ、質の高いコーディングのスレだよ。
例えば上質なコーヒーを嗜みながらとか。
390仕様書無しさん:05/01/11 00:06:21
あ、そういうことか。
マッサージイスで休憩を取りながら、コーディングを行うとか。
充分な睡眠は大事だぁね。
391仕様書無しさん:05/01/11 00:06:46
>>388
賢い親を持つ。
392仕様書無しさん:05/01/11 00:08:48
>389

だからサルサファーストだって一店のw
393仕様書無しさん:05/01/11 00:51:55
質の高い環境によって、質の高い仕事が生まれる
394仕様書無しさん:05/01/11 00:59:14
業務系じゃないことだけは確かだな。
395仕様書無しさん:05/01/11 01:07:56
>>393
つまり自分のせいじゃなく環境のせいだと
396仕様書無しさん:05/01/11 01:54:08
 快適な環境づくりは、安全、衛生、利便などの確保はもちろんとして、
さらに人々にやすらぎやうるおいを感じさせるような環境づくりである。
このようなより質の高い環境が形成されることにより人々はより一層
環境との触れ合いを深め、環境の恵み豊かなことを実感するであろう。
それは今後においても人々の共通の目標となり得るものである。
397仕様書無しさん:05/01/11 02:02:20
綺麗なお姉さんがいると、俄然やる気が増す。
398仕様書無しさん:05/01/11 02:04:22
>>397
ヤル気しか起きない癖に。
399仕様書無しさん:05/01/11 02:06:43
いえ、くどく勇気は無いので、愛想笑いと妄想レイプだけです。
400仕様書無しさん:05/01/11 02:17:02
コーディングに集中してるところに
「ねぇプログラミングなんて止めて、エッチしようよぉ」と
美人の先輩
後ろから手コキなんてどうだろうか?
401仕様書無しさん:05/01/11 02:21:55
>>400
妄想乙
402仕様書無しさん:05/01/11 02:26:03
いや机の下にもぐりこんでもらってフェ(ry
40369式フリーPG ◆hND3Lufios :05/01/11 02:41:07
中田(ry
404仕様書無しさん:05/01/11 03:00:16
>>403
ま た 、かよっ!
405仕様書無しさん:05/01/11 03:15:58
綺麗なお姉さんでやる気が増す
  ↓
やる気がヤル気に
  ↓
効率落ちる
  ↓
綺麗なお姉さんの手こきで解消
  ↓
効率あがる
  ↓
やる気がヤル気に
  ↓
繰り返し

マッチポンプか。
406仕様書無しさん:05/01/11 21:43:36
手コキの後は確実に効率落ちると思うが。
407仕様書無しさん:05/01/11 22:08:51
いきなり話を戻すと体調って大事だよな。
深夜にセックスした翌日の午前は確実に何も出来ない。
だから最近晩飯前にセックスしたりする。
お前等もやってみれ。翌日コーディングの質が全然違うぞ。
408仕様書無しさん:05/01/11 22:41:23
コーディングの質より、晩飯の質を確保したい。
409仕様書無しさん:05/01/11 23:00:23
低炭水化物ダイエットの心持ちで。
410仕様書無しさん:05/01/12 03:07:52
コーディングの際にはエラー原因を指摘するとともに推奨修正コードを表示し、
ワンクリックで自動的にコードを修正する機能や、「スニペット」と呼ばれる目的別の
入力支援機能などにより「極力自動化することで、品質の高いコーディングが可能になる」
411仕様書無しさん:05/01/12 03:57:40
のなら苦労はないねぇ。
412仕様書無しさん:05/01/12 10:33:38
プログラムするプログラム。
人類永遠の夢だな。
413仕様書無しさん:05/01/12 10:43:19
プログラムを作るプログラムにもバグがある訳で。
414仕様書無しさん:05/01/12 16:18:24
形式的記述からプログラムを自動作成したら、形式的記述どおりのプログラムは自動作成されていたけど、形式的記述自体にバグがあった、という話ですね。
415仕様書無しさん:05/01/12 19:10:49
>>414
分かりにくくなったぞ。
言うなら質が下がったぞ。
416仕様書無しさん:05/01/12 23:23:17
>>415
形式的記述を勉強してください。
417仕様書無しさん:05/01/12 23:59:08
>>416
形式的記述=プログラム と置き換えてしまうと、
形式的記述でないプログラムが含まれない事になる。

つまり不適切な拡張は価値を付加するどころか低下させるという典型例って事だ。
418仕様書無しさん:05/01/13 15:03:11
>>417
> 形式的記述=プログラム と置き換えてしまうと、
> 形式的記述でないプログラムが含まれない事になる。

形式的記述で全部書けばいいだけでは?
あとの文章につながってないような・・・
419仕様書無しさん:05/01/13 22:50:24
>>418
あとの文章の意図を分かりやすく言い換えると、
>>413>>414に言い換えたら文章の価値が下がった」
ってこと。そうなると、

>形式的記述で全部書けばいいだけでは?
というアプローチは文章の責任を緩和しただけで、
文章の価値を高める提案ではない。
420仕様書無しさん:05/01/14 00:27:57
>>419
ということは、つまり、417はもともと意味の通りにくい文章だったと。
421仕様書無しさん:05/01/14 23:00:30
>>420
通常は容易に推測可能で特に問題無い文章だと思われます。
ただし>>418は論理的でなく、>>417を攻撃とみなして、反撃に出ようという意図が感じられたので、
直接的で紛れの無い表現に切り替えることで、こちらも体勢を整えたわけです。
422仕様書無しさん:05/01/15 00:05:44
>>421
仮想敵を脳内で構築した、と。
423仕様書無しさん:05/01/17 20:44:34
デザインパターンとかは?
424仕様書無しさん:05/01/17 22:47:33
後で[パターン]に直す事はあるが、最初から[パターン]にしようとして作ってはダメだ
本末転倒
425仕様書無しさん:05/01/17 23:07:40
オブジェクト指向ちゃんとやれば品質高いっぽいですね。
426仕様書無しさん:05/01/17 23:25:48
>>424
最初からデザインパターンを使ってできるものは、最初からパターンにしろ。
それこそ本末転倒。

>>423
デザインパターンは、それを使ったからといってコードの質が高くなるもんでもない。
意味なく使えば、わけわからなくなって質が悪くだけだ。

>>425
オブジェクト指向は、「ちゃんと」やったり「ちゃんと」やらなかったりするもんじゃないし。
オブジェクト指向に属する方法論というなら話は別だろうけど。
そもそもオブジェクト指向は「やる」もんじゃないよ。
それと、オブジェクト指向も必要ないところで使えば複雑にするだけ。

「ちゃんとやれば」という話であれば、質が高くやるようにすることを「ちゃんとやる」というんだろうから、それもまた意味のない話で。
427仕様書無しさん:05/01/17 23:37:17
デザインパターンは、変な強迫観念を植え付けることがあるから嫌いだなぁ。
品質をあげる方策として話すのはね。
オブジェクトを一つしか作ることがないからといって、いつでもそれを保証する必要があるわけじゃないのに、シングルトンにしないといけないというような。
428仕様書無しさん:05/01/17 23:52:48
デザインパターンは、設計のライブラリみたいなもんで、これがやりたければこういう設計にしろっていうパターンのカタログだぞ。
API使ったら質が上がるわけじゃないように、デザインパターン使ったら質が上がるわけじゃない。
429仕様書無しさん:05/01/18 00:29:32
「将来こういう風に使われる可能性があるからこう作っておく」
の将来が、10年先なら無理にデザインパターンを適用する必要は無い。
1年先なら…、納期や手間を考えて、余裕があるならすべきだな。
430仕様書無しさん:05/01/18 00:36:15
>>427>>429は本質的に理解してないような・・・
431仕様書無しさん:05/01/18 01:01:06

その本質を提示できない>>430も本質を理解できていない。
432仕様書無しさん:05/01/18 02:57:22
>>429
今要らないなら、要らない。
433仕様書無しさん:05/01/18 22:45:25
YAGNIか。
434仕様書無しさん:05/01/18 23:08:12
YAGNIはYAGNIで変に誤解して、設計はあとまわしにすることだと思うやつがいるからなぁ。
>>424みたいに。
435仕様書無しさん:05/01/18 23:34:31
パターンが冗長なら使わないのがYAGNIでしょ。
>>434はパターン使えば設計OKみたいな思想なの?
436仕様書無しさん:05/01/19 00:09:32
>>435
なんでそうつながるかわからんのだが。
パターン使えば設計OKだとは思わないが、パターンを使う設計はOKだと思う。

>>424は、最初からパターン使ってもだめだと書いてる。少なくとも、そう読める。
冗長なら使わない、を、冗長じゃなくても使わない、後回し、みたいな感じにとってるように思える。
437仕様書無しさん:05/01/19 00:27:17
つーかよ、ここの実装をどうするればいいかな〜とか考えたら
自然とデザインパターンと同様のパターンになったりするだろ?

そこまでたどり着かないなら、もともとデザインパターン適用するほどの
問題を含んでない処理だったり、実装者が無能だったりするんだが。
438仕様書無しさん:05/01/19 02:18:35
基本的なパターン技術を学んだ人間にとって、新しい技術に適応するのは比較的容易
439仕様書無しさん:05/01/19 02:25:13
パターン
主流の技術が何度も何度も移り変わっていく中で、基本的な共通のデザイン
440仕様書無しさん:05/01/19 02:53:08
/ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄
| 必要に迫られてからオブジェクトを作るパターンですな。

   ̄ ̄ ̄|/ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄
  ∧_∧       / ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄
  ( ・∀・)  ∧ ∧ < それは、Virtual Proxyの一種ですね…
 (     )  (;゚Д゚)  \____________
 ̄ ̄ ̄ ̄ ̄ (つ_つ__
 ̄ ̄ ̄日∇ ̄\| BIBLO |\
       ̄   =======  \

/ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄
| 納期が迫ってからコーディングせよ、と。

   ̄ ̄ ̄|/ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄
  ∧_∧       / ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄
  ( ・∀・)  ∧ ∧ < ソンナコト言ってないでしょ!!
 (  ⊃ )  (゚Д゚;)  \____________
 ̄ ̄ ̄ ̄ ̄ (つ_つ__
 ̄ ̄ ̄日∇ ̄\| BIBLO |\
       ̄   =======  \
441仕様書無しさん:05/01/19 10:52:59
>>436
日本語読解能力が無いんじゃね?
442仕様書無しさん:05/01/20 00:49:32
>>441
それでは、「最初から[パターン]にしようとして作ってはダメだ」という理由を説明してくださいな。
どうして最初からパターンにしようとして作っちゃダメなのか。
テンプレートパターンにすれば解決できるとわかっても、テンプレートパターンにしようとしてはダメなのか。
443仕様書無しさん:05/01/20 01:09:57
使えそうなデザインパターンを何でも使おうという誘惑に抵抗しなければ
ならない

たまに、2階建ての普通の住宅に立派なエスカレータを付けてしまうような
設計(もちろん比喩)を見かけることがある
「何故?」と聞くと「デザイン・パターンの本に載っていたので」
なんていう答えが返ってきたりする
444仕様書無しさん:05/01/20 02:35:28
>>443
別に、デザインパターンの用途通りに使う分には構わないんではないかと。
乱用がダメなのは、なんでも一緒。
445仕様書無しさん:05/01/25 15:00:59
アルゴリズム,文法,オブジェクト指向と理解していけば,ライブラリを利
用して,ある程度のオブジェクト指向プログラムは作れるようになります。
しかし「こういうアプリケーションを作る」と具体的に決めて,必要なコード
がサッと出てくるようになるには,やはり「経験」が必要です。

この経験を効率よく取得する方法が「デザインパターン」で,定番の解説書
である「オブジェクト指向における再利用のためのデザインパターン(著者
4人をthe Gang of Four,同書のことをGoF本と呼ぶことが多い)」の23の
パターンがよく知られています。同書は,ソースコードではなく設計や考え
方を再利用するためのもので,経験豊富なプログラマの設計がカタログ化
されています。

未経験の状態から闇雲にクラスを考えるのではなく,優れたデザインパターン
をお手本にすることで,多くの経験者から助言を得たのと同じ効果が得られます。
446仕様書無しさん:05/01/25 15:02:43
ソフトウェアテストは開発に比べて、地味で低いレベルのスキルだと思われています。
しかし開発力が高いエンジニアはテストも達者だ、というのも事実です。テストの
スキルは、地味な確認作業の積み重ねではなく、開発力を表す指標に他なりません。
「テスト道」を極めていくと、そもそもバグを作り込まない開発に近づいていくのです。
447仕様書無しさん
>>445
未経験の状態から闇雲にデザインパターンの利用を考えるのではなく,
優れたデザインパターンの利用をお手本にすることで,
多くの経験者から助言を得たのと同じ効果を得る必要があります。