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

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

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

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

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

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

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

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

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

で？

**デフォルトの名無しさん** · 2017/02/08(水) 22:05:08.20

>>746
> リファクタリング前提の開発なんて小規模開発以外はやるものじゃないね

設計に問題があるときどうしてるの？
問題があるっていうのは、最初の時点で間違っていた場合の他
機能追加などで最初の想定と変わってしまった場合

リファクタリングしないで、問題ある設計のまま
開発を続行するの？

大きい開発ほど最初に想定しなかった事態が起こるはずだけど？

**デフォルトの名無しさん** · 2017/02/08(水) 22:42:04.56

>>749
それをリファクタリングと言うのか
ただの上流への出戻り、やり直し、糞開発じゃないの

>>747
アジャイルって知ってる？オナニーくん

**デフォルトの名無しさん** · 2017/02/08(水) 22:59:10.86

>>750
> ただの上流への出戻り、やり直し、糞開発じゃないの

上流へ出戻りするのは良いんだが、
今のコードはどうするんだよ？捨てるのか？

リファクタリングというのは今のコードをよく知られている
手順を使って安全に（バグを入れることなく）変化させていくことをいう

リファクタリングの勉強をちゃんとした人なら、知っているはずだが
リファクタリングしないことを選択すべき理由として
作り直したほうが速い場合っていうのがある。

作り直したほうが早い場合はリファクタリングの哲学によって作りなおすが、
コードを安全に変化させたほうが早い場合は当然リファクタリングをする。

で最初の質問に戻るが、お前コードを修正したほうが早い場合でも
リファクタリングしないで、コードを捨てて作り直すって言ってんの？
それとも行き当たりばったりなただの修正を行ってバグ発生させるの？

**デフォルトの名無しさん** · 2017/02/08(水) 23:15:25.00

現状それなりに動いているけど
将来性を考慮しての改善するのがリファクタリングでしょ

そもそもマトモに動いてないコードは問題外

**デフォルトの名無しさん** · 2017/02/08(水) 23:18:57.65

> 将来性を考慮しての改善するのがリファクタリングでしょ
YAGNIに反するからそれは違う。
その将来が絶対来るというのなら話は別だけど

**デフォルトの名無しさん** · 2017/02/08(水) 23:22:55.16

>>751
うーんw
いずれにしてもコードを捨てる捨てないに関わらず設計に問題があるものをその開発中に直すことをおれの界隈ではリファクタリングとは言わないね
おまえがそれをリファクタリングと言うのは自由なので好きにしてくれw

**デフォルトの名無しさん** · 2017/02/08(水) 23:27:19.72

>>754
俺が言ってるんじゃなくて世間一般の定義。

っていうか開発中とそうでないのが別れてる時点で
お前、前時代的だしなぁ。

お前なら一日に何十回もデプロイするような
ウェブアプリをどうやって変化させていくんだ？

「俺にはできません。」ですかな？ｗ

**デフォルトの名無しさん** · 2017/02/08(水) 23:31:13.83

ちなみに、TDDでは最初にテストコードを書いて
それに通る最小限の実装を書く、その後リファクタリングを
行うというのを繰り返して開発するものので、

http://www.atmarkit.co.jp/ait/articles/1403/05/news035.html#025
> 開発中に直すことをおれの界隈ではリファクタリングとは言わないね

> 開発中に直すことをおれの界隈ではリファクタリングとは言わないね
というのはもぐり、無知レベルでしかないよ

**デフォルトの名無しさん** · 2017/02/08(水) 23:31:50.65

引用を間違えた

http://www.atmarkit.co.jp/ait/articles/1403/05/news035.html#025
>【5】テストを成功状態にしたままリファクタリングする

**デフォルトの名無しさん** · 2017/02/08(水) 23:36:21.44

うーんw
自ら話を反らしていくスタイルw

**デフォルトの名無しさん** · 2017/02/08(水) 23:38:20.99

それてないじゃん？ｗ

それてるっていうのなら、戻していいよ。君の手で

**デフォルトの名無しさん** · 2017/02/08(水) 23:53:10.75

うーんww
そもそも少人数短期イテレーション開発におけるリファクタリングの話なんて始めからしてないのだがw
毎日デプロイするwebアプリ？そんな小さな話も全くしてないw
おまえが数億円契約の大規模開発をやったことないのはよくわかったw

**デフォルトの名無しさん** · 2017/02/09(木) 01:52:04.00

