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

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

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

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

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

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

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

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

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

で？

**デフォルトの名無しさん** · 2014/08/02(土) 19:57:37.46

>>397みたいな事言ってると、拡張を繰り返すうちにコードが保守不能なカオスになって
もう無理だから全部捨てて作り直しだー、ってなるんだよ

でもSIerとしては、それが飯の種だから良いんだけどね

**デフォルトの名無しさん** · 2014/08/02(土) 20:03:28.32

全部捨てて作り直しだーまで追い詰めるって馬鹿だと思う。
少しずつ変化させていくことができないからそうなるんだよね。
全部いっぺんに変えるなんて現実的じゃないんだから。

全部いっぺんに変えることは不可能。じゃあどうするか？
それに答えられないから、どんどん壊れていくんだよ。

まあ、少しづつ良くしていくことが出来るのも技術力なわけで。
それを頭でわかっているのと実行するのとは全然違うわけで、
その実行できる力ってのが技術力そのものなわけで。

**デフォルトの名無しさん** · 2014/08/02(土) 20:19:36.36

>>400
前向きってのは、コード書きの脳からデザイナーの脳に変われるように努力しろって事。

**デフォルトの名無しさん** · 2014/08/02(土) 20:23:43.06

>>403
何に逃げてるのさ？

両方できるようになるというのなら正しい意見だが、
別のものに逃げたらだめだろ。

まるでペンもイラレもろくに使えない奴が
発想力とかいうのに逃げているのと同じ。

コードをまともに書けるようになった上でデザイナーになることはできる。
だけど、コードから逃げてもデザイナーにはなれない。

**デフォルトの名無しさん** · 2014/08/02(土) 20:23:58.64

よくある設計とコーディングっていう役割分担からしてくるっとる。
プログラミングなんて、設計九割五分なのに。
実装なんざオマケのオマケ。

SEとプログラマ、とわけてプログラマがキーボード叩く役とか、きがくるっとる。
まぁ聡明なお前らの会社は違うだろうけどね。

**デフォルトの名無しさん** · 2014/08/02(土) 20:28:21.78

「前向き」って言ってる奴が、
コードとデザインの両方を手に入れるじゃなくて、
コードから逃げてデザインを求めていて笑えるよ。
そういう奴は両方できない。

**デフォルトの名無しさん** · 2014/08/02(土) 20:33:33.15

やっぱり自分でコード書かなきゃやってる気がしない

**デフォルトの名無しさん** · 2014/08/03(日) 00:40:07.16

もう最近ガチガチの詳細設計やるとこって殆ど無いだろ
コメント的仮想コードとかで詳細は終わらせちゃうところが多い
その方が柔軟だしな

**デフォルトの名無しさん** · 2014/08/03(日) 00:45:38.31

一応UMLでシーケンス図とクラスとPublicメソッドだけはきっちり作ってるな
DBアクセスとかあたりまで
そっから先はprivateで実装して
アプリのフレームワークに依存しないメソッドとかクラスとかはプCommonフォルダに各自放り込んでもらう

で上手くいくと思ったけど
Commonがかなりカオスなことに

**デフォルトの名無しさん** · 2014/08/03(日) 07:51:54.04

>>408
あー、主に非技術者がやる作業だね。

**デフォルトの名無しさん** · 2014/08/03(日) 07:57:18.76

>>409
＞Commonがかなりカオスなことに

kwsk

**デフォルトの名無しさん** · 2014/08/03(日) 10:20:01.47

まるで業務系しか仕事がないかの勢いw

**デフォルトの名無しさん** · 2014/08/03(日) 10:36:51.70

>>411
コードが酷いのは予想のうちだけど
あれだけ言ったのに、規約が守られずにアプリのフレームワークに依存が作られてる
最初あたりに誰かがやったせいで後続が真似して、手続きなんとなくまとめただけみたいな処理がいっぱい
関数の共通化もうまくいってなくて
例えば分かりやすいところでは文字列をバイト列に変換してパディングするって処理があるんだけど
SJisStringUtil.ToByte
DBCodeChanger.LeftPaddingByteArray
StringModel.BytesWithSpace
こんな感じでいっぱいできてる
挙句にsTanakaとかフォルダできてるしｗ

