【TDD】テスト駆動開発【TestFirst】

**デフォルトの名無しさん** · 2010/09/19(日) 21:26:12

テスト駆動開発 (test-driven development; TDD) についてﾏﾀｰﾘ語りましょう

ツールについては別スレで
テストツールについて語るスレ 2
http://hibari.2ch.net/test/read.cgi/tech/1208013693/

**デフォルトの名無しさん** · 2014/02/14(金) 11:31:08.45

>>352
> 「テストが無事でも元と同じ品質のコードをもう一度書くことができないときがある」
> で、論破。

論破って…単なる仮説を立てただけだろ。立証してから言ってくれ
そういう分かりやすい最終的な結論だけで話しを進めるたがる事を
抽象的な話しが出来ないっていうんだよ

**デフォルトの名無しさん** · 2014/02/14(金) 11:56:51.72

>>354
> 論破って…単なる仮説を立てただけだろ。立証してから言ってくれ

は？どうみても
「テストが無事でも元と同じ品質のコードをもう一度書くことができないときがある」
は明らかだろ。

> 抽象的な話しが出来ないっていうんだよ

抽象的を辞書で引け、アホ。

**デフォルトの名無しさん** · 2014/02/14(金) 12:45:53.91

>>351
なんであの糞記事を擁護するの？

**デフォルトの名無しさん** · 2014/02/14(金) 12:52:21.25

>>355
> 「テストが無事でも元と同じ品質のコードをもう一度書くことができないときがある」
> は明らかだろ。

明らか言われても論破された気にはなれないよ

ちなみに「できないときがある」の反対は「常にできる」だから該当記事の「～ことができる」を
反論している事にはならないよ
むしろ同じ事を言っている

> 抽象的を辞書で引け、アホ。

辞書で引いてみたよ
１いくつかの事物に共通なものを抜き出して、それを一般化して考えるさま。「本質を―にとらえる」
で、だから何？

**デフォルトの名無しさん** · 2014/02/14(金) 14:24:13.22

>>357
言葉遊びして楽しい？
それより、なんであの糞記事を擁護するのか教えてよ。

**デフォルトの名無しさん** · 2014/02/14(金) 14:31:22.73

>>367
ごく限られた条件下(*)においては、テストが無事なら同じ品質のコードを書くことができる
こともあるだろうが、それはテストの大切さとは直接関係ないし、ましてやTDDとは何の
関係もない。

(*)後付けのC1カバレッジ100%で全ての副作用に対するassertionが記述されているテスト
一式がある場合。

TDDスレなんだから、このスレの住人は、TDDにおけるテストの大切さはみんな重要だと
思っているだろうし、その他のテストの重要性もわかってるだろう。

その上で、>>327は駄目記事だと言ってるんだが。

**デフォルトの名無しさん** · 2014/02/14(金) 17:22:33.79

>>357
そもそも
＞テストが無事なら元と同じ品質のコードをもう一度書くことができる。
なんてことが必要になる状況はめったにない、で論破じゃないかと。

>>359
TDDにおけるテストの重要性は、「同じ品質」ではなく「同じ動作」を求めるため、
しかもカバレッジ100%の完成したコードではなく実装途中のコードに対して、
でよいよね？

**デフォルトの名無しさん** · 2014/02/14(金) 17:32:25.39

>>360
> TDDにおけるテストの重要性は、「同じ品質」ではなく「同じ動作」を求めるため、
> しかもカバレッジ100%の完成したコードではなく実装途中のコードに対して、
> でよいよね？

そんなかんじ。
カバレッジに関しては、C0カバレッジですら100%に満たないよね。
TDDのテストは、その人が十分だと思う分しか書かれない。
そして、そのテストコードをいわゆる「単体テスト」では使わないという人もいる（extremeな人は全捨てするらしい。マジか）。
俺は使うけど。

**デフォルトの名無しさん** · 2014/02/14(金) 22:19:43.22

>>353
そうだな。誰もそこまでのテストは求めていないし、そんなことする気にもなれない。

