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

>どのようにテストすればよいかという点を欠いたままの今のテストファーストではバグは減りません。

減らない？
増えないが正解だ

どこから引用してきたんだろう・・・・
ま、考えなく書きやすいところだけユニットテスト書いてテストしたつもりになっても、普通に動作確認で気づくような不具合しか対処できないってことじゃないかな。
テストファーストしないときにバグとして報告されていたものに関しては、相変わらずテストされずバグとして報告される、と。

？？？
テストファーストってやったりやらかったりすんの？ありえねー
ってゆーか意味無いじゃん

>>201
やっぱり「減らない」の方が適切だよね？「増えない」は語弊がありそう。
バグをテスト段階での発生件数として論じたいのかもしれないけど、
そもそもがバグ減らすのが目的だし、発見→修正　でバグ減るわけだし。

>204
>やっぱり「減らない」の方が適切

んなわきゃねー

>>203
全部できてるつもりになってるの？
そっちの方が怖い。

できたりできなかったりするのが、特別なプロセスや個人の能力なしにはありえないことをわかってないのも怖いな。

>206
>全部できてる

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

(もっともGUIとかはテストファースト対象外だけどね。その話を一点のかな)

>>208
だから、それで保証できるのはとりあえずテストがあるということだけで、全部テストできたことにはつながらんでしょ。
テストファーストでテスト書いたら、全部テストできたつもりになるのが怖い。

>209

もまえユニットテストとその上位のテストをごっちゃに考えてないか？
そもそもテストファーストはユニットを作るときの手法であってテスト手法ではない

>>210
ということは、藻前の意見は、>>201から続く今の流れとは関係ないってことだな。
テストファーストはユニットを作るときの手法であってテスト手法ではないのに、テストしたつもりになっていては工程の終盤以降に報告されるバグは減らない、ってことじゃないのか？

とりあえずテストファーストしとけば「増えない」んだって話じゃねーのか？
そもそもテスト手法ではないんだってば

「どのようにテストすればよいかという点を欠いたままの今のテストファーストではバグは増えません。」
説明なしで意図どおりに解釈できる文章ではないと思うが。

>>212
いまは、テストファーストがテスト手法かどうかという話をしてるのではなくて、テストファーストをすることでテストをした気になって妥当なテストが行われないことがあるんじゃないのかって話だよ。

もまえバカか？
あえて書けば

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

だ

>>212
テストファーストがテスト手法ではないなら、とりあえずテストファーストするだけならバグは増えも減りもしないね。

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

ただ意味がない文章にしただけじゃないか。
減らないというのが論点なんだろ。

「コーディング前にサルサを踊っても、バグは増えません」
と同じレベルの文章にしただけだね。

>214
だからテストファーストは 減らすって観点ではなくて
増やさないって観点だろって事

>>215
だから、テストファーストでテストした気になって妥当なテストが行われないということが起きる可能性があるということを話してんじゃねぇの？

>>219
デグレードしないってこと？
それはただ論点をずらしただけだろ。
それに、テストファーストがテスト手法ではなくて妥当なテストが行われていなければ、デグレードも起きうるよ。

テストファーストしただけで、デグレードが起きないっていいたいの？
すごく危険な妄想だと思うけど。

>デグレード
まぁそういう観点もあるが、とりあえず今の話の流れとは違う

コーディング時に埋め込まれてしまう類のバグを増やさない、って話だよ
例えば複数のユニットが絡み合う動作時の不具合などはほとんど関係ない
だからこっちは減らない

>>223
じゃあ、増えないともいえないよ。
コーディング時に埋め込まれてしまう類のバグを増やさないためには、ただテストファーストしただけではだめで、どのようにテストするかという観点が必要だと思うが。

いやどのようにって観点がなくても増えないよ
テストケースにパスするだけのコーディングしかしないんだから

それに、「バグが増えない」という話は、>>218のようなサルサファーストでもバグはいままでどおりで増えないわけだし、意味がない。

サルサファーストだと疲れちゃってケアレスミスが増えるかもw

>>225
そのテストケースの中身が問題なんだろって。

>>227
コーディング始めるたびに、あっちこっちでサルサが踊られる様子を想像してみろ。
なごむぞ。

テストファーストはコストがかかるので、バグが減るっていう効果がないならやらないほうがいい。
アフターテストが不要になるわけではないし、それなら、普通にテストアフターだけやったほうがいい。

実装を先に書いてからテストを書く場合テストの完全性を保障することは困難です

テストを先に書いたとしても
テストが不足していることを発見することが難しいですけど

>>231
テストを先に書くにしても、どのようにテストするかという観点がなければ、完全なテストに近づくことはできないと思うが。

>230

後が違ってくる
デグレいわゆるエンバグが無かった事を確認汁！とかで

それも、テストファーストでバグが減るって効果がないときには役に立たんよ。
その場合は、ふつうにアフターテストだけ繰り返した方が、コスト的に安くつく。

くれぐれも言っておくけど、どのようにテストするかという観点なしに、ザルのようなテストケースかいた場合だよ。

