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

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

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

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

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

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

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

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

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

で？

**デフォルトの名無しさん** · 2011/11/17(木) 23:02:59.45

>>205
ウェブ系なんて工業製品とかわんねーけどな
あんなん汎用性見越して組む必要あるかね？

寿命が短いからどう組んでもどうとでも動くが正解だろ？
納期まで早い方が真
お前の世界こそプログラムを綺麗にまとめて褒める奴１人もいないと思うがな

**デフォルトの名無しさん** · 2011/11/17(木) 23:38:17.66

>>207
汎用性見越して組むとか言ってないんだが。

無駄にある重複コードをまとめると言ってるだけ。

**デフォルトの名無しさん** · 2011/11/17(木) 23:39:39.61

重複コードを作ると、納期が延びます。

修正があると、重複コードの分
修正量が増えます。

少しの修正であっちこっち修正して、
あっちこっちテストして納期伸ばしてるのは誰ですか？ｗ

**デフォルトの名無しさん** · 2011/11/18(金) 00:57:17.23

>>209
それって何箇所？
１０箇所？２０箇所？程度なら貼ったほうが速いよね？
思いっきりまとめあげられてて難しい仕組みに頭ひねってソース解読しなきゃいけないぐらいだったら
単純コピーで貼ってあってくれたほうがまだソース読みやすいよね

っていうか件数が１００件いかない程度のコピペならお前が便所に席を立った間にやっておいてやるよ
この程度の件数だったらどう組んでも変わらない

**デフォルトの名無しさん** · 2011/11/18(金) 01:28:11.79

>>210
お前適性ないんじゃね？

ぶっちゃけ、仕事楽しくないでしょ？

**デフォルトの名無しさん** · 2011/11/18(金) 01:48:53.37

自分でやるんじゃなくて他人にやらせるんだろ

**デフォルトの名無しさん** · 2011/11/18(金) 06:57:57.33

>>211
いや、楽しいよ
お前みたいな対象物のメリットとデメリットも判断できんようなの出し抜いて数字上げるのが何よりの快感だわ(笑)
結局、技術の上部だけしかすくえないひとって何も見えてないんだよね
新しいってだけである意味パニック状態になってる自分がなにより見えてない

**デフォルトの名無しさん** · 2011/11/18(金) 07:32:36.75

数字を出しさえすればそれが全てだと思い込んでいることはよく判った。
さぞかし楽しい人生だろうねぇ。

**デフォルトの名無しさん** · 2011/11/18(金) 11:48:05.79

>>213
お前性格屈折してるな
そうとういじめられたな

**デフォルトの名無しさん** · 2011/11/18(金) 12:54:07.46

>>210
> 思いっきりまとめあげられてて難しい仕組みに頭ひねってソース解読しなきゃいけないぐらいだったら
> 単純コピーで貼ってあってくれたほうがまだソース読みやすいよね

申し訳ありません
ifとforしか理解できない人もいるということを忘れていました
リファクタリングの過程でデザインパターンを適用してしまったことをお許しください

**デフォルトの名無しさん** · 2011/11/18(金) 12:59:02.53

>>213
コピペもできるしリファクタリングもできる俺がそれを言うならまだわかるけど、
お前はコピペしかできないんだからさ、取捨選択の上でコピペを採用したみたいな言い方はやめてよ
もっともらしい後付けをしたところで、お前のカードはコピペしかないわけで

**デフォルトの名無しさん** · 2011/11/18(金) 12:59:57.09

>>216
forすら理解してないかもよ
100回ループ廻すくらいならコピペするって言い出しかねん

**デフォルトの名無しさん** · 2011/11/18(金) 15:50:01.61

正面から反論できないときは人格攻撃になるんですね
その時点で白旗あげてるっていうかなんていうか

**デフォルトの名無しさん** · 2011/11/18(金) 19:16:21.49

>>219
だってー
低レベルな人を教育してあげる気なんて毛頭ないですしー

**デフォルトの名無しさん** · 2011/11/18(金) 23:06:02.19

>>220
でも自分のやってることの説明できないってのは問題じゃない？
結局トレードオフの問題であって
やればやるほどとかどんな場面でもってわけじゃないってとこは否定できないわけでしょ
じゃあ、君のやり方は正しいの？また、他の人と差がでるのは何が決め手なの？
ってのは結局のところどこでも求められると思うんだけどね
それが説明できないなら君に用のある人なんていないと思うんだよね
みんな暇じゃないから(笑)

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

へえ

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

トレードオフ考えてやるんだから
やっぱりリファクタリングは必要ってことね

リファクタリング全否定って人はいるのかしら

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

トレードオフはコードをまとめる話だろ？
リファクタリングはまったく必要ないよ
そもそも意味わからないもん
次の仕様が決まってる中でのコード修正ならわかるけど
次になんの予定もないのに何に向けてどう修正してるのかまったく理解できない
その修正はいいの？悪いの？
オナニーで終わってない？

これらを判断できる材料すらわからない
単に金をドブに捨ててるだけだと思う

**デフォルトの名無しさん** · 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

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