トップページ⇒tech
1001コメント360KB

テスト駆動開発はなぜ流行らなかったのか？2

■ このスレッドは過去ログ倉庫に格納されています
0001デフォルトの名無しさん2014/01/13(月) 08:09:14.87
まとめ

適切にテストコードを導入するためには
適切なコードの書き方や設計まで知っておく必要があり
既存のコードが適切で無い場合、大幅な書き換えが必要になるから。
最悪開発プロセスから変えないといけない。

またテストコードが書きづらい部分（GUIやウェブUI等）が存在し
書きづらいということを知っていないと、無理に書こうとして
挫折するか、無理矢理なテストコードを書いてメンテナス不能になるから
0153デフォルトの名無しさん2014/01/17(金) 01:36:29.89
>>146
>だいた後捨てたり使いましたりするだろ。
脳内妄想もたいがいにしろ童貞
0154デフォルトの名無しさん2014/01/17(金) 01:48:43.56
>>152
テストを最初から書くことのメリットは、粒度を疎にすることと、
インターフェイスをコーディングの始めからトイレで席を立って帰ってきてエディタを保存するまでの間一貫させておくことと、
コードの長さをプロジェクトの了解の外にあるプログラマ個人の思い付きによる機能追加で長くしないことがある

関数型で書くときこそテストを先に書く必要がある理由は、関数型はドメインが陽にコードに現れないから
ポイントフリープログラミングなんかその典型
0155デフォルトの名無しさん2014/01/17(金) 03:33:03.87
>>154
前段は疎にする以外はテストを書くことによりそれが得られる理由がわからん。

後段はドメインが出てこないとは何を指して言ってるんだ？
0156デフォルトの名無しさん2014/01/17(金) 03:52:31.04
>>154
つまり、質の悪いプログラマを使わざるをえないプロジェクト向けということでおk？
普通はテストなんか無くても自然とやってることだらけじゃん。
0157デフォルトの名無しさん2014/01/17(金) 05:47:10.62
>>126
３Dの挙動ぐらいテストできるだろ
毎回同じ表示がされればいいだけなんだから
0158デフォルトの名無しさん2014/01/17(金) 08:07:30.81
>>132
どうせ仕様変更入るから仕様書なんて書かなくてもいいよね

まあ趣味ならそれもあり。
0159デフォルトの名無しさん2014/01/17(金) 10:17:12.49
>>132
> bar書いてる途中で、引数は配列にしようとか、そもそもbar関数要らないやと
> 仕様変更入ったらそのテストコード意味なくなるよね。
それ、仕様変更じゃなくて設計変更じゃないの、というのはおいといて。

引数を配列にしたくなったら、テストをそのように変えればいいし、bar()がいらなくなったら、テストを削除すればいいだけだよね。

> 一度もOKになることのないテストコードは書かなくてもよくね？