**デフォルトの名無しさん** · 2014/08/03(日) 10:42:19.36

まあありがちやねｗ

だから規約を作った人は
必ずコードレビューをしなくてはいけない。

**デフォルトの名無しさん** · 2014/08/03(日) 20:06:25.42

>>953
糞設計、糞コード書くような人たちが
集まってコードレビューしてもなんの意味もない
しかもそういう人って声が大きいだけが取り柄みたいな人だろうし

**デフォルトの名無しさん** · 2014/08/03(日) 21:25:01.28

ロングパスきっちり通せよｗ

**デフォルトの名無しさん** · 2014/08/03(日) 23:57:33.38

Ａ社に発注して作らせた大規模なソフトを、
Ｂ社に一時的にメンテナンスさせて、
今はＣ社に機能拡張させているとか言う例が実際にあるからなー

それぞれがそレなりにちゃんとした会社であっても、
開発者の継続性が０の場合、
中のソースがかなり混乱するのは仕方ないかもしれん。

**デフォルトの名無しさん** · 2014/08/04(月) 22:06:42.37

リファクタリングはアートですよ。
アートは人間が生み出すものではありません。
ある日、天から降りてくるんです。
この感覚がわからない人は、アートしたことが無いんです。
つまり、リファクタリングもわからないってことです。

**デフォルトの名無しさん** · 2014/08/04(月) 22:17:15.14

わかる、わかるぜ～
ソースコードがある書き方になりたがってねだってくるんだぜ～
俺はそのとおりに書き写してるだけなんだぜ～

**デフォルトの名無しさん** · 2014/08/04(月) 22:19:31.15

やべえ。
適当ぶっこいてたらマジキチ召喚しちまった。
ちょっと反省。

**デフォルトの名無しさん** · 2014/08/04(月) 22:54:50.48

自作自演乙

**デフォルトの名無しさん** · 2014/08/27(水) 12:13:22.10

他人のコードだと思って、何の前情報もない状態でコードを読み
そこから読み取れる情報だけで、「なんで？」って思う実装を減らしていくのがリファクタリング

もちろん、処理の効率とかをよくする場合もあるけど、
どっちかというと、そういうのよりも第三者が見て読みやすいコードである状態を保つ事のほうが重要
(リファクタリングで大幅に処理コストが改善できるような糞実装が最初にされてることは稀)

ただ、リファクタリングをできるレベルに達していない職場も少なくない
とくに業務系や人売りで奴隷を集めた職場とかは、大抵メンバーのスキルが足りてなさすぎて無理
っていうか設計(という名のゴミファイル作成)段階からそびえ立つうんこを作っていってるから、実装時は既に手遅れ

**デフォルトの名無しさん** · 2014/09/04(木) 15:14:28.47

リファクタリングの誤用
ttp://capsctrl.que.jp/kdmsnr/wiki/bliki/?RefactoringMalapropism

リファクタリングの境界線
ttp://capsctrl.que.jp/kdmsnr/wiki/bliki/?RefactoringBoundary

**デフォルトの名無しさん** · 2014/09/13(土) 02:08:52.13

ボキもリファクタリングして欲しいです
https://twitter.com/y_konogi/status/510266774290694144/photo/1

**デフォルトの名無しさん** · 2014/09/13(土) 02:46:33.71

ちんこの振る舞いを保持したまま変化させる、もちろん性的な意味で。

**デフォルトの名無しさん** · 2014/09/13(土) 03:35:58.05

インタフェースの変更はリファクタリングか
http://capsctrl.que.jp/kdmsnr/wiki/bliki/?IsChangingInterfacesRefactoring
> 答えは簡単――インタフェースの変更はリファクタリングだ。

