リファクタリングをただのコード修正と思ってる人へ

**デフォルトの名無しさん** · 2010/05/29(土) 17:25:56

テストも書かないでリファクタリングとかうけるｗ

まずな、リファクタリングでは機能追加・修正は行わない。
動作はまったく同じでコードをきれいに書き換えること。

書き換えるといっても、これなら同じ動きだろ？って推測でやってはいけない。

まずテストを書く。ユニットテストをできるように、
単一のクラスでインスタンスを作る。

汚いコードなのだからたいていは依存関係のせいで単一ではクラスが生成できない
それを生成するために、クラスの動作を書き換える。
といっても元のコードは修正しない。継承やプリプロセッサを使って
依存関係を断ち切るために既存のコードを上書きする。
どうしてもそれが不可能な場合には、決められた手順で最小のコード修正を行う

そうやって既存のクラスのユニットテストを行う。
それでやっとリファクタリングが行える。
既存のクラスのユニットテストを通るように新たなコードに修正、
もしくは新規作成して置き換える。

この手順と考え方を守ってないのはリファクタリングではない。

で？

**デフォルトの名無しさん** · 2014/10/07(火) 01:36:41.20

テストケースは全部通さないと駄目だよ
人間の書くテストが全部網羅してるとも限らないから
テストの穴を突いた部分が他所で影響してるかもしれない
原則としてよほどの事でもない限り一度リリースしたら手をつけないがベスト
リファクタリングなんて幻想だからやめなさい

**デフォルトの名無しさん** · 2014/10/07(火) 09:53:16.20

インタフェースを作り替えたらテストも必要
というかテストできない・しづらいインタフェースを作ったらあかん

**627** · 2014/10/07(火) 20:19:23.95

>>628
＞テストケースは全部通さないと駄目だよ

内部動作をリファクタリングする場合はそうだと思います。

＞人間の書くテストが全部網羅してるとも限らないから
＞テストの穴を突いた部分が他所で影響してるかもしれない

１００％のテストはないけど、十分捕捉率の高いテストと
十分機能変更の余地が低いリファクタリング手法の組み合わせで
実用になるというのがリファクタリングの主張ですよね。

内部動作のリファクタリグだけならそれでいいんですけど、
ただやっぱりインターフェイスの拡張・取捨選択も
やりたくて、そういう場合どうすればいいのかなと。

＞原則としてよほどの事でもない限り一度リリースしたら手をつけないがベスト

一度リリースしたっきりでソースのことを忘れ去っても
大丈夫なプロジェクトならそうかもしれませんが、
リファクタリングがターゲットにするプロジェクトは
リリースした後に（リファクタリングするしないに関わらず）
何度も手を付けてメンテナンスすることが要求されるような
継続性のあるプロジェクトではないでしょうか？

＞リファクタリングなんて幻想だからやめなさい

上手くいくと言っている人も多いので、
安易に幻想だと断定もできないように思います。
幻想だとはっきり納得出来たらやめます。

**627** · 2014/10/07(火) 20:20:02.46

>>629
＞インタフェースを作り替えたらテストも必要
＞というかテストできない・しづらいインタフェースを作ったらあかん

テストしづらくはないのですが、
例えば１つ１つの public メソッドにテストを書いていたら
とても作業が時間内に終わらないというような、
時間がかかってしまう的な問題です。

でも public メソッドはクラスの持つインターフェイスだから
テストは必要ってことですか？

**デフォルトの名無しさん** · 2014/10/08(水) 15:43:43.04

ただ、そのテストのメンテナンス、テストを減らしたり、改善したり、
そういう話はまだ多くないんですね。(例えば)テストが増えてくると、
全部のテスト通すのに 3 時間かかったりとか、テストの量自体が問題になってくる。
またテストが実装に深く依存してて、リファクタリングしたらテストが
ばーっと真っ赤*49になっちゃうからやめようみたいな話とか。

テストをたくさん書けば良いってものじゃないんですよ。
設計の改善を前後で担保するためのテストだったはずなのに、
設計改善の邪魔をしてるんじゃないか？と。
テストが変更のコストを一定にするという夢を俺たちは見てやってきたのに、
テストが増えると変更コストが上がっていないかい？という問題に対してどう戦うか、
それが今の TDD の主戦場だと思っています。

http://www.ogis-ri.co.jp/otc/hiroba/others/OORing/interview43.html