そうじゃなくて、TDDでは一度OKにするんだよ。
class Foo { // 仮想言語
　　public int bar(int i, int j)
　　{
　　　　return 10;
　　}
}
こう書いて、ビルドしてテスト実行。
0160デフォルトの名無しさん2014/01/17(金) 12:58:54.95
>>130
それ本気で言ってんの？
0161デフォルトの名無しさん2014/01/17(金) 15:54:05.17
BDDと、どっちが強いの？
0162デフォルトの名無しさん2014/01/17(金) 19:23:42.69
ハイ、本気です。
0163デフォルトの名無しさん2014/01/17(金) 19:29:17.69
小ミスをコンパイルエラーを直すような感覚で発見・修正できる
それで十分
0164デフォルトの名無しさん2014/01/17(金) 19:32:44.88
JUnit,CppUnixtの存在意義って？
0165デフォルトの名無しさん2014/01/17(金) 19:43:27.77
>>158
テストコード書くのは仕様が決まってからでいいんじゃないかと。
仕様が決まってない状態でテストコード書いても意味ないだろう。
0166デフォルトの名無しさん2014/01/17(金) 19:45:10.81
ありませんね。
0167デフォルトの名無しさん2014/01/17(金) 22:22:53.61
>>165
そんなことは仕様も決まってないのにコード書いてる >>132 に言ってくれよ (w
0168デフォルトの名無しさん2014/01/17(金) 22:35:46.81
コード書きながら仕様を決めていくことはよくあることだし。
0169デフォルトの名無しさん2014/01/17(金) 22:40:31.19
ドキュメントを書きながら仕様を決めるのと
コードを書きながら仕様を決めるのと
なにも書かずに頭の中で仕様を決めるとでは
どれが一番無駄がなく短い時間で出来ますか？
0170デフォルトの名無しさん2014/01/17(金) 22:54:27.62
>>154
テストを先に書くと、コーディング途中で「本来なら事前に予想もできなかった複雑なことを、さも簡単なことのように何食わぬ顔でコードに書き足していくこと」が難しくなる

ドメインとは、引数の型と、その引数がとりうる範囲
関数型はこれが分かりにくいので、結局テストで明示されることになる
0171デフォルトの名無しさん2014/01/17(金) 22:57:42.14
>>169
> ドキュメントを書きながら仕様を決めるのと
仕様はけして決まらない

> コードを書きながら仕様を決めるのと
仕様はけして決まらない

> なにも書かずに頭の中で仕様を決めるとでは
仕様はけして決まらない

> どれが一番無駄がなく短い時間で出来ますか？
時間を浪費して頭がハゲるだけ
0172デフォルトの名無しさん2014/01/17(金) 23:06:17.61
>>171
「私はエディタに向かっていったい何を書きたかったのだろうか」 は、いつ決まりますか？
0173デフォルトの名無しさん2014/01/17(金) 23:33:39.18
>>172
「Save Asノ 」ではなく「Save」できたときだ
0174デフォルトの名無しさん2014/01/18(土) 00:02:55.09
今日のクロスでもテストを書きまくることは自分の足を銃で打つみたいなことだとか誰か言ってたな(´･_･`)
0175デフォルトの名無しさん2014/01/18(土) 00:09:20.08
>>171
えと、順位を決めてくださいという話です。
0176デフォルトの名無しさん2014/01/18(土) 00:11:01.37
プロジェクトでコーディングする場合、一番必要なのは不自由さだ
自由を一切認めず、ただ黙々と単調で枠にはまった定番のコードを書き続けるよろし

独創性を発揮する連中は足でも撃っておとなしくさせるべき
0177デフォルトの名無しさん2014/01/18(土) 00:15:17.42
>>176
半分正解で半分間違い。
0178デフォルトの名無しさん2014/01/18(土) 00:17:08.68
そうだね。簡単にいえば、

独創性を発揮して、単調で型にはまった定番のコードにしていく

ってことかな。
0179デフォルトの名無しさん2014/01/18(土) 00:23:39.71
まずね、初期の段階は各人がそれぞれ技術レベルの違う
コードを好き勝手書いてる段階になると思う。

これは良くない。

で、単調で型にはまった定番コードにみんな足並みそろえるわけだけど、
その単調なコードというのを作るのには、独創性が必要になる。

あたりまえだけど、単調でも冗長なコードはだめ、無駄が多いからね。
だから単調かつ短いコードにしなきゃいけないんだけど、
それには高い技術力と独創性が必要になる。

そうすると一連のコードが、独創性が必要な汎用性が高いが
一度作れば終わりのコードと、単調だけど短いコードに分かれていく。
この作業をどんどんつき進めていって、単調なコードをどんどん短くしていく。

単調なコードを短くするには、独創性が高いコードを単調なコードから抜き出していく作業。
だから単調で型にはまった定番のコードを作るために独創性が必要になる。
0180デフォルトの名無しさん2014/01/18(土) 00:30:12.12
単調なコードを作るのに必要なのは独創性ではない
必要なのは　「ここ分かりにくいと思います」　と口にする勇気だけだ
0181デフォルトの名無しさん2014/01/18(土) 00:31:02.58
>>179
おまえuyだろ
0182デフォルトの名無しさん2014/01/18(土) 00:32:35.87
>>171
アジャイルって、どのタイミングで仕様かためるんだ？
0183デフォルトの名無しさん2014/01/18(土) 00:34:14.72
仕様というか、今から書こうと思ってるコードの動作確認の方法が事前に分かってないというのはダメだと思うんだ
0184デフォルトの名無しさん2014/01/18(土) 00:37:42.51
>>180
「わかりにくいと思います」じゃただ口に出しているだけ。

じゃあどうすればいいかという答えが出なければ
なにも変わらない。

その、どうすればいいかという答えをだすのに
独創性が必要になるんだよ。もちろん技術力もね。
0185デフォルトの名無しさん2014/01/18(土) 00:54:07.39
独創性の排除、没個性化、簡潔化ほど評価されるんじゃないのか
簡潔にならない独創性なんて、闇の力に魅入られた中学生ぐらいだろ
0186デフォルトの名無しさん2014/01/18(土) 00:58:02.74
単純な独創性の排除は、
やる気が失われることになるので
生産性が下がるんだよ。

それに、改善は一度やれば終わりではなく
ずっと繰り返しやり続けること。

つまり次はどんな改善を行うか？ という発想が
常に必要ってことだよ。
何も考えない脳ではできない作業
0187デフォルトの名無しさん2014/01/18(土) 01:08:02.31
>>184
どうすればいいかは、定番のきまりきった答えがあります
車輪の再発明はしないでください

万が一、定番の答えが存在しない問題にであった場合は、一旦作業を止めて、グループの中で一番独創性がない人に合せて、みんなでコーディングについて同意をとってください
あなたが独創性を発揮して解決しても、他の人が同じ答えにたどりつかず、プロジェクト全体でコーディング規則の不統一や保守性の低下をもたらします
0188デフォルトの名無しさん2014/01/18(土) 01:13:47.13
>>186
単純な独創性の排除は、人間性が失われることになるので、自動化可能な範囲や能力が低い派遣での置き換え可能性が広がり、生産性が上がる
やる気は、自動化の方向や、あなたの仕事を削除する方向に回してください
0189デフォルトの名無しさん2014/01/18(土) 01:16:01.87
>>187
定番の答えでできるレベルの、その先の話だよ。
定番でできる範囲を超えた更にその先、もしかしたら
誰もやったことにないことをやるのだから
高い技術力と独創性が必要になるわけ。
0190デフォルトの名無しさん2014/01/18(土) 01:17:50.59
>>187
> グループの中で一番独創性がない人に合せて

それはやらない方がいい。

ようは他の人が足を引っ張られてるってことだから。


足を引っ張られてもそれを補うぐらいの、コスト（人を沢山使える）
ならばやっていいと思うよ。

でも大多数に少人数かいはつでは、足を引っ張られたらおしまい。
0191デフォルトの名無しさん2014/01/18(土) 01:18:48.23
>>188
> やる気は、自動化の方向や、あなたの仕事を削除する方向に回してください

だから自動化をするのにも独創性と技術が必要になるんだよ。
0192デフォルトの名無しさん2014/01/18(土) 01:19:11.16
>>189
もっとはっきりと「誰もやったことにないことをやるな」と言えばお分かりいただけるでしょうか…
0193デフォルトの名無しさん2014/01/18(土) 01:20:49.70
>>192
誰もやったことがないことをやるなって、
AmazonやGoogleに言ってみるといいよ。

負け犬の遠吠えに見えるだろうね。
0194デフォルトの名無しさん2014/01/18(土) 01:22:43.62
Amazonとか独創性をもって
自動化を進めてきた企業の一つだろうね。
商品ピッキングシステムとかAWSとか
0195デフォルトの名無しさん2014/01/18(土) 01:23:01.89
>>190
他の人の足を引っ張るのは、独創性がない人ではなく、3ヶ月後の自分ですら読むことのできない独創的なコードを書くバカ

>>191
その独創性は、コードには出さないでね
0196デフォルトの名無しさん2014/01/18(土) 01:25:22.55
>>195
お前、独創的と、汚いコードをごっちゃにしてるぞ。
お前が言ってるのは単なる汚いコードだ。

違うというのなら、その汚くない独創的なコードの
例を出してみろよ。出せないだろう？
それが答えだよ。
0197デフォルトの名無しさん2014/01/18(土) 01:29:37.61
>>193-194
AmazonやGoogleで使ってるプログラムの、コードの各ブロックに独創性があると思いますか？
100万円かけろと言われれば、「ありません」の方にかけます

AmazonやGoogleの独創性は、コーディングよりももっと上のシステムで議論するときに発揮されています
0198デフォルトの名無しさん2014/01/18(土) 01:33:56.91
>>196
もっとはっきりと「あなたが低いIQでしぼりだした独創的なコード＝世界のプログラマが定番にしなかった汚いコード」 と言えばおわかりいただけるでしょうか…
0199デフォルトの名無しさん2014/01/18(土) 01:38:00.20
c++の式テンプレート使ってるublasなんて独創的で綺麗だけど読めない
0200デフォルトの名無しさん2014/01/18(土) 01:39:14.33
>>197
さっき書いたでしょ？

コードは独創的な部分とそうではない部分に分かれるって。

一連のコードを二つに分けるんだよ。
独創的な部分（ライブラリだったりフレームワークだったり）を頑張って作り、
そして、つまらない単調なコードをどんどん減らしていく。

AWSのおかげでつまらない単調なサーバーメンテナンスから解放されて
より高度なサーバー管理システムと呼べるようなことができるようになったよ。

これが改善なんだよ。単に流れ作業をしている人にはできないこと。
0201デフォルトの名無しさん2014/01/18(土) 01:39:15.43
おまえらはboostコミュニティの書いた生成物を読むべき
わたしはCやJava、PHPをつかう。
0202デフォルトの名無しさん2014/01/18(土) 01:40:05.91
>>199
技術力が低い人が読めないのは
単に技術力が低いだけだから・・・。
0203デフォルトの名無しさん2014/01/18(土) 01:41:51.66
独創性や技術力があっても金になるとは限らない
むしろ、人類の共有文化にすべきといった価値観が広まっている
0204デフォルトの名無しさん2014/01/18(土) 01:44:14.97
> 独創性や技術力があっても金になるとは限らない
それは当たり前だろｗ

高い技術を持っているはずの技術研究機関が
儲かる商売だと思っている人はいないよ。
0205デフォルトの名無しさん2014/01/18(土) 01:49:50.14
結局のところ、技術力が高かろうが低かろうが商売になる
金にならないのは技術者以外の誰かがボンクラなのだ
0206デフォルトの名無しさん2014/01/18(土) 01:59:24.31
Web脳の奴って、本当にアホで
サーバーの自動化とフレームワークぐらいしか想像力が働かない
そういう連中が宣う技術力とは何なのか。ただの雑用ではないのか。
PHPで、歯でも磨いてろよ
0207デフォルトの名無しさん2014/01/18(土) 02:09:43.68
>>206
別に俺は他のものも思いつくけど、

実はお前が思いつかないから、
それだけしか言えないんじゃないの？

サーバーの自動化とフレームワーク以外の物を
言ってみなよ。
0208デフォルトの名無しさん2014/01/18(土) 02:40:36.53
>>207
そんなものいくらでも思い付くが、だからどうした
Web脳のアホ連中が新しいフレームワークと
サーバーの自動化を追い続けること技術力だとか
アホの子みたいに繰り返している事実が変わるの？
0209デフォルトの名無しさん2014/01/18(土) 02:42:06.49
いや、お前がそういうことにしたいってだけだろう？
0210デフォルトの名無しさん2014/01/18(土) 02:44:58.90
なら、おまえは反例をあげろ
0211デフォルトの名無しさん2014/01/18(土) 02:55:08.72
いや、その前に、お前が質問に答えろよ。

そもそも、なにかいいたいのなら
最初に証明するのはそっちの仕事だし。

いいよ別に答えなくて。
どうせ会話する価値の無い人間だってわかってるから。
0212デフォルトの名無しさん2014/01/18(土) 02:57:53.01
>>211
会話する価値がないならなんでレスしてたの？おまえ、バカだろ
0213デフォルトの名無しさん2014/01/18(土) 03:00:23.24
暇つぶしだけど？
0214デフォルトの名無しさん2014/01/18(土) 03:01:12.60
つまり暇つぶしの相手としての価値は
あるってことじゃないですかー
0215デフォルトの名無しさん2014/01/18(土) 03:01:24.01
>>213
自分の価値のなさを認めて、死ね
0216デフォルトの名無しさん2014/01/18(土) 03:02:28.69
未だにWeb脳とか言って引きこもってる奴いるんだな
よく生きてられんねｗ
0217デフォルトの名無しさん2014/01/18(土) 03:04:18.16
あれだろ？ 自分はまだましなんだみたいな。
0218デフォルトの名無しさん2014/01/18(土) 03:06:23.67
何？今のトレンドって、鍬持って畑耕すこと？
0219デフォルトの名無しさん2014/01/18(土) 03:10:36.15
ノマドがnodeへ行き農奴になったと
0220デフォルトの名無しさん2014/01/18(土) 03:12:00.39
解説おつ
0221デフォルトの名無しさん2014/01/18(土) 03:17:29.25
すみません。どなたか畑を耕すgemを存じないでしょうか？
0222デフォルトの名無しさん2014/01/18(土) 03:21:01.59
>>221
つ http://www.megahobby.jp/products/item/1129/
0223デフォルトの名無しさん2014/01/18(土) 03:30:39.70
OSSの耕耘機のURL貼って自演しようとしてたんだから邪魔するな厨房
ttp://www.ted.com/talks/marcin_jakubowski.html
こういうのが技術力だアホカスども。
0224デフォルトの名無しさん2014/01/18(土) 09:37:16.88
昔、ブラックSIerの代表NTTとSRAが絡んだプロジェクトに入ったことが
あるのだが...

そこで提示されたC/C++のコーディング規約が、

マクロは使ってはいけない。.......... ハァ？
テンプレートは使ってはいけない。.......... ハァ？
0225デフォルトの名無しさん2014/01/18(土) 09:46:12.85
俺は理由が書いていないルールは禁止
というルールを持っているんだけど、
マクロやテンプレートを使ってはいけないルールには
理由が書いてあった？


なお、理由が書いていないルールは禁止いうルールにも
もちろん理由は書いてある。
0226デフォルトの名無しさん2014/01/18(土) 10:11:53.18
>>225
確か理由は、コードが追いづらい、読みにくいだったかと。(w

ちなみに、NTTによると統計上平均100行に1つのバグがあるので、
コード行数に対してバグレポート数がそれ以下の数だと、コード
レビューやテストが足らんらしい。

足らないのはNTTのエンジニアのスキルだろと思うたYO。
0227デフォルトの名無しさん2014/01/18(土) 10:39:24.94
自動車の自動安全停止装置への反応とかを見てると、
テスト自動化することによって100件中99件の不具合が未然に防止されたとしても、
残り1件が発生したら鬼の首を取ったかのように叩かれるんだろうな。
0228デフォルトの名無しさん2014/01/18(土) 10:39:47.24
マクロ使うな。コードが追いづらくなるから。
→よーし、いっちょやってやるか

テンプレート使うな。コードが追いづらくなるから。
→ハア？やってらんねーよ！

>>226データじゃなくて？
0229デフォルトの名無しさん2014/01/18(土) 10:44:31.79
マクロ使うなテンプレート使うなって、もちろん新規に作るなって意味だよね？
0230デフォルトの名無しさん2014/01/18(土) 10:50:26.25
OSSのハードウェア開発なんてmolphy oneの事が頭に浮かんでくるので、
胡散臭さしか無いなぁ。
0231デフォルトの名無しさん2014/01/18(土) 12:09:19.48
C++ ならマクロは禁止も有りかな
テンプレートも組織によってはメリットよりデメリットの方が大きいし
NTT 系ならあり得る話
0232デフォルトの名無しさん2014/01/18(土) 13:07:44.83
未熟なエンジニアを排除せずきちんと仕事を与えることが出来るすばらしい企業じゃないか
0233デフォルトの名無しさん2014/01/18(土) 13:24:02.00
>>226
漏れは、最初からあまりバグを出さないから、
テストでバグの件数を満たすため、
いつもわざとバグを作っている

これが結構疲れる。しかもこのルールのせいで、
本当にバグが増えるw

ほんまに、くだらんルールだよ
バグの数には、個人差があるのに
0234デフォルトの名無しさん2014/01/18(土) 13:34:28.96
>>233
もともとQAの元になる数字は公式的に導き出した数字じゃなくて統計的に出た
数字っていうのを知らない、理解できないって人が多いのが第一の不幸で、
そもそも統計って何？的な文系の人間が大量にいるのが第二の不幸だよな。
統計的に出た数字は絶対的な指標になんてなりえないのに。
0235デフォルトの名無しさん2014/01/18(土) 13:46:11.68
まね〜じゃ〜などという中途半端な役職を作ったもんだから
それが仕事してるフリをするために必要なんだよ
0236デフォルトの名無しさん2014/01/18(土) 15:56:18.31
全体レビュー会でバグ収束曲線についてしたり顔で語ってた役員
いまどこでどうしてるかなあ
0237デフォルトの名無しさん2014/01/18(土) 16:21:14.03
動的言語だとメソッド名変更ですら
手作業でやる必要があるから
ユニットテストは必要

静的言語なら不要
0238デフォルトの名無しさん2014/01/18(土) 18:06:30.65
boostは危険だよなー。
0239デフォルトの名無しさん2014/01/18(土) 18:27:35.71
同僚が無能だと感じるのは心が弱いから
コーディング規約が無意味だと感じるのも心が弱いから
単体テストが不要だと感じるのも心が弱いから
boostが危険なのはboostに心を許した己の心の弱さから。
結局、すべては心の問題。
ttp://wired.jp/2013/12/29/enlightenment-engineers-vol9/4/
0240デフォルトの名無しさん2014/01/18(土) 18:32:22.96
テストは心の弱い人がすることですよ。

テストを通したから大丈夫なんだって安心したいだけなんですよ。
無意味だって事は判っているんですホントは。
心の弱さなんですよね。
0241デフォルトの名無しさん2014/01/18(土) 18:54:11.88
同僚が無能だと感じるのは心が弱いから .......... 単体テストが実行されていません
コーディング規約が無意味だと感じるのも心が弱いから .......... 単体テストが実行されていません
単体テストが不要だと感じるのも心が弱いから .......... 単体テストが実行されていません
boostが危険なのはboostに心を許した己の心の弱さから。 .......... 単体テストが実行されていません
結局、すべては心の問題。 .......... 単体テストが実行されていません

まず、テストコードを書いてください。
0242デフォルトの名無しさん2014/01/18(土) 19:02:20.68
強い心があればテストなんて必要ない。
0243デフォルトの名無しさん2014/01/18(土) 20:27:44.98
強い心で仕様だと言い張ればバグではない
0244デフォルトの名無しさん2014/01/18(土) 21:29:08.62
顧客を打ち負かす勇気！
0245デフォルトの名無しさん2014/01/18(土) 21:36:02.90
私が神です
0246デフォルトの名無しさん2014/01/18(土) 21:41:44.09
発注したことを誤りと認め悔い改めよ
0247デフォルトの名無しさん2014/01/18(土) 21:50:05.02
食いあらためよ。
0248デフォルトの名無しさん2014/01/18(土) 21:56:20.80
神は全てのバグを許されるでしょう
0249デフォルトの名無しさん2014/01/18(土) 22:02:32.96
髪はどこへ行った？
0250デフォルトの名無しさん2014/01/18(土) 22:06:59.92
髪は全てのハゲを見放すでしょう
0251デフォルトの名無しさん2014/01/18(土) 22:15:01.67
強い心で仕様だと言い張ればハゲではない
0252デフォルトの名無しさん2014/01/18(土) 22:16:05.89
全体レビュー会でハゲ収束曲線についてしたり顔で語ってた役員
いまどこでどうしてるかなあ
■ このスレッドは過去ログ倉庫に格納されています