未知のバグフィックスはリファクタリングか？
http://capsctrl.que.jp/kdmsnr/wiki/bliki/?IsFixingAnUnknownBugRefactoring
> 私はリファクタリングと呼べると思う。バグを含んだ振る舞いを知らなかった（あるいは気にしなかった）わけだから、
> これは「外部から見たときの振る舞い」ではないのだ。たとえバグに気付いていたとしても、
> それが気にするようなバグでなければ、リファクタリングと呼んでもよいと思う。

最適化はリファクタリングか？
http://capsctrl.que.jp/kdmsnr/wiki/bliki/?IsOptimizationRefactoring
> 最適化とリファクタリングはどちらも変化を伴うものだが（なかには最適化かつリファクタリングとなる変化もあるが）、
> 両者は別物だと私は考えている。なぜなら、両者の目的が異なるからである。リファクタリングは、
> コードを理解しやすくするためである。最適化は、プログラムを速くするためである。
> つまり、リファクタリングと最適化は似ており、共通する変更がありはするものの、目的が異なるため、両者は別物であると私は考えている。

宣言の順序変更はリファクタリングか？
http://capsctrl.que.jp/kdmsnr/wiki/bliki/?IsDeclarationOrderingRefactoring
> 宣言（Javaで言うメソッドやフィールド）の順序を変更することは、リファクタリングと呼べるのか？
> リファクタリングの定義で、「理解や修正が簡単になるように」というフレーズを使った。
> 宣言部分を変更すると、理解や修正が簡単になるのだろうか？私は、そういう場合もあると思う。
> ソフトウェアの内部構造を変更しないという点が紛らわしいかもしれない。リネームしても実行内容は変化しない。
> だがリネームは、プログラムの理解度を向上させる非常に重要なリファクタリングの一種である。

**デフォルトの名無しさん** · 2014/09/13(土) 13:49:13.80

あれもこれも取り入れた「オブジェクト指向」とまるっきり同じパターンだな
どんどん曖昧な意味になりそう

**デフォルトの名無しさん** · 2014/09/13(土) 14:14:43.12

すべてリファクタリングの結果発生する作業だろ。
まったく理解できていないな。まさに本末転倒

**デフォルトの名無しさん** · 2014/09/13(土) 16:14:30.25

要件を仕様にまとめるのもリファクタリングですか？

**デフォルトの名無しさん** · 2014/09/13(土) 20:28:39.39

>>429
リファクタリングの一部ではあるな

**デフォルトの名無しさん** · 2014/09/13(土) 20:33:35.66

OpenSSLがリファクタリングされまくっているな

**デフォルトの名無しさん** · 2014/09/14(日) 00:35:49.32

>>429
違う

> リファクタリング中に2,3日システムが動かなくなっちゃってーなどと言ってる奴がいたら、
> んなもんリファクタリングじゃあなーいと言ってやれ。ドキュメントをリファクタリングしちゃるとか言ってる奴、
> それもリファクタリングじゃねーぞコラ。そういうのは、リストラクチャリング（再構築）というのだッ

**デフォルトの名無しさん** · 2014/09/14(日) 02:43:07.06

客の要件はそのままプログラムにできるけど、
それじゃあ最適化できてないから
外面の挙動は変わらない範囲で最適化を行う。
コードの実体だけがリファクタリングの対象じゃないだろ。

**デフォルトの名無しさん** · 2014/09/14(日) 03:54:19.00

>>433
それこそがリファクタリングの誤用で
リファクタリングではないと述べられていること。

**デフォルトの名無しさん** · 2014/09/14(日) 10:24:07.39

最適化じゃないんだよ
最適化なんかできるわけねーだろってのが大前提なんだよ

**デフォルトの名無しさん** · 2014/09/14(日) 13:02:21.11

バグも含めて機能そのままで、構造だけ変える（良くするつもり）ができるっていうのが結構単純な
還元主義的な思い込みで、実際の構造物は両者は一体というか、都合良くできないと思うんだよね。

