ﾘﾌｧｸﾀﾘﾝｸﾞすると全部ﾃｽﾄしろと言ってくる奴の矛盾3

■ このスレッドは過去ログ倉庫に格納されています
2018/10/29(月) 19:39:29.27
機能追加や変更した時に、全部テストしてるでしょ？
いつもやってることじゃん

よくある応答のパターン

1. 必要もないのにリファクタリングを勝手にやるな
⇒ 客などから修正を要求するときに行うので、勝手にやることはありません

2. 修正の指示は出したがリファクタリングの指示は出してない
⇒ 修正工程の一つに含まれる作業なので修正と分離することは不可能です

3. リファクタリングすると動きが変わるだろ
⇒ 動きを変えないのがリファクタリングです

4. リファクタリングしたら全部テストしなきゃならないだろ
⇒ 修正しろと客などから言われたんだから修正するしか無い
どちらにしろ全部テストするんだろう？


前スレ
ﾘﾌｧｸﾀﾘﾝｸﾞすると全部ﾃｽﾄしろと言ってくる奴の矛盾2
https://medaka.5ch.net/test/read.cgi/prog/1526720757/
2018/10/30(火) 07:38:48.78
> 一つは精度が必要なときとかfloatで十分、doubleでないとダメ

修正内容が「精度を上げたい」なら共通関数を変更するべきだが、
「一箇所だけ精度を上げたい」ならば、そのときに分ければいいの

おかしいでしょ？精度を上げたい箇所を明確にしないまま作業するなんて
まず先に精度を上げたい場所がどこかが決まる。

そしてそれはリファクタリングではなくて単なる仕様変更
一箇所だけ精度をえるという仕様変更

その違いもわからないなら、プログラマやめたほうがいいよ
2018/10/30(火) 07:43:42.21
>>9
> 条件が特定のルーチンしか通らないとか

設計が破綻してる

func() { A処理 and B処理 } があって？
一つは、A処理 B処理 両方通って
もう一つが A処理 のみしか通らないなら

func 内部で条件フラグとかで分けるんじゃなくて
呼び出し側で、A処理を行うA() と B処理を行うB() を呼び出す
もう一つは、A処理を行うA() のみを呼び出すの

クソコードによくある。長い関数でグダグダやっていて
特定の場合だけ処理を分けたいから、フラグを追加してフラグみて
片方だけ実行とかね。ほんとコレ、クソコード
2018/10/30(火) 08:00:14.00
>>9
> 条件が特定のルーチンしか通らないとか
そもそも言ってることがおかしくない？

func() { Aルーチン and Bルーチン } があって条件が特定のルーチンしか通らないんでしょ？
片方は Aルーチン と Bルーチンの 両方を通る。もう片方はAルーチンのみを通るということだ

修正箇所がBルーチンなら片方は修正されるし、もう片方はそもそも通らないのだから関係ない話

だからAルーチンが修正箇所ということになるが、
「条件が特定のルーチンしか通らない」とはどういうことだ？
両方共、修正箇所のAルーチンを通ってるではないか？
2018/10/30(火) 08:02:02.33
一言で言うならば共通関数の中に、
AルーチンとかBルーチンのようなエリアができてる時点でクソ
2018/10/30(火) 08:15:30.49
「精度上げてっていったのに上がってないんだけど？」

この関数は上げましたよ？でも他の部分がfloatのままなので
他に渡すときにfloatに変換されますねぇ
他の部分を変更しろとは言われてないしーｗｗｗ
2018/10/30(火) 08:15:55.30
>>13
それな
2018/10/30(火) 21:26:03.00
たいていけんか腰のやつって中身のない議論するんだよなあ
2018/10/31(水) 00:33:03.79
>>13
これに尽きる
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 版である。

何かを修正するのと、新しく精度違う版が必要になった（機能追加）のを
ごっちゃにするんじゃねーよ
2018/10/31(水) 07:15:32.13
>>18
じゃあ、そういう修正が入っても既存は一切いじらないって主張でいいんだよね？
2018/10/31(水) 17:14:17.74
>>19
まず「そういう修正」の中身を明らかにしようか？

floatをdoubleに変えるのは"仕様変更"である
リファクタリングは仕様を変えないものなのだから
仕様を変えると言っている以上、これはリファクタリングではない

リファクタリングなら当然既存を修正する
繰り返すが、既存を修正する

