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

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

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

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

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

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

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

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

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

で？

**デフォルトの名無しさん** · 2011/11/19(土) 17:30:26.36

汚いコード
ゴミ溜めが如くきったない部屋で過ごしてもなーんにも問題無い
↑
↓
チリ一つも落ちていないようなクリーンルームじゃないと過ごせない
綺麗なコード

って話だろ？何事もほどほどにしとけって事だよ

**デフォルトの名無しさん** · 2011/11/19(土) 17:33:20.81

>>225
人の話を良く聞かないで進めちゃって失敗するほうじゃない？

**デフォルトの名無しさん** · 2011/11/19(土) 18:59:16.42

>>224
キミがそのコードをずっとメンテナンスする責任者だとして、
どこかのプログラマが明らかにまとめるべきところまとめてこなかったり、
分けるべきところをを無理やりまとめてきたりした場合、
正しく動くという理由でそのままにしておくのかい？

**デフォルトの名無しさん** · 2011/11/19(土) 19:28:32.54

>>227
作るときに設計書にあわせてもらいます
ソースだけ弄るってことはしません

**デフォルトの名無しさん** · 2011/11/19(土) 19:33:14.80

ソース＝設計書だろ?

**デフォルトの名無しさん** · 2011/11/19(土) 19:47:12.13

>>229
底辺乙

**デフォルトの名無しさん** · 2011/11/19(土) 19:51:09.79

>>228
要するに仕様は変えずに設計を変えるんだろ
リファクタリングじゃないか

**デフォルトの名無しさん** · 2011/11/19(土) 20:14:22.32

最高綺麗で動く
↑　汚いが動く
↓　綺麗で動かない
最低汚くて動かない

一番下のは捨ててよし
[動く／動かない] と [綺麗／汚い] の相関関係だお

汚いけど動くのは、綺麗だが動かないものより価値がある。
でも綺麗で動かないのを動くにしやすいし、
汚いけど動くものも、後で何か変更するにあたって、動くのを保ちつつ綺麗にしておくと直しやすい。
「綺麗にする」のがリファクタリング。動かないものを動くようにすることとはイコールではない。関係はあるけど。

**デフォルトの名無しさん** · 2011/11/19(土) 20:27:15.16

>>232 使用がバッチィからコードもバッチイって発想はないのか？

**232** · 2011/11/19(土) 20:45:33.70

仕様が汚いと動かすのが難しい
↑
↓
綺麗な仕様は動かしやすい
って関係はあると思うけど、コードと仕様は直接関係しないんじゃねの？

**デフォルトの名無しさん** · 2011/11/19(土) 20:55:13.83

>>234
汚い仕様を何とか動かすために、汚い姑息なコードを大量に入れてる
例なら山ほどあるよ

**デフォルトの名無しさん** · 2011/11/19(土) 21:31:39.15

コードを綺麗/汚いで語るから話がおかしくなるんじゃないか。
リファクタリングって大なり小なり設計の問題の修正のことだと思うんだが。
オレがずれてるのか。

**デフォルトの名無しさん** · 2011/11/19(土) 21:34:18.54

>>236
おれもそう思うよ. 仕様も設計の内だとも思うけど...

**デフォルトの名無しさん** · 2011/11/19(土) 21:49:35.63

もちろん設計の問題とコードの綺麗/汚いは関係ありますが？

最初にきちんと設計をしたつもりでも、実装段階では想定したとおりに行かなかったり、抜けがあったりすることはよくあることです。
実際に書いているうちにいろいろ思いつくこともあります。ちょこっと例外的な処理を付け加えて、を繰り返し、コードは汚くなっていきます。
そうしてソースがスパゲッティ化し、メンテ不能のソースとなっていきます。

そうならないようにするためにリファクタリングがあります。
リファクタリングとは、仕様を変えることなく、ソースコードを改造することをいいます。
汚いソースコードでもプログラムは動きますが、メンテナンスするのは大変です。
汚いソースコードと綺麗なソースコードではメンテのしやすさが全く違います。
なのできるだけ綺麗なソースを書くように心がけ、汚くなったら速やかに書き直すことです。
後々のことを考えて、わかりやすいソースに直します。

**デフォルトの名無しさん** · 2011/11/19(土) 22:15:38.43