**デフォルトの名無しさん** · 2014/02/15(土) 00:21:14.85

テストとソースって
たまごとにわとりの関係なの？

**デフォルトの名無しさん** · 2014/02/15(土) 07:15:22.29

たまごが成長すれば、ニワトリになり
そのニワトリが複数個のたまごを生む。
そのたまごがそれぞれ成長し
それぞれがたまごを複数個生む。

テストとソースはこういう関係です。

**デフォルトの名無しさん** · 2014/02/15(土) 09:04:51.54

カバレッジは、ISOとかで必要なところもあるんだろう
あれも結局は認証されたxUnitでテストするらしいが

**デフォルトの名無しさん** · 2014/03/02(日) 15:11:51.03

カバレッジのスレないのでここで。

テストするまでもないコードというのがある。
たとえば変数の初期化関数とか。
こういうのをテストしたってしょうがない。
だけど実行しないとカバレッジは上がらない。

カバレッジ100%を目指しているわけじゃないが
それはカバレッジを上げるために時間がかかりすぎるなら
コストとメリットを天秤にかけてやらなくていいという話なはず。
だから関数呼び出しだけで簡単にカバレッジがあがるならやってもいいではないか？

テストを行わないが関数実行だけはする。これに意味が無いかといえば
そうではなく。それはコードが確実に動くということを証明できる。
スクリプト言語系はスペルミスなど実行しなければエラーを検出できないことがある。

つまりだ。テストを行わないで関数を実行するだけ。というのは気持ち悪いがありなのだろうか？
テストはしていないが、あえて言うなら関数が動くことをテストしているということ。

**デフォルトの名無しさん** · 2014/03/02(日) 15:58:52.16

それは、なしです

**デフォルトの名無しさん** · 2014/03/02(日) 16:30:47.67

実は関数読んでなかったり別の関数呼んでたらどうするわけ？

**デフォルトの名無しさん** · 2014/03/02(日) 17:01:14.12

>367
理由は何ですか？

処理を実行してコンパイルエラーを
実際に見つけられているのです。

**デフォルトの名無しさん** · 2014/03/02(日) 17:46:28.42

>>366はガバレッジとテストの関係について何か壮大に勘違いしてると思う

**デフォルトの名無しさん** · 2014/03/02(日) 18:15:04.54

なにがしかでも作業効率が改善できてるならいいんじゃないの

カバレッジ○○％達成できました！とか言って持ってきたら殴るけど

**デフォルトの名無しさん** · 2014/03/02(日) 19:06:23.64

>>370 >>371
話ちゃんと聞いてね。

テストもカバレッジも目的じゃない。

実行することでコードが確実に動くことが保証される。
たとえば古いバージョンや新しいバージョンで動かないコードを検出できる。

だから実行だけさせることにも、意味はあるよね。

**デフォルトの名無しさん** · 2014/03/02(日) 19:12:20.55

話を聞いてないように見えるのはお前が基本を理解してないか
もしくは説明が下手だからだ

**デフォルトの名無しさん** · 2014/03/02(日) 19:31:34.78

あぁ、わかった。

例外が発生するテストの反対。
つまり例外が起きないテストと考えればいいわけだ。
ということはコードの最後に必ず成功するテストを入れた方がよさそうだ。

**デフォルトの名無しさん** · 2014/03/03(月) 17:40:56.93

>>366
テストは、実際どのように使うのかというドキュメント性があり、また、テストを書くことによって設計が洗練されるということもあるので、ただ実行するだけのメソッドも意味は無くないと思うよ。

**デフォルトの名無しさん** · 2014/03/03(月) 19:28:18.39

書いたら保守せなあかん
簡単に書けるからと書くと、負の遺産になりかねないかも

変数の初期化関数とかは必要だからやってるのであって
それがないと困る箇所が本当は別にあるのではないだろうか
と妄想

2014/03/28(金) 03:11:16.97

てｓ

**デフォルトの名無しさん** · 2014/04/06(日) 10:39:53.51