>>760
大規模だからって何の自慢になると思ってるんだ？

大規模は別にどうでもいいよ
どういった開発をしているのかが重要だろ。

いくら金がかかっているからって
ろくでもないやつばっかり集めて人海戦術で
ひたすら効率の悪い開発方法をしている？
だとしたら自慢どころか恥だよね。

もっと規模とか金以外に自慢できることないの？

**デフォルトの名無しさん** · 2017/02/09(木) 04:01:02.59

>>753
は？
while文よりfor文の方がわかりやすいね
って書き直す事のどこが機能追加なの？

読みやすくしておくことも未来への投資じゃね？

**デフォルトの名無しさん** · 2017/02/09(木) 06:44:32.92

リファクタリングに開発規模は関係ない
レガシーコードの山に頭抱えながら仕事するのも自由だし、好きにしてくれ

**デフォルトの名無しさん** · 2017/02/09(木) 07:38:20.57

規模が大きい開発はクソコーダーがクソコードを量産してくるから俺様が随時コードを書き換えてやる

ってのが ID:E3hlYujb の主張
こういうリファクタオナニストに好きにさせてはいけない

**デフォルトの名無しさん** · 2017/02/09(木) 08:20:04.14

リファクタリングに必要な見積りを出してくれ

**デフォルトの名無しさん** · 2017/02/09(木) 11:43:47.05

>>765
これな

**デフォルトの名無しさん** · 2017/02/09(木) 11:48:27.92

>>764
そうじゃなくて作ってからリファクタリングなんてやってる暇があるなら先にレビューで潰すってことさ
それでも設計レベルでの変更が必要にるならレビュアもゴミだったってだけのこと

**デフォルトの名無しさん** · 2017/02/09(木) 12:39:15.13

本当に大規模開発やったことあるのか？
新規で作って作りっぱなしだったのか？

**デフォルトの名無しさん** · 2017/02/09(木) 12:49:33.29

>>767
それこそ規模の大小は関係ないわけだが
結局なにが言いたいのお前

**デフォルトの名無しさん** · 2017/02/09(木) 13:07:11.30

>>769
関係ないことはない
設計レベルでの見直しをリファクタリンクを言うのであればそんなことがやすやすと可能なのは少規模開発だけ

**デフォルトの名無しさん** · 2017/02/09(木) 13:11:02.24

話を戻すと開発中にそんな状況になるのを俺はリファクタリングとは言わん
リファクタリングとはもっと前向きなものだ

っていうことを>>750から何度も言ってるからだけなんだがねw

**デフォルトの名無しさん** · 2017/02/09(木) 14:01:01.97

じゃあ何のことをリファクタリングと呼んでるの？

**デフォルトの名無しさん** · 2017/02/09(木) 14:27:10.00

そもそもファクタリングとは？
それをやり直すってことでしょ

**デフォルトの名無しさん** · 2017/02/09(木) 15:01:34.48

じゃあ逆に聞くけど設計から変えてUTのコードがそのまま使えるケースってどんなの？w
テストコードの書き換えが必要な改修は開発スキームとして事前にスケジュールに組み込まれるリファクタリングとは全く別ものだろww

**デフォルトの名無しさん** · 2017/02/09(木) 15:14:26.88

別にリファクタリングは個別のユニットテストに影響ないレベルとは限らないでしょ。
リファクタリング対象によってそこは取捨選択すべき。

**デフォルトの名無しさん** · 2017/02/09(木) 17:19:48.49

結論から言えば概念としてのリファクタリングは否定しないが、
リファクタリングのための工数なんて実際は取れないし、
そんな余計なリソースがあるなら他の事に回した方がいい
所詮暇を持て余した学生の戯言だよ

**デフォルトの名無しさん** · 2017/02/09(木) 19:13:25.68

>>775
いやだから話の前提が>>749だから選択も糞もないくやらないといけない状況でそれをリファクタリングとはいわねーって
もうええわww

**デフォルトの名無しさん** · 2017/02/09(木) 19:41:42.20

プロジェクトの開始時にリファクタリングの見積も出してね
オーバーした分はお金出せないからね

**デフォルトの名無しさん** · 2017/02/09(木) 20:10:08.12

だからまずファクタリングの定義からしようか
それをやり直すってだけの話でしょ

**デフォルトの名無しさん** · 2017/02/09(木) 20:29:21.19

機能要件を満たすため
非機能要件を満たすため
オナニーするため
目的が何であろうとリファクタリングはリファクタリングですよ