**デフォルトの名無しさん** · 2014/10/08(水) 17:47:03.08

>>632
下手なテストを書くとそうなるって話ですね。

**デフォルトの名無しさん** · 2014/10/08(水) 23:56:17.82

よくわからんが何かの言い訳に使えそうな

**デフォルトの名無しさん** · 2014/10/09(木) 10:21:37.01

テストできない・しづらいインタフェースを作ったらあかん

**デフォルトの名無しさん** · 2014/10/09(木) 20:44:29.80

ボタン一個一発こそ至高

**デフォルトの名無しさん** · 2014/10/12(日) 07:13:20.02

>>627
有能な人材だけで構成されているなら可能
でも有能な人材はそもそもそんなコードを書かない
つまり、現実では実現不能ということ。

よく考えてよ。
ゲーム会社への就職も面接すらいけずに終わり、他の会社も全滅、登録派遣しかなく
ようやく派遣されたCOBOLでクビになり、
自分は有能だと思い込んでいるケドWindowsしか使えない
無職の人の立てたスレだよ？

**デフォルトの名無しさん** · 2014/10/12(日) 13:23:31.01

>>637
返信ありがとうございます

＞よく考えてよ。
誰が立てたかでなく、何を言っているかで判断しています

＞有能な人材だけで構成されているなら可能
627 では可能かどうかという聞き方はしていないのですが、
627 のどの部分を指して可能と言われているのでしょうか？

＞でも有能な人材はそもそもそんなコードを書かない
これも、627 ではどんなコードかに関して言及していないと
思うのですが、そんなコードというのは何を指しているのでしょうか？

**デフォルトの名無しさん** · 2014/10/12(日) 14:51:47.69

世の中に汚いコードが溢れてるってことだなｗ

リファクタリングは汚いコードを直すことじゃないよ。
コードは修正するたびに（≒機能追加）
どんどんコードが増えていく。

素人集団は、コードの既存部分を直さずに追加するだけで終わらせる。

有能な人材はそもそも汚いコードを書かないというが、
それは、有能な人材は、リファクタリングをしながら機能追加していくから
汚いコードに"成長しない" ということを意味する。

**デフォルトの名無しさん** · 2014/10/12(日) 15:32:46.02

設計がまずかったり場当たり的に組んでしまったりして
いったん汚いコードになってしまったらもう手遅れですか？

汚いコードをインターフェイスを変えつつ
改善していきたいと思っているのですが

**デフォルトの名無しさん** · 2014/10/12(日) 16:01:06.81

>>648
「汚いコード」のうちは未完成と考えるよ。

設計書だってレポートだって小説だって
書いた最初は下書きでそれから清書するもんだろ？

**デフォルトの名無しさん** · 2014/10/13(月) 12:31:48.66

コードが汚いとか騒ぐやつは総じて低スキル

**デフォルトの名無しさん** · 2014/10/13(月) 17:48:27.91

>>640
汚いのを綺麗にする行為をリファクタリングとは"呼ばない"

これが原理主義者の主張するところである

**デフォルトの名無しさん** · 2014/10/13(月) 21:27:10.38

>>643
ではリファクタリグしたとしても汚いコードは汚いままなのですね

**デフォルトの名無しさん** · 2014/10/13(月) 22:25:07.42

>>644
汚いコードはリファクタリング前に綺麗にしてから
リファクタリングするから、
リファクタリング後は当然綺麗になってるよ。

**デフォルトの名無しさん** · 2014/10/13(月) 22:41:00.86

>>645
リファクタリグとは別に、汚いコードを綺麗にする方法があるのですね
どうやるんでしょう？

**デフォルトの名無しさん** · 2014/10/13(月) 22:43:13.35

>>646
まず何が綺麗で何が汚いかを勉強することだね。
それを知らないことにはどうしようもない。

逆に知ってしまえば、具体的な質問ができるようになるよ
汚い××というコードを、綺麗な○○に変化させるには
どうしたらいいでしょうか？って

そういう質問なら答えがちゃんと言える。
君の今のレベルの質問は曖昧すぎて答えがない。

**デフォルトの名無しさん** · 2014/11/22(土) 11:07:28.63

>>642
その高スキルに限って自分のソースが保守できずに早々に放棄する
書きなぐり続けるのはその繰り返しのため

**デフォルトの名無しさん** · 2014/11/22(土) 16:04:31.14