２つ質問です。
テストを作ってから同じテストを別のオブジェクトにするとき
別のテストをつくりますか？
リファクタリングをするときソースを書き換えてもとに戻せなくならないように
リファクタリングをする前のファイルを保存しておきますか？

**デフォルトの名無しさん** · 2014/04/06(日) 10:44:48.65

>>378
たいていのテスト環境にテストコードの再利用の仕組みはあると思うけど。

バージョン管理しろよ。

**デフォルトの名無しさん** · 2014/04/24(木) 16:15:35.14

DHH(Ruby on Railsの作者)の"TDD is dead. Long live testing." （の訳）
http://d.hatena.ne.jp/yach/20140424#p1

**デフォルトの名無しさん** · 2014/04/24(木) 17:32:03.50

彼らは自分のエゴを満たすためにコードを書いてるんだから、
金色の牛を殺したりしたらダメだよね?(´・ω・｀)

**デフォルトの名無しさん** · 2014/04/25(金) 16:52:52.53

>>380
一行目から引いた

**デフォルトの名無しさん** · 2014/04/28(月) 12:40:27.17

Unit Test Frameworks
よんだけど、CPPUNITのことが全然書いてないので
CPPUNITの高度な使い方ってどうやってわかりますか？

**デフォルトの名無しさん** · 2014/04/28(月) 15:56:01.02

>>383
> Unit Test Frameworks
これ何

**デフォルトの名無しさん** · 2014/04/28(月) 15:59:59.35

UnitTestFrameworks.pdf?

**デフォルトの名無しさん** · 2014/04/28(月) 16:19:09.38

つか、CppUnitの高度な使い方って何よ？

**デフォルトの名無しさん** · 2014/04/28(月) 16:20:09.84

>>385
> UnitTestFrameworks.pdf?
何それ？何かの海賊版か？

**デフォルトの名無しさん** · 2014/04/28(月) 16:23:45.04

抽象クラスのテストを作って派生クラスのテストでテストしたいクラスを初期化する方法とか。

**デフォルトの名無しさん** · 2014/04/28(月) 16:24:20.94

UnitTestFrameworks.pdf
で検索すると出てくる著作権フリーの書籍。

**デフォルトの名無しさん** · 2014/04/28(月) 16:27:49.28

>>388
ちゃんとわかる文章書け。
つか、ほんとにそれ「CppUnitの高度な使い方」に関する疑問なのか？

**デフォルトの名無しさん** · 2014/04/28(月) 16:29:49.62

>>389
> UnitTestFrameworks.pdf
> で検索すると出てくる著作権フリーの書籍。
なんでずばっとURL書かないの？
俺が検索したら、O'REILLYの奴しか見つからなかったが。
これ、フリーじゃないだろ。

**デフォルトの名無しさん** · 2014/04/28(月) 16:30:35.56

>>391
Ｏ'ＲＥＩＬＬＹはフリー

**デフォルトの名無しさん** · 2014/04/28(月) 16:34:49.54

>>392
まさか、DRMフリーの意味がわからんのか？

**デフォルトの名無しさん** · 2014/04/28(月) 16:46:40.37

PDF の各ページのフッタ見ればわかるけどフリーで配布されてるわけじゃないね

**デフォルトの名無しさん** · 2014/04/28(月) 16:51:24.25

なんかの記事で見たけど、無断配布を禁止するより
しない方が本が売れるからわざとそうしてるらしい。

**デフォルトの名無しさん** · 2014/04/28(月) 16:56:55.25

>>395
> なんかの記事で見たけど、無断配布を禁止するより
> しない方が本が売れるからわざとそうしてるらしい。
どこの記事だよ？
O'reillyはDRMはフリーにしたけど、無断配布は禁止だろ。

**デフォルトの名無しさん** · 2014/04/28(月) 20:05:02.12

なんだ釣りか

**デフォルトの名無しさん** · 2014/04/29(火) 10:12:01.42

