リファクタリングすると全部テストしろと言ってくるやつの矛盾

■ このスレッドは過去ログ倉庫に格納されています
2018/04/15(日) 13:13:44.63
機能追加や変更した時に、全部テストしてるでしょ?
いつもやってることじゃん
2018/04/15(日) 13:16:31.37
それなw

あと、リファクタリングするとお前責任取れるのかとか言ってくるが
機能修正でバグった時の責任はリファクタリングじゃないんだから
全部あんたがとれよって言うと顔真っ赤になるw
2018/04/15(日) 13:23:46.40
半角カナを使う奴まだいたのか
2018/04/15(日) 13:29:25.23
スレタイ長くて入らないからね
2018/04/15(日) 13:53:39.75
簡潔にまとめられない奴はプログラミング向いてない
6仕様書無しさん
垢版 |
2018/04/15(日) 14:07:43.60
そんなことない
なんでもかんでも一緒にするな
7KAC
垢版 |
2018/04/15(日) 14:29:02.33
>>1
テスト粒度とかリスクとか理解できないの?
2018/04/15(日) 14:43:15.84
リファクタリングはテスト必須で
論理的におかしくならないと判明している
決められたやり方でやるので
リスクは低いしテストは自動化されています。
その前提ぐらい知らないんですか?
2018/04/15(日) 14:45:55.12
>>8
だからテストやらなくていいって?
そもそもクラスまで作り変えてるならテスト免除どころか設計書のレビューからだよね
2018/04/15(日) 14:46:35.64
>>9
リファクタリングは「テストをやってる」ことが
前提なので、
あんたが言ってるのは別のものでは?
2018/04/15(日) 14:47:26.22
> そもそもクラスまで作り変えてるならテスト免除どころか設計書のレビューからだよね

そうですね? なんでレビューせずに
リファクタリングするなんて思い込んでんの?
2018/04/15(日) 15:05:33.14
> リファクタリングはテスト必須で

って書いてあるのに



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


これもう頭が悪いレベルだろw
2018/04/15(日) 15:06:06.29
リファクタリングの存在を否定できないと
困る人がいるんですよw
2018/04/15(日) 15:30:21.76
設計書から書き直すならただの改修作業なんだよね?
2018/04/15(日) 15:32:49.90
>>14

改修作業の中身の違い

 1. 無計画に適当に修正して手動でテストしてそれでもバグでて苦労するのと
 2. リファクタリングの手法を使ってテストコード書いて低リスクで修正するかの違い
2018/04/15(日) 16:11:52.19
>>15
具体的にどう違うの?
2018/04/15(日) 19:48:05.09
>>15
TDDでリファクタリングした場合、
1、初歩的なミスにすぐ気付ける
2、作業者が精神的に安心できる

なお、開発者目線の開発体制の優先順位は
バージョン管理 > コードレビュー > 自動テスト > リファクタリング
なので、必ずリファクタリングとTDDはセットになる
2018/04/15(日) 19:48:54.60
>>16
リファクタリングの手法では先に自動化されたテストコードを書く
もしくはすでに存在していなければならない
だから、リファクタリングしたらテストしろよっていうのは意味不明。

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

おそらく修正とテストが分離した考え方しか持って無くて
修正後に手動でテストを行うというやり方しか知らないのだろう
そんな再現性がなくてテスト回数もすくないんじゃ、
バグがなかなか取れずにデスマになるのは必死だろう
2018/04/15(日) 21:04:44.02
>>17
工数も削減できないし
品質も上がらないんだ?w
20仕様書無しさん
垢版 |
2018/04/15(日) 21:17:10.48
なにをゆうちょるんじゃあ主は
2018/04/15(日) 21:37:54.42
リファクタリング厨って受け売りでしか語らないから面白くない
2018/04/15(日) 23:16:16.00
ゴミスレ
2018/04/16(月) 05:06:44.38
オープニングから自演w
2018/04/16(月) 05:08:34.00
>>21
というか、責任あるポジションの経験がないやつが語ってるだけだからな
ちゃんと決定権を持つやつを納得させるだけの説明ができればいいだけだが、
それすらできていないっつーね
2018/04/16(月) 06:25:24.08
>>2
責任とって辞めます。
2018/04/16(月) 12:37:10.95
>>19
そこらへんの話でいうと、
売上や品質が上がった客観的なデータが示せりゃ、どの会社でも自動テストやリファクタリングは採用されるんよ
そこまでしてないなら、その議論は語るに値しない
んで、殆どの会社はそこを検証していない
2018/04/16(月) 12:45:59.35
>>26
そんなもん、やってみりゃ肌で感じ取れること
数値にしなきゃ理解できないよぉとかバカみたいなこと言ってると腕のいい職人にはなれませんよ??
2018/04/16(月) 13:26:59.58
>>27
数値にできる学がねぇんだろw
数値化しろよ
2018/04/16(月) 13:36:47.19
>>27
仕事を規定の時間内に許容できる品質のものを上げるのが実装者に求める要求で、それに付随する手段は手段でしかない。
で、手段は自由にやればいいし、基本介入しないし、結果しか見る気は無い。
だからやりたければやれば?としか自分は言わない
工数増えるのは論外
2018/04/16(月) 14:37:58.22
>>26
> そこまでしてないなら、その議論は語るに値しない
> んで、殆どの会社はそこを検証していない

