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

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

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

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

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

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

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

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

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

で？

**デフォルトの名無しさん** · 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%の下手が次々と入ってきてクズソースを乱発。
腕の良い者達は、クズソースのリファクタ作業だけをやるハメに。
腕の良い者達だけでやっていれば、もっと早く開発ができるのに。しかしリファクタリングというとできるのは腕の良いものだけ。
よってクズの尻拭いを永久にやらされる上級者は、腐る。
そしておしまい。

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

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

３行で言うと

1%の有能な人間のリファクタリングの速度より
99%を占めるクズが作り出すクズソース量産スピードのほうが速い
だから、間に合わない。

ということだね。

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

隠された4行目は

そして、1%の有能な人間はここにはいない。

か？

**デフォルトの名無しさん** · 2014/09/16(火) 21:22:31.12

>>500
何が理想論なのかと思えば、
あんたの会社では無理って話なんだね。

**デフォルトの名無しさん** · 2014/09/17(水) 00:27:57.13

また俺の会社すげえ自慢か
ITドカタのクセに生意気だ

**デフォルトの名無しさん** · 2014/09/17(水) 01:33:42.78

なんで力量がはっきりしてない人のソースレビューもせずに、
終わってからリファクタリングしてるの。クズじゃないの。
自分のコード書くだけが仕事じゃねーんだぞ。

**デフォルトの名無しさん** · 2014/09/17(水) 01:41:26.78

リファクタリングが工程になのであればら、彼の知っている開発手法はそもそもTDDに向いてないので、その前提でTDDの話なんてできないと思うのです

世の中にはCIって概念があるのを知らないのだろうか

まぁ土方なら仕方ないと思いますが

**デフォルトの名無しさん** · 2014/09/17(水) 01:43:13.03

TDDすれと間違えたし、誤字りまくった
てへぺろ

**デフォルトの名無しさん** · 2014/09/17(水) 02:10:48.96

リバースエンジニアリングが難しいのと同じで、
自分でソースを書くよりも、
他人が書いたソースを読むのは、ずっと難しい

仕様書→ソースは、簡単
ソース→仕様書は、難しい

**デフォルトの名無しさん** · 2014/09/17(水) 04:16:14.76

>>504
> また俺の会社すげえ自慢か

俺の会社だせえ自慢じゃね？ｗ

**デフォルトの名無しさん** · 2014/09/17(水) 04:18:50.43

>>508
> 他人が書いたソースを読むのは、ずっと難しい

最近これ違うと思うようになってきた。

他人が書いたソースが読みにくいと思ったら
そのソースは他人が読むように書かれていない
自分よがりなソースコードなんだよ。

読む方に非があるんじゃなくて、書くほうが悪い

**デフォルトの名無しさん** · 2014/09/17(水) 07:16:49.41

自分よがりなんて書いてる奴は、他人に読みやすい文章になるような注意力に欠けた
独りよがりの文章しか書けないんだろうな。

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

>>511
うわあ読解力ﾊﾟﾈｪ

**デフォルトの名無しさん** · 2014/09/17(水) 21:24:55.43

>>511
> 独りよがりの文章しか書けないんだろうな。
独りよがりって、自分よがりと同じ意味じゃね？

**デフォルトの名無しさん** · 2014/09/17(水) 23:24:58.57

君達は本当に頭が悪いんだな

**デフォルトの名無しさん** · 2014/09/18(木) 00:20:18.22

うむ

http://www.weblio.jp/content/%E8%87%AA%E5%88%86%E3%82%88%E3%81%8C%E3%82%8A

自分よがり
読み方：じぶんよがり
別表記：自分善がり

ひとりよがり（独り善がり）に同じ。周囲を顧慮せずに自分の都合や損得のみで物事を考えること。

**デフォルトの名無しさん** · 2014/09/18(木) 19:33:06.94

>>500
まぁほぼ同意だな

**デフォルトの名無しさん** · 2014/09/18(木) 20:26:58.62

>>516
自作自演しなくていいよ。
そんなコメント普通しないからｗ

**デフォルトの名無しさん** · 2014/09/18(木) 22:19:08.95