**デフォルトの名無しさん** · 2017/02/09(木) 21:09:00.44

オブジェクト指向でシステム開発するなら、リファクタリングは必須です。
クラスの設計、インターフェースの抽出・設計といったプログラミング前に
既に必要です。

**デフォルトの名無しさん** · 2017/02/09(木) 21:09:16.18

>>771
> リファクタリングとはもっと前向きなものだ

ここへ来ていきなり精神論かよ
やっぱり頭沸いてんだろお前w

**デフォルトの名無しさん** · 2017/02/09(木) 21:29:45.22

とりあえず動くものを新規で作って書き換える場合か、すでに動いているもので、修正が入りまくって汚くなったものを整理するくらいしかない。

自由にいじくりまわすのをリファクタリングとは言わない。

**デフォルトの名無しさん** · 2017/02/09(木) 21:35:33.02

>>762
> while文よりfor文の方がわかりやすいね
> って書き直す事のどこが機能追加なの？

while文よりfor文の方がわかりやすいねとか
俺は言ってない。お前が言ったことだ。

お前は、機能追加じゃない例を自分で出して
自分で自分にツッコミを入れてるだけなんだが、

何がしたいの？

**デフォルトの名無しさん** · 2017/02/09(木) 21:39:19.62

とりあえずみんな
http://www.shoeisha.co.jp/book/detail/9784798116839
とか
https://estore.ohmsha.co.jp/titles/978427405019P
これ読んでる？

**デフォルトの名無しさん** · 2017/02/09(木) 21:42:53.34

>>777
> いやだから話の前提が>>749だから選択も糞もないくやらないといけない状況でそれをリファクタリングとはいわねーって

お前根本的に間違ってるんだわ。

まず先に最初の話のツッコミ漏れを補完しておくとだな
>>749で設計に問題があるときはどうするのか聞いた。
これは言い換えると「やり直し以外の選択の余地がない例」として上げたんだよ。

それなのに、>>750で
> ただの上流への出戻り、やり直し、糞開発じゃないの
やり直しすればいいじゃんって、お前アスペか？

やり直し以外の選択肢の余地がないことにたいして、
「やり直ししろ」ってそれは反論になってない
俺が意図してる答えだ

でな、リファクタリングかどうかっていうのは、手段なの
「糞もないくやらないといけない状況」のときに、
リファクタリングを使って、修正を行うのか
リファクタリングを使わずに、修正を行うかの話

ここまで言えば、お前が根本的に間違ってることが理解できるだろ？
お前はリファクタリングが手段であることをわかってない。どんな状況かはどうでもいい。
修正をするときに、どうやって修正するかの話だ。

お前は、リファクタリングしないで、行き当たりばったりで修正してバグを入れ込むんだろう？
俺はリファクタリング（わかりやすく言えばリファクタリングの本に書いてあるテクニック）を使って修正するんだよ

**デフォルトの名無しさん** · 2017/02/09(木) 21:45:29.54

>>778
> プロジェクトの開始時にリファクタリングの見積も出してね

リファクタリングが手段であることを知れば、
「リファクタリング（手段）の見積もり」がおかしい言い方だとわかるだろう。

正しく言うならば「プロジェクトの開始時に修正の見積もだしてね」だ
修正にはバグだけじゃなくて仕様の追加や間違いによる修正も含まれる。

あとは修正するしかない状況で、行き当たりばったりで修正するか
リファクタリングで修正するかの違いなだけだ

**デフォルトの名無しさん** · 2017/02/09(木) 21:46:27.58

>>776
> リファクタリングのための工数なんて実際は取れないし、
リファクタリングのための工数が取れなくて
リファクタリングを使わない修正であれば
工数が取れるっておかしくね？ｗ

**デフォルトの名無しさん** · 2017/02/09(木) 21:52:20.21

https://estore.ohmsha.co.jp/titles/978427405019P

リファクタリングに工数がーとか言ってる奴はこれ特に読んで欲しい

**762** · 2017/02/09(木) 21:55:31.20

>>784
ほらな
きちんと書いてないと
こうやって誤解されるわけだ
言いたかったのは

「現状while文で処理されていて問題ないけど
このケースはfor文の方がわかりやすいから書き直そう！」
どこに機能追加される余地があんの？

**デフォルトの名無しさん** · 2017/02/09(木) 21:57:10.56

>>790
> どこに機能追加される余地があんの？
ないよ？