>>642
俺様のコードは凡人には分からない
協調作業が出来ないタイプの典型
困ります､俺のプロジェクトから即刻リジェクト
してほしいです
田中お前だよ

**デフォルトの名無しさん** · 2014/11/25(火) 12:34:50.30

世の中なんでも使い捨てで楽な方に向かってるのに
プログラミングの世界は古いものを大事に使いたがる不思議
怠惰なフログラマこそ率先してコードを使い捨てにすべきじゃね？

**デフォルトの名無しさん** · 2014/11/25(火) 23:55:42.35

>>650
使い捨てる理由の大半はどんなにうまく保存しようとしても劣化し続けるから。
ソフトウェアはそういう物理的制約から書いたものはずっと同じまま残り続ける。
うまくバックアップや環境が残りさえすれば半永久的に使い続けることが出来る
わけだから、怠惰であればあるほどそういう資産を積み上げていくんだよ。

**デフォルトの名無しさん** · 2014/11/26(水) 12:34:55.88

>>651
バカだな劣化するからリファクタリングとかいう下らない事が流行るんだぞ

**デフォルトの名無しさん** · 2014/11/26(水) 19:48:43.25

再利用って考え方がそもそもコストが高いんだよ
もんじゅとか例に挙げなくてもリサイクルって金掛かるだけで
利権で儲けるしかない仕組みだって判るよね

**デフォルトの名無しさん** · 2014/11/27(木) 00:55:26.29

再利用のコストに関しては単純に何回再利用するかで変わってくるから、
コストの高い再利用をしているお前が悪いんじゃないのとしか言えない。

リファクタリングも同じで、2度と手を入れないような部分や新規プロジェクトを
渡り歩くような人には不要なもの。ただ昨今のアジャイル開発とか呼ばれている
ものだと、ある程度の期間は修正や追加が必要になってくる。無計画に接ぎ木を
してわけの分からないキメラを作るより、ある程度剪定して理解できる範疇に
修める必要があるよねっていうのがリファクタリング。

**デフォルトの名無しさん** · 2014/11/27(木) 12:34:12.35

>>654
ソフトウェアの再利用もその都度コストがかかるんだが？
普通は回数に比例してコストが増加するぞ

**デフォルトの名無しさん** · 2014/11/27(木) 12:41:38.96

>>655
> ソフトウェアの再利用もその都度コストがかかるんだが？
> 普通は回数に比例してコストが増加するぞ
再利用するために何らかの変更が必要なら、そのときだけコストがかかるが、
以降はコストかからんだろ。

**デフォルトの名無しさん** · 2014/11/27(木) 23:29:56.27

再利用前提で作ろうとしてる時点で余計なコトスがかかっとるわい

**デフォルトの名無しさん** · 2014/11/28(金) 02:38:41.57

古くなった原発の再利用

**デフォルトの名無しさん** · 2014/11/28(金) 04:18:59.87

再利用性や拡張性というのは、将来のことだから仕様外。
仕様外だからプログラミングの対象外。

おわり。

**デフォルトの名無しさん** · 2014/11/28(金) 07:48:17.97

再利用と考えるからいけない。
モジュール化。

適切なモジュール化は、再利用出来るだけじゃなく、
複雑度も減ってバグも少なくなる。

適切なモジュール化が出来ない奴が
再利用にコストがかかるとか
コードが再利用できないとか言う。

**デフォルトの名無しさん** · 2014/11/28(金) 12:44:59.78

>>660
それは再利用じゃないよ
機能を小さく保つ事で、本来の目的である一次利用出来る範囲が広がるだけだ
それを便宜的に「再利用しやすい」などと表現してる訳だ
ソフトウェア本来の目的とは異なる本当の意味での再利用にはコストがかかるんだよ

**デフォルトの名無しさん** · 2014/11/28(金) 17:41:36.95

本当の意味での再利用？
そんなもんに興味持つ必要はなさそうだが？

>>660
それな。
本当にそれ。

**デフォルトの名無しさん** · 2014/11/29(土) 01:59:23.82

>>661
> 機能を小さく保つ事で、本来の目的である一次利用出来る範囲が広がるだけだ
一次利用が出来る範囲が広がる＝再利用だろｗ

**デフォルトの名無しさん** · 2014/11/29(土) 13:13:20.77

再利用じゃなくて流用と言えばいいのに