テスト駆動とかもそうだけど、この種のスローガンが胡散臭いのは、物作りの本質的な困難を直視
しないで、小手先の技法を当てはめれば解決みたいに喧伝しすぎるところにあるんじゃないかと思う。

**デフォルトの名無しさん** · 2014/09/14(日) 14:21:12.62

別に胡散臭いとは思わないが、真に受けちゃったバカが「リファクタリング最強！」とか言い出すのはかなりうざい。

**デフォルトの名無しさん** · 2014/09/14(日) 15:42:46.67

>>436
> バグも含めて機能そのままで、構造だけ変える（良くするつもり）ができるっていうのが結構単純な
> 還元主義的な思い込みで、

できるよ。

というか、リファクタリングは構造を良くしましょう（終わり）じゃなくて、
構造を良くするのは当然の話しとして、機能をそのままにするためにはどうすればいいか？
って所が出発点で、

機能をそのままにするために、編み出された様々なテクニックが
リファクタリング手法なんだよ。

できないというのなら、リファクタリング手法（それには名前が付いている）
一つ一つに対して出来ない根拠を述べてみてよ。

君は単に、リファクタリングに手法があることを知らないで、
闇雲に自己流でなおそうとしてみて失敗しただけでしょう？

**デフォルトの名無しさん** · 2014/09/14(日) 15:44:54.17

なんだ、自分で自白してるじゃんかｗ

> この種のスローガン

スローガンとしか認識していないｗ

リファクタリングは、数学的な証明と
なんらかわらないんだが。

**デフォルトの名無しさん** · 2014/09/14(日) 18:12:37.41

ダメなコードは直すことでよくできる
という公理が大前提
1000行もあるようなおバカ関数を数学的に定式化して改善するのは無意味なこと
見れば何をすべきかわかる

**デフォルトの名無しさん** · 2014/09/14(日) 18:52:51.74

>>440
つまりどういうこと？
リファクタリングすればいいって話を
言葉を変えていってるだけだよね？

**デフォルトの名無しさん** · 2014/09/14(日) 19:25:36.36

リファクタリングを知らない人は、
リファクタリングを一気に直してしまおうと
思っているに違いない。

リファクタリングが問題が起きることがありえない
小さな修正の繰り返しであることをしらない。

**デフォルトの名無しさん** · 2014/09/14(日) 19:30:47.61

デザパタ信者みたいなのが暴走して悪評を広めてるんだろう

**デフォルトの名無しさん** · 2014/09/14(日) 19:32:04.00

その悪評を鵜呑みにしているのが
頭悪いと言われる所以なわけで。

自分の頭で考えろよとｗ

**デフォルトの名無しさん** · 2014/09/14(日) 21:08:34.07

リファクタリング

**デフォルトの名無しさん** · 2014/09/15(月) 00:27:34.64

流石に数学の定理と同等か言い過ぎだろ。
パターンと同じでさ、セオリーやメソッドじゃない、ちょっとしたコツの集積だろ

オブジェクト指向、CMMI、PMBOKとかと同じでさ、アメリカ人の教授とかはそういうのまとめて
自分が言い出しっぺになって、学会ごっこしたり、資格試験の元締めやろうとしたりするのが好きなんだよ。

そういう商売に乗せられているだけなのに、さも学術的な根拠があるものとして「勉強」したりするのが
偉いと思っている奴はどっかオツムが弱いとしか言いようがないw

**デフォルトの名無しさん** · 2014/09/15(月) 00:37:25.87

>>446
数学の定理じゃなくて、数学の証明だろ？

a + b = c を b = c - a
に置き換えるようなもの。

式の変形だよ。

リファクタリングのテクニックっていうのはどれも
この式の変形と同じようなもの。

一部の人が勘違いしているように、ぶっ壊して同じように作りなおすことじゃなくて、
項の移動のように、全く同じ結果になる変形をしているにすぎないんだよ。

**デフォルトの名無しさん** · 2014/09/15(月) 00:39:47.71