別にDRMフリーって無料配布を禁止してないわけじゃないんだけどなw

**デフォルトの名無しさん** · 2014/04/29(火) 10:15:16.74

A. オライリー・ジャパンが販売する書籍（Ebookも書籍だと考えています）は、
コピー・フリーではありますがコピーライト・フリーではありません。
日本国の著作権法による保護を受けており、
著作権法で定められた範囲を超えた複製、頒布、
送信などは、
著作権法に抵触する恐れがありますのでご注意ください。

**デフォルトの名無しさん** · 2014/04/30(水) 12:43:00.88

著作権フリーだの無断配布だの意味不明な俺用語でかたるのがおかしい

**デフォルトの名無しさん** · 2014/05/08(木) 10:55:00.04

> なんか誤解してるっぽく見えるからそれをときたいだけなのに原理主義だの教条主義だの
> テスト厨だのって言われるのは心外っすね。。こちらだって別に銀の弾丸だと思ってないし、
> ただ誤った理解を訂正したいだけなのに。。

正しい理解が為されればTDDがdisられないという考えがすでに宗教。
だから原理主義言われるんだよ。

**デフォルトの名無しさん** · 2014/05/08(木) 13:18:58.75

そうだな
TDDという概念自体が完全に誤ったもの
動いてるコードに手を触れないことこそが真理

**デフォルトの名無しさん** · 2014/05/08(木) 23:11:10.80

>>402
君、概念以前にTDDが何なのかすらよく分かってないでしょ

**デフォルトの名無しさん** · 2014/06/14(土) 11:06:05.15

うんこ

**デフォルトの名無しさん** · 2014/07/21(月) 15:26:18.47

オウンコ

**デフォルトの名無しさん** · 2014/07/21(月) 15:27:39.55

マンコ

**デフォルトの名無しさん** · 2014/08/06(水) 12:12:57.58

テスト鳥文

**デフォルトの名無しさん** · 2014/08/19(火) 01:55:15.38

とりぶん？

**デフォルトの名無しさん** · 2014/09/29(月) 15:59:03.19

なぜ流行らなかったスレが死滅したな

**デフォルトの名無しさん** · 2014/09/29(月) 22:02:10.49

あのスレのカオスっぷりを見れば
なぜ流行らなかったのか良く分かる

**デフォルトの名無しさん** · 2014/09/29(月) 22:59:57.93

2ちゃんねらーの脳みそではテストなんて書けるわけがなかったってことだ

**デフォルトの名無しさん** · 2014/09/30(火) 08:06:51.52

TDDはともかくユニットテストまで否定かよ
恐れ入る

**デフォルトの名無しさん** · 2014/10/01(水) 16:56:59.90

TDDやユニットテストを否定する奴って、経験ゼロなのに経験豊富な奴の知見や実感なんかを否定するよね。
あと、自分の嫌いなスクリプト言語をわざわざdisりに行く奴とメンタルが似てる気がする。

**デフォルトの名無しさん** · 2014/10/01(水) 17:01:54.48

自己紹介ですね
わかります

**デフォルトの名無しさん** · 2014/10/01(水) 22:34:56.80

>>413
>>380

**デフォルトの名無しさん** · 2014/10/02(木) 14:30:41.58

>>415
http://blog.fieldnotes.jp/entry/2014/05/07/225129

> DHH氏のTDD is dead. Long live testing. (DHH)のエントリは、国内でもさまざまな議論を
> 呼び起こしました。ですが、そのセンセーショナルな見出しの影響もあり、「(TDDと同一視
> した上での)ユニットテストは不要」などの、ミスリードされた論調も見られます。

**デフォルトの名無しさん** · 2014/10/02(木) 14:37:04.66

あとこれも追加。

【翻訳】TDD is Fun
http://diskogs.hatenablog.com/entry/2014/04/25/085112

**デフォルトの名無しさん** · 2014/10/02(木) 21:31:51.50

>>416
そのリンクを出して何を言いたいのか分からない
もう一回>>413と>>380を嫁