誰がそこに機能追加される余地があるって
言ってるの？

お前？

**デフォルトの名無しさん** · 2017/02/09(木) 21:58:18.00

>>791
>>753 こいつ

**デフォルトの名無しさん** · 2017/02/09(木) 21:58:44.70

>>753には while とか for の話は
明らかに書いてないけど？

**デフォルトの名無しさん** · 2017/02/09(木) 21:59:52.90

>>791
あのさー
YAGNIに反するって言ったのは誰なんですかね？
余計な機能はつけるなってことでしょ？
whileからforに書き換えるのに何か機能追加されんの？

**デフォルトの名無しさん** · 2017/02/09(木) 22:01:15.92

YAGNIの話？

753 自分：デフォルトの名無しさん[sage] 投稿日：2017/02/08(水) 23:18:57.65 ID:EqksEKaR [3/7]
> 将来性を考慮しての改善するのがリファクタリングでしょ
YAGNIに反するからそれは違う。

これがどうfor やwhileと関係すんの？

**デフォルトの名無しさん** · 2017/02/09(木) 22:02:47.10

ほんまやね。レス辿って明らかにおかしいのを見つけたがら言ったけどそれforのレスにかすりもしなかったわ。すまん。

**デフォルトの名無しさん** · 2017/02/09(木) 22:06:33.30

>>786
おまえ日本人か？w

**デフォルトの名無しさん** · 2017/02/09(木) 22:08:07.52

下手に勘違いされると困るから補足しておくと、

汚いから修正するってだけならYAGNIでやるべきではないが、

その部分を修正していたり読む必要があるならば、
いつ必要しているの？今でしょ？ってことで
今すぐ必要としていることなわけだから、
そこを修正するのはYAGNIではない

**デフォルトの名無しさん** · 2017/02/09(木) 22:25:26.99

読まなきゃ汚いと思わないんだから、矛盾してるような気がするけど。
必要ないのに汚いコードを読み始める酔狂な奴が居るとしたら別だけど。

**デフォルトの名無しさん** · 2017/02/09(木) 22:29:02.28

> 読まなきゃ汚いと思わないんだから
いや、コードメトリクスツールなどをつかえば
読まなくても、客観的に汚いとわかる

**デフォルトの名無しさん** · 2017/02/09(木) 22:29:15.76

>>797
いつになったら何のことをリファクタリングと呼んでるか書いてくれるの？

**デフォルトの名無しさん** · 2017/02/09(木) 22:34:05.44

汚いから直すってのもリファクタリングと呼ぶと思うけど、
汚いから直すってのは実際の開発現場じゃなかなか難しいと思うよ

その汚さが原因で性能が出ないとか、機能追加できない、し辛いって明確な理由があれば別だけどね

**デフォルトの名無しさん** · 2017/02/09(木) 22:41:25.83

>>802
> その汚さが原因で性能が出ないとか、機能追加できない、し辛いって明確な理由があれば別だけどね

だから俺は聞いたんだよ？

そういうどうしても直さなければいけないときに
リファクタリングで安全に修正するのか？
それとも行き当たりばったりに修正してバグを入れるのか？って

**デフォルトの名無しさん** · 2017/02/09(木) 22:43:53.46

いや、俺に噛みつかれましても

**デフォルトの名無しさん** · 2017/02/09(木) 22:45:29.16

>>801
理解できる頭がないのに質問するなよw
何度も言ってるだろうがww

**デフォルトの名無しさん** · 2017/02/09(木) 22:47:35.42

リファクタリングを行うタイミングを間違ってるんだよね

俺は何らかの機能修正とかでコードをいじるときに
関連するところを少しづつなおす
大抵が数行程度で10分もかからずに終わる

こまめに修正しないで、手遅れになってからやろうとするから
大規模になってしまって、別途工数が～とかいう話になるんだよ。

手遅れになってしまったものを修正する工数がないからと
手遅れなコードのままさらにコードを追加するから
さらに手遅れになっていくんだろうが

**デフォルトの名無しさん** · 2017/02/09(木) 22:59:39.83

>>806
多分解ってると思うけどその言い方は誤解を生むと思うぞ。
リファクタリングと機能追加は明確に分けるべきで、リファクタリングして、テスト走らせて振る舞いが変わってない事を確認してから機能追加に入るべき

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

>>805
他人の否定はしてるけど、自分では何も言ってないよ君

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

リファクタリング=上腕二頭筋

