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

[1 仕様書無しさん 2018/04/15(日) 13:13:44.63]

機能追加や変更した時に、全部テストしてるでしょ？
いつもやってることじゃん

[2 仕様書無しさん 2018/04/15(日) 13:16:31.37]

それなｗ

あと、リファクタリングするとお前責任取れるのかとか言ってくるが
機能修正でバグった時の責任はリファクタリングじゃないんだから
全部あんたがとれよって言うと顔真っ赤になるｗ

[3 仕様書無しさん 2018/04/15(日) 13:23:46.40]

半角カナを使う奴まだいたのか

[4 仕様書無しさん 2018/04/15(日) 13:29:25.23]

スレタイ長くて入らないからね

[5 仕様書無しさん 2018/04/15(日) 13:53:39.75]

簡潔にまとめられない奴はプログラミング向いてない

[6 仕様書無しさん 2018/04/15(日) 14:07:43.60]

そんなことない
なんでもかんでも一緒にするな

[7 KAC 2018/04/15(日) 14:29:02.33]

>>1
テスト粒度とかリスクとか理解できないの？

[8 仕様書無しさん 2018/04/15(日) 14:43:15.84]

リファクタリングはテスト必須で
論理的におかしくならないと判明している
決められたやり方でやるので
リスクは低いしテストは自動化されています。
その前提ぐらい知らないんですか？

[9 仕様書無しさん 2018/04/15(日) 14:45:55.12]

>>8
だからテストやらなくていいって？
そもそもクラスまで作り変えてるならテスト免除どころか設計書のレビューからだよね

[10 仕様書無しさん 2018/04/15(日) 14:46:35.64]

>>9
リファクタリングは「テストをやってる」ことが
前提なので、
あんたが言ってるのは別のものでは？

[11 仕様書無しさん 2018/04/15(日) 14:47:26.22]

> そもそもクラスまで作り変えてるならテスト免除どころか設計書のレビューからだよね

そうですね？　なんでレビューせずに
リファクタリングするなんて思い込んでんの？

[12 仕様書無しさん 2018/04/15(日) 15:05:33.14]

> リファクタリングはテスト必須で

って書いてあるのに

↓

9 返信：仕様書無しさん[sage] 投稿日：2018/04/15(日) 14:45:55.12
>>8
だからテストやらなくていいって？


これもう頭が悪いレベルだろｗ

[13 仕様書無しさん 2018/04/15(日) 15:06:06.29]

リファクタリングの存在を否定できないと
困る人がいるんですよｗ

[14 仕様書無しさん 2018/04/15(日) 15:30:21.76]

設計書から書き直すならただの改修作業なんだよね？

[15 仕様書無しさん 2018/04/15(日) 15:32:49.90]

>>14

改修作業の中身の違い

　1. 無計画に適当に修正して手動でテストしてそれでもバグでて苦労するのと
　2. リファクタリングの手法を使ってテストコード書いて低リスクで修正するかの違い

[16 仕様書無しさん 2018/04/15(日) 16:11:52.19]

>>15
具体的にどう違うの？

[17 仕様書無しさん 2018/04/15(日) 19:48:05.09]

>>15
TDDでリファクタリングした場合、
1、初歩的なミスにすぐ気付ける
2、作業者が精神的に安心できる

なお、開発者目線の開発体制の優先順位は
バージョン管理 > コードレビュー > 自動テスト > リファクタリング
なので、必ずリファクタリングとTDDはセットになる

[18 仕様書無しさん 2018/04/15(日) 19:48:54.60]

>>16
リファクタリングの手法では先に自動化されたテストコードを書く
もしくはすでに存在していなければならない
だから、リファクタリングしたらテストしろよっていうのは意味不明。

リファクタリングの中にテストすることが条件として含まれており
修正前と修正後の両方、それどころか修正のたびにテストすると言ってるのに
なんでそんな当たり前ことを、それも最後だけテストするような質問をするんだ？と
疑問になる

おそらく修正とテストが分離した考え方しか持って無くて
修正後に手動でテストを行うというやり方しか知らないのだろう
そんな再現性がなくてテスト回数もすくないんじゃ、
バグがなかなか取れずにデスマになるのは必死だろう