お前が言ってる「そういう修正」の中身は
「他の処理は変えずに一部分だけ精度を上げるという仕様変更のための修正」だ
2018/10/31(水) 17:20:06.36
え？でもやっぱり今回の改修で他の機能までバグるのはおかしいですよね？

リファクタリングもしたからバグったって？

いやいや、リファクタリングをは動きを変えないものだから
それでバグるわけ無いでしょ？

改修内容を間違えたんですよね。一部分だけ修正しろと言ったのに
全部修正したんですよね？リファクタリングのせいにしないでください

もう一回うそついたら訴えますよ

これが現実
震えて眠れ
2018/10/31(水) 17:25:09.87
>>21
まあ、人間である以上いじったらバグる可能性は残るんだよ
君は信用できない
2018/10/31(水) 17:28:45.81
ウチとエンドの客の受入れ試験のお金も君が出してくれるならその範囲を変更してもいいよ
って普通に言われるだろ
仕事はお前だけが回してるわけじゃない
小さい会社でばっかり組んでるとヤバイな
2018/10/31(水) 18:01:35.14
>>23
修正する以上、テストするだろ？
リファクタリングは修正に関する部分しかしないんだから
テストの工数はすでに計上済み
2018/10/31(水) 18:02:20.54
>>22
> まあ、人間である以上いじったらバグる可能性は残るんだよ

だから修正範囲のテストをするんですよね？
それとも修正をするなと？
客から言われてるのに？
2018/10/31(水) 18:17:28.96
>>25
え？だからお前のはいらんとこに手を広げて関係ない機能まで修正入るんだろ？
共通処理使ってるからって理由だけで
2018/10/31(水) 18:25:28.78
>>26
何度も言うが、リファクタリングは動きを変えないものなんだから
共通処理を変えた所で動きは変わらない

修正内容が共通処理部分なんだろ？
ならリファクタリングしなかったとしても共通処理を修正するだろ
ということでここからはリファクタリングとは関係ない話だぞ


なら共通処理を修正するなら、テストもするわけだ
共通処理をコピーしたとしても、テストの数は変わらない
俺はあたり前のことしか言ってないぞ
2018/10/31(水) 18:28:04.96
リファクタリングといいながら、リファクタリングとは
関係ない話ばっかりしてるんだもんなぁｗ
あきれるよ。


単に共通処理を修正（仕様変更）する時、
コピーして修正（仕様変更）するか
コピーせずに修正（仕様変更）するの話じゃんか
2018/10/31(水) 18:36:42.44
>>27
動き同じでも触ったらテストするんだよ
おｋ？
2018/10/31(水) 18:36:50.17
今回の修正で共通処理をいじったんだな？
ちゃんと共通処理のテストをしたのか？

共通処理の中は、エリアが２つに分かれていて、
今回の修正で影響がある部分はテストしました

どういう意味だ？

今回のテストは共通処理の中のエリアBを通りますが、
他の部分からエリアBを通る部分はないはずです。
だから他の部分は影響がないはずです。

だから共通処理を修正しましたが、共通処理自体のテストはしてません
今回の修正内容に関する部分だけテストしました。


テストやり直しな
2018/10/31(水) 18:37:51.23
>>29
> 動き同じでも触ったらテストするんだよ

そこは今回の修正対象ですよね？
なら最初からテストするに決まってるじゃないですかｗ
2018/10/31(水) 18:38:14.72
>>27
動きが同じってどこまで？
メモリの使い方も同じなの？
2018/10/31(水) 18:39:16.81
>>31
いいや
お前のはやらなくていい範囲まで手を出してるよね？
2018/10/31(水) 18:40:19.27
>>33
やらなくて良い範囲は手を出しませんよ？
何いってんの？

今回の修正する範囲、テストする範囲しか
リファクタリングしませんｗｗｗ
2018/10/31(水) 18:41:32.14
>>33
まさか、共通処理を修正しているくせに
共通処理の一部分は通らないはずだから
テストしなくていいとか言ってんの？ｗｗｗ
2018/10/31(水) 18:43:55.61
>>32
> メモリの使い方も同じなの？

メモリの使い方が仕様に明記されてるならその通りでしょうね
（明記されてないなら何が正しいかも決められないわけで、
正しいことをテストできない）
2018/10/31(水) 19:25:29.91
>>35
だから俺はしない
分離しちゃう
リファクタリングなんてソースの修正範囲を広げる愚行などもってのほかだ
2018/10/31(水) 19:26:13.32
>>36
動作は変えないんじゃなかったのか？
2018/10/31(水) 19:44:15.27
>>37
> だから俺はしない
> 分離しちゃう