>>446
あと警告として、自分が知らないことを
勉強している奴は生意気だっていうのやめたほうがいいよ。
中学生かよ。あいつ勉強なんかしてるんだぜーってｗ

**デフォルトの名無しさん** · 2014/09/15(月) 00:43:11.40

何が「警告」だよ
笑わせるな

**デフォルトの名無しさん** · 2014/09/15(月) 00:44:52.76

いや、普通に恥ずかしいでしょ？

ガリ勉ガリ勉いって勉強しない悪ガキ。
自分が後で困るというのに。

警告してあげないといつまでたっても
気づかないよ。

**デフォルトの名無しさん** · 2014/09/15(月) 01:15:03.90

ぶっ壊して同じ結果が得られるように作り直すこととの違いを教えてください。

**デフォルトの名無しさん** · 2014/09/15(月) 01:41:27.21

イチから作り直したい病と
現実の範囲で出来る事だけやる工夫の違い

**デフォルトの名無しさん** · 2014/09/15(月) 02:07:53.50

機能やクラスを抽出するのだって破壊を伴うんじゃないの。
リスクが少ない範囲での変更もあれば、
時には大胆なリファクタリングもあると思うけど。

**デフォルトの名無しさん** · 2014/09/15(月) 04:21:21.27

>>451
> ぶっ壊して同じ結果が得られるように作り直すこととの違いを教えてください。
たとえば数学で、3x - 11 = 4 のxを求めるという問題があった時

1. 移項とい手法を使って、3x = 4 + 11 にして、
2. 足し算という手法を使って、3x = 15 にして
3. 両辺を同じ数で割るという手法を使って、x = 5
という風に、変形をしても等しいと証明されている
安全な手法を使ってシンプルな形に変形していくのがリファクタリング

>>453
大胆なリファクタリングって何よ？

まずさ、数学の式の変形のやり方と一緒で、
リファクタリング手法には名前があるって知ってる？

一覧見つけてきたから、これのどれが大胆で破壊を伴うのかちゃんと説明してくれ。
http://d.hatena.ne.jp/asakichy/20100607/1275877997

**デフォルトの名無しさん** · 2014/09/15(月) 04:22:40.33

>>453が言ってる、
大胆なリファクタリングというのは、

これらの手法を使わずに
いきなり最終的な答えを
だそうとしていることでしょ？

それはリファクタリングじゃない。

**デフォルトの名無しさん** · 2014/09/15(月) 04:24:53.24

>>452も少し勘違いしているね。

リファクタリングを「ソースコードを綺麗にしましょう」ということを
英語で言ったものとしか認識していないようだ。

リファクタリングというのは、安全に変形できるという
手法を使って、いっぽずつ書き換えていくもの。

手法を使わない書き換えはリファクタリングじゃない。

**デフォルトの名無しさん** · 2014/09/15(月) 10:57:57.36

>>456
それな
その手法の確立というか
その手法の念押しというか
そういう面も大きい

**デフォルトの名無しさん** · 2014/09/15(月) 11:09:38.77

これがリファクタ信者の暴走か

**デフォルトの名無しさん** · 2014/09/15(月) 11:28:39.31

リファクタリングの「関数の抽出」をやったら
増えた関数呼び出し分の実行コストが無視出来なくて
仕様を満たさなくなってしまいました

**デフォルトの名無しさん** · 2014/09/15(月) 11:46:22.25

>>459
そしたら「関数のインライン化」という
リファクタリングをすれば
動作を変えることなく、仕様を満たせるようになるよ。

やっぱり問題が起きた時にやるのは
リファクタリングだね（笑）

**デフォルトの名無しさん** · 2014/09/15(月) 11:49:22.77

つまり途中で一回ぶっ壊して同じ結果が得られるように作り直すわけね
良いと思うよ

**デフォルトの名無しさん** · 2014/09/15(月) 12:21:05.22

リファクタリングがゲシュタルト崩壊しそうなスレだ。

**デフォルトの名無しさん** · 2014/09/15(月) 12:43:17.41

安全を過信しすぎだな