>>238
> そうならないようにするためにリファクタリングがあります。

そうならないように設計を見直す方が先じゃないか?

小手先でどれだけいじっても, 汚い設計は汚いソースを
再生産するだけじゃないのか?

それだったら, 設計をリファクターすべきだ

ぶっちゃけ, ユーザーインターフェースが変わらなきゃ
仕様の範囲内だ

**デフォルトの名無しさん** · 2011/11/19(土) 23:03:54.10

>>238
コピペはいらんよ。

汚い綺麗で語るとコードの可読性ばかりを問題にしてるように感じるって話。
だからリファクタリングがいらないとか言う奴がいるんじゃないの。

コードが綺麗であっても設計上の問題が存在することは当然あるよね。

コードの綺麗/汚いは設計の一部しか示していないと思うし、
その修正はリファクタリングの一部でしかないと思う。

**デフォルトの名無しさん** · 2011/11/20(日) 07:43:51.29

>>240
したらただの仕様変更だよねそれって
まあ、名称にこだわる必要もないけど

**デフォルトの名無しさん** · 2011/11/20(日) 08:21:15.92

関数、クラスの仕様は変わっても
システム全体の仕様は変わりません。

なので仕様変更にはあたりません。

**デフォルトの名無しさん** · 2011/11/20(日) 08:21:59.02

設計変更と仕様変更は別の話といえばよかったか。

**デフォルトの名無しさん** · 2011/11/20(日) 12:07:12.15

設計を仕様と見なしたら
仕様変更を伴わないコード変更って存在するのか？

**デフォルトの名無しさん** · 2011/11/20(日) 12:08:20.66

aとかbとかわけのわからん変数名を
意味がある変数名に変更するとか。

**デフォルトの名無しさん** · 2011/11/20(日) 13:09:50.85

I/F変更を伴うかどうかっていう観点じゃないの

ユーザに見える部分とか
担当者の異なるモジュール間とか

**デフォルトの名無しさん** · 2011/11/20(日) 17:10:54.61

オリンパスコーディング

**デフォルトの名無しさん** · 2011/11/20(日) 17:46:34.19

結局、
外から見た目の振る舞いが変わるか/変わらないかがポイントで、
外から見た目の振る舞い＝仕様であって
内部構造≒設計は、リファクタリングの対象
って事でおｋ？

**デフォルトの名無しさん** · 2011/11/20(日) 18:02:36.08

>>248
個人的にはソレが正しいと思うけど
そう思ってない人がいる予感。
241とか

**デフォルトの名無しさん** · 2011/11/20(日) 18:50:26.97

>>249
じゃあ、リファクタリングってのは設計変更までを指すってことでいい？
何やんだかさっぱりわからないけど

**デフォルトの名無しさん** · 2011/11/20(日) 18:53:49.64

>>250
設計の範囲を定義しろ。
話はそれからだ。

**デフォルトの名無しさん** · 2011/11/20(日) 21:17:25.23

>>251
そっちにまかせる
>>248がえらそうに宣言してるから>>248に決めてもらうか

**デフォルトの名無しさん** · 2011/11/21(月) 09:59:01.46

(この人たち、なんで今さらこんな議論をしてるんだろう)

**デフォルトの名無しさん** · 2011/11/21(月) 22:35:10.04

最初からずっとこのスレにいるのは
お前だけだよｗ

**デフォルトの名無しさん** · 2011/11/22(火) 10:39:05.00

そうか、リファクタリング本を読んでるのは俺だけだったか

**デフォルトの名無しさん** · 2011/11/23(水) 00:32:21.88

>>255
本の受け売りじゃなくて中身をちゃんと理解しろよ

**デフォルトの名無しさん** · 2011/11/23(水) 01:19:14.75

そういう手合いはおそらくよんですらいない
買っただけ

**デフォルトの名無しさん** · 2012/02/07(火) 13:45:03.37

改修が必要になったときに初めて
その場で interface をでっちあげて、その後、クラスお取替え

これでいい気がしてきた

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

それでいい

**デフォルトの名無しさん** · 2012/03/24(土) 14:35:39.62

リファクタリングを身に付けるとコードレベルでの設計力が上がりますか？