要求仕様の変更に追随するために設計を変えていくのがリファクタだ

撒き散らしたクソコード直すのはリファクタとは言わん
テストの前に個々人レベルでやる仕事だ

**デフォルトの名無しさん** · 2014/09/18(木) 22:31:11.52

他人が作ったものをメンテする時は
まず他人にやらせろってこと？

**デフォルトの名無しさん** · 2014/09/18(木) 23:29:47.48

クソコード直すのがリファクタリングでいいと思うお

**デフォルトの名無しさん** · 2014/09/18(木) 23:52:12.25

結局言葉遊びの域を出なかったね

**デフォルトの名無しさん** · 2014/09/18(木) 23:53:02.19

つーかリファクタリングとか言いにくいから修正でいいじゃん

**デフォルトの名無しさん** · 2014/09/19(金) 00:33:41.85

リファクタリングを定義しようぜ
とりあえずQA形式にして質問と回答は最近の書き込みから適当に埋めた

＜＜リファクタリングとは＞＞
Q 何時やるの？ A やりたい時。糞コードを見つけたら。今でしょ
Q 具体的には(工程では)いつ？ A 回答なし
Q やる必要あるの？ A 回答なし
Q 誰がやるの？A 自称上級者
Q 上級者の定義は？A 回答なし
Q その上級者には何かメリットが？A 回答なし
Q リファクタリングってお金もらえるの？A ボランティア
Q どういう効果が期待できるの？ A 将来的なリスクを回避する、または逆にリスクを抱える

**デフォルトの名無しさん** · 2014/09/19(金) 17:39:57.70

>>500に対して>>503の返しするということは、>>500の話が論が正しいことを>>503が認めているということ。

つまるところ、会社の構成員の実力によって不可能になるということ。
をあんたの会社では～。の一文で認めている。

ゆえにその切り返しをするなら、リファクタリングは議論する価値がないということ

**デフォルトの名無しさん** · 2014/09/19(金) 17:51:51.67

ちょっと何言ってるのかわかりませんわ

**デフォルトの名無しさん** · 2014/09/19(金) 18:08:18.14

誰でもできることでないなら、実現は夢物語ということだ

**デフォルトの名無しさん** · 2014/09/19(金) 18:36:04.63

工程を確保して
下がやりたいと言ったら邪魔するなというだけの話かもしれない

**デフォルトの名無しさん** · 2014/09/19(金) 18:47:45.84

>>524
行き詰まるところ先人達が考えて考えた結果

　新言語の開発

にしか答えがないんだよなww
どんな素人でも言語のルールには逆らえない。つまり従わざるを得ない。
理論だけで劇的な変化があったのなんて

GOTOレス

だけだろ。

わかりやすくステップ数で言うけどjavaで10ステップで組まれていてごちゃごちゃなプログラムがある。
仕様変更するのに1万ステップの変更が必要。これを、新言語おまんこ女学院言語で開発すると、

main()
おまんちょ（）

って書くだけで同じ機能が実現され、

仕様変更には

use ここか？ここがええんか？
main
おまんちょ（伝説の第４９手目（３箇所、同時、左手だけちょうどいい微速））

って直せば実現できる言語が生まれれば、これ以上の可読性の向上はないわけで。
馬鹿でも簡単に、馬鹿でも可読性が高く、馬鹿でもスピーディーに・・・・を求めて新言語というのは生まれている

**デフォルトの名無しさん** · 2014/09/19(金) 18:48:57.11

>javaで10ステップ
を
>javaで10万ステップ
に訂正

**デフォルトの名無しさん** · 2014/09/19(金) 19:42:02.22

>>485
パッケージ製品のメジャーバージョンアップとか？
一般的なIT土方の工事現場にはまず縁ないわな

**デフォルトの名無しさん** · 2014/09/19(金) 20:44:14.36

リファクタリングしない人は
修正する時、テストしないの？

テストするならリファクタリングしても
問題ないよね。

**デフォルトの名無しさん** · 2014/09/19(金) 20:59:36.15

全部埋めてやったぞ