**デフォルトの名無しさん** · 2014/10/03(金) 11:17:58.55

>>418
えっとね、>>380も>>413も書いたの俺なんだわ。
逆にお前が何を言いたいのかわからんわ。

**デフォルトの名無しさん** · 2014/10/03(金) 23:03:06.98

>>419

>>413
> TDDやユニットテストを否定する奴って、経験ゼロなのに経験豊富な奴の知見や実感なんかを否定するよね。

>>380
> http://d.hatena.ne.jp/yach/20140424#p1
> TDDには感謝しているが、設計の教義としてはとっくに使わなくなっている。

とっくに使わなくなっている＝現場で使えない＝否定　だよね

**デフォルトの名無しさん** · 2014/10/06(月) 10:30:55.78

>>420
アスペなの？
俺が言ったのは傾向だよ。

**デフォルトの名無しさん** · 2014/10/06(月) 22:45:50.57

TDDは慣習

**デフォルトの名無しさん** · 2014/10/12(日) 02:49:57.49

組み込みなんだが

実機とＴＤＤの解析環境でコンパイラが別になる

こういう場合は何をもってテストしたといえるんだ？

**デフォルトの名無しさん** · 2014/10/12(日) 10:48:18.63

気になるのはコンパイラが別になるってことだけ？
それなら解析環境（？）でテストがパスすればテストしたと言えるだろう

コンパイラの差異については結合テストとシステムテストをパスすれば
問題ないと考えていいんじゃないの

**デフォルトの名無しさん** · 2014/10/12(日) 11:10:47.48

最適化のバグでひどい目に遭ってからそのへんの互換性は信用出来ないと思い知ったわけだが
それでもテストしないよりはマシ

**デフォルトの名無しさん** · 2014/10/12(日) 15:18:45.36

>>424
他にも色々ある

というか俺の職場の装置のソースがクソなんだろうけど
パラメータが多すぎて全部網羅するのは無理

ＴＤＤでいうテストってのはどういうイメージなのか
ネットや本を見てもピンとこない

ｘ＋１の関数に１をいれて２になりましたとか
そんな説明は求めてないのだが

**デフォルトの名無しさん** · 2014/10/12(日) 21:43:25.28

>>426
TDDがどんなものか、何の略かまでは分かる？
クソなソースになっているのならどうしようもないだろう

それにパラメータ多すぎて全部網羅するのは無理っていうけどさ
TDD以前にカバレッジはどうすんのよ

組み込みでC0すらパスしないような状況になってたらかなりマズイ気がするが

**デフォルトの名無しさん** · 2014/10/12(日) 22:13:02.74

>>426
TDDで目指すのは小さなフィードバックループを作ること
開発者が安心を得つつコーディングできること
安心というのは、ここでいうと例えば「実機で確認されていないコード・機能をベースに、それに依存したコードをさらに積み上げていくこと＝不安な状態」的な

何をもってTDDでいうテストとなるか、って定義は割とどうでもいい気がする
>>423の環境で何をどうすれば開発者が安心できるか、作業のループを小さくしてフィードバックを得られるか、が大事
「これが動けばこのコードは正しい」っていう一般的なテストがあって
それが自動化できてさらにフレームワークで成否確認までできるなら十分
そうでないなら何か妥協したテストでやるしかない

・実機と検証(解析？)環境がどの程度異なっていて、開発者は検証環境をどの程度信頼できるのか
・どの程度の頻度で実機テストができるのか
とかが重要なのでは？
ここらへんは現場を見てないので多分他人には分からない所。

仮に検証環境があまり信頼できないのであれば、そこだけでどれだけ完璧な開発プロセスをこなしてもムダになる危険性が残るだろうから
実機での確認をいかに頻繁に行ってフィードバックを得られるか、が重要になる
そうすると一般的なTDDは実践しづらくなると思う。
けど実機でのテストを自動化できるのであれば多少は導入できるかも？

組み込みとか知らんのでとんちんかんなこと言ってたらすまん