**デフォルトの名無しさん** · 2012/03/24(土) 16:05:22.68

設計力は下がります
でも組んだ後の問題に対する対応力は上がります

**デフォルトの名無しさん** · 2012/03/24(土) 17:35:34.20

>>261
何故、設計力は下がるのですか？

**デフォルトの名無しさん** · 2012/03/24(土) 21:11:33.51

設計力あがるだろ

正しい設計のコードに
変化させるのがリファクタリングだ。

**デフォルトの名無しさん** · 2012/03/24(土) 21:36:47.86

>>49-52で結論は出てる
リファクタリングはオナニー
好きにやればいい
公開オナニー好きでも床オナ好きでもその方法を誰も咎めることはできない

**デフォルトの名無しさん** · 2012/03/24(土) 21:51:30.52

オナニー？　自己満足と言いたいのかもしれないが。
仕事でやるのなら自己満足じゃないぞ。
みんなの満足。

**デフォルトの名無しさん** · 2012/03/24(土) 22:21:58.07

みんなでオナニー

**デフォルトの名無しさん** · 2012/03/25(日) 12:10:02.63

分散マスタベーション

**デフォルトの名無しさん** · 2012/04/22(日) 22:43:46.10

密に結合した処理を処理を疎になるようにするとか
処理が対象になるようにシーケンス直すとか
って意味があるリファクタリングだと思うけど
こういうのはリファクタリングっていわんの？

**デフォルトの名無しさん** · 2012/08/05(日) 00:31:39.26

>クラス内部で別のクラスを生成しない
>>4のこの話って完全にはDIでも使わなきゃ無理だけど、
FactoryMethodで解決できるよね。

>publicメソッドの引数には、なるべくクラスを使わない。
完全抽象化クラスに類するもの限定ってなら正しいけど、
intや文字列型だけってのは無いよね。スタブ渡せば済む話だし。

**デフォルトの名無しさん** · 2012/08/05(日) 01:11:40.91

言葉の揚げ足取りに終始しててウザいだけのスレになっちゃってるなｗ

**デフォルトの名無しさん** · 2012/10/14(日) 16:17:10.72

大規模アプリには
必ずリファクタリングが必要。
開発工程の一つに加えていいレベル。

**デフォルトの名無しさん** · 2012/10/15(月) 15:52:21.57

VB6で幾度となく機能追加が行われたコードをぼんやり眺めてると
リファクタリング？何それおいしいの？
という気分になってくる。

**デフォルトの名無しさん** · 2012/10/16(火) 18:14:20.05

>>272
そういうコードこそ、リファクタリングが楽しいんじゃないの？

**272** · 2012/10/16(火) 18:35:14.51

趣味でやるならすごく楽しい。一人でやるのなら絶対リファクタリングしてる。
けど仕事となると時間が取れない。
さらなる機能追加と他言語への移植作業用のドキュメントが優先になってまつorz
移植作業前にリファクタリングできたら解読も楽だろうになあ。
そんなことより成果物（ドキュメント）が優先だってさ。しゃーねーや。

忍法帖【Lv=40,xxxPT】(0+0：5) · 2013/07/11(木) NY:AN:NY.AN

refakuta

**デフォルトの名無しさん** · 2013/07/11(木) NY:AN:NY.AN

リファク太

◆unko./w.Osri · 2014/01/10(金) 07:46:54.18

リファクトスタンダード

**デフォルトの名無しさん** · 2014/01/21(火) 23:03:30.89

リファクタリング本はかなり勉強になったな。
ぐちゃぐちゃなコードしか書けなかったのが、リファクタリングしまくってたら
最初からオブジェクト指向やらデザインパターンやらを考慮したコードが書けるようになってた。

**デフォルトの名無しさん** · 2014/07/25(金) 01:44:17.80

リファクタリング中にバグが見つかっても修正しちゃいけないんですか？
振る舞いが変わるわけだし。
リファクタリング原理主義者の方の意見が聞きたいです。

**デフォルトの名無しさん** · 2014/07/25(金) 07:34:43.94

好きにすれば？どうせ個人でやってんだろ
一人ならほんと楽しいよねリファクタ。

業務でリファクタなんかできねーよ
リリースしてから何年も動いてるパッケージに手入れられるわけないだろ！