**デフォルトの名無しさん** · 2017/02/09(木) 23:12:13.46

>>807
うん。わかってる

> リファクタリングして、テスト走らせて振る舞いが変わってない事を確認してから機能追加に入るべき

どちらもあるよ。

機能追加してからリファクタリングする物の典型的な例がTDD
Red/Green/Refactor 通りの順番

**デフォルトの名無しさん** · 2017/02/10(金) 00:46:58.66

どんどん別の手法がまざっていく洗脳馬鹿

**デフォルトの名無しさん** · 2017/02/10(金) 01:18:18.70

別の手法ってなんの話だ？

**デフォルトの名無しさん** · 2017/02/10(金) 02:12:34.39

>>810 のことだよ。

**デフォルトの名無しさん** · 2017/02/10(金) 02:25:45.27

> Red/Green/Refactor 通りの順番

これのことか？

Refactorはリファクタリングのことだよ
別の手法じゃなくて全く同じもの

**デフォルトの名無しさん** · 2017/02/10(金) 12:06:41.01

1.機能追加前にテスト書く
2.追加コード書く
3.テスト
4.ダメならテストに通るまでコードいじる

もしかしてこれもリファクタリング扱いしてるの？

**デフォルトの名無しさん** · 2017/02/10(金) 12:38:04.04

>>815
それはRed→Greenのところでしょ…

**デフォルトの名無しさん** · 2017/02/10(金) 21:26:25.38

　最近、特定のフラグ変数に関するif文の山をswitch構文に清書し直したんだけど、これってリファクタリング？

**デフォルトの名無しさん** · 2017/02/10(金) 21:34:25.32

>>816
それさ、リファクタリングのいち定義であってリファクタリングではないから。

**デフォルトの名無しさん** · 2017/02/10(金) 21:35:50.89

>>817
そのif文が変ならな。まともなif文なら書き換える必要がない。

**デフォルトの名無しさん** · 2017/02/10(金) 21:37:35.22

>>817
ただswitch文にすると仕様変更時にswitch文では対応できなくなる可能性があるので逆かもしれない。

**デフォルトの名無しさん** · 2017/02/10(金) 21:42:51.54

>>817
確かにswitchでかけるならばifよりswitchの方が少しだけ見やすくなるけど、
大抵はリファクタリングにはならないよ
巨大なswitchもリファクタリングすべき対象となる

何がダメなのかというと比較の回数がifのときと変わってないから。
比較が多い＝複雑なので、これは単なる書き方の違いでしかなくて
リファクタリングとまではいかない。重要なのは比較回数

じゃあどうすべきかというと、一番簡単な方法は
関数テーブル（ルックアップテーブル）を使う方法
大量のswitchでの比較が条件が揃えば0個にまで減る

**デフォルトの名無しさん** · 2017/02/10(金) 21:46:49.78

>>818
> それさ、リファクタリングのいち定義であって

> Red/Green/Refactor 通りの順番
がリファクタリングの定義に見えるんだ・・・

ここにはどこにもリファクタリングの定義なんてものは
書いてないんだが

>>816が言ってるのは、Red→Greenでやる内容は
リファクタリングじゃないよって言ってるだけでしょ

俺からも補足するが、リファクタリングは
動いているコードを、動いているコードに置き換えることだよ。

修正前と修正後のどちらかが動いていなければ
それはリファクタリングではない

**デフォルトの名無しさん** · 2017/02/10(金) 21:57:11.80

* Green
　　1.機能追加前にテスト書く
* Red
　　2.追加コード書く
　　3.テスト
　　4.ダメならテストに通るまでコードいじる
　　5.テストに通った。やったー完成だ！ ←ふざけんじゃないよ。なんだこのコピペだらけで無駄がばかりのクソコードは
* Green
　　6.リファクタリングする
　　7. 読みやすくなりました。←このコードならレビューする気になる。シンプルあとで読んだ人も理解しやすいだろう
　　8. 完成、1に戻る

**デフォルトの名無しさん** · 2017/02/10(金) 22:00:06.48

現実にはこの5. テストに通っただけの状態で
完成としてしまうやつが多いんだよな。

そういうコードで許される環境っていうのは
コードレビューが行われていない。
コードを見ずにテストに通ればOKとしてしまう環境

そして向かうはデスマーチｗ

**デフォルトの名無しさん** · 2017/02/10(金) 22:14:40.62

駄目だこりゃ。なんでそういう手順がリファクタリングなのか？