**デフォルトの名無しさん** · 2014/10/13(月) 10:22:06.70

>>428
ありがとう

指摘はとても現実を捉えていて救われた思いがした

現実は顧客の装置の一部のデバイスを作ってるのだけど
検証環境が貧弱（または無い）ので
仕様変更箇所のみを検査するみたいな対応になってしまってる
ここ数年リストラで人減りまくったのと
士気の低下なのかテスト不足と思われる市場不良が多発

「安心」と言う意味では
徹底的な回帰テストをすることが大事だとおもう

問題はどうやってそれをやるかなのだけど

**デフォルトの名無しさん** · 2014/10/14(火) 11:44:30.46

>>428
> 実機での確認をいかに頻繁に行ってフィードバックを得られるか、が重要になる
> そうすると一般的なTDDは実践しづらくなると思う。
組み込みの種類にもよるだろうけど、対象物をmock（あるいは、シミュレータ）で作って
実機なしに開発・テストできるようにするのが、自動テストをやる派の中では一般的だと思う。

まあ、中には「現地に行かないと、プログラムの起動すらできないのでテストできません」とか
言う奴もいるんだが。

**デフォルトの名無しさん** · 2014/10/15(水) 22:41:20.51

UARTなりＣＡＮなりイーサネットなり
この部分は完璧に通信できるものとして実装するでおｋ？

**デフォルトの名無しさん** · 2014/10/16(木) 10:27:00.84

エラーのシミュレーションはするべき

**デフォルトの名無しさん** · 2014/10/16(木) 13:38:30.32

異常系の仕様が定義されていればそれに対応する
それ以外は単体テストの範囲ですらない

**デフォルトの名無しさん** · 2014/10/16(木) 13:56:42.86

>>433
定義あるいは明示されていない異常が発生して鼻から悪魔が出ても、それは俺のせいじゃないから
問題ないという主義ですか？

**デフォルトの名無しさん** · 2014/10/16(木) 17:14:14.25

まるで公務員の主張だな

**デフォルトの名無しさん** · 2014/10/16(木) 19:29:56.64

一緒に仕事したくねーな

**デフォルトの名無しさん** · 2014/10/16(木) 21:49:07.00

縦割りはそういうもの

**デフォルトの名無しさん** · 2014/10/17(金) 01:41:12.71

担当者が設計と開発で分かれているなら>>433が正しい

開発の見積もりは「この仕様（設計書）通りに作ったら○○人月」で算出してるわけで
「異常系に漏れがないかチェックしろ、漏れてたら仕様に書いてなくても対応しろ」は
見積もり範囲外の作業だよ

予算が潤沢に貰えるなら「サービス」で対応するかもしれないが
そんなに潤ってるプロジェクトは滅多にないだろう

**デフォルトの名無しさん** · 2014/10/17(金) 10:40:07.93

>>438
設計する人は、たとえばファイルに保存するときに起こり得るエラー原因ごとにどう対処すべきかを
網羅したりするんですか？

**デフォルトの名無しさん** · 2014/10/17(金) 11:21:29.10

printf() の戻り値見ろと言っているに等しい

**デフォルトの名無しさん** · 2014/10/17(金) 15:20:26.07

>>439
必要なら処理中の突然の電源断やディスクやメモリの破損なんかも網羅するよ
必要か（現実味があるか）どうかを切り分けるのが仕事だよ

**デフォルトの名無しさん** · 2014/10/17(金) 16:05:39.88

>>441
ちょっと議論するのめんどくさいんだけど、開発者の裁量内で判断する異常処理ってないのという疑問なんだけど。
そういう判断を一切する必要がない開発者は、エンジニアやプログラマとは呼ばずに、コーダーやパンチャーって呼ばれると思うんだけど。

**デフォルトの名無しさん** · 2014/10/17(金) 22:32:13.59

>>442
たとえ一人でやっている場合でも、アーキテクチャ（何が起きるか）と、
インプリメンテーション（どう起こすか）は明確に分けるべき。
ましてや複数人でやるんなら、アーキテクチャが明示されることが必要。