検証しろっていうのはわかるが、それは世間一般には
すでに検証されていてすでに品質が上がったというデータは出てるんだよな

それも検証するコストも出せないような会社がやるような中途半端な
方法じゃなくて、もっと大規模で信頼できる方法で検証した結果がすでにある。

で、それを参考にすりゃいいのに、参考にしないんだろう。
つまり他人を信用してない。だから他人がなにやってもどんなデータを出しても
そういう会社は信用しないんだろう。
2018/04/16(月) 14:41:43.64
リファクタリングが有効かどうか?
検証してやるよ。コスト?そりゃ当然かかるよ

ここで嫌がる会社が多い

重要なのは、失敗するかもしれないがやってみよう
という考えが通じる会社かどうかなんだろうな
2018/04/16(月) 14:52:53.46
体力がなくて単純工すらできないごみクズがIT技術者(笑)になる日本では
コストメリットどころかリスクしかない。
33KAC
垢版 |
2018/04/16(月) 17:54:10.17
「リファクタリングしたら工数減ります」
「リファクタリングの為の工数ください」

うん。意味不明だね。
2018/04/16(月) 18:19:38.72
> 「リファクタリングの為の工数ください」

誰もそんなこと言ってないけど?

>>31が言ってること勘違いした?
リファクタリングが有効かどうかの検証の話だよ。
検証するには、同じことをリファクタリグをするのと
しないので2回やらないといけない。
検証にはコストがかかる。
2018/04/16(月) 19:00:22.44
>>28
俺の筋肉量でリファクタリングの効果を説明できる
2018/04/16(月) 19:33:16.67
>>34
いや、リファクタリングで総工数が減るなら勝手にやればいいだけじゃね?
リファクタリングで品質下がるなんて聞いた事無いわけだし。それとも単体テストレベルまでがっちり管理されてんの?
2018/04/16(月) 19:50:39.52
リファクタリングで増減する工数って、内部設計クラスレベル〜クラステストまででしょ
詳細設計省かずやる巨大案件でも無い限り、実装者に委ねられる部分やん。
ともすれば、やりたきゃやれって回答にしかならん。
2018/04/16(月) 20:03:20.01
>>36
> いや、リファクタリングで総工数が減るなら勝手にやればいいだけじゃね?

俺はやってるよ。リファクタリングで工数減るから
そもそも修正作業の中に自動的に組み込まれるものだから
あえて "リファクタリング単体で" 工数を取るなんてことはしない

だからリファクタリングのために工数くださいっていう発想が
そもそも間違ってるわけ。修正に伴う追加作業じゃない。
修正作業そのものなんだから
2018/04/16(月) 20:08:32.88
仕組みが悪いからって正常に動いてる箇所まで手を入れるってねーな
2018/04/16(月) 20:37:02.97
リファクタ自体は否定しないが、>>1は確実に技術に溺れて盲信してるアホだから許可出さない
2018/04/16(月) 21:02:09.30
>>39
正常に動いていると証明するテストをしてないってこと?

正常に動いていることを証明するテストを修正後にもやれば、
正常に動くと証明できるでしょう?
2018/04/16(月) 21:03:03.43
>>40
修正許可与えてるなら、どんな修正をしたとしても
許されるはずだけど?
2018/04/16(月) 21:22:15.99
>>38
修正が発生したときにしかリファクタしないの?
2018/04/16(月) 21:24:48.73
修正ってなんだよ、バグってんのか
機能追加だろうがなんでも修正って言う奴は素人でしょ
45仕様書無しさん
垢版 |
2018/04/16(月) 21:26:39.53
ただのレッテル張りじゃねえかw
46仕様書無しさん
垢版 |
2018/04/16(月) 21:27:14.47
素人というやつは童貞だ
イカ臭いプログラム書いてろ
と言ってるようなもの
2018/04/16(月) 21:30:14.08
>>43
なんどもリファクタリングは修正の一部だって言ってるじゃん
一部ってことはそれ以外も有るってことだよ

複雑なコードを読み解いて、リファクタリングしないで複雑なまま修正するのと
複雑なコードを読み解いて、リファクタリングしてから修正するのと
どっちがリスクが少ないかって話だ