**デフォルトの名無しさん** · 2014/11/29(土) 14:17:24.97

全く修正しないで使うのが再利用。
コピーして修正して使うのが流用

流用をすると、AとA'というコードが生まれなんで二つに分かれてるの？
違いはなんんあの？と結局両方を読まないといけなくなる。
流用するたびに読むべきコードがどんどん増えていく。
はてに一つを修正するともう片方の修正を忘れるとか。

なので全く修正しないで使う「再利用」でないと意味が無い。
全く修正しないで使えるのだからコピーする必要はなくなる

**デフォルトの名無しさん** · 2014/11/29(土) 14:46:23.56

流用元から流用先がどこにどれだけあるかは基本的に分からない。
流用元に何かバグがあって修正する必要があった場合に論理的に考えると
流用先も直しておいた方がいいor直す必要がある。ただ流用先を全て特定
することは難しく、特に流用先で動くように変数名とか変えてあると確実に
漏れる。バグじゃなくても何か修正追加したいと思った時の事を考えると
コピペをばらまくより関数で再利用するほうがいいよねってなる。

ただ人間は欲深いもので1つの関数にあれもこれも詰め込んで破綻させる
奴が出てきたりする。こういうのを見て、関数なんて作らなくてコピペでいい
だろって奴が出てきて無限ループする。

**デフォルトの名無しさん** · 2014/11/29(土) 22:16:12.25

頑張って同じ機能がすでにあるか探して、
あったらあまりいいコードじゃなくても正しく仕様を満たすからそれ使って
散々気をつけてんのに誰かが変更しやがる

**デフォルトの名無しさん** · 2014/11/30(日) 12:24:33.02

リファクタリングと言う名の正義

**デフォルトの名無しさん** · 2014/12/05(金) 19:01:54.53

>>668
同意､正義を振りかざす曲者

**デフォルトの名無しさん** · 2014/12/21(日) 11:54:37.04

>>661,660
>ソフトウェア本来の目的とは異なる本当の意味での再利用にはコストがかかるんだよ
　
　アプリ内でのモジュールの共通化（＝アプリに特化したフレームワーク、ライブラリ
の抽出）と、どんなプロジェクトでも使えるようにフレームワークやライブラリーを
汎用化するのは似て非なるものだと思う。

**デフォルトの名無しさん** · 2015/02/15(日) 22:12:39.01

>>1-1000
テスト

**デフォルトの名無しさん** · 2016/03/27(日) 21:55:32.43

どのタイミングでやったら工数に影響を与えずにできるの?

**デフォルトの名無しさん** · 2016/09/10(土) 20:12:17.64

みんな、言い負かされないようにリファクタリングを定義してるから、本当の目的がなんなのかぼやけちゃってるよね。

保守性（機能変更のし易さ）と速度の向上

リファクタリングの目的はこれでしょ。
それが必要ならリファクタリングすればいいし、将来的な機能変更もなく速度にもとくに問題がないなのら、どんなに汚いコードであっても下手にいじる必要はないよね。

むろん、個人で作った（使ってる）プログラムならリファクタリングするかしないかはその人の勝手だけど。

**デフォルトの名無しさん** · 2016/11/02(水) 19:22:35.91

>>673
次の変更がきてから変更すればいいじゃない？

**デフォルトの名無しさん** · 2016/11/11(金) 18:20:08.17

なるほど

**デフォルトの名無しさん** · 2017/02/06(月) 05:50:15.98

大抵の趣味人はリファクタリングなんかせずに垂れ流しだろ

**デフォルトの名無しさん** · 2017/02/06(月) 06:14:33.50

趣味としてのリファクタリングも結構面白いけど

**デフォルトの名無しさん** · 2017/02/06(月) 06:41:48.30

あとwikiから

"Code refactoring is the process of restructuring existing computer code―changing the factoring―without changing its external behavior. "

リファクタリングとは既存のコードを再構成する工程であり、
そのコードの外的な振る舞いを変えずに
問題の細分化(factoringを意訳)を変えることである。

だってさ、こんなスレよりよっぽどわかりやすいや

**デフォルトの名無しさん** · 2017/02/06(月) 06:56:02.14

リファクタリングにはユニットテスト必須だよな

**デフォルトの名無しさん** · 2017/02/06(月) 12:26:12.33