少なくともユーザに仕様として提示されるものは、全てアーキテクチャなんで、
必要なファイルが無かったり、外部装置や EAI の接続先が故障していた場合
に"何が起きるか" は、アーキテクチャとして定義されなければならない。

どちらが、より創造的かということには意味はなくて、単に別の仕事。

**デフォルトの名無しさん** · 2014/10/17(金) 22:37:06.62

TDD (BDD) には、インプリメンテーションをやるまえに
テストケースを作ってアーキテクチャを確認しようぜ
という意味も有る。

**デフォルトの名無しさん** · 2014/10/18(土) 00:53:05.90

そりゃプログラマだってアホじゃないんだから要件漏れ気づくこともあるよ
テストを作成していて漏れに気づくことだって多いしね

ただしそれを見つけたり直したりするのはプログラマの役目ではないし責任もない
優秀なプログラマなら「○○処理が漏れてますよ」と指摘だけして
どうしますか？対応するなら再見積もりしますね？で予算をふんだくる

**デフォルトの名無しさん** · 2014/10/18(土) 12:25:58.33

なるほど

**デフォルトの名無しさん** · 2014/10/18(土) 15:13:02.82

>>445
あんた公務員か

**デフォルトの名無しさん** · 2014/10/18(土) 15:19:28.52

たぶんプログラマって言葉の定義が違うんじゃね
SE/PG世界のプログラマは普通のプログラマと別の概念

**デフォルトの名無しさん** · 2014/10/18(土) 15:52:52.83

>>439
Javaの例外は3種類あって、
プログラマが主に想定する例外は、Exception

Error
メモリ不足やハードウェアの故障など、
プログラムではどうにもならないもので、catchする必要がない

Exception
ファイルが読み書きできない、ネットワークがつながらないなど、
プログラムで想定できるもので、catchすべき

RuntimeException
NullPointerのチェックなど、
一々想定していると切りがないもので、catchしなくてもよい

**デフォルトの名無しさん** · 2014/10/18(土) 16:24:30.31

アーキテクチャをそんな意味で使うの初めて見た

**デフォルトの名無しさん** · 2014/10/19(日) 00:06:51.41

>>440
> printf() の戻り値見ろと言っているに等しい

例外がない言語はそうなるから大変なんだよね。

例外がある言語ならすべての行でエラーが起きる可能性がある
という前提でプログラムしても全然負担にならないのに。

**デフォルトの名無しさん** · 2014/10/20(月) 11:17:44.91

>>443
> たとえ一人でやっている場合でも、アーキテクチャ（何が起きるか）と、
> インプリメンテーション（どう起こすか）は明確に分けるべき。
> ましてや複数人でやるんなら、アーキテクチャが明示されることが必要。
ちょっと俺とは「アーキテクチャ」の使い方が違うようだ。

> 少なくともユーザに仕様として提示されるものは、全てアーキテクチャなんで、
ユーザに仕様として提示すべきものは「外部仕様」。
そして、その中には内部で使用するアーキテクチャは明示されるかもしれないし、明示されないかもしれない。

> 必要なファイルが無かったり、外部装置や EAI の接続先が故障していた場合
> に"何が起きるか" は、アーキテクチャとして定義されなければならない。
内部設計では、何が起きえて何をすべきかを網羅することは必要だが、外部仕様としてはそれらをすべて
含む必要はない。

**デフォルトの名無しさん** · 2014/10/21(火) 17:54:15.96

コードを書かない？設計者が、最終的に使用するミドルウェア・ライブラリ・APIに精通してる奴多すぎ。
んで、if (エラー条件)となる部分を全部設計書に明記するだって？
どんだけ分厚い設計書なんだよ。

**デフォルトの名無しさん** · 2014/10/21(火) 17:56:11.27

>>451
> 例外がある言語ならすべての行でエラーが起きる可能性がある
例外がありゃあったで、別に考えないといけないことも増えるんだけどね。