ザルのようなテストケースで、デグレードしたときによく見られるようなちょっとむずかしめのバグが発見できるとも思えないし。
デグレードって、なんか必要な条件を忘れたときに起きることが多いからね。
どのようにテストするかという観点なしに書いたテストでは、その条件をテストしてないことが大いにありうる。

>235

デグレの発見でもアフターテストの方が安くつく？ありえねー
アフターテストで見つかるバグとテストファーストで予防されるバグは異なるんだって

>デグレードって、なんか必要な条件を忘れたときに起きる

それはデグレードとは言わないな。単なる新しいバグ埋め込みでそ。
いじってないと思っている箇所の動作がおかしくなるのがデグレだよ。

>>237
だから、テストファーストで書いたテストケースがザルでバグが予防できてない場合だって書いてるでしょ。

>>238
いじってないと思ってる箇所があるということは、必要な条件を忘れたことにはならんのか？

テストファーストって、仕様書からテスト項目を作成しようってぐらいの事と
思ってた。
コードを基にテストしちゃアカンって事と。

テスト項目をプログラム言語で書くとにより、テストの実施・結果にブレを
出さないって手法は、よくテストファーストで用いられるが、テストファー
ストの概念そのものとは関係ないかなと思う。
だがら、>>216氏が言ってるように、テストファーストでもバグは増えも減り
もしないと思う。

いじってないと思っている、のは追加修正とは関係ない箇所の意味です。

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

もっとも"手を入れる必要がある箇所の洗い出しが不十分である"場合は
デグレードではありませんけど

いじったところとは関係ないと思ってたのに関係あったってことだろ。
そこを関係があることを考慮するというのは、必要な条件であって、それを忘れたのだったら必要な条件を忘れている。
どこがどこと関係あるか把握できない不思議なプログラムを書いてるってんなら別だけどね。
その場合は、テストうんぬん以前に考えることがあると思う。

"テストファースト"って
1.実装しようとする動作の検証テストを作る
2.そのケースに合格する実装を行う
って事なんだけど
その"テストケースがざる"とか言ってる意味がわかんないな
実装しようと思っていないテストを作るって事？

>243
だからそれはデグレードではないってw

> 1.実装しようとする動作の検証テストを作る

このときに、どのようにテストするかという観点なしにテストを書いたらテストケースがザルになるだろ。

それはどこの定義なんだ？

つうか、どんな経過でバグ修正のときに別のバグが埋め込まれたとしても、それはデグレードだと思うのだが。

まあ、ここでデグレード談義しても意味がないので、今までのデグレードはエンバグにしておいてくれ。

>246
>どのようにテストする

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

世の中きみのように頭がよくいつでも完璧な仕事ができるやつばかりじゃないし、実装したいことを思い浮かべただけで妥当なテストケースが書けるような単純な処理ばかりではない。

テストファーストさえすれば、いつでもだれでも自然に妥当なテストケースが書けると思ってるんなら、それはそれで危険だな。

テスト項目が全てパスする絵をみてしまうと作業が完璧なのだと勘違いしてしまう罠

>251
それは逆じゃないか？
テストケースなしに妥当な実装できるのが
頭が良い香具師か単純な処理という事では？

>>254
どっちにしろ妥当な実装するには頭がいいか単純な処理である必要がある、という結論になってもいいですか？

スレの流れとは関係ないけど
以前は動作していた機能が動かなくなること、がデグレードだと思う
そういう意味で新たにバグを埋め込む事とイコールではない希ガス
(たとえ直接のデグレード原因がそのバグであったとしても)

>>256
新たなバグを埋め込むことと、以前は動作していた機能が動かなくなることは、表裏一体だと思うが。

そして、ここでは、バグが埋め込まれたととらえるか、以前は動作していた機能が動かなくなったととらえるかは、問題にはならないと思うが。

>257
新たにバグを埋め込んでも、以前動作していた機能に影響がないこともあるし
バグの埋め込みによらずに、以前動作していた機能が動かなくなる事もある
だから違う

ある機能が動作しないというのが、そもそもバグだ。
だから、以前動作していた機能が動かなくなること自体がバグの埋め込みだ。
発生要因とは関係がない。

書いたコードが意図と反していてある部分が動かなくなったとしても、意図したコードを書いたにもかかわらずある部分が動かなくなったにしてもコーディングした本人以外から見れば、不具合は不具合、バグはバグ、デグレードはデグレード。

>260
最初っから埋め込まれているバグはどう解釈しても"デグレード"ではないが、何か？

そのバグはいままでテストを通っていて、発現していなかったんだろ？
いままでは問題なかったと。
そういう設計のほころびのようなものが、一番のデグレードの原因だと思うのだが。
っつうか、わけのわからない信念持ってる人と議論しても意味がないので、これでやめる。

これでやめる

デグレード、「更新による品質の低下」って感じage

「更新による品質の低下」の要因は問わないと思うんだがね。

退化［退行］する、なのだから「更新による」ってのが重要なのであろう

更新時に書いたコード自体が誤っていたのか、更新時に書いたコードによって正しい部分がうまく動かなくなったのか、更新時に書いたコードによって潜在的なバグが発現したのかは、重要ではないってことだな。