だからリファクタリングの話関係ないじゃん

バグ修正の場合も分離するの？
あちこちでバグ起きてるんだけど？
2018/10/31(水) 19:45:00.61
>>38
> 動作は変えないんじゃなかったのか？

動きを変えないということは、
ソースコードをコピーしたりしてもだめだっていうのはわかってる？
2018/10/31(水) 19:46:10.79
訂正
× 動きを変えないということは、
○ メモリの使い方を変えないということは

いかなる修正を行っても、メモリの使い方は
変わるから・・・お前すべてのテストをしろって言いたいの？
2018/10/31(水) 19:50:11.58
>>39
リファクタリングとは関係ない話だけど
ソースコードコピーしたら、その分テスト工数が増えるじゃん
2018/10/31(水) 19:53:12.18
リファクタリング否定派だと思っていたら、
まさか関数否定派だったとはｗ

共通処理禁止、コードをコピペして使え
バグが見つかったら、コピペした物すべて
探し出して修正しろ。そして全てテストしろ
2018/10/31(水) 21:09:57.67
曲解ばっかりだな
リファクタリングなんてまともな職場なら許可なんて下りるわけない
2018/10/31(水) 21:35:54.69
有名ソフトウェア企業はすべてリファクタリングの許可が降りてるのに？
2018/10/31(水) 21:39:08.69
たいていというかほぼ全てがリファクタリングに取り組んでいるよな

やってないところはCOBOLに関係がある分野ぐらいか・・・
まあ、あそこは文化が違うからな
2018/10/31(水) 21:51:48.53
まあそもそも許可とってやるもんじゃないし。
「修正」の中に含まれてるもんだからね
2018/10/31(水) 22:03:50.26
>>47
は？
理由もないのに内部の造りまで変えたソースなんて品証通るわけねーだろ
コードレビューナメてるのか？
2018/10/31(水) 22:05:54.48
>>48
テストしてるから通るよ
ってか、なんのためにテストしてるの？
2018/10/31(水) 22:07:22.25
むしろ汚いコードで、コードレビューやれるのかって話だよなｗ
2018/10/31(水) 22:09:20.37
コードレビューは難しいコードを何人もの人が何時間もかけて
解読する作業なんです。

チームの仲間が暗号コードを作成し
別の人が暗号コードを解読する。
それがコードレビューなのです。

そういう不毛なことをして喜んでいるんです。
2018/10/31(水) 22:10:03.05
>>49
通る？
なぜ？
テメーの不必要な変更で増えた分のお客の受け入れテストの金と時間はどこから出るの？
2018/10/31(水) 22:11:39.53
俺も新卒のとき自分の作業しか見えなかったな
そのままおっさんになってるようなのは痛い
2018/10/31(水) 22:12:14.14
>>52
だすもなにも、逆にコスト減るからなぁ

クソ汚いコードを何日もかけてコードレビューするのにくらべたら
綺麗なコードはほんの数分で終わってしまうこともざらにある
2018/10/31(水) 22:14:04.64
汚いコードをばんって出されて、
このコードが正しいかどうか見てください！って言われても
コード汚いとそいつが作業した時間以上にかかるんだよ
コードレビューやるのにどれだけ時間がかかると思うのか
2018/10/31(水) 22:16:09.81
許可なく自由にコードいじれるって凄いねｗ
自由な社風って素敵やん
2018/10/31(水) 22:17:07.82
リファクタリングは動きを変えないので
テストはいまあるテストコードをそのまま流せばいいだけ

だからリファクタリングのコードレビューは、
単に自動テストが変更されていないかを確かめるだけでよい

必要なのは本質的な仕様変更に対する修正
この修正がリファクタリングされてないと複雑な修正になってしまう
リファクタリング後だと簡単な修正で済む
コードレビューも楽になる
2018/10/31(水) 22:18:25.00
>>56
仕事を任せられるっていうのはそういうことやで

許可無いと仕事させてもらえないなら、
お前はその程度ってことだ
2018/10/31(水) 22:24:15.14
無駄な改行までしちゃってｗ
煽りたくて必死って感じかな？
60仕様書無しさん
垢版 |
2018/10/31(水) 22:26:44.29
お前はその程度ってことだ（ｷﾘｯ
2018/10/31(水) 22:26:52.81
とうとう捨て台詞ｗ
2018/10/31(水) 22:36:36.70
相当悔しかったんだろｗ
そういう奴にはコレを言ってやれ