**デフォルトの名無しさん** · 2014/09/15(月) 12:46:23.34

>>461
一回ぶっ壊したらだめだろｗ
それではリファクタリングになっていない。

リファクタリングは壊さずに直すことであり
壊さないで直すための手法がまとめられている。
http://d.hatena.ne.jp/asakichy/20100607/1275877997

**デフォルトの名無しさん** · 2014/09/15(月) 13:45:51.89

>>464
>>459の操作で一回ぶっ壊れてるじゃん
少なくとも「関数の抽出」はリファクタリングの操作としてアトミックじゃない

**デフォルトの名無しさん** · 2014/09/15(月) 15:20:24.10

慌てずリファクタリングの公式に沿って変更すれば副作用は一切ない。

**デフォルトの名無しさん** · 2014/09/15(月) 15:20:49.07

>>465
> 少なくとも「関数の抽出」はリファクタリングの操作としてアトミックじゃない

アトミックだけど？

リファクタリング本を見ればしっかり書いてあるよ。
アトミックに作業する方法。

どうせあんたは関数を消して書きなおす（書き直してる間
元の関数がなくなってる状態）が起きるって思ってるんだろうけど。

ほんと、やり方をしらんのね。しらんから壊れるって言ってる。
わかりやすい。

**デフォルトの名無しさん** · 2014/09/15(月) 15:21:50.80

ちなみに、リファクタリングブラウザを使えばもっと簡単に行える。
もちろん、リファクタリング本にはそういうツールを使わないやり方も書いてある。

**デフォルトの名無しさん** · 2014/09/15(月) 15:45:17.66

>>459と>>460の間に一回壊れてるよね

**デフォルトの名無しさん** · 2014/09/15(月) 15:51:22.11

>>467
手で書き直したとかじゃなくて、メソッドの抽出することで
仕様を満たさなくなるケースもあるって話だろう

その直後にインライン化したとしても、一旦仕様を満たさない状態になったのは事実

**デフォルトの名無しさん** · 2014/09/15(月) 15:53:23.99

まあ俺ぐらいリファクタリングに精通すると、最初からリファクタリング後の最終形になるように最初からコーディングできちゃうわけで、あえてリファクタリングを意識しなくていいわけなんだけどね。

中島敦の「名人伝」にでてくる「弓ってなに？」といった弓の名手のごとし。

**デフォルトの名無しさん** · 2014/09/15(月) 15:55:47.97

>>469
壊れてないよｗ
ばかなのかな？
人の話きかないよね。

**デフォルトの名無しさん** · 2014/09/15(月) 15:57:45.71

>>470
> 手で書き直したとかじゃなくて、メソッドの抽出することで
> 仕様を満たさなくなるケースもあるって話だろう

メソッドの抽出で仕様を満たさなくなることはありません。

> その直後にインライン化したとしても、一旦仕様を満たさない状態になったのは事実

あんたの言ってる「仕様」って関数呼び出し○ナノ秒以内で
あることっていう要件の話だよね？ｗ
それは仕様ではない。

**デフォルトの名無しさん** · 2014/09/15(月) 16:00:52.19

>>471
それは過剰な設計になってるよ。

コードの規模に応じて、適切な設計というのは異なる。

コードに修正が入る、それがバグの修正でない限り
機能化拡張だろう。

機能拡張にともなって規模が増るというような時にリファクタリングをするんだ。
機能追加とリファクタリングはわけてやるものだから、
機能追加前、もしくは機能追加後にリファクタリングね。

最初から過剰な拡張性をもたせるのはよくない。

**デフォルトの名無しさん** · 2014/09/15(月) 16:31:02.56

今更ながら>>1が言っていたことって正しいんだなって思った。

ソースコードを綺麗に作りなおすのがリファクタリングだって
思っている奴が多いこと多いこと。

**デフォルトの名無しさん** · 2014/09/15(月) 16:59:56.60

ポリモーフィズム化するのは機能追加だアホ

**デフォルトの名無しさん** · 2014/09/15(月) 17:07:57.72