ソフトウェアの欠陥の多くは、ソフトウェア修正時に発生する。
ある証券会社の第２次オンラインシステムの際のデータでは、欠陥の50％が修正に起因していた。

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

多くのソフトウェア開発現場では、「面倒だ」という理由でテスト結果の予測を記述せず、
テスト結果の出力を人手で目で検証するということが、未だに行われている。
結果として、多くのプロジェクトで多くの欠陥がリリース後に発見され、多くの技術者が夜遅くまで働いている。

で、それは、どのようにテストするかという観点なしにテストファーストによるテストを書いても、結果として多くの欠陥がリリース後に発見されるってことだろ。

テストのカテゴリ

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


テストファーストの範囲は基本的にユニットテストだけだが、何か？

>>269
これって、テストファーストでもテストアフターでもどっちでもいいから、テストを自動化しろってことだよね。

>>271
ユニットテストでどのようにテストするかという観点なしにテストケースを書いたとしてもバグは減らないということとどういう関係が？

>273

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

そもそもテストファーストはテストの話ではないし

>>274
>そもそもテストファーストはテストの話ではないし

だから、テストファーストで、テストをどうするかという観点で考えてないテストケース書いてテストしたつもりになってるのが問題だと何度・・・

>275

>250

>>276
そう続くなら
>そもそもテストファーストはテストの話ではないし
という主張がおかしくなるよ。

>>271の
> テストファーストの範囲は基本的にユニットテストだけだが、何か？

も、テストファーストをテストの話としているわけだし。
都合のいいようにテストファーストをテストの話にしたりテストの話ではないことにしたり、たまらんなぁ。

>277

>244-
(250)

>> 1.実装しようとする動作の検証テストを作る

テストファーストがテストの話ではないなら、どうしてここで「検証テストを作る」と出てくるんだ？

>278

だから テストはするけど、開発手法なんだっつーの
おまけにテストの観点が重要なのはもっともなんだけど、無くてもどうにかなるんだってば

>>281
なんか、支離滅裂だなぁ・・・。
テストはするけどテストの話ではないのか。

>280

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

>282