ユニットが再編成されたコードの外的な振る舞いをテストする
という意味ではユニットテストはその目的を果たしてないけどな

**デフォルトの名無しさん** · 2017/02/06(月) 13:37:16.68

うちの会社の糞プロジェクトはリファクタしてことでバグ生んで大炎上してたな

**デフォルトの名無しさん** · 2017/02/06(月) 16:24:54.25

>>680
外的な振る舞いを変えないのがリファクタリングだろ

**デフォルトの名無しさん** · 2017/02/06(月) 20:52:46.36

>>682
なんだ？だからテストしなくても良いとか言いたいのか？

**デフォルトの名無しさん** · 2017/02/06(月) 21:26:39.16

>>683
なんでそうなるんだ？
リファクタリングによって振る舞いが変わってない事を確認する為にユニットテストが必須という話をしてるのに

**デフォルトの名無しさん** · 2017/02/06(月) 21:43:37.79

>>684
なんでそうなるんだ？
ユニットが再編成されたコードの外的な振る舞いが変わっていない事を確認する為にユニットテストは使えないという話をしてるのに

**デフォルトの名無しさん** · 2017/02/06(月) 22:00:46.99

分子構造が再構築された全ての細胞の働きがもとそれと１つも変わらないならそれは再構築前と同じ生物になるのではないか
という理屈

**デフォルトの名無しさん** · 2017/02/06(月) 22:00:51.21

>>684
テストが必要っていうのは正しいが、そのテストはユニットテストとは限らん。

まず>>678に書いてある「外的な振る舞い」というのは
どこが外的かを考える必要がある。

リファクタリング対象がモジュール（クラス等）であれば
必要なテストはユニットテストだ。

だけど設計に近いレベルであれば必要なテストというのは
E2Eテストやシステムテストだったりする。

何をリファクタリングするかによって必要なテストは変わる

**デフォルトの名無しさん** · 2017/02/07(火) 11:38:03.93

>>687
設計に近いレベルの変更というのがどういうものを指すのか良くわからんが、E2Eテストやシステムテストが必要になるコード変更はリファクタリングとは言わないでしょ。

**デフォルトの名無しさん** · 2017/02/07(火) 11:39:08.61

えっ！？

**デフォルトの名無しさん** · 2017/02/07(火) 12:21:09.75

>>688
むしろその規模のリファクタリングでなければコーダーのオナニー以上の意味がないくらいなのだが

**デフォルトの名無しさん** · 2017/02/07(火) 13:06:50.95

>>690
規模の話はしていない。
1箇所数行のリファクタリングであろうが、1万箇所数万行のリファクタリングであろうが話は同じ。

E2Eテストやシステムテストでなければテストできないようなリファクタリングって、具体的にどんなものなんだ？

**デフォルトの名無しさん** · 2017/02/07(火) 15:04:10.93

>>691
リファクタリングで効率が良くなったとして、ユニットテストレベルで勝手にリリースして
本当は他のシステムで必要な協調動作パラメータの再調整が必要だったり
想定してたバッファがパンクする可能性とか想像できんの？
そもそもリファクタリング単体の案件なんてまず発生しないし
他の案件の一部にねじ込むってパターンがほとんどだから結局テストは全工程やる事になるけど

**デフォルトの名無しさん** · 2017/02/07(火) 15:27:04.15

>>692
「他のシステムで必要な協調動作パラメータの再調整が必要」なほどの大きな変更を「外的な振る舞いが変わっていない」と表現・定義して、それがリファクタリングであるというのはちょっと同意できない。

そもそも、>>687で
> 何をリファクタリングするかによって必要なテストは変わる
ということなので、E2Eテストやシステムテストが必要なリファクタリングとは、具体的にどんなものか、というのが疑問なんだけど。

**デフォルトの名無しさん** · 2017/02/07(火) 15:28:33.61

>>692
> 想定してたバッファがパンクする可能性とか想像できんの？
あと、これ、単なるバグ（または設計ミス）でしょ。
しかも、単体レベルで検知可能。

**デフォルトの名無しさん** · 2017/02/07(火) 16:00:21.23

>>692 のレベルが低すぎて笑う

**デフォルトの名無しさん** · 2017/02/07(火) 18:13:12.04

レベル低くて結構だが
要件から漏れた設計なんて後からいくらでも見つかるのが現実
最初から設計や実装が完璧ならリリース後のコードに手を付けようなんて考えすら出てこないだろ

