1仕様書無しさん2018/10/29(月) 19:39:29.27
機能追加や変更した時に、全部テストしてるでしょ？
いつもやってることじゃん
よくある応答のパターン
1. 必要もないのにリファクタリングを勝手にやるな
⇒ 客などから修正を要求するときに行うので、勝手にやることはありません
2. 修正の指示は出したがリファクタリングの指示は出してない
⇒ 修正工程の一つに含まれる作業なので修正と分離することは不可能です
3. リファクタリングすると動きが変わるだろ
⇒ 動きを変えないのがリファクタリングです
4. リファクタリングしたら全部テストしなきゃならないだろ
⇒ 修正しろと客などから言われたんだから修正するしか無い
どちらにしろ全部テストするんだろう？
前スレ
ﾘﾌｧｸﾀﾘﾝｸﾞすると全部ﾃｽﾄしろと言ってくる奴の矛盾2
http://2chb.net/r/prog/1526720757/ 2仕様書無しさん2018/10/30(火) 00:34:02.46
え？でもやっぱり今回の改修で他の機能までバグるのはおかしいですよね？
共通ルーチン？
なんで分けて改修しないんですか？
テスト全部やり直してくださいよ
もう一回やったら訴えますよ
これが現実
震えて眠れ
3仕様書無しさん2018/10/30(火) 01:30:02.07
> 共通ルーチン？
> なんで分けて改修しないんですか？
分けて二箇所改修する意味は？
4仕様書無しさん2018/10/30(火) 01:31:48.92
え？でもやっぱり今回の改修でバグは治ったんじゃないんですか？テストしたんですよね？
テストはした箇所は治っていました。ですが似たような箇所で同じような計算をしていて
そちらは治っていませんでした。軽く検査した所、同じような計算が10箇所ありましたので
その改修とテストに今回の10倍の時間と費用がかります。
5仕様書無しさん2018/10/30(火) 01:31:54.29
6仕様書無しさん2018/10/30(火) 01:34:55.63
なんで共通化しないんですか？
それはね。あなたから開発費をせしめるためですよ
7仕様書無しさん2018/10/30(火) 01:35:30.51
>>5
共通ルーチン使っていて、片方は問題ないなんてありえないよ
どういう場合にそうなるんだよｗ 8仕様書無しさん2018/10/30(火) 01:57:05.61
片方問題がなかったら、それはもう設計時点の問題だな
違う処理であるべきなのに、同じ処理にしてしまったんだから
9仕様書無しさん2018/10/30(火) 06:54:44.63
>>7
え？想像力がたりなさすぎない？
一つは精度が必要なときとかfloatで十分、doubleでないとダメ
条件が特定のルーチンしか通らないとか
いくらでもあるぜ
お前一つも浮かばなかったの？
プログラマやめちゃえよ
設計なんか語るレベルにないじゃん 10仕様書無しさん2018/10/30(火) 07:38:48.78
> 一つは精度が必要なときとかfloatで十分、doubleでないとダメ
修正内容が「精度を上げたい」なら共通関数を変更するべきだが、
「一箇所だけ精度を上げたい」ならば、そのときに分ければいいの
おかしいでしょ？精度を上げたい箇所を明確にしないまま作業するなんて
まず先に精度を上げたい場所がどこかが決まる。
そしてそれはリファクタリングではなくて単なる仕様変更
一箇所だけ精度をえるという仕様変更
その違いもわからないなら、プログラマやめたほうがいいよ
11仕様書無しさん2018/10/30(火) 07:43:42.21
>>9
> 条件が特定のルーチンしか通らないとか
設計が破綻してる
func() { A処理 and B処理 } があって？
一つは、A処理 B処理 両方通って
もう一つが A処理 のみしか通らないなら
func 内部で条件フラグとかで分けるんじゃなくて
呼び出し側で、A処理を行うA() と B処理を行うB() を呼び出す
もう一つは、A処理を行うA() のみを呼び出すの
クソコードによくある。長い関数でグダグダやっていて
特定の場合だけ処理を分けたいから、フラグを追加してフラグみて
片方だけ実行とかね。ほんとコレ、クソコード 12仕様書無しさん2018/10/30(火) 08:00:14.00
>>9
> 条件が特定のルーチンしか通らないとか
そもそも言ってることがおかしくない？
func() { Aルーチン and Bルーチン } があって条件が特定のルーチンしか通らないんでしょ？
片方は Aルーチン と Bルーチンの 両方を通る。もう片方はAルーチンのみを通るということだ
修正箇所がBルーチンなら片方は修正されるし、もう片方はそもそも通らないのだから関係ない話
だからAルーチンが修正箇所ということになるが、
「条件が特定のルーチンしか通らない」とはどういうことだ？
両方共、修正箇所のAルーチンを通ってるではないか？ 13仕様書無しさん2018/10/30(火) 08:02:02.33
一言で言うならば共通関数の中に、
AルーチンとかBルーチンのようなエリアができてる時点でクソ
14仕様書無しさん2018/10/30(火) 08:15:30.49
「精度上げてっていったのに上がってないんだけど？」
この関数は上げましたよ？でも他の部分がfloatのままなので
他に渡すときにfloatに変換されますねぇ
他の部分を変更しろとは言われてないしーｗｗｗ
15仕様書無しさん2018/10/30(火) 08:15:55.30
16仕様書無しさん2018/10/30(火) 21:26:03.00
たいていけんか腰のやつって中身のない議論するんだよなあ
17仕様書無しさん2018/10/31(水) 00:33:03.79
18仕様書無しさん2018/10/31(水) 05:16:08.64
共通関数があるとしてfloatかdoubleにコードを統一できないなら
単にfloat版とdouble版の関数を作るだけだろ
例えばこんな感じに
https://linuxjm.osdn.jp/html/LDP_man-pages/man3/clog10.3.html
> double complex clog10(double complex z);
> float complex clog10f(float complex z);
> long double complex clog10l(long double complex z);
>
> 他の関数は同じ機能を持つ float 版と long double 版である。
何かを修正するのと、新しく精度違う版が必要になった（機能追加）のを
ごっちゃにするんじゃねーよ 19仕様書無しさん2018/10/31(水) 07:15:32.13
>>18
じゃあ、そういう修正が入っても既存は一切いじらないって主張でいいんだよね？ 20仕様書無しさん2018/10/31(水) 17:14:17.74
>>19
まず「そういう修正」の中身を明らかにしようか？
floatをdoubleに変えるのは"仕様変更"である
リファクタリングは仕様を変えないものなのだから
仕様を変えると言っている以上、これはリファクタリングではない
リファクタリングなら当然既存を修正する
繰り返すが、既存を修正する
お前が言ってる「そういう修正」の中身は
「他の処理は変えずに一部分だけ精度を上げるという仕様変更のための修正」だ 21仕様書無しさん2018/10/31(水) 17:20:06.36
え？でもやっぱり今回の改修で他の機能までバグるのはおかしいですよね？
リファクタリングもしたからバグったって？
いやいや、リファクタリングをは動きを変えないものだから
それでバグるわけ無いでしょ？
改修内容を間違えたんですよね。一部分だけ修正しろと言ったのに
全部修正したんですよね？リファクタリングのせいにしないでください
もう一回うそついたら訴えますよ
これが現実
震えて眠れ
22仕様書無しさん2018/10/31(水) 17:25:09.87
>>21
まあ、人間である以上いじったらバグる可能性は残るんだよ
君は信用できない 23仕様書無しさん2018/10/31(水) 17:28:45.81
ウチとエンドの客の受入れ試験のお金も君が出してくれるならその範囲を変更してもいいよ
って普通に言われるだろ
仕事はお前だけが回してるわけじゃない
小さい会社でばっかり組んでるとヤバイな
24仕様書無しさん2018/10/31(水) 18:01:35.14
>>23
修正する以上、テストするだろ？
リファクタリングは修正に関する部分しかしないんだから
テストの工数はすでに計上済み 25仕様書無しさん2018/10/31(水) 18:02:20.54
>>22
> まあ、人間である以上いじったらバグる可能性は残るんだよ
だから修正範囲のテストをするんですよね？
それとも修正をするなと？
客から言われてるのに？ 26仕様書無しさん2018/10/31(水) 18:17:28.96
>>25
え？だからお前のはいらんとこに手を広げて関係ない機能まで修正入るんだろ？
共通処理使ってるからって理由だけで 27仕様書無しさん2018/10/31(水) 18:25:28.78
>>26
何度も言うが、リファクタリングは動きを変えないものなんだから
共通処理を変えた所で動きは変わらない
修正内容が共通処理部分なんだろ？
ならリファクタリングしなかったとしても共通処理を修正するだろ
ということでここからはリファクタリングとは関係ない話だぞ
なら共通処理を修正するなら、テストもするわけだ
共通処理をコピーしたとしても、テストの数は変わらない
俺はあたり前のことしか言ってないぞ 28仕様書無しさん2018/10/31(水) 18:28:04.96
リファクタリングといいながら、リファクタリングとは
関係ない話ばっかりしてるんだもんなぁｗ
あきれるよ。
単に共通処理を修正（仕様変更）する時、
コピーして修正（仕様変更）するか
コピーせずに修正（仕様変更）するの話じゃんか
29仕様書無しさん2018/10/31(水) 18:36:42.44
>>27
動き同じでも触ったらテストするんだよ
おｋ？ 30仕様書無しさん2018/10/31(水) 18:36:50.17
今回の修正で共通処理をいじったんだな？
ちゃんと共通処理のテストをしたのか？
共通処理の中は、エリアが２つに分かれていて、
今回の修正で影響がある部分はテストしました
どういう意味だ？
今回のテストは共通処理の中のエリアBを通りますが、
他の部分からエリアBを通る部分はないはずです。
だから他の部分は影響がないはずです。
だから共通処理を修正しましたが、共通処理自体のテストはしてません
今回の修正内容に関する部分だけテストしました。
テストやり直しな
31仕様書無しさん2018/10/31(水) 18:37:51.23
>>29
> 動き同じでも触ったらテストするんだよ
そこは今回の修正対象ですよね？
なら最初からテストするに決まってるじゃないですかｗ 32仕様書無しさん2018/10/31(水) 18:38:14.72
>>27
動きが同じってどこまで？
メモリの使い方も同じなの？ 33仕様書無しさん2018/10/31(水) 18:39:16.81
>>31
いいや
お前のはやらなくていい範囲まで手を出してるよね？ 34仕様書無しさん2018/10/31(水) 18:40:19.27
>>33
やらなくて良い範囲は手を出しませんよ？
何いってんの？
今回の修正する範囲、テストする範囲しか
リファクタリングしませんｗｗｗ 35仕様書無しさん2018/10/31(水) 18:41:32.14
>>33
まさか、共通処理を修正しているくせに
共通処理の一部分は通らないはずだから
テストしなくていいとか言ってんの？ｗｗｗ 36仕様書無しさん2018/10/31(水) 18:43:55.61
>>32
> メモリの使い方も同じなの？
メモリの使い方が仕様に明記されてるならその通りでしょうね
（明記されてないなら何が正しいかも決められないわけで、
正しいことをテストできない） 37仕様書無しさん2018/10/31(水) 19:25:29.91
>>35
だから俺はしない
分離しちゃう
リファクタリングなんてソースの修正範囲を広げる愚行などもってのほかだ 38仕様書無しさん2018/10/31(水) 19:26:13.32
39仕様書無しさん2018/10/31(水) 19:44:15.27
>>37
> だから俺はしない
> 分離しちゃう
だからリファクタリングの話関係ないじゃん
バグ修正の場合も分離するの？
あちこちでバグ起きてるんだけど？ 40仕様書無しさん2018/10/31(水) 19:45:00.61
>>38
> 動作は変えないんじゃなかったのか？
動きを変えないということは、
ソースコードをコピーしたりしてもだめだっていうのはわかってる？ 41仕様書無しさん2018/10/31(水) 19:46:10.79
訂正
× 動きを変えないということは、
○ メモリの使い方を変えないということは
いかなる修正を行っても、メモリの使い方は
変わるから・・・お前すべてのテストをしろって言いたいの？
42仕様書無しさん2018/10/31(水) 19:50:11.58
>>39
リファクタリングとは関係ない話だけど
ソースコードコピーしたら、その分テスト工数が増えるじゃん 43仕様書無しさん2018/10/31(水) 19:53:12.18
リファクタリング否定派だと思っていたら、
まさか関数否定派だったとはｗ
共通処理禁止、コードをコピペして使え
バグが見つかったら、コピペした物すべて
探し出して修正しろ。そして全てテストしろ
44仕様書無しさん2018/10/31(水) 21:09:57.67
曲解ばっかりだな
リファクタリングなんてまともな職場なら許可なんて下りるわけない
45仕様書無しさん2018/10/31(水) 21:35:54.69
有名ソフトウェア企業はすべてリファクタリングの許可が降りてるのに？
46仕様書無しさん2018/10/31(水) 21:39:08.69
たいていというかほぼ全てがリファクタリングに取り組んでいるよな
やってないところはCOBOLに関係がある分野ぐらいか・・・
まあ、あそこは文化が違うからな
47仕様書無しさん2018/10/31(水) 21:51:48.53
まあそもそも許可とってやるもんじゃないし。
「修正」の中に含まれてるもんだからね
48仕様書無しさん2018/10/31(水) 22:03:50.26
>>47
は？
理由もないのに内部の造りまで変えたソースなんて品証通るわけねーだろ
コードレビューナメてるのか？ 49仕様書無しさん2018/10/31(水) 22:05:54.48
>>48
テストしてるから通るよ
ってか、なんのためにテストしてるの？ 50仕様書無しさん2018/10/31(水) 22:07:22.25
むしろ汚いコードで、コードレビューやれるのかって話だよなｗ
51仕様書無しさん2018/10/31(水) 22:09:20.37
コードレビューは難しいコードを何人もの人が何時間もかけて
解読する作業なんです。
チームの仲間が暗号コードを作成し
別の人が暗号コードを解読する。
それがコードレビューなのです。
そういう不毛なことをして喜んでいるんです。
52仕様書無しさん2018/10/31(水) 22:10:03.05
>>49
通る？
なぜ？
テメーの不必要な変更で増えた分のお客の受け入れテストの金と時間はどこから出るの？ 53仕様書無しさん2018/10/31(水) 22:11:39.53
俺も新卒のとき自分の作業しか見えなかったな
そのままおっさんになってるようなのは痛い
54仕様書無しさん2018/10/31(水) 22:12:14.14
>>52
だすもなにも、逆にコスト減るからなぁ
クソ汚いコードを何日もかけてコードレビューするのにくらべたら
綺麗なコードはほんの数分で終わってしまうこともざらにある 55仕様書無しさん2018/10/31(水) 22:14:04.64
汚いコードをばんって出されて、
このコードが正しいかどうか見てください！って言われても
コード汚いとそいつが作業した時間以上にかかるんだよ
コードレビューやるのにどれだけ時間がかかると思うのか
56仕様書無しさん2018/10/31(水) 22:16:09.81
許可なく自由にコードいじれるって凄いねｗ
自由な社風って素敵やん
57仕様書無しさん2018/10/31(水) 22:17:07.82
リファクタリングは動きを変えないので
テストはいまあるテストコードをそのまま流せばいいだけ
だからリファクタリングのコードレビューは、
単に自動テストが変更されていないかを確かめるだけでよい
必要なのは本質的な仕様変更に対する修正
この修正がリファクタリングされてないと複雑な修正になってしまう
リファクタリング後だと簡単な修正で済む
コードレビューも楽になる
58仕様書無しさん2018/10/31(水) 22:18:25.00
>>56
仕事を任せられるっていうのはそういうことやで
許可無いと仕事させてもらえないなら、
お前はその程度ってことだ 59仕様書無しさん2018/10/31(水) 22:24:15.14
無駄な改行までしちゃってｗ
煽りたくて必死って感じかな？
60仕様書無しさん2018/10/31(水) 22:26:44.29
お前はその程度ってことだ（ｷﾘｯ
61仕様書無しさん2018/10/31(水) 22:26:52.81
とうとう捨て台詞ｗ
62仕様書無しさん2018/10/31(水) 22:36:36.70
相当悔しかったんだろｗ
そういう奴にはコレを言ってやれ
お前はその程度ってことだ
63仕様書無しさん2018/10/31(水) 22:47:10.48
早速コピペｗｗｗ
使い捨てにされるってのは所詮そこまでの奴
俺ならそいつにこう言ってやるね
お前はその程度ってことだ
64仕様書無しさん2018/10/31(水) 23:02:07.47
オウム返しは負け犬の証ですよ
65仕様書無しさん2018/10/31(水) 23:05:41.29
誰もオウム返してないってｗ
66仕様書無しさん2018/10/31(水) 23:10:16.98
リファクタリング肯定派なんてこの程度の集まりか
草ばっか生やしちゃってさ・・・
がっかりだよ
67仕様書無しさん2018/10/31(水) 23:15:47.32
反対派が何も言い返せなくなったんじゃんかｗ
言い返せることがあるなら言い返せばいいんだぞ
話ならいくらでも続けてやる
68仕様書無しさん2018/10/31(水) 23:16:59.35
まず、リファクタリングといいながら
仕様変更というリファクタリングとは関係ない話に
すり替えようとしたのは何故だ？
そしてテストする箇所が増えるのに
コードをコピーするのは何故だ？
69仕様書無しさん2018/10/31(水) 23:18:00.56
意味もなく煽る
無駄に改行
とにかく草
これがﾘﾌｧｸﾀ厨
70仕様書無しさん2018/10/31(水) 23:19:42.00
ほらこれだ
71仕様書無しさん2018/10/31(水) 23:20:40.83
技術者としての向上心を捨てるって、こわくない？
72仕様書無しさん2018/10/31(水) 23:23:48.30
もっと怖いのは、会社が技術力を必要としなくなったときだな
そこで働いているのはひたすら奴隷よ
替えのきく奴隷
73仕様書無しさん2018/10/31(水) 23:24:38.65
ほらな
話すりかえてすぐ逃げる
74仕様書無しさん2018/10/31(水) 23:27:14.94
仕方ないよ。リファクタリングを理解できない程度なんだから
75仕様書無しさん2018/10/31(水) 23:33:01.94
うーん？
リファクタリングなどの技術力って基本的にポータブルなスキルだから、会社がどうこうは関係ないよね。
76仕様書無しさん2018/10/31(水) 23:37:39.41
ただのコードの整理を理解もくそもない
77仕様書無しさん2018/10/31(水) 23:38:22.05
つぶしがきく技術ってことだな
78仕様書無しさん2018/10/31(水) 23:41:04.44
79仕様書無しさん2018/11/01(木) 19:54:54.74
一人で自作自演してｗ
極端すぎるからお前の意見なんてまともなやつなら同調しねーよｗ
80仕様書無しさん2018/11/01(木) 20:06:32.64
うるせーよ。いいからお前はリファクタリングは
意味がないに同調してればいいんだよ
81仕様書無しさん2018/11/02(金) 06:11:13.68
このスレ見てからリーダブルコード買って読んだんだけど
あんなのは労働基準も社内ルールも全く違う国の夢物語
いまだ縦社会の日本じゃ到底実現不可なのが現状だよ
82仕様書無しさん2018/11/02(金) 10:20:02.40
そうか、やはりリーダブルコードの世界が "夢" なんだな
83仕様書無しさん2018/11/04(日) 10:14:59.39
>>81
大手ゼネコンの多重受けみたいな場合でもなければ融通は効くでしょう
環境のせいではなく不勉強で過去の踏襲しかしないタイプのリーダーしか居ないことが本当の問題
彼らは比較的自由にできるチャンスがある案件でも日本風のやり方しかできない 84KAC2018/11/05(月) 00:43:36.75
そもそも、リファクタリングで同じものができるなんてのは幻想。
絶対に体外的な仕様に影響がでる。
この事実を理解しいいないバカがリファクタリングすると大変なことになる。
85仕様書無しさん2018/11/05(月) 01:09:14.70
> そもそも、リファクタリングで同じものができるなんてのは幻想。
> 絶対に体外的な仕様に影響がでる。
でるわけないじゃんｗ
リファクタリングで使用するテクニックは
動きが変わらないと保証されてるものばかり
数学の式の変形とやってることは変わらん
86仕様書無しさん2018/11/05(月) 01:56:23.54
でもテストはやれよな
いじったとこの影響範囲全部
87仕様書無しさん2018/11/05(月) 05:49:48.56
>>86
基本的には元々あるテストを流すだけ
ベンチマーク追加して、リファクタリングの有効性を示すことはあるけど 88仕様書無しさん2018/11/05(月) 07:05:27.53
>>87
元々あるテストを流すだけってなんや？
何十人も動員して、エクセルに書いたテスト仕様書の
通りに実行してテストするんやで
テスト仕様書が曖昧で、毎回これどういう意味ですか？って聞かれるは、
人によってやり方が微妙に違うわで、正しくテストしているか不安だから
同じテストを何人も使って行うんやで
どれだけ金がかかってると思う？
コストがかかるから一年に数回しかできない
その数回で確実なテストを行うんだ。
これが真面目な仕事ぶりっていうもんや
根性見せろや 89仕様書無しさん2018/11/05(月) 07:23:01.87
>>88
だよね
明らかに作るより金かけてるもんね
テスト流すだけって頭おかしいわ 90仕様書無しさん2018/11/05(月) 07:36:06.93
91仕様書無しさん2018/11/05(月) 07:43:57.42
92仕様書無しさん2018/11/05(月) 07:48:08.67
>>91
え、ポチッとボタン押すだけのことがそんなに難しいの？ 93仕様書無しさん2018/11/05(月) 07:48:55.50
>>92
それ単体だけだろ？
結合とシステムテストは？ 94仕様書無しさん2018/11/05(月) 08:05:43.80
95仕様書無しさん2018/11/05(月) 08:07:33.28
96仕様書無しさん2018/11/05(月) 08:14:38.40
>>88
どうやら30年前の世界に生きてるやつがいるようだ 97仕様書無しさん2018/11/05(月) 08:32:38.30
30年前の世界を知ってる爺
50代スレに戻ってどうぞ
98仕様書無しさん2018/11/05(月) 08:52:19.59
>>93
> 結合とシステムテストは？
どういう意味？
結合とシステムテストでバグが一つでも見つかったら、
修正しなきゃいけないってことで、
修正するならば、全部テストやり直しになるので
結合とシステムテストでは原則バグは見つからないという前提
それでもバグは見つかるので、
全部テストするコスト×数回分がテスト全体のコストになる
どれだけ高額になるかわかるだろう？
全部テストっていうのはそれだけのことを年数回やっている 99仕様書無しさん2018/11/05(月) 08:56:08.14
そのテストを自動化すれば、膨大なテストコストが削減できて、
信頼性も高いテストになりますけど？
100仕様書無しさん2018/11/05(月) 09:05:45.88
>>98
じゃあなんで動いてるコードいじったの？バカ？ 101仕様書無しさん2018/11/05(月) 09:11:24.93
>>100
いじってやるから一億よこせ
言い方は悪いが要約するとこういう契約が成立したから 102仕様書無しさん2018/11/05(月) 09:14:58.90
103仕様書無しさん2018/11/05(月) 09:15:01.04
>>99
お前なぁ
今更やり方なんか変えられないんだよ
仮に自動化してコストが大きく下がってみろ？
今までは何だったんだって問い詰められるだろ
かと言って楽してボッタクリなんてのも許されない
努力、根性＝仕事＝給料なんだから
> 信頼性も高いテストになりますけど？
コンピュータに信頼性も糞もあるかよ
エクセルなんて計算間違えるんだぞ
電卓のほうがまだ信頼できる
ソフトウェアはバグだらけで間違えるから
人間がテストしてると言うのに、
バグだらけのソフトウェアにテストさせてどうする？ 104仕様書無しさん2018/11/05(月) 09:15:52.56
>>103
> バグだらけのソフトウェアにテストさせてどうする？
あれ？矛盾してない？ｗ
> 結合とシステムテストでは原則バグは見つからないという前提 105仕様書無しさん2018/11/05(月) 09:16:33.97
106仕様書無しさん2018/11/05(月) 09:16:56.86
107仕様書無しさん2018/11/05(月) 09:17:21.85
>>104
アホか、ソフトウェアがバグだらけだから
人間が単体テストをして、結合とシステムテストで
バグがでないようにするんだろうが 108仕様書無しさん2018/11/05(月) 09:18:37.92
>>107
その理屈なら、人間がテストした「自動テスト」にはバグがないから
それを使って自動テストすれば良いのでは？ 109仕様書無しさん2018/11/05(月) 09:21:45.50
>>107
それ、単体テストで完璧なものに仕上げていれば
結合とシステムテストでバグが出ないって理屈だよね？
>>93で
> それ単体だけだろ？
> 結合とシステムテストは？
って単体テストしか自動化できない（そんなこと無いが）だろって
言ってるが、完璧に仕上げるべきは単体テスト
その重要な単体テストがしっかり自動化できていれば、
結合とシステムテストでバグが出ないのでは？ 110仕様書無しさん2018/11/05(月) 09:22:41.22
>>106
だから、何人も使って同じテストを行うんだろうが 111仕様書無しさん2018/11/05(月) 09:23:36.35
最近のやつは自動化とかいいやがって、
頑張るってことを知らねぇな
112仕様書無しさん2018/11/05(月) 09:37:43.03
113仕様書無しさん2018/11/05(月) 09:42:52.24
>>112
そこに書いてあるとおりやれ
でいいからある意味自動ｗ 1141092018/11/05(月) 10:02:56.81
あ、反論なくなっちゃったｗｗｗ
115仕様書無しさん2018/11/07(水) 16:16:45.76
単体テストを自動テストで済ます→分からんでもない
単体テストが完璧なら一度通った結合やシステムでバグは出ない→現実見ろ
いやぁ、ダメでしょ
116仕様書無しさん2018/11/07(水) 20:07:24.92
>>115
そのとおり。だから手動でテストする。
それが本当のテストというもの
自動テストに意味はない 117仕様書無しさん2018/11/07(水) 20:42:11.58
相変わらずの下手な煽りおつ
118仕様書無しさん2018/11/08(木) 01:43:37.41
>>116
いや、単体テストだけやればいい、という点が間違いなだけ
単体を自動テストでやろうが手動でやろうが、
結合テストやシステムテストはやらなきゃならん 119仕様書無しさん2018/11/08(木) 03:41:33.89
>>118
ならないなんて言ってないぞ。
毎回沢山の人を動員してテストをしている
自動化して楽をしようという根性がいかんといってるのだ
プロなら根性で頑張る。そのコスト意識を持てとということだ。
リファクタリングすると、沢山の人を動員を動員して
テストする＝膨大なコストがかかるという話だ 120仕様書無しさん2018/11/08(木) 03:41:59.99
× ならないなんて言ってないぞ。
○ （テストを）やらないなんて言ってないぞ。
121仕様書無しさん2018/11/08(木) 03:55:13.13
根性論を持ち出す人は大概声がデカいだけの無能
竹刀で叩かれながらうさぎ跳びで階段を登るレベルの時代錯誤
122仕様書無しさん2018/11/08(木) 08:30:28.59
>>119
単体テストの一部でも自動化したら、その分テスト工数が減るじゃん
で、減った工数でさらに品質を高められる
それを根性論で否定するのは無能と言わざるを得んな 123仕様書無しさん2018/11/08(木) 08:58:58.31
>>122
工数下がったらその分請求金額を下げないといけなくなるだろ
働いてないのに金を取るのはボッタクリというんだ
コンプライアンス守れ 124仕様書無しさん2018/11/08(木) 12:07:06.68
>>123
どう考えても同じ工数で品質を上げる方がいいと思うが 125仕様書無しさん2018/11/08(木) 13:56:50.80
126仕様書無しさん2018/11/08(木) 20:12:54.82
>>124
品質っていうのは高すぎてもだめなんだよ
必要もないのに無駄にコストをかけたことになるだろ
範囲内に収めるのが重要 127仕様書無しさん2018/11/08(木) 21:11:34.20
つまり何をやったらいくらって厳密に知ってる必要があるってことだな
128KAC2018/11/09(金) 01:00:09.01
>>124
ソフトウェアの品質は要求に対して柔軟に変えるもの。
QCDのコントロールはプロジェクト推進の基本だぞ？
>>123
「アウトプットが同じでも、かけた時間によって価格が変わる」
という商売は考え方がおかしい。
たとえば、いつも買っているお菓子が
「コンベアの速度落として生産性落とすので価格上げます」
と言われたら納得できる？
逆に機械新調してさらなる大量生産できるようになったら、
「価格を下げないのはコンプライアンス違反だ」と訴える？
派遣じゃないんだから、もう少しまともに商売を考えたほうがいい。 129仕様書無しさん2018/11/09(金) 02:16:07.62
>>128
おかしいとか言われてもね。
人月で請求金額出してるので
一人○○万円で○○日かかりますから
これぐらいの金額ですって言ってんだから
多少の誤差はあれど、この通りでなければならない。 130仕様書無しさん2018/11/09(金) 14:57:59.76
工数に対する単価には、品質の松竹梅があってだな。