お前はその程度ってことだ
2018/10/31(水) 22:47:10.48
早速コピペｗｗｗ

使い捨てにされるってのは所詮そこまでの奴
俺ならそいつにこう言ってやるね

お前はその程度ってことだ
2018/10/31(水) 23:02:07.47
オウム返しは負け犬の証ですよ
2018/10/31(水) 23:05:41.29
誰もオウム返してないってｗ
66仕様書無しさん
垢版 |
2018/10/31(水) 23:10:16.98
リファクタリング肯定派なんてこの程度の集まりか

草ばっか生やしちゃってさ・・・
がっかりだよ
2018/10/31(水) 23:15:47.32
反対派が何も言い返せなくなったんじゃんかｗ
言い返せることがあるなら言い返せばいいんだぞ
話ならいくらでも続けてやる
2018/10/31(水) 23:16:59.35
まず、リファクタリングといいながら
仕様変更というリファクタリングとは関係ない話に
すり替えようとしたのは何故だ？

そしてテストする箇所が増えるのに
コードをコピーするのは何故だ？
2018/10/31(水) 23:18:00.56
意味もなく煽る
無駄に改行
とにかく草

これがﾘﾌｧｸﾀ厨
2018/10/31(水) 23:19:42.00
ほらこれだ
2018/10/31(水) 23:20:40.83
技術者としての向上心を捨てるって、こわくない？
2018/10/31(水) 23:23:48.30
もっと怖いのは、会社が技術力を必要としなくなったときだな
そこで働いているのはひたすら奴隷よ
替えのきく奴隷
73仕様書無しさん
垢版 |
2018/10/31(水) 23:24:38.65
ほらな
話すりかえてすぐ逃げる
2018/10/31(水) 23:27:14.94
仕方ないよ。リファクタリングを理解できない程度なんだから
2018/10/31(水) 23:33:01.94
うーん？
リファクタリングなどの技術力って基本的にポータブルなスキルだから、会社がどうこうは関係ないよね。
76仕様書無しさん
垢版 |
2018/10/31(水) 23:37:39.41
ただのコードの整理を理解もくそもない
2018/10/31(水) 23:38:22.05
つぶしがきく技術ってことだな
2018/10/31(水) 23:41:04.44
>>74
>>69

意味もなく煽る
お前のことだよ
2018/11/01(木) 19:54:54.74
一人で自作自演してｗ
極端すぎるからお前の意見なんてまともなやつなら同調しねーよｗ
2018/11/01(木) 20:06:32.64
うるせーよ。いいからお前はリファクタリングは
意味がないに同調してればいいんだよ
2018/11/02(金) 06:11:13.68
このスレ見てからリーダブルコード買って読んだんだけど
あんなのは労働基準も社内ルールも全く違う国の夢物語
いまだ縦社会の日本じゃ到底実現不可なのが現状だよ
2018/11/02(金) 10:20:02.40
そうか、やはりリーダブルコードの世界が "夢" なんだな
2018/11/04(日) 10:14:59.39
>>81
大手ゼネコンの多重受けみたいな場合でもなければ融通は効くでしょう
環境のせいではなく不勉強で過去の踏襲しかしないタイプのリーダーしか居ないことが本当の問題
彼らは比較的自由にできるチャンスがある案件でも日本風のやり方しかできない
84KAC
垢版 |
2018/11/05(月) 00:43:36.75
そもそも、リファクタリングで同じものができるなんてのは幻想。
絶対に体外的な仕様に影響がでる。

この事実を理解しいいないバカがリファクタリングすると大変なことになる。
2018/11/05(月) 01:09:14.70
> そもそも、リファクタリングで同じものができるなんてのは幻想。
> 絶対に体外的な仕様に影響がでる。

でるわけないじゃんｗ

リファクタリングで使用するテクニックは
動きが変わらないと保証されてるものばかり

数学の式の変形とやってることは変わらん
2018/11/05(月) 01:56:23.54
でもテストはやれよな
いじったとこの影響範囲全部
2018/11/05(月) 05:49:48.56
>>86
基本的には元々あるテストを流すだけ
ベンチマーク追加して、リファクタリングの有効性を示すことはあるけど
2018/11/05(月) 07:05:27.53
>>87
元々あるテストを流すだけってなんや？