>>473
> あんたの言ってる「仕様」って関数呼び出し○ナノ秒以内で
> あることっていう要件の話だよね？ｗ
> それは仕様ではない。

ループの中で繰り返し呼び出されたら馬鹿にならん差になることもある
仕様かどうかはケースバイケースだアホ

**デフォルトの名無しさん** · 2014/09/15(月) 17:15:35.47

リファクタリングの「関数のインライン化」をやったら
生成されるプログラムのバイナリサイズが許容範囲を超えて
仕様を満たさなくなってしまいました

**デフォルトの名無しさん** · 2014/09/15(月) 17:17:53.19

ID:kUSteVkT必死すぎだなｗ

”要件” を満たせないなら、
同じ仕様のまま要件を満たすように
リファクタリングすればいいだろうｗ

**デフォルトの名無しさん** · 2014/09/15(月) 17:32:28.60

ID:kUSteVkTアは書いたコードが要件を満たせなかったら
そのコードを捨てて一から作り直んだろうかｗ

**デフォルトの名無しさん** · 2014/09/15(月) 17:33:12.92

一日中スレに張り付いてる ID:9UWhhSIJ に必死過ぎと言われてもな…

で、リファクタリングの手法に則って変換しても
要件を満たせないケースがあると認めるのか？

**デフォルトの名無しさん** · 2014/09/15(月) 17:38:23.74

やっと要件といったねｗ

リファクタリングは仕様を変えずに
コードをわかりやすい形に修正するものだから
要件を満たさなく慣れば、満たすように
リファクタリングすればいいってことで終わる話だ。

なんせリファクタリングしても仕様は変わらないのだから
仕様を変えずに要件を満たせるように作り変えられる。

**デフォルトの名無しさん** · 2014/09/15(月) 17:44:05.42

>>482
いや、俺は最後に修正をコミットするときに仕様を満たしてれば
途中で壊れてようがリファクタリングとしてOKって立場だから、それで良いよ

でも、お前はリファクタリングの手法に則ってれば
絶対に壊れることは無いっていう立場だろ？(>>454-456)

**デフォルトの名無しさん** · 2014/09/15(月) 18:58:56.46

絶対に壊れない奥義は秘中の秘で
師匠に皆伝を認められないと伝授してもらえないんだよ

**デフォルトの名無しさん** · 2014/09/15(月) 19:33:35.36

リファクタリングってどのタイミングでやる事を想定してるのかな
プロジェクトにそんな工程存在しないし
終わって凍結したコードを後から修正なんてしないでしょ
不具合とか新機能とか更改する案件が出てきて初めて
次のプロジェクトやりましょうってなるわけでしょ
そうなったとしてコードの機能追加や修正はあっても
このスレで言う仕様通りに動くものにわざわざ手をつけるなんてことするかな

**デフォルトの名無しさん** · 2014/09/15(月) 19:40:39.59

やりたい時がやるべき時なんだよ。
コードがクソだと思ったら何時でもそれがリファクタリングのタイミング。

**デフォルトの名無しさん** · 2014/09/15(月) 19:58:17.80

だからそんなタイミングなんて実際存在しないよねって話をしてるのに

**デフォルトの名無しさん** · 2014/09/15(月) 20:46:42.81

>>487
だからコードがクソだと思わなかったらやる必要ないんだって

**デフォルトの名無しさん** · 2014/09/15(月) 21:25:15.72

>>483
> いや、俺は最後に修正をコミットするときに仕様を満たしてれば
> 途中で壊れてようがリファクタリングとしてOKって立場だから、それで良いよ

リファクタリングの誤用
http://capsctrl.que.jp/kdmsnr/wiki/bliki/?RefactoringMalapropism
> ……のだが、リファクタリングは、適切に使われてはいない。
> リファクタリング中に2,3日システムが動かなくなっちゃってーなどと言ってる奴がいたら、
> んなもんリファクタリングじゃあなーいと言ってやれ。ドキュメントをリファクタリング
> しちゃるとか言ってる奴、それもリファクタリングじゃねーぞコラ。そういうのは、リストラクチャリング（再構築）というのだッ。