前者だと、複雑なコードを読み解いた人(修正担当者)がいるにもかかわらず
別の人が、また大変な思いをして読み解いてレビューしなければいけない
そして、次同じところを修正する時、また複雑なコード読み解かなければいけない
2018/04/16(月) 21:32:16.33
みんな実装するだけで精一杯なんよ
2018/04/16(月) 21:33:31.81
リファクタリングは神の領域に達するものにのみ許される技。
素人はおとなしくExcel方眼紙でセル結合の練習でもしておけ。
2018/04/16(月) 21:36:56.37
>>47
そんな入門書の1章に書いてあるような話はいいよ、面白くないから
2018/04/16(月) 21:45:07.82
>>50
入門未満の人がいるんでね
2018/04/16(月) 21:48:55.54
入門レベルの奴でも上から目線になれるから張り切ってんのか
2018/04/16(月) 21:54:14.63
だから>>1にはやらせない
2018/04/16(月) 21:58:29.27
>>37
テストの品質が後工程に無関係ならな。
まあそんな現場が多いのは事実だが。
2018/04/16(月) 22:14:39.29
>>51
リファクタリングするときのレビューとかどうしてる?
設計レビューもだし、コードレビューもだけど
2018/04/16(月) 22:21:54.62
リファクタリングしてるのでNG
57KAC
垢版 |
2018/04/16(月) 22:42:11.58
>>47
お前さん、理想通りに開発が進めば
自動試験だけで完璧なものができるとか信じてる?
2018/04/16(月) 23:48:14.82
テストしづらいとか、クラスが肥大化しすぎて開発に支障があるとかならまだしも
見通しが悪いなんて理由でうごいてるもんをほいほい変えていいもんじゃろか
2018/04/17(火) 01:28:22.88
リファクタリングは超プロの領域
このスレには本当のリファクタリングが出来る奴はいない

elseなしに書き換えるのが精一杯のFラン説教野郎みたいなのがいるだけ
2018/04/17(火) 01:37:33.43
大規模リファクタリングの秘孔をついた
お前のプロジェクトはもう死んでいる
2018/04/17(火) 02:47:02.14
>>55
> リファクタリングするときのレビューとかどうしてる?
リファクタリングではないときはどうしてる?
それと同じなんだが。

まあそういう質問するってことはリファクタリングに限らず
そもそも設計もコードもレビューしてないってことなんだろうけど
まずはそこからやねw
2018/04/17(火) 02:49:20.05
>>57
> 自動試験だけで完璧なものができるとか信じてる?

だからレビューするんでしょ?

自動試験はバグがないことを証明する手段
その手段が正しいかどうかはレビューでみる。

人手でレビューして、テストした内容も記録されて
後なにがあれば完璧なものができると思います?
2018/04/17(火) 02:51:40.76
>>58
> テストしづらいとか、クラスが肥大化しすぎて開発に支障があるとかならまだしも
> 見通しが悪いなんて理由でうごいてるもんをほいほい変えていいもんじゃろか

機能追加とか修正するという前提なんだから、どちらにしろ変更するしかないでしょw
64KAC
垢版 |
2018/04/17(火) 08:07:55.30
>>62
自動試験してレビュー通ったらシステムインしてサービス開始すんの?
2018/04/17(火) 08:35:24.00
入門書第1章に書いてあることの受け売りなら長文で語るけど、具体的な話からは煽りで逃げるし、
体験から語ってると思えるような発言もないし、こいつ多分そんなにノウハウないよ
2018/04/17(火) 10:12:11.71
>>64
レビューもするし自動以外のテストもする
そこは普通の機能変更のときとなにも変わらない

ただその時のやり方が、複雑なコードを頑張って解析して
無理やりパッチを当てるような、あとから見た時に
なんでこんな面倒なことしてんの?と思われるような変更をするやり方から、

次回は複雑なコードを読まなくて良いように、複雑なコードを
シンプルに修正しつつ、まるで0からコードを書いた時のように
こういう機能を実現するなら、普通こう書くよねという
当たり前の形にするやり方に変わるだけ

変更するたびに複雑になっていくやり方をやめて
変更しても複雑にならない、むしろシンプルになるような
やり方をしましょうってこと

その後にやるテストうんぬんは、もともと機能変更でやる予定だったんだろ?
なら最初からやるって決まってることじゃないか
2018/04/17(火) 10:12:38.07
>>65
> 具体的な話からは煽りで逃げるし、
ん? どのレス?
2018/04/17(火) 10:13:52.53
レビューってさ
もう儀式になってない?
2018/04/17(火) 10:16:36.37
TDDってさ
組織的にガチガチにやるもんじゃなくて
設計者の間で守るべき密やかな秘密程度で
やったほうが良い気がすんのね。
2018/04/17(火) 11:00:00.11
>>68
それはどんなコード変更のときでもやるべきことだから
リファクタリングの話とは関係ないという注意だけしておくね
2018/04/17(火) 11:05:57.21
>>69
ようは、リファクタリング前に存在するテストコードが
リファクタリング後でも通ることで動きを変えてないことが
証明できれば良いのでTDDである必要はないよ。

具体的にはgit使えば歴史変えられるんで、
コード変更しつつテストコード書いて、
コード変更とテストコードでコミット分けて
あとでrebaseしてテストコードのコミットをコード変更の
コミットより前に持ってくれば良い
2018/04/17(火) 12:12:26.72
>>71
TDDは保護するためのテストじゃないから
2018/04/17(火) 12:23:08.56
>>68
レビューのつもりで儀式やってるだけのところが多いね。
■ このスレッドは過去ログ倉庫に格納されています
5ちゃんねるの広告が気に入らない場合は、こちらをクリックしてください。

ニューススポーツなんでも実況