**デフォルトの名無しさん** · 2017/02/10(金) 22:20:09.64

>>825
お前が理解してないだけだよｗ

**デフォルトの名無しさん** · 2017/02/10(金) 22:33:35.95

Refactorとリファクタリングが同じ意味の言葉だってのが伝わってないのかも知れないな

**デフォルトの名無しさん** · 2017/02/10(金) 22:38:11.34

あ、はい間違えました

>　6.リファクタリングする

これじゃリファクタリンギングですねｗ

**デフォルトの名無しさん** · 2017/02/10(金) 22:59:58.18

このスレってそもそも特定のリファクタリング作業のスレッドか。話がかみ合わないわけだ。

**デフォルトの名無しさん** · 2017/02/10(金) 23:48:55.17

誰が特定のリファクタリング作業の話をしてるんだ？
誰がはどうでもいいや「特定の」ってどれのことだよ？

**デフォルトの名無しさん** · 2017/02/11(土) 00:00:12.78

TDDの例出したからTDDに限定した話だって勘違いしてるんでしょ

**デフォルトの名無しさん** · 2017/02/11(土) 00:04:14.10

>>829
「特定の」がなにか言うだけだよ。
お前がちゃんと考えて発言しているなら
簡単な質問なはずだが？

もっとも俺はお前が何も考えてないってことを
あぶり出すために「特定の」が何か聞いたんだけどなｗ

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

お、あぶり出してるねえ

**デフォルトの名無しさん** · 2017/02/22(水) 01:09:25.60

このスレの存在忘れてたわｗ
なんだ逃げたのかｗ

**デフォルトの名無しさん** · 2017/02/22(水) 12:59:43.56

>>423 >>426 のやつNot Foundになってた

リファクタリングの誤用
https://bliki-ja.github.io/RefactoringMalapropism/

リファクタリングの境界線
[見当たらない]

インタフェースの変更はリファクタリングか
https://bliki-ja.github.io/IsChangingInterfacesRefactoring/

未知のバグフィックスはリファクタリングか？
https://bliki-ja.github.io/IsFixingAnUnknownBugRefactoring/

最適化はリファクタリングか？
https://bliki-ja.github.io/IsOptimizationRefactoring/

宣言の順序変更はリファクタリングか？
https://bliki-ja.github.io/IsDeclarationOrderingRefactoring/

**デフォルトの名無しさん** · 2017/02/23(木) 18:03:32.56

定義から定まってないからなリファクタリングって
いや、実在するのか？

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

殆どの用語は定義なんか定まってないよ
数学でさえ、ある用語に対して数学ではこういう定義で
使いましょうと決めているだけ

**デフォルトの名無しさん** · 2017/02/26(日) 20:54:48.09

ソースを組んだときと今とでチンコのポジションを若干変更した
これがリファクタリングである

**デフォルトの名無しさん** · 2017/02/26(日) 22:44:41.65

特定の統合開発環境のリファクタリング機能をリファクタリングだと言ってるやつはいなくなったなw

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

俺の中では変数名の変更=リファクタリング

Visual Studioの機能名がそうだったから

**デフォルトの名無しさん** · 2017/02/27(月) 01:49:20.76

俺の中では、マーチンファウラーのリファクタリング本（古い方）に
のっているのがリファクタリング
変数名の変更ももちろんのってる

後はそのリファクタリングをどれだけ簡単に
正確に行えるかの違い。

ローカルスコープ程度で済むものなら良いけど
スコープが広い部分のリファクタリングは手動でやるのは大変
それを自動的に間違いなく行える、静的型付け言語＋IDEの力は偉大

**デフォルトの名無しさん** · 2017/02/27(月) 02:49:09.61

あるスコープの中で外部から見た仕様を変えずに内部の設計を変えるのがリファクタリング

**デフォルトの名無しさん** · 2017/02/27(月) 17:22:25.25

>>842
それではチンコのポジションも

**デフォルトの名無しさん** · 2017/02/27(月) 22:10:17.46

チンポジ設計

**デフォルトの名無しさん** · 2018/05/23(水) 23:04:38.11

僕の知り合いの知り合いができたパソコン一台でお金持ちになれるやり方
役に立つかもしれません
グーグルで検索するといいかも『ネットで稼ぐ方法　モニアレフヌノ』

K2FKH

**デフォルトの名無しさん** · 2018/07/04(水) 23:04:33.21

GKH