**デフォルトの名無しさん** · 2014/07/25(金) 10:51:25.65

業務でリファクタリングの時は、バグの種類にもよるけど基本的にはそのまま。
勿論、リファクタリング後に修正することを見越してリファクタリングすることになる。
実は、バグを見つける為にリファクタリングすることもあるので、「できねーよ」で済まない場合もあるのよ。

**デフォルトの名無しさん** · 2014/07/25(金) 11:26:11.42

バグを見つけるためにリファクタリングをすることはあるが
改修はリファクタリング前のコードに対して行うことになるなぁ

**デフォルトの名無しさん** · 2014/07/25(金) 12:21:15.76

リファクタリングとは
テストの合格を維持したままの
コードの修正でしょ

**デフォルトの名無しさん** · 2014/07/25(金) 12:41:48.16

上を納得というか安心させるための無駄検証にコストを掛けた後だと
いじくれないというのはわかる

だがサブシステムを小分けして
その範囲内で裁量をもたせられるようにしてないのはアカン

**デフォルトの名無しさん** · 2014/07/25(金) 13:58:36.59

>>282
> 改修はリファクタリング前のコードに対して行うことになるなぁ

それって人件費を無駄に捨ててるじゃないか？
会社に損害与えてるよ。
プロ意識無いのかね？

**デフォルトの名無しさん** · 2014/07/25(金) 20:12:11.75

リファクタリングしたがる人とは仕事したくないよね

**デフォルトの名無しさん** · 2014/07/25(金) 20:12:41.10

でも実は一発目無計画で作ってリファクタリングするのが一番品質がいい

**デフォルトの名無しさん** · 2014/07/25(金) 21:18:52.98

一発目無計画っていうのがありえなさすぎ。
趣味のプログラミングだろそれは。

**デフォルトの名無しさん** · 2014/07/25(金) 22:15:52.25

>>287
それは全然不思議じゃないね。
下書きだと思えばいい。

一発で書くよりも、下書きして全体を理解してから
清書する。

**デフォルトの名無しさん** · 2014/07/25(金) 23:03:10.49

神ならざる身で限界を知りつつも最善を目指す手法ではないか

**デフォルトの名無しさん** · 2014/07/25(金) 23:24:21.34

考え方の違いなんだよね。この業界に「ボーイスカウトの規則」っていう言葉があるらしい。

http://qiita.com/hirokidaichi/items/d6c473d8011bd9330e63
> ボーイスカウトが、来る前よりも帰った後の方が山をきれいにしておくことにちなんだ規則。
> ソフトウェア開発においては「モジュールをチェックインする際には、必ずチェックアウト時よりも美しくする」ことを意味する。

リファクタリングしない人って、ただ動けばいい、コードが怖くて触れない。
他の部分はいじらないですませようとしちゃう。

修正しない部分なら見て見ぬふりもいいが、修正するなら、
そのまわりを綺麗にしろと。

それが出来ない人は、バグも多いんだよ。してシンプルにしてないから。
複雑なものはバグが多い。複雑だからコードを理解していない。
理解してないからバグが出る。当たり前の話。

**デフォルトの名無しさん** · 2014/07/25(金) 23:31:13.15

そういう自己満足だけの身勝手な修正が一番たちが悪いんだよ

**デフォルトの名無しさん** · 2014/07/25(金) 23:33:03.76

>>292
なんでですか？

まずきれいなコードのほうが、メンテナンス性が高くなり
バグが減り、開発コストも下がります。

ここは、否定しませんよね？

じゃあ、最終目標は「修正」するべきであってます。

あなたは、まったく筋違いの否定をしているのでは？

**デフォルトの名無しさん** · 2014/07/25(金) 23:42:25.29

>>293
そもそも前提が間違ってる。
きれいなコードって何だ？お前のオナニーだろ？
コード修正したいなら、きちんと設計のレビューを受けてチームの了承得てからにしろ。

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

コードがスパゲティになってしまって、
簡単な機能追加ですら2週間もかかるようになってしまってた
（しかも、テストを繰り返しても正しさに自身が持てなかった）のが、
3週間ほど時間をかけてリファクタリングした結果
簡単な機能追加なら1時間もかからず行えるようになりました