偶然だが ... (ry

鯛の形をした饅頭をタイヤキと呼ぶのと、検証テストを先に記述することをテストファーストと呼ぶのと、関係なさが全然違う。
ほんとにそういう認識なら、テストファースト自体を考え直したほうがいい。

>>281
> おまけにテストの観点が重要なのはもっともなんだけど、無くてもどうにかなるんだってば

どうにかされたほうにしてみればｶﾞｸﾌﾞﾙものだな。

>>244
＞1.実装しようとする動作の検証テストを作る

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

っていう価値観は前提としてもOKだよね？

保守ageして寝て起きたら乗り遅れた・・・orz
まああれだ。>>281ｶﾞｸﾌﾞﾙには同意だな。
結局テスト作るのは>>287くらいには難しいよな。
あとテストファーストはテストの話だよな。
それにユニットテスト以外のテストファーストもあるよな。
でももうどうでもいいよな。はは。は。

>>288
いや、乗り遅れて正解だったと思われ。

201からの流れがよーわからん。誰かまとめてくれ。

>201　お前の物は俺のもの発言
〜　　　ドラえもんに泣きつく
〜　　　秘密道具で復讐成功
〜　　　秘密道具がばれて>201に殴られる
>290　現在に至る

>>290
テストファーストはテストじゃない
--じゃあなに？
テストしてコーディングすること
--そのテストはちゃんとやんないといけないんじゃない？
テストファーストはテストじゃない
--じゃあなに？
テストしてコーディングすること
--そのテストはちゃんとやんないといけないんじゃない？
テストファーストはテストじゃない
--じゃあなに？
テストしてコーディングすること
--テストファーストはテストじゃないのにどうしてテストしてとなるの？
テストファーストとテストはタイヤキと鯛の関係だ
--あほちゃう？

わかりやすくて改修しやすくて分離可能で再利用しやすくしとけばいいんじゃないの

単純なことだろ　　意味わかるよね。

おまいら、むつかしく考えすぎ。　単純なものをうまく組み合わせる　ただそれだけでしょ。

急に流れが戻ったのは明け方の馬鹿が反省したから？

>>294
賢いな。シンプルイズベスト（←なぜか英語に変換されない）だな。

テストファーストとはテスト項目に重点をおいてコーディングを行う開発手法のこと。
テストを通ることを最優先して実装を行う。
モジュールの品質はテストによって保障されるが、
最初からテストを通ることを主目的にしているため、品質の確保がしやすい。

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

「テスト」とひとくくりにすると混同しやすいが、
「テスト工程をクリアしたら品質が保障される」ということを逆手にとって
「では最初からテスト工程を通ることを重視する」だけであり、
テスト工程でのテスト作業そのものを指すわけではない。

もちろんテスト作業の質を上げる工夫もされているが、
テスト作業（テストケースの作成、結果確認など）がタコなら品質は保証できない。
（これはアフターテストでも同じだが）

アジャイル開発などでは、コードの修正を行ったら回帰テストを全項目行うことを
推奨していたはず。全項目を確認しなおすことで、ソースに対する信頼性を
保障することが出来る。ただし、これを人手やるのは大変なので回帰テストの自動化が
求められている。

>>297と>>298は何に対するレス？

テストファーストでやると1つのクラスに対して
テストコード→実装コード→テストコード→実装コードと
かなりの回数繰り返さないと質の高いテストを記述することができないのが問題

なぜなら実装コードを書く前からすべてのテストを記述することは非常に難しいから。
異常処理・例外の類などは特にね

俺が思うに「最初にテストケースを考える」ことこそ
テストファーストの真髄だと思うんだ。
（テストファーストを唱えてる人がどう思ってるか知らんけど）
そこで生まれたテストケースが貧弱かどうかは実はどうでもよくて
発想の転換でテストケースを濃くする事と
コード書く時に外部条件を意識して書くようにする事
要するに熟達したプログラマが普通にやってるこの2点を
システマチックにやる事で品質向上を狙うモノではないかと。

>>294
作るものが単純じゃないから、そう一筋縄にはいかないんだよ。
複雑なものを作るときに単純なものを組み合わせると、その組み合わせが単純ではなくなるから、全体として結局複雑になる。
そのとき、部分部分が単純なものでしかないと、複雑な組み合わせを追わないといけない。
そしたら、場合によっては複雑なものを単純に組み合わせたほうがよくなる。

単純なものを組み合わせるのがいいんだったら、アセンブリ最強ってことになるな。

つか、質の高いコード = テストファーストなの？
他の話題は無いのかよ、と。
早く話題変えないと、あと700レスで埋まっちゃうYO

>>302
RISCなんかは、アセンブリ最強と同じ発想で作られてんだが?

>>304
違うよ

>>305
バカ?

>>304
それはプログラマにとってじゃなくCPUにとってだと思われ。

>>303
テストファーストは要求を満たすシンプルなコーディングを促進するから、
あながちスレ違いとは言えない。でもやっぱりテストの話で、鯛の話じゃないよなぁ。

>>302
良く設計された単純なものを単純に組み合わせるという選択肢もある。

>>309
エントロピー保存の法則というものがあって、全体的な複雑さにはそれ以上単純にできない限界があるから、それは無理。

×無理
○非常に難しいか、特別な場合に限られる

たとえば、GoogleのPageRankが行列の固有値を求めればいいだけになっているみたいに、理論をちゃんと構築すれば、プログラム自体は単純になるね。
その場合は、設計作業がページの重要度を行列の固有値問題に変換するという複雑な作業になっているので、全体の複雑さは保たれてるわけだ。

>>312
複雑さが1000だとして、
10×10×10 というバランスで進める開発と
2×20×25 というバランスで進める開発に優劣は無いって事？
そんなことないだろ。

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

質が高いと評価されるソースを作成するための技法習得
って事かな？
だとするとまず設計がきっちりできる事が要求される
いいかげんにてきとーに設計して作ったものの質が高いはずが無い
もっともそのためにはそもそも何を作ればよいかというレベルでの
要求分析(要件定義)がきっちりできている事が前提だが、、、

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

それは

　　早　寝　早　起　き

だ

わかったらさっさと寝ろ。

>だとするとまず設計がきっちりできる事が要求される
>要求分析(要件定義)がきっちりできている事が前提だが、、、

…もういいよ。

その前に契約が（ｒｙ

1 ：デフォルトの名無しさん ：04/12/05 14:50:20
良いコードを書きたいです。でも、書けないです。
良いコードを読めばよいと聞きますが、どれがよいコードなのか分かりません。
長くないけど、良いコードと悪いコードを比較して、わかり易く教えてください。
デザインパターン適用するといいと聞きますが、どれだけいいのか分かりません。
異常処理書くと汚くなってしまいます。
例外処理はtry{}catch(Exception e){}としてしまいます。
言語や環境、職場によって良いとされる書き方は変わります。
例えば、携帯Javaは容量を少なくするコードが良くなります。
スピードを徹底的に重視すれば、オブジェクト指向は邪魔なだけです。
関数型言語では、再帰呼び出しを使うのが上等です。
コードリーディングとか、達人プログラマーとか、
本買って読むといいらしいけど、お金ないし、
買いに行くのめんどくさいし、ウェブで見たいです。
そういうサイトつくりたいけど、頭悪くて作れません。
てことで、まとめWiki作って、勝手に書き込んで欲しいです。
トヨタ式的なものがソフトウェア産業でできてないと言うし悔しいです。
てことで、良いプログラムを書くためのやり方、良いソースの書き方を議論して、
最強のソフトウェア開発方法をまとめてください。

コードを書くことは目的ではなく手段なのだ。
と言ったら煽りかのぅ

321 ：デフォルトの名無しさん ：05/01/04 19:12:06
これまでの成果
---
・公開されているよいソースコードを読むとよい
・assert文を使うとよい
・よい本を読むとよい
・コード量が少なくなるようにする
・メソッドの数をできるだけ少なくする
・クラスはできるだけ作らないようにする?
・リファクタリングする
・素早く頭働かす?
・メンタルの健康を保つ?
・ネストはできるだけ下げないようにする?
・変更履歴にはwhat i didではなく why i did itを書け?
---

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

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

こういう人って結構いるのでは？

>昔、とんでもなく品質の悪いプログラムのメンテ引き継ぐことになった。

んで結論は 品質＝保守性 なのか？
質の高いコーディングとは メンテナンスしやすいコードを書くということなのか

>>310
309ではないが、
そんな物理法則を持ち出されてもな。
それにその単純さの限界を示さなで無理と一言で片付けられてもな。

すまん。
>>311で無理という部分は訂正されていたな。

>>313
複雑さ10のクラスが100あるのと、複雑さ100のクラスが10あるのとあって、全体的な複雑さが一緒だとするね。
クラスが100あると追うときにあちこち飛ぶことになるけど、複雑さ100のクラスは同じところに記述されているから追うのが楽。

ってことが考えられる。
優劣がないわけじゃなくて、優劣はあるけど場合によるから一概に言えないということ。

>>323
物理法則じゃなくて、ここでは情報の法則ね。エントロピーは平均情報量のこと。

複雑さは一定っていうことは頭に置いておいた方がいいと思う。
じゃないと、無邪気に目に見えるところだけ単純化して、目に見えないところに追いやられた複雑さに足をとられることになる。

いや、エントロピーの法則って、熱力学第二法則をソフトウェア工学に転用したものだろ？

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

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

転じて、ソフトウェアも改変を重ねるうちに、だんだんぐちゃぐちゃに崩れ去っていってしまう
ことは避けられない、ということを指す。

ソフトウェア工学以前に情報理論の根幹やん＞エントロピ
「bit」の定義とかとも関係深いし。

>>327
少なくともソフトウェア工学にはそういうのはないと思うが・・・。
情報工学の情報量の話。

で、それは改変というエネルギーを与えるとエントロピーが増大するという話だから、とりあえず今の話題とは関係ないよ。

ソースコードのエントロピーという考え方は面白いな

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

コピペばっかりだと、エントロピーが、ある特定の値以上になるだろうから
その辺を統計とって、判断するのには、使えるだろうけど。

>>330
コピペは情報量をふやさないよ。
だって、コピペには、オリジナルの部分を除けば、コピペされているという情報程度しかないからね。

で、話題的には、目に見えるところだけ単純にしても、結局それはどこかに複雑さを追いやっただけだよ、って話がしたかったわけさ。
だから、保守とか可読性を考えると、一部分だけ複雑にしておいて、コード上に分散させないほうがいいこともある、って言いたかった。

>>331
エントロピーの基礎を勉強した方が良いと思われ

設計書こねくりまわして「きれいな設計」して、コードが単純になったとしても、その設計がなんのことかわからなくなることがあるから、素直に複雑なままコーディングしたほうがいいってこともある。
難しい設計や難しい数式より、難しいコードの方が追いやすい。

>>332
そちらこそ。

イキの良い新人君って綺麗で効率よくてｶｯｺｲｲコードを書こうとして
意図してか無意識にか知らんが仕様の一部を勝手に無視してくれることがあって
出来てきたものが使えんこともしばしば
新人教育の第一歩がこのへんの矯正になることが少なくない

リファクタリングしまくったらクラス爆発した。
しかも命名規則が糞だから機能追いにくい。

とか、

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

とか。

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

どうよ？

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

>>336 具体的にはどういうこと？

バカとハサミは使いよう。

保守性たったの5か・・・ゴミめ

>>339
要AA

それって道具に使われる人？

>>333
＞難しい設計や難しい数式より、難しいコードの方が追いやすい。

俺は簡単な設計の簡単なコードの方が追いやすいと思うけど。

>>342
流れ嫁
簡単なシステムが追いやすいのは当たり前。

>>343
複雑さの限界を前提にしてる時点でズレてるんじゃないかと思って。
そもそも神の創造する最高にシンプルな設計・コードを100%として、
人類が現在到達しているレベルは30%に満たないくらいだとは思えないか。
ましてやお前等なんて10%に到達してるかどうか。

って考えると、複雑さに対する諦めよりも、
よりシンプルさ（可読性も高く初心者でも理解可能なほどの単純さ）
を目指す方が現実的ではないかと思う。次第です。

>>344

>>326

質が高いとは、バグが少ないことと、メンテナンスしやすいことだと
言い換えることができる

つーか、メソッドやクラスを分割しまくると、コーディング能力に
ネーミングセンスという新しいセンスが要求されるようになる

単純なメソッド分割は、賢いコメント以上の意味はないしな。

>>345

>>344

>>349
つまり、複雑さとか情報量とかの意味がわからないってことね。

>>350
頭痛が痛い
頭痛がする

どちらが複雑な文章ですか？
どちらの情報量が多いですか？

>>351
「頭痛が痛い」の方が、「痛」が２回含まれてるので情報量が低い。

情報量って、意味わかってる？

「頭痛がする」はすべて違う文字なので、情報量が高く「頭痛が痛い」より複雑。

なんの前提条件もあたえられず情報量とか複雑さとかを判定するなら、こうなる。

>>352-353
へーそういう考え方なんだ。知らなかった。
質の高いコーディングとは無関係だとは気付かずマジレスしちゃったよ。

>>354
>>351の文章が質の高いコーディングと無関係なだけだな。

>>355
日本語としての情報量は同じだけど、上の方が文法的に複雑。
こっちの方がだいぶ近いと思うんだけど。

>>356
頭痛が痛いのはあたりまえなので、ことばとしての情報量もない。
文法的に複雑というのも意味不明。
そして質の高いコーディングと無関係。

>>344
情報量とかエントロピーとか複雑さとかの関係をしらないで、単純にそういうことを夢見てたら、目に見えにくい複雑さに足すくわれるよ。

>>356
複雑以前に不具合だろ。

>>359
意味が変わるわけじゃないから不具合じゃないだろ。
１処理で同じチェック２回しても不具合じゃない。２回目が意味無いだけで。
ただし品質は低いという。

>>360
推奨された文法じゃないけどね。

>品質は低い

別に品質には影響ないだろ？保守性が悪いけど

>>362
保守性も品質だよ。

>>363
保守性を品質に入れるかは微妙だな。
評価対象にするとして、保守性なんてどうやって数値化するんだろう？
評価できない性質を品質の対象に入れていいんだろうか？

>>364
逆に評価出来る品質って何ですか？

>>365
ISOのなんちゃら

ソフトウェアの品質として定義されたものといえば、ISO9126ってことになるな。
ttp://www.cam.hi-ho.ne.jp/adamosute/kyotu/iso9126.htm

>>367
保守性おもくそ入っとるやん

つか、今フリーで入手できるソースコードのうち
喪前等が質の高いコードだと思ってるのって、どれよ？

それを議論すれば、答えにたどり着けると思われ

>>368
定義見たけど、これって変更するときとか障害が発生したときに
初めてわかる項目だよね？
ISOの定義はおいとくとして、客先に納入するときに保守性の保障なんて
どうやってやるんだろう？

保守性は重要だけど、保守性を一般化するのは難しい。

分割の上手く取れているコードは読みやすいが、仕様変更の要求が当初の
設計で分割した境界線を跨ぐ形だと、それは大幅な仕様変更を要求される。

ここの文章を見ればわかるけど、ここに挙げられたすべてをソフトウェアの品質として採用する必要はなくて、必要に応じて取捨選択しろ、と。
保守性が重要になるなら、保守性もソフトウェアの品質として考慮せよ、と。
重要にならないなら、考慮する必要はなし、と。

>>369
それは、そのフリーウェアの分野のその機能のその規模のコードでの基準にしかならないよ。

>1の言う 質の高い...って
a.品質の高いソース
b.品質の高いソースを作るコーディング方法
で言うところの b. だろ？
b.の話はテストファースト以外に何かでた？サルサファースト?w

　　　 |:::::::::::::::::::／￣ヽ::::::::::::::::::::::::::::::::::::::::::::::::::＼
　　　 |/ヽ:::::／ 　 　 　|:::::::::::::::::::::::::::::::::::::::::::::::::::::::＼
　　　 | 　 V 　　　　　　|:::::::::::::::::::::::::::::::::::／￣￣￣￣￣￣￣￣
　　　ﾉ 　 l　 ＿＿＿ ＜, ---､::::::::::::::::::::|　しょうがねぇな。
　　　ヾ=｡'l`| ｃﾛ ｭ 　 T 　 : 日|:::::::::::::::::::|　お前等のコードをスカウターでテストしてやるよ
　　∠,「 ﾗ　ヽ＿＿√￣|　: 日|:::::::::::::::＜ 　相当質が高いはずだポチッ
　 ／::::|く､　 _,､　　　　　`ー､‐'::::::::::::::::::::| 　キロあたりのバグが・・１０・・２０・・３０・・４０・・５０・・バ・・バカな！
∠-::::::::l､ ￣ 　 　 　 ／/ 　 ＼:::::::::::::::::::| 　まだあがっていく！？
　/＿＿ ,＼　　　 ／／　　　　　`ー--二＼＿＿＿＿＿＿＿＿
　/　/　/ / ヽ-‐　／　　　＿＿ 　 　　 ／／ |　　|　　|
　|　| 　|　l､　￣ｰ'￣￣￣＿＿＿＿／／　　|　　|　　|

>キロあたり
グラムですか？

>>373
テストファーストに則ればまずaを議論すべきだな。

>373
ぺよんじゅんさまアプログラミングとか？

保守性を問うなら読みやすさ、理解しやすさまでだね。
改造しやすさとなると、その要求次第になる。

>>375
印刷した紙の1kgあたりのバグだよ。

>>378
汎用性かシンプルデザインか、みたいな議論もあるぞ。

質が高いとは、バグが少ないことと、メンテナンスしやすいことだと
言い換えることができる

>>375
どう考えてもマ板ではkbだろ。
こういうボケの幼稚さからしても漏れはこの板の品質の低さほうが心配だよ。

勝手に言い換えると>>367あたりの立場がなくなってくるぞ。

>>382
釣りだろうがライン数だろ。

>ライン数

前時代の方でつね ライナー

ライン数なんて信じられんね。
ステップ数だろ。

まあ、質をどう定義したところで、質が高いプログラム書くやつの品質は高いし、質が低いプログラム書くやつの品質は低い。

で、質の高いプログラム書くには？

ちがうよ、質の高いコーディングのスレだよ。
例えば上質なコーヒーを嗜みながらとか。

あ、そういうことか。
マッサージイスで休憩を取りながら、コーディングを行うとか。
充分な睡眠は大事だぁね。

>>388
賢い親を持つ。

>389

だからサルサファーストだって一店のw

質の高い環境によって、質の高い仕事が生まれる

業務系じゃないことだけは確かだな。

>>393
つまり自分のせいじゃなく環境のせいだと

　快適な環境づくりは、安全、衛生、利便などの確保はもちろんとして、
さらに人々にやすらぎやうるおいを感じさせるような環境づくりである。
このようなより質の高い環境が形成されることにより人々はより一層
環境との触れ合いを深め、環境の恵み豊かなことを実感するであろう。
それは今後においても人々の共通の目標となり得るものである。

綺麗なお姉さんがいると、俄然やる気が増す。

>>397
ヤル気しか起きない癖に。

いえ、くどく勇気は無いので、愛想笑いと妄想レイプだけです。

コーディングに集中してるところに
「ねぇプログラミングなんて止めて、エッチしようよぉ」と
美人の先輩
後ろから手コキなんてどうだろうか？

>>400
妄想乙

いや机の下にもぐりこんでもらってフェ(ry

中田（ｒｙ

>>403
ま た 、かよっ！

綺麗なお姉さんでやる気が増す
　　↓
やる気がヤル気に
　　↓
効率落ちる
　　↓
綺麗なお姉さんの手こきで解消
　　↓
効率あがる
　　↓
やる気がヤル気に
　　↓
繰り返し

マッチポンプか。

手コキの後は確実に効率落ちると思うが。

いきなり話を戻すと体調って大事だよな。
深夜にセックスした翌日の午前は確実に何も出来ない。
だから最近晩飯前にセックスしたりする。
お前等もやってみれ。翌日コーディングの質が全然違うぞ。

コーディングの質より、晩飯の質を確保したい。

低炭水化物ダイエットの心持ちで。

コーディングの際にはエラー原因を指摘するとともに推奨修正コードを表示し、
ワンクリックで自動的にコードを修正する機能や、「スニペット」と呼ばれる目的別の
入力支援機能などにより「極力自動化することで、品質の高いコーディングが可能になる」

のなら苦労はないねぇ。

プログラムするプログラム。
人類永遠の夢だな。

プログラムを作るプログラムにもバグがある訳で。

形式的記述からプログラムを自動作成したら、形式的記述どおりのプログラムは自動作成されていたけど、形式的記述自体にバグがあった、という話ですね。

>>414
分かりにくくなったぞ。
言うなら質が下がったぞ。

>>415
形式的記述を勉強してください。

>>416
形式的記述＝プログラム　と置き換えてしまうと、
形式的記述でないプログラムが含まれない事になる。

つまり不適切な拡張は価値を付加するどころか低下させるという典型例って事だ。

>>417
> 形式的記述＝プログラム　と置き換えてしまうと、
> 形式的記述でないプログラムが含まれない事になる。

形式的記述で全部書けばいいだけでは？
あとの文章につながってないような・・・

>>418
あとの文章の意図を分かりやすく言い換えると、
「>>413を>>414に言い換えたら文章の価値が下がった」
ってこと。そうなると、

＞形式的記述で全部書けばいいだけでは？
というアプローチは文章の責任を緩和しただけで、
文章の価値を高める提案ではない。

>>419
ということは、つまり、417はもともと意味の通りにくい文章だったと。

>>420
通常は容易に推測可能で特に問題無い文章だと思われます。
ただし>>418は論理的でなく、>>417を攻撃とみなして、反撃に出ようという意図が感じられたので、
直接的で紛れの無い表現に切り替えることで、こちらも体勢を整えたわけです。

>>421
仮想敵を脳内で構築した、と。

デザインパターンとかは？

後で［パターン］に直す事はあるが、最初から[パターン]にしようとして作ってはダメだ
本末転倒

オブジェクト指向ちゃんとやれば品質高いっぽいですね。

>>424
最初からデザインパターンを使ってできるものは、最初からパターンにしろ。
それこそ本末転倒。

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

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

「ちゃんとやれば」という話であれば、質が高くやるようにすることを「ちゃんとやる」というんだろうから、それもまた意味のない話で。

デザインパターンは、変な強迫観念を植え付けることがあるから嫌いだなぁ。
品質をあげる方策として話すのはね。
オブジェクトを一つしか作ることがないからといって、いつでもそれを保証する必要があるわけじゃないのに、シングルトンにしないといけないというような。

デザインパターンは、設計のライブラリみたいなもんで、これがやりたければこういう設計にしろっていうパターンのカタログだぞ。
API使ったら質が上がるわけじゃないように、デザインパターン使ったら質が上がるわけじゃない。

「将来こういう風に使われる可能性があるからこう作っておく」
の将来が、10年先なら無理にデザインパターンを適用する必要は無い。
1年先なら…、納期や手間を考えて、余裕があるならすべきだな。

>>427と>>429は本質的に理解してないような・・・

その本質を提示できない>>430も本質を理解できていない。

>>429
今要らないなら、要らない。

YAGNIか。

YAGNIはYAGNIで変に誤解して、設計はあとまわしにすることだと思うやつがいるからなぁ。
>>424みたいに。

パターンが冗長なら使わないのがYAGNIでしょ。
>>434はパターン使えば設計OKみたいな思想なの？

>>435
なんでそうつながるかわからんのだが。
パターン使えば設計OKだとは思わないが、パターンを使う設計はOKだと思う。

>>424は、最初からパターン使ってもだめだと書いてる。少なくとも、そう読める。
冗長なら使わない、を、冗長じゃなくても使わない、後回し、みたいな感じにとってるように思える。

つーかよ、ここの実装をどうするればいいかな〜とか考えたら
自然とデザインパターンと同様のパターンになったりするだろ？

そこまでたどり着かないなら、もともとデザインパターン適用するほどの
問題を含んでない処理だったり、実装者が無能だったりするんだが。

基本的なパターン技術を学んだ人間にとって、新しい技術に適応するのは比較的容易

パターン
主流の技術が何度も何度も移り変わっていく中で、基本的な共通のデザイン

／￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣
|　必要に迫られてからｵﾌﾞｼﾞｪｸﾄを作るﾊﾟﾀｰﾝですな。
＼
　 ￣￣￣|／￣￣￣￣￣￣￣￣￣￣￣￣
　　∧＿∧　　　　　　　／￣￣￣￣￣￣￣￣￣￣￣￣
　 （　・∀・）　 ∧ ∧ ＜　それは、Virtual Proxyの一種ですね…
　（　　　　 ）　 (；ﾟДﾟ)　 ＼＿＿＿＿＿＿＿＿＿＿＿＿
￣￣￣￣￣ （つ＿つ＿＿
￣￣￣日∇￣＼| BIBLO |＼
　　　　　　￣　　　=======　　＼

／￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣
|　納期が迫ってからｺｰﾃﾞｨﾝｸﾞせよ、と。
＼
　 ￣￣￣|／￣￣￣￣￣￣￣￣￣￣￣￣
　　∧＿∧　　　　　　　／￣￣￣￣￣￣￣￣￣￣￣￣
　 （　・∀・）　 ∧ ∧ ＜　ｿﾝﾅｺﾄ言ってないでしょ!!
　（　　⊃ ）　 (ﾟДﾟ；)　　＼＿＿＿＿＿＿＿＿＿＿＿＿
￣￣￣￣￣ （つ＿つ＿＿
￣￣￣日∇￣＼| BIBLO |＼
　　　　　　￣　　　=======　　＼

>>436
日本語読解能力が無いんじゃね？

>>441
それでは、「最初から[パターン]にしようとして作ってはダメだ」という理由を説明してくださいな。
どうして最初からパターンにしようとして作っちゃダメなのか。
テンプレートパターンにすれば解決できるとわかっても、テンプレートパターンにしようとしてはダメなのか。

使えそうなデザインパターンを何でも使おうという誘惑に抵抗しなければ
ならない

たまに、2階建ての普通の住宅に立派なエスカレータを付けてしまうような
設計(もちろん比喩)を見かけることがある
「何故？」と聞くと「デザイン・パターンの本に載っていたので」
なんていう答えが返ってきたりする

>>443
別に、デザインパターンの用途通りに使う分には構わないんではないかと。
乱用がダメなのは、なんでも一緒。

アルゴリズム，文法，オブジェクト指向と理解していけば，ライブラリを利
用して，ある程度のオブジェクト指向プログラムは作れるようになります。
しかし「こういうアプリケーションを作る」と具体的に決めて，必要なコード
がサッと出てくるようになるには，やはり「経験」が必要です。

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

未経験の状態から闇雲にクラスを考えるのではなく，優れたデザインパターン
をお手本にすることで，多くの経験者から助言を得たのと同じ効果が得られます。

ソフトウェアテストは開発に比べて、地味で低いレベルのスキルだと思われています。
しかし開発力が高いエンジニアはテストも達者だ、というのも事実です。テストの
スキルは、地味な確認作業の積み重ねではなく、開発力を表す指標に他なりません。
「テスト道」を極めていくと、そもそもバグを作り込まない開発に近づいていくのです。

>>445
未経験の状態から闇雲にデザインパターンの利用を考えるのではなく，
優れたデザインパターンの利用をお手本にすることで，
多くの経験者から助言を得たのと同じ効果を得る必要があります。