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

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

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

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

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

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

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

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

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

で？

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

>>193
そういう文句はオリジナルを書いた奴に言え。

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

自分の言葉で語れない奴はカス

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

お前のセリフに説得力はない

**デフォルトの名無しさん** · 2011/11/12(土) 01:34:54.40

>>191
違いを理解できない能力なだけじゃないの？

**デフォルトの名無しさん** · 2011/11/16(水) 20:57:29.42

重複の除去が有効とか書いてあるじゃん

前にやった仕事で、ほんの一部を除いて同一の機能を持つモジュール２つが
別々の人によってそれぞれ実装されてて
目玉飛び出そうになったのを思い出した

**デフォルトの名無しさん** · 2011/11/16(水) 21:30:50.10

別にいいじゃん
その２つをくっつけることで後に呼び出し先Ａの機能を修正したいだけなのに
その機能がわざわざまとめられてるために
もう一つの呼び出し先Ｂのソースまで洗わないといけなくなるかもしんないだろ

まとめるのは必ずしも正解ではない

**デフォルトの名無しさん** · 2011/11/16(水) 22:33:28.29

>>199
必ずしも正解ではないのは正しいけど
同じような修正が必要になったときに片方の修正が忘れられることの方が多いと思われ
共通で使われてるメソッドの参照元を調べることより
クラスもメソッドも違うけど実は中身が同じでなければならなかったのを探すほうが大変な気が

分ける理由がないうちは一緒にしといて
必要になったら分ける方のが正しいと思う

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

ちなみに >>198 は
その両方を移植する仕事だった

「工数儲けた」と思ってたら
両者をソース読んで同一機能であることを確認した上で
一つにすりあわせて、その承認もらう羽目になったとさ

当然まともな設計書なんてありゃしないし

**デフォルトの名無しさん** · 2011/11/17(木) 22:48:38.78

>>200
いや、お前の言ってることはGoogleやAppleでは正しいだろうな
だが、日本の工業製品ではＮＧ

もちろんいいたいことはわかるけど
それじゃ見積もりがとれないこの１点でＮＧ

色々な大手でたくさんのプロジェクトが走っていて
共通ライブラリなんて生まれないっつか生まれても消滅してしまう理由はここにある

修正の影響範囲が巨大すぎて見積もれない
また、修正時に全員が同じタイミングで対応できない
これも大きな問題だ
こっち動かなくなるのに「直したよ～」とかメールくれられても困るだろ？
そっちに手がまわらないのにリリース前に真ライブラリでバグってリリース失敗であぼんとか話にならない

修正した本人は「いいんですーこれが本来あるべき姿なんです～」って主張しようと
修正するほうは「糞が・・・」って思うっしょ？
まあ、ＭＳの出荷するもんにみんなが愚痴をこぼす瞬間だと思うけど

**デフォルトの名無しさん** · 2011/11/17(木) 22:50:23.01

>>202
で、その壁を超えられる所が勝ち組で
超えられないところはどんどんブラック会社化するわけだ。

仕事、つまらないだろう？ｗ

**デフォルトの名無しさん** · 2011/11/17(木) 22:55:03.81

>>203
でもいくらもないっしょ？
日本のＩＴって進化に失敗してて紙業務を電子化したような仕事のほうが多いよね？
韓国にもすっかり抜かれちゃったみたいで国内全員でｼｮﾎﾞｰﾝって感じじゃない？
研究開発分野と本当に極一部だけだろうね
まあ、いまそういう開発してても日本じゃいつ紙業務の電子化ＩＴにまわされるかわからないから
勝ち組って意味でいうと海外脱出組が勝ち組だろうね

**デフォルトの名無しさん** · 2011/11/17(木) 22:58:57.20

>>204
ごめんな。

うち自社で作ったウェブサービス提供する会社なんだわ
HTML5系とかそっち系。

選ぶ会社の時点で勝ち負けが決まるよね。
仕事、つまらないだろう？ｗ

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

うちは少数精鋭なんで（使えない奴はやめさせられる）
同じコードをいくつも書くとかそんな無駄なことやってられないんだよね。

テストも人海戦術で同じことを何度もやるとか、時間的に無理だし、
もちろん手動テストは極力減らすので、変更したって
影響があるならすぐ分かる。

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

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

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

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

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