**デフォルトの名無しさん** · 2014/07/26(土) 01:29:58.80

今どきスパゲティコードなど、そうそうお目にかかるもんじゃない

**デフォルトの名無しさん** · 2014/07/26(土) 02:28:53.78

リファクタリングするもしないも、そのソフトの特性や現場事情があんだから、
まずそういう情報がないとなんとも言えねーだろ。
共通して言えるのは独断で判断するなってことだよ。

**デフォルトの名無しさん** · 2014/07/26(土) 08:38:26.34

>>296
ちゃんとリファクタリングするようになったからね

**デフォルトの名無しさん** · 2014/07/26(土) 09:05:17.83

設計の手法が確立してきたからだろｗ

**デフォルトの名無しさん** · 2014/07/26(土) 09:15:20.20

リファクタリングする前のコードを保存しておいて
リファクタリングしてテストに合格したら
前のコードを消去すれば安全だよ

**デフォルトの名無しさん** · 2014/07/26(土) 09:33:49.93

>>300
マトモなバージョン管理システムとBTSは導入済み前提でしょうよ
でなきゃリファクタリングなんて無理

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

>>288
神が降りてきて、わぁぁぁぁぁってプログラム書く手が動くような事あるだろ？

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

業務ではないなｗ

**デフォルトの名無しさん** · 2014/07/26(土) 13:52:30.19

最近ソフトウェアが壊れていくプロセスってのが
わかりだしてきたよ。

いくつかパターンがあってね、名前でもつけて
近いうちに何処かで発表したいかなって思ってる。

たとえばモノマネパターン。
周りにあるコードを真似て書こうとするパターン。

このような関数があったとする。
function foo(name) {
　var funcTable = {
　　func1: functioni() {・・・},
　　func2: functioni() {・・・},
　　func3: functioni() {・・・},
　};
　funcTable[name]();
}

それを真似してこんなコードを書く
function bar() {
　var name = 'func1';

　var funcTable = {
　　func1: functioni() {・・・},
　};
　funcTable[name]();
}

もし0からコードを書かせたらこんなアホなコードを書くわけがないのに、
なぜか周りにあるコードを真似して書こうとする。

**デフォルトの名無しさん** · 2014/07/26(土) 15:29:59.33

クソコード書いて、次は誰かがもっといいコード書くだろうからそれマネしようとか思ってたら
俺のクソがプロジェクト中にコピペされて救いようがなくなってたことならある

**デフォルトの名無しさん** · 2014/07/26(土) 23:32:58.38

>>305
それそれ、誰もが知ってるコピペパターンｗ

できれば最初からクソコード書くなって話でもあるが、
それは仕方ない。誰でも成長するものなのだから＝後の自分はもっと綺麗に書ける。
なのに、昔の初心者のコードを真似る奴が多い多い。

それやってると、初心者のコードをありがたがって参考にしてどうするの？ｗ

話それたけど、本来はコピペするなら再利用できる形にリファクタリングして
それを呼び出さないといけない。そしてこれは絶対にやるべきリファクタリングの一つ。

ただし、無関係な処理なのに形が似ている（しかしわずかに違う）のを
無理やり共通化して複雑化させるパターンもあるので注意。

そういう場合でもコードはなるべくシンプルになるようにしなくちゃいけないのだが、
モノマネパターンの通り、なぜか同じ形を真似ようとする。
できないわけじゃないのに真似をする。何も考えてないのかねって思う。

**デフォルトの名無しさん** · 2014/07/27(日) 02:21:16.13

仕様書が別になってたらどんなに処理が似てても別にするなあ

**デフォルトの名無しさん** · 2014/07/27(日) 09:42:53.89

似てる処理を共通化できないのは設計がきちんと出来てない証拠
仕樣的に別物とか関係ない

**デフォルトの名無しさん** · 2014/07/27(日) 09:55:49.81

いやあるよ。
だいたい仕様変更が入ったときって、仕様書の画面毎とかだかし、
テストも仕様書毎につくるから、共通化してもテストの工数あんま減らんし。
修正になった仕様書の枚数と、手をいれる工数が一致してるとすごく客に説明しやすい。