何十人も動員して、エクセルに書いたテスト仕様書の
通りに実行してテストするんやで

テスト仕様書が曖昧で、毎回これどういう意味ですか？って聞かれるは、
人によってやり方が微妙に違うわで、正しくテストしているか不安だから
同じテストを何人も使って行うんやで

どれだけ金がかかってると思う？
コストがかかるから一年に数回しかできない
その数回で確実なテストを行うんだ。

これが真面目な仕事ぶりっていうもんや
根性見せろや
2018/11/05(月) 07:23:01.87
>>88
だよね
明らかに作るより金かけてるもんね
テスト流すだけって頭おかしいわ
2018/11/05(月) 07:36:06.93
>>89
はいキチガイ
2018/11/05(月) 07:43:57.42
>>90
社会に出ろよボーヤ
2018/11/05(月) 07:48:08.67
>>91
え、ポチッとボタン押すだけのことがそんなに難しいの？
2018/11/05(月) 07:48:55.50
>>92
それ単体だけだろ？
結合とシステムテストは？
2018/11/05(月) 08:05:43.80
>>92
ｗｗｗ
2018/11/05(月) 08:07:33.28
>>93
ニートおつ
2018/11/05(月) 08:14:38.40
>>88
どうやら30年前の世界に生きてるやつがいるようだ
2018/11/05(月) 08:32:38.30
30年前の世界を知ってる爺
50代スレに戻ってどうぞ
2018/11/05(月) 08:52:19.59
>>93
> 結合とシステムテストは？

どういう意味？

結合とシステムテストでバグが一つでも見つかったら、
修正しなきゃいけないってことで、
修正するならば、全部テストやり直しになるので
結合とシステムテストでは原則バグは見つからないという前提

それでもバグは見つかるので、
全部テストするコスト×数回分がテスト全体のコストになる

どれだけ高額になるかわかるだろう？

全部テストっていうのはそれだけのことを年数回やっている
2018/11/05(月) 08:56:08.14
そのテストを自動化すれば、膨大なテストコストが削減できて、
信頼性も高いテストになりますけど？
2018/11/05(月) 09:05:45.88
>>98
じゃあなんで動いてるコードいじったの？バカ？
2018/11/05(月) 09:11:24.93
>>100
いじってやるから一億よこせ
言い方は悪いが要約するとこういう契約が成立したから
2018/11/05(月) 09:14:58.90
>>88
素晴らしい日本の品質
2018/11/05(月) 09:15:01.04
>>99
お前なぁ

今更やり方なんか変えられないんだよ
仮に自動化してコストが大きく下がってみろ？
今までは何だったんだって問い詰められるだろ

かと言って楽してボッタクリなんてのも許されない
努力、根性＝仕事＝給料なんだから

> 信頼性も高いテストになりますけど？
コンピュータに信頼性も糞もあるかよ
エクセルなんて計算間違えるんだぞ
電卓のほうがまだ信頼できる

ソフトウェアはバグだらけで間違えるから
人間がテストしてると言うのに、
バグだらけのソフトウェアにテストさせてどうする？
2018/11/05(月) 09:15:52.56
>>103

> バグだらけのソフトウェアにテストさせてどうする？

あれ？矛盾してない？ｗ

> 結合とシステムテストでは原則バグは見つからないという前提
2018/11/05(月) 09:16:33.97
>>103
はいキチガイ
2018/11/05(月) 09:16:56.86
>>103
人間は間違いを犯す
2018/11/05(月) 09:17:21.85
>>104
アホか、ソフトウェアがバグだらけだから
人間が単体テストをして、結合とシステムテストで
バグがでないようにするんだろうが
2018/11/05(月) 09:18:37.92
>>107
その理屈なら、人間がテストした「自動テスト」にはバグがないから
それを使って自動テストすれば良いのでは？
2018/11/05(月) 09:21:45.50
>>107
それ、単体テストで完璧なものに仕上げていれば
結合とシステムテストでバグが出ないって理屈だよね？

>>93で

> それ単体だけだろ？
> 結合とシステムテストは？

って単体テストしか自動化できない（そんなこと無いが）だろって
言ってるが、完璧に仕上げるべきは単体テスト
その重要な単体テストがしっかり自動化できていれば、
結合とシステムテストでバグが出ないのでは？
■ このスレッドは過去ログ倉庫に格納されています
5ちゃんねるの広告が気に入らない場合は、こちらをクリックしてください。
ニューススポーツなんでも実況