＜＜リファクタリングとは＞＞
Q 何時やるの？ A やりたい時。糞コードを見つけたら。今でしょ
Q 具体的には(工程では)いつ？ A アジャイルですから。工程て何？
Q やる必要あるの？ A やらなきゃバグでるよ？いつか破綻するよ？
Q 誰がやるの？A 自称上級者
Q 上級者の定義は？A 糞コードを発見する嗅覚を持つこと
Q その上級者には何かメリットが？A コードが綺麗な方が気持ちいいだろ
Q リファクタリングってお金もらえるの？A ボランティア
Q どういう効果が期待できるの？ A 将来的なリスクを回避する、または逆にリスクを抱える

**デフォルトの名無しさん** · 2014/09/19(金) 21:28:04.06

＜＜リファクタリングとは＞＞
Q 何時やるの？ A テスト駆動開発においては、テスト記述→コードを書く→リファクタリングの順番で開発する
Q 具体的には(工程では)いつ？ A コードを書いた直後。工程で言えば開発工程
Q やる必要あるの？ A 義務だろうね。小説で言えば清書する必要あるの？ぐらいのレベル。
Q 誰がやるの？A 客観的指標（McCab等）で差があるコードを見比べて、優れている方を言えるレベルの人全員
Q 上級者の定義は？A 客観的指標（McCab等）で計測して良いとされるコードを書ける人
Q その上級者には何かメリットが？A 上級者であっても、可読性やメンテナンス性が高いコードの方が早く機能追加・修正・不具合対応ができる。
Q リファクタリングってお金もらえるの？A 開発の一部であり、清書みたいなものなので当然お金はもらえる。
Q どういう効果が期待できるの？ A 期待ではなく事実としてメリットがある。メリットは二つ上に書いたとおり。

**デフォルトの名無しさん** · 2014/09/19(金) 21:57:34.29

当然お金はもらえるってなんだよワロタ

**デフォルトの名無しさん** · 2014/09/19(金) 22:04:08.26

>>534
たとえばさ、誤字脱字、これはあっても読めれば別に問題ないんだよ。
でも見つけたら直すだろう？

そうやって誤字脱字の見直し、修正が例え1時間で終わったとしても
業務である以上、それは給料に変わるんだよ。

**デフォルトの名無しさん** · 2014/09/19(金) 22:35:47.59

問題ないのに直すのは明らかに無駄な労力だろ
リファクタリングてそういう事なのか？

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

そこらに地雷が埋まってても踏まなきゃ平気なんだよ

**デフォルトの名無しさん** · 2014/09/20(土) 00:35:33.60

>>531
そもそもテストは各工程に含まれてるよね？
一度コードに手を付けたらリファクタリングだろうが何だろうがテストはやり直しだよ
工程をこなしてる間つまりリリースし終わって暇にでもならないと
リファクタリングなんか入り込む余地なんて無いぞ
要するに無駄ってことじゃないの

**デフォルトの名無しさん** · 2014/09/20(土) 01:43:02.74

>>536
「ソースコードを読むのに時間が掛かる」は
一番重要な問題だよ。

それが開発工数の大半を占めているんだから

**デフォルトの名無しさん** · 2014/09/20(土) 10:04:40.32

まあ理論的に完璧なリファクタリング手法を使っても
無関係であるはずの部分でコンパイラやＯＳのバグを踏んだらそれまでだから
実テストにやたら工数のかかってたらその後はさわれないだろうね

**デフォルトの名無しさん** · 2014/09/20(土) 10:58:44.27

テストやりました。バグが見つかりました。

ソースコードが汚くて、コードの意味がわかりません。
ソースコードが汚くて、バグの原因がわかりません。
あちこちにコピペされてて、バグの修正が大変です。
バグを修正したら、別のバグが発生しました。
バグを修正しましたが、処理が複数のモジュールに
分散していたので多くの再テストが必要です。

こういうのを解決するのがリファクタリング。

**デフォルトの名無しさん** · 2014/09/20(土) 11:27:24.57

違うね。

> テストやりました。バグが見つかりました。
> （以下略）

それはデバッグや。

**デフォルトの名無しさん** · 2014/09/20(土) 11:43:01.81