>似てる処理を共通化できないのは
断じて違う。「似てる処理」を共通化するんじゃない。部品を共通化するんだ。
このへん誤解してなんど泣いたことか。
おまえのその考え方はスパゲッティまっしぐら。

**デフォルトの名無しさん** · 2014/07/27(日) 09:59:56.78

>>309
どんな考えでもいいけど何かしらの共通化がされてたら
> 修正になった仕様書の枚数と、手をいれる工数が一致
これは成立しないぞ
まず自分の矛盾に気付くのが先のようだ。

**デフォルトの名無しさん** · 2014/07/27(日) 10:34:57.72

>>310
青いのう
部品を共通化するって考え方が徹底してれば、だいたいの場合は一致するもんだ。

もちろん客に説明するより少ない工数で済むならそれでいいよ？
問題は、「似てる処理」を共通化してると、工数が仕様書の改修量よりずっと膨らむことがあるってことなんだ。
ささいな修正が全体に影響してテストが膨らんだり、結局コピペで新たにクラス作らなくちゃいけなくなったりな

うん、これも共通化してるなら何でも同じとか言われそうだな
現実のブツ無しだと説明が難しいが…

**デフォルトの名無しさん** · 2014/07/27(日) 10:58:40.58

>>311
説明が難しいのはお前が「部品」とかいうオレオレ言語使って自己満足してるからだ。
ワケの分からん独自理論開発するまえに基本をしっかり勉強しろ。

**デフォルトの名無しさん** · 2014/07/27(日) 11:02:04.82

>>311
甘いのう
残念ながら今時の設計者の中にはコードを全く書けないやつが少なからず居る
よって、共通化なんて幻想に過ぎぬわwww

**デフォルトの名無しさん** · 2014/07/27(日) 11:19:32.95

func1(){
a b c d
}
↓
func0{
a b
}

func11(){
func0() c d
}

func12()
func0() e f
}
上のような共通化は似てる処理と部品どっちが主張しているんだ？

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

>>312
独自理論じゃないよ！みんなそう言ってるよ！
お前こそ本読んで知った気になってるだけだろ！頭でっかちめ

確かに、だいたい初心者向けの本には同じ処理を共通化すべしとか適当に書いてあるから、
実際の経験がないと理解しづらい部分ではある。

**デフォルトの名無しさん** · 2014/07/27(日) 13:06:38.84

>>315
「部品」で意味してるのは何なんですか？

**デフォルトの名無しさん** · 2014/07/27(日) 14:19:58.36

>>316
ごめん。一般的じゃなかった。
「機能」って読み替えて。

**デフォルトの名無しさん** · 2014/07/27(日) 14:22:31.05

人間は細胞でできているだろ
プログラムも細胞で作れば上手くいく
俺の独自理論だけど

**デフォルトの名無しさん** · 2014/07/27(日) 14:35:22.28

うだうだ言わずに 60兆個の細胞を持ってこい

**デフォルトの名無しさん** · 2014/07/27(日) 15:03:56.50

共通化するときの決まりの一つとして、
全く同じコードの時に共通化するのであって
似ているコードを共通化してはいけない。

似ているコードをむりゃリ共通化しようとすると、
引数で処理を分岐することになる。
aが渡されればAの処理を、
bが渡されればBの処理をみたいに。

引数で分岐しだすとアウトだな。

**デフォルトの名無しさん** · 2014/07/27(日) 15:10:03.90

>>317
あーなるほど
わざわざありがとうございます

**デフォルトの名無しさん** · 2014/07/27(日) 18:36:01.67

経験的にforの内部、ifの内部は関数にまとめると都合よいことが多い
そして気が付くと xxhelper, xximpl, xxsub といった関数であふれるｗ

**デフォルトの名無しさん** · 2014/07/27(日) 22:38:54.70

>>320
似ている理由を吟味するのがリファクタリングだろ。
似ている理由を吟味した結果、同じことをちょっと違った実装しているだけと気付けば問題なく共通化できる。

**デフォルトの名無しさん** · 2014/07/28(月) 00:24:14.35

>>323
設計段階で、最初から同じものだと分かってるものでさえのちのち弊害出てくるのに。
後付けでコード眺めて似てるじゃんとか思っただけのもんがまともに共通化できるわけないだろうが