> リファクタリングはより具体的な技術のことで、小さな「振る舞いを保持したままの変化」
> （リファクタリングと呼ばれている）から成り立っている。システムをリファクタリングするときは、
> 数分以上、システムが壊れたままにしてはいけない。

**デフォルトの名無しさん** · 2014/09/15(月) 21:31:41.31

>>486
＞やりたい時がやるべき時なんだよ。

趣味だよなこういうのは
死ぬまでいじってろ

**デフォルトの名無しさん** · 2014/09/15(月) 21:36:40.31

>>490
趣味とは、汚くても動けばいい。と
客の前で言えないことを、こっそりやること。

**デフォルトの名無しさん** · 2014/09/15(月) 22:30:57.87

>>489
コミットするまでシステムはそのままなんだから（正確にはデプロイするまでだが）
完全にリファクタリングの定義に沿ってるよね
誤用してるのはお前だね

**デフォルトの名無しさん** · 2014/09/15(月) 22:47:48.33

IDEのリファクタリングのメニューから選べる機械的にできる変換のみを
リファクタリングとする派閥があるんだよ
要件を満たすかではなく、機械的にできる事が重要なわけ

なお、これは底辺の馬鹿でも可能な「ドカタ・スタイル」として認知されてる

**デフォルトの名無しさん** · 2014/09/15(月) 23:33:30.39

>>492
これはひどい
バカというより迷惑

**デフォルトの名無しさん** · 2014/09/16(火) 02:50:25.03

>>446
>オブジェクト指向、CMMI、PMBOKとかと同じでさ、アメリカ人の教授とかはそういうのまとめて
>自分が言い出しっぺになって、学会ごっこしたり、資格試験の元締めやろうとしたりするのが好きなんだよ。

リファクタリングって、資格試験制度や学会作ろうって動きがあるのかな？
パターンはなんかやってるところあるよね。

**デフォルトの名無しさん** · 2014/09/16(火) 04:23:48.75

>>493
> IDEのリファクタリングのメニューから選べる機械的にできる変換のみを
> リファクタリングとする派閥があるんだよ

それは、リファクタリングをわかってない派閥であり、
無知なリファクタリング反対派となんらかわらないよ。

リファクタリング本を読んでいれば、
リファクタリングブラウザで行えるのは
リファクタリングのほんの一部だって知ってる。

**デフォルトの名無しさん** · 2014/09/16(火) 12:38:21.05

リファクタラー内部抗争勃発

**デフォルトの名無しさん** · 2014/09/16(火) 13:41:58.56

リファクタリング前と後で同じテストが通ればOK派と、
リファクタリング中のどの時点でもテストが通らないとダメ派か。

**デフォルトの名無しさん** · 2014/09/16(火) 19:13:39.64

リファクタリングのアトミックな単位は一文字削除

**デフォルトの名無しさん** · 2014/09/16(火) 20:19:15.75

>>1
リファクタリング自体が理想論。

つまりは、自分（以下Ａ）と同等かそれ以上の腕の持ち主だけで人材が構成されている必要がある。ただし、これは自分視点。
しかし、この状態だと、Ａ以上の腕の持ち主からＡを見ると、Ａは足手まといで汚いソースを作り上げる元凶。
上級者が、切磋琢磨していく状態なら良いが、上級者なんて1%もいない。99%の下手が次々と入ってきてクズソースを乱発。
腕の良い者達は、クズソースのリファクタ作業だけをやるハメに。
腕の良い者達だけでやっていれば、もっと早く開発ができるのに。しかしリファクタリングというとできるのは腕の良いものだけ。
よってクズの尻拭いを永久にやらされる上級者は、腐る。
そしておしまい。

リファクタ云々よりクズの徹底排除こそ最優先。
それがなされなければ、確実にクズソースの生成のほうが圧倒的に早い。