>>542
いや、それは前置きだから。

リファクタリングが解決するのは、
デバッグまでの過程で発生する問題。

同じデバッグという目的であっても、
その目的を達成するまでの時間は違うんだよ。

**デフォルトの名無しさん** · 2014/09/20(土) 11:48:06.25

ちょっと意味が分からない

**デフォルトの名無しさん** · 2014/09/20(土) 12:22:36.52

開発段階ですでにスケジュールオーバーしてる現場だらけなのに机上の空論w
新言語開発しろw

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

>>544
意味がわからないレベルの人っているんだよねｗ

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

テストってコードを書いた本人がやるべき？

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

リファクタリングすら必要ないほどの腕のいい奴を最初から揃えれば良くね？
というのと同じくらいリファクタリング理論は破綻してる

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

他人のソースコードの解読は新規作成より時間がかかるケースが多々。
仕様がわかってるなら、そんなチェックをお願いしないといけない奴のソースレビューをするより、最初から自分でやったほうが早いし確実
つまり、リファクタリングの行き着く先は、無脳者を開発に入れなければ良いに行き着く。
少数精鋭方式。

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

>>548-549
一理あるが理想論
だから現実解としてリファクタリングが出てきたんじゃないのか？

**デフォルトの名無しさん** · 2014/09/20(土) 16:04:59.48

仕様変更っていうのは避けられないものだし、
機能追加や新しく出来た○○に対応するとか
どうしても変化は避けられないわけで
その変化にたいしてコードも変化させていかないといけないんだよ。

それにさ、人っていうのは成長するのは当たり前なのだから、
一年前の自分より、もっと優れたものを書けるようになっているはず。

一年後はさらに優れたものを書けるようになるはずだが、
それは今をきちんとやっていてできること。
過去の自分の真似ばかりしていても、成長はできないよ。

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

何を意味の分からん事を
と思ったら、またお前かｗ

**デフォルトの名無しさん** · 2014/09/20(土) 18:11:49.33

>>552
言い返したいことがあるのなら
なにか言い返していいんだぜ

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

>>550
でもgotoレスと違って誰も実践しないだろ？
そういうことだ。
誰が好き好んで人の尻拭いをやるというのだ

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

リファクタリングは有能が無能の尻を拭く作業ではなく自分の尻を拭く作業だ

最初は速度など無視してとりあえず動くように作る
動いたら次に速く動くようにする
速く動いたらそれを読みやすく整える
読みやすくなったら今度は新機能を楽々追加する

これで立派なリファクタリングだ

**デフォルトの名無しさん** · 2014/09/20(土) 21:06:59.81

速く動くようにするのは一番後でいいだろ

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

>>556
ボトルネックが出来て、そこを解決すれば全体に速度が上がるようなものなら
後からでもどうにかなるが、全体的に微妙に遅い、微妙にリソース食っている、
それで全体的に遅くなってるだと後からじゃどうにもならない。

**デフォルトの名無しさん** · 2014/09/20(土) 21:27:33.19

>>555
実際誰もやっていない
それが、この理論の決定的な答え
誰もやらない＝やって評価されるどころか、失敗した場合の責任を問われるだけ
メリット一切無い

**デフォルトの名無しさん** · 2014/09/20(土) 21:36:13.07

>>555
そもそも、そんなものはリファクタリングではない

リファクタリングは「現時点『運用中』の動いているシステムプログラム」に勝手に手を加えること。
「まがいなりにも動いているシステムのプログラムを勝手にいじるな」
というのが世界の常識。でこの常識を変えようとした思想がリファクタリング。
ただ、結局は、誰もやらんってこと。

理由の大半は「仕様がわからん」ということ。

**デフォルトの名無しさん** · 2014/09/20(土) 21:44:36.36

エクストリームプログラミングから全否定かよ。
カオスだな。

**デフォルトの名無しさん** · 2014/09/20(土) 21:54:03.46

バグを仕込んでしまう可能性があるのが致命的
あとは評価制度の問題だな
長期的に絶対メリットはあるんだがそんなん誰も見ちゃいねえし