**デフォルトの名無しさん** · 2017/02/07(火) 18:17:09.92

ID:pecoNgwzがすごい小さい世界で生きていることだけはよくわかる

**デフォルトの名無しさん** · 2017/02/07(火) 20:26:46.11

スレタイ通りの人達

**デフォルトの名無しさん** · 2017/02/07(火) 21:49:17.94

>>691
> 1箇所数行のリファクタリングであろうが
君はこれで何がリファクターされると考えているのかね？
既存のコードを君好みのノーテーションに変える事をリファクタリングとは言わないのだよ
リファクタリングとはただのコード修正とは違うという意味
君分かってないよね

**デフォルトの名無しさん** · 2017/02/07(火) 21:55:16.30

っていう勘違いをここまで堂々と話してるところが2chだなぁと感じる

**デフォルトの名無しさん** · 2017/02/07(火) 21:58:23.39

>>691
> E2Eテストやシステムテストでなければテストできないようなリファクタリングって、具体的にどんなものなんだ？

違う言語にリファクタリングした場合

**デフォルトの名無しさん** · 2017/02/07(火) 22:06:09.85

>>692
> リファクタリングで効率が良くなったとして、ユニットテストレベルで勝手にリリースして
> 本当は他のシステムで必要な協調動作パラメータの再調整が必要だったり
> 想定してたバッファがパンクする可能性とか想像できんの？

これリファクタリングと全く関係ないよね？

機能追加で便利になったとして、ユニットテストレベルで勝手にリリースして
本当は他のシステムで必要な協調動作パラメータの再調整が必要だったり
想定してたバッファがパンクする可能性とか想像できんの？

**デフォルトの名無しさん** · 2017/02/07(火) 22:10:27.76

>>701
言語関係ないと思うが。
出来た実行可能ファイルかライブラリーか知らんがそれの挙動が変える前と代わっていないかテストすればいいだけだろ

**デフォルトの名無しさん** · 2017/02/07(火) 22:11:07.79

>>692
> そもそもリファクタリング単体の案件なんてまず発生しないし
当たり前。何かの修正があるときに
適切な形に変えるのがリファクタリング

「何かの修正」が加わる前の時点での適切な設計と
「何かの修正」が加わった後の適切な設計は必ずしも同じではない

「何かの修正」を加えるときは、もし最初から「何かの修正」が存在したと
仮定した時の適切な設計も同時に実現しなければいけない

修正するたびに適切な設計から離れていく、修正するたびに
壊していくようなやり方は責任あるプロの仕事とはいえない

> 他の案件の一部にねじ込むってパターンがほとんどだから結局テストは全工程やる事になるけど

結局テストは全行程やるんだから、修正のたびにリファクタリングを加えてなんのもんだもない

**デフォルトの名無しさん** · 2017/02/07(火) 22:11:57.21

>>703
だから、出来た実行可能ファイルかライブラリーか知らんがそれの挙動が変える前と代わっていないか
E2Eテストやシステムテストでテストするんだよ

**デフォルトの名無しさん** · 2017/02/07(火) 22:21:19.34

>>705
実行ファイル一つならそうである可能性もあるけど、ライブラリだったらシステム全体ではないよね。言語関係ないとはそういうこと。

**デフォルトの名無しさん** · 2017/02/07(火) 22:24:10.12

勘違いさせたならすまんが、俺は別にリファクタリングにシステムテストとかが必要ないなんて思ってない。その一つとは別人。

**デフォルトの名無しさん** · 2017/02/07(火) 22:44:43.58

リファクタにE2Eテストがいらないというのはある意味ただしいんだよ
アジャイルにおけるリファクタなんかがまさにそう
自動テストありきでイテレーションに組み込まれる
ただリファクタにも色々あるよねって話

**デフォルトの名無しさん** · 2017/02/07(火) 22:53:25.47

リファクタリングの責任範囲はユニットテスト迄でシステムテストとかは機能の変更、追加、向上なんかの範囲だと思うけどね
この二つを混ぜてリファクタリングと呼んでる人が一定数いて話をややこしくしてる
もちろんリリース前には一通りテストはするけどそれはそれ。リファクタリングに必要なテストとは別物

**デフォルトの名無しさん** · 2017/02/07(火) 22:55:46.93

>>708
いやE2Eテストが自動化出来ないというわけでもないからちょっと違うくない？
リファクタリングにも色々あるよねというのには同意。
リファクタリングの対象を決めることは大事だよね。
システム全体をリファクタリングしようとしても成功率は低い。だからE2Eテストはいらない(システム全体を一度に変えようとすんな)と言いたい気持ちも解る。

**デフォルトの名無しさん** · 2017/02/07(火) 22:57:24.46

>>709
責任範囲がユニッテテスト迄w
もはや何を言いたいのか自分でも分かってないだろお前w

**デフォルトの名無しさん** · 2017/02/07(火) 23:01:56.40

>>711
君が言いたいことは分かんないけど自分の言いたいことはわかってるよ

**デフォルトの名無しさん** · 2017/02/07(火) 23:08:35.66

>>712
いや分かってねえよお前w

既存のユニットテストが利用出来るようなコード修正は
お前のコードオナニー以外の何者でもない
お前はリファクタリングという正義を笠に着てコードオナニーをしているだけの
童貞コーダーにすぎないのだよ

**デフォルトの名無しさん** · 2017/02/07(火) 23:11:01.58

>>713
まさに混同してる人が話をややこしくしてる見本

**デフォルトの名無しさん** · 2017/02/07(火) 23:16:01.53

>>706
何だその意味がない答えは？

> 実行ファイル一つならそうである可能性もあるけど、ライブラリだったらシステム全体ではないよね。言語関係ないとはそういうこと。

ライブラリだったらシステム全体ではないかもしれないけど、実行ファイル一つならそうである可能性もある

**デフォルトの名無しさん** · 2017/02/07(火) 23:16:32.08

>>710
まあそうね

>>713
いやわかってないのはおまえ
リファクタといえば一般的にはTDDありきのおまえのいうオナニーだ

**デフォルトの名無しさん** · 2017/02/07(火) 23:17:49.44

>>709
> システムテストとかは機能の変更、追加、向上なんかの範囲だと思うけどね

意味が全くわからん。外から見たときに機能も何も変わらなくて
内部の設計が良くなってるならそれはリファクタリング

**デフォルトの名無しさん** · 2017/02/07(火) 23:19:18.43

>>716
> リファクタといえば一般的にはTDDありきの

TDDがリファクタリングありきなのであって
リファクタリングはTDDとは関係ない

**デフォルトの名無しさん** · 2017/02/07(火) 23:22:44.32

>>718
関係ないのではなくリファクタがそれだけではないってだけ
おまえめんどくさいな

**デフォルトの名無しさん** · 2017/02/07(火) 23:23:22.80

>>719
それだけじゃないっていうのなら、
他に何があるのかを言えよ

お前は否定するだけで、自分の意見を何も言ってない

**デフォルトの名無しさん** · 2017/02/07(火) 23:23:38.10

>>716
んなアホなw
まともなリファクタリングしている奴だって大勢いるわw

**デフォルトの名無しさん** · 2017/02/07(火) 23:23:56.74

>>715
だから違う言語にしたというのと、システムテストをするというのは無関係だって話だよ。それだけ。

**デフォルトの名無しさん** · 2017/02/07(火) 23:25:16.66

ID:6yEMM6pR がまともなリファクタリングを語るのはもうギャグにしか見えない

**デフォルトの名無しさん** · 2017/02/07(火) 23:32:41.16

>>722
外部から見たときの動きを変えずに、内部の言語を変えたら
ユニットテストもつかえねーだろ。
何を言ってんだお前

**デフォルトの名無しさん** · 2017/02/07(火) 23:37:57.69

>>717
そう言ってるつもりだけど？機能の変更までやったらシステムテストは必要だけどそれはリファクタリングの後の工程だよねってこと

**デフォルトの名無しさん** · 2017/02/07(火) 23:41:30.42

>>724
なんで？例えばC互換のABI作れる言語なんて山ほどあるけど(バイナリ作る言語ではほぼ必須機能だよね)
他にも内部の言語は変えたけどモジュールの外向きのラッパーは今までと同じ言語で書くというのもあるだろ

**デフォルトの名無しさん** · 2017/02/07(火) 23:46:26.22

>>725
お前頭沸いてんなw
そもそもテストの存在意義すら分かってねえじゃねえかw
ユニットテストは必要だけどシステムテストは必要ないなどと言う開発メソッドは
人類の歴史上でただの一度たりとも存在した事はねえよw