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

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

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

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

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

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

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

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

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

で？

**デフォルトの名無しさん** · 2014/07/29(火) 22:51:00.80

受託なんてドカタを人月で売って稼ぐビジネスモデルなんだから、

リファクタリングでコードを拡張しやすく保ち、
機能拡張を他社より速く行う事で競争優位に立つ

とか、そういうのは関係ないじゃん？

お前らマクドナルドのパートと大差無いんだから、
技術者の議論に入ってきちゃダメだよ

**デフォルトの名無しさん** · 2014/07/29(火) 23:05:38.45

>>340
ほー。
具体的にどういう課題があってどんなリファクタして、プロジェクトがどの程度成果上げたのか具体的に説明してみ？

壊れたレコードみたいに本で読んだこと繰り返して、しかも理解が浅くて現実が見えてないっぽいから
底辺派遣てすぐばれるよｗ

**デフォルトの名無しさん** · 2014/07/29(火) 23:07:53.67

>>341
現実つーかレスの意味が見えてないのはお前のほうだな

**デフォルトの名無しさん** · 2014/07/29(火) 23:56:17.33

何か高度な裏の意味があるらしい

**デフォルトの名無しさん** · 2014/07/30(水) 00:19:39.30

自社サービスで食っていけてるってだけで圧倒的な成果だろうな

労働集約型な受託開発なんて価格競争で擦り減るばかりで
エンジニアに何のメリットもないし、早く脱出すべきなんだけど
脱出するためのスキルが溜まらない負のスパイラル

**デフォルトの名無しさん** · 2014/07/30(水) 09:05:15.28

SEが設計してコーダがコード書くってスタイルと
リファクタリングは相性悪いだろうな

**デフォルトの名無しさん** · 2014/07/30(水) 11:16:11.07

SEの設計が日本語プログラミングになってるからな。
日本語と一対一のコードでないとめんどくさいことになる。

**デフォルトの名無しさん** · 2014/07/30(水) 18:54:49.24

>>346
それで食えないスパゲティの一丁上がりかw

**デフォルトの名無しさん** · 2014/07/30(水) 20:26:49.42

リファクタリングは1にも2にも自分のためにやるものだ
デスマーチを充実したアフターファイブに変えたければやっとけｗ

**デフォルトの名無しさん** · 2014/07/30(水) 21:00:14.66

>>346
その日本語プログラミングではBASICにも劣る
抽象化しか出来ないのが問題なんだよね

**デフォルトの名無しさん** · 2014/07/30(水) 21:00:10.81

そしてリファクタスパイラルへ…

**デフォルトの名無しさん** · 2014/07/30(水) 22:54:34.89

リファクタリング否定派は技術力に乏しく低脳という風潮

一理ある

**デフォルトの名無しさん** · 2014/07/30(水) 23:20:51.69

どう考えてもすぐリファクタする方が低脳だろｗ
リファクタしたがる奴の傾向として

・理解力の不足。
自分に理解できないものをすぐ諦めてクソ呼ばわりする。
他人の書いたコードの一貫したポリシーや目的を汲み取れないから、先人が用意してくれた便利なライブラリも使えない。
理解できないから規約も無視しがちで、彼の書いたところだけ作りがおかしい。

・謙虚さの不足。
相手を見下して、自分のほうがいいものが作れると根拠なく信じてる。
すでに用意されているものを再発明するだけならまだいいが、
しばしば完成されたフレームワークの重要な部分にクソを差し込んでめちゃくちゃにする。

・計画性の不足。
先の見通しが利かないから、行き当たりばったりでクソしか作れない。
リファクタも行き当たりばったりにやるから、クソが超臭うクソになるだけということになりがち。
挙句に自分で訳がわからなくなって、成果物を全部消したりする。

・客観性の不足
自分のやったことの成果を、客観的に見ることが出来ない。
リファクタしたことで、掛けた工数がどれくらいでペイしたとか、数字で物事を考えられない。
彼がリファクタするのは、単に楽しいから。本人は仕事してる気になってるが、周囲から見ると遊んでるだけ。

という感じ。
そもそも最初からちゃんと書く能力があったら、リファクタしたいと思うことは少ないはず。

**デフォルトの名無しさん** · 2014/07/30(水) 23:55:14.83

>>352
> ・理解力の不足。
> 自分に理解できないものをすぐ諦めてクソ呼ばわりする。
> 他人の書いたコードの一貫したポリシーや目的を汲み取れないから、先人が用意してくれた便利なライブラリも使えない。
> 理解できないから規約も無視しがちで、彼の書いたところだけ作りがおかしい。
>
> ・謙虚さの不足。
> 相手を見下して、自分のほうがいいものが作れると根拠なく信じてる。
> すでに用意されているものを再発明するだけならまだいいが、
> しばしば完成されたフレームワークの重要な部分にクソを差し込んでめちゃくちゃにする。

とりあえず、最初の二つだけで良いから
リファクタリングとの関係を論理的に説明してみ？

**デフォルトの名無しさん** · 2014/07/31(木) 00:02:21.65

>>353
他人の書いたコードを書き換えたがるんだよ…
自分に理解できないからクソだ。という理屈で。

クソに感じるのは自分の能力が足りないせいだということに気づかない。

**デフォルトの名無しさん** · 2014/07/31(木) 00:08:01.18

そんな奴、実際には見た事無いが
受託開発だとレベル低いから居るのかもしれんね

**デフォルトの名無しさん** · 2014/07/31(木) 00:28:09.58

>>354
具体的にはどう書き換えられたの？

共通化できる処理を各所にバラバラに書き散らかしてたのを
シンプルにまとめられた挙句
「DRYも理解出来ないアホが開発に関わるとか意味が分からない」
って言われたとか？

**デフォルトの名無しさん** · 2014/07/31(木) 00:49:44.01

コードオナニストは、常にコード以外の観点が欠けているのが特徴。
いくら諭しても話が噛み合わず、日夜コードのブラッシュアップに励んでいる。

**デフォルトの名無しさん** · 2014/07/31(木) 00:51:52.79

>>356
知らん。問答無用で差し戻したから。

散々テストしたはずなのに客先に持ってったら動きが変わってて
共通モジュールに手が入ってたんで何やったのか聞いたら「わかりにくかったんでリファクタしました。」
何年も動いた実績あるモジュールにそんな理由でいじんなアホか死ね

>「共通化できる処理を各所に（略」
うん。そうだな…だいたい君と同じぐらいの理解度の奴だったよ。

**デフォルトの名無しさん** · 2014/07/31(木) 00:54:29.60

> 散々テストしたはずなのに客先に持ってったら動きが変わってて

それリファクタリングになってないから
リファクタリングじゃない話を使ってリファクタリング批判してどうすんだよ

**デフォルトの名無しさん** · 2014/07/31(木) 01:01:10.62

>>359
別にリファクタは批判してないよ？
考えもなしにリファクタしたがる奴を批判してるんだ。

**デフォルトの名無しさん** · 2014/07/31(木) 01:07:13.72

>>360
お前んところがレベル低くて、勝手にコードぶっ壊す馬鹿が居るってだけの
リファクタリングと関係ない話を一般論として語られても、
底辺は可哀想だなって感想しか持ち様が無いぞ

**デフォルトの名無しさん** · 2014/07/31(木) 01:09:10.48

>>359
お前はリファクタリングのつもりかもしれんが
完璧なテストが存在しない以上、挙動が変わる危険は常につきまとうんだよ。

**デフォルトの名無しさん** · 2014/07/31(木) 01:15:43.10

完璧なテストとか言う以前に、
ろくに自動テストとか書いてないでしょ？

ていうか、レビューもまともに機能してない
（じゃなかったら>>358のケースなんてコードがマージされるはずない）
テストもマトモに書いてないじゃ、そりゃトラブルよ

**デフォルトの名無しさん** · 2014/07/31(木) 01:21:33.19

Excelで書かれたチェックリスト片手に手動でテストして
「散々テストしたのに」って言ってそう

**デフォルトの名無しさん** · 2014/07/31(木) 07:53:29.99

>>336
挙動を変えるのはリファクタリングじゃなくて仕様変更だろ

**デフォルトの名無しさん** · 2014/07/31(木) 21:56:38.46

仕様変更でもバグ修正でもいいが、
コードを書き換えたら挙動が変わることがある。

つまり、機能追加もバグ修正もするなってことだ。

**デフォルトの名無しさん** · 2014/07/31(木) 22:08:52.98

ネストが揃ってないとか空行が多いとか
変数がはるか上で宣言されてるけど使ってるのは遥か下に固まってるとか
理解力以前に目が疲れるコードをどうにかしろって言ってるんだよ

**デフォルトの名無しさん** · 2014/08/01(金) 18:46:58.63

変数定義の位置を移動したりスペースを除去したり
するのもリファクタリングなわけだが

**デフォルトの名無しさん** · 2014/08/01(金) 19:22:03.81

失敗例をあげてリファクタリングは糞って言ってるの最高に滑稽。
井戸の王様を気取ってる蛙か

**デフォルトの名無しさん** · 2014/08/01(金) 20:37:16.99

OO批判と同じ流れだな

**デフォルトの名無しさん** · 2014/08/01(金) 20:43:59.51

リファクタリングが糞なんじゃないよ
リファクタリングしたがる人が糞なんだよ

**デフォルトの名無しさん** · 2014/08/01(金) 21:19:55.74

>>371
ゴミみたいなコードばっか書いてっから
他人にリファクタリングされまくっちゃうんだろ

**デフォルトの名無しさん** · 2014/08/01(金) 22:07:17.79

新人はリファクタしたがっていかん
関数の共通化とかGenericsとかTemplateとか覚えたてのこと使いたがる

ちょっとしたクソが一晩したらそびえたつ巨大なクソに

**デフォルトの名無しさん** · 2014/08/02(土) 01:12:27.41

技術レベルの低い人ってのは初心者に近くて
リファクタリングという技術用語を理解できないんだよ。

だからわかり易い言葉に置き換えるといい
リファクタリング＝整理整頓・改善

こう言い換えれば、改善する必要があるんです。
整理整頓すると普段の仕事が捗るんです。ということになる

こう言い換えれば、反対する人はいなくなるよ。

**デフォルトの名無しさん** · 2014/08/02(土) 01:27:17.11

生理整頓した状態を維持しながら仕事しろよｗ
個人レベルの話ならクソコードをフィックス前にに最低限他人が読めるようにするのなんて責務のうちだ

リファクタはどっちかというと組織再編といったほうがいい
課題と今後の見通しがあってはじめてやることで

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

>>375
その責務を果たさない奴が、
行き当たりばったりのコード書くんだよな。
そいつに限ってリファクタリングの意味を理解してないという。
もう技術者として終わってるとしか言いようが無いね。

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

リファクタリング本を一回読んだとき何を感じるかだよな。
ああそうそう、こういう点で苦しくなってたんだ、って気付くか、
何一つピンとこずに何やってんのこの本？と思うか。

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

クソコードを普通のコードに直す作業をあんまりリファクタと呼びたくないｗ

**デフォルトの名無しさん** · 2014/08/02(土) 11:27:29.15

結合テストとかまで進んじゃったら無理だよね

**デフォルトの名無しさん** · 2014/08/02(土) 11:55:25.68

リリースした後でバージョンアップのついでにやるもんだろ

**デフォルトの名無しさん** · 2014/08/02(土) 11:59:50.68

ボーイスカウトの法則といって、
コードを修正するときは、修正する前よりも
綺麗にするもんです。

これが出来るのと出来ないのが、
初心者と中級者の境目。
もちろん、出来ないほうが初心者ね。
これが許されるのは新卒1年ぐらいなもん。

**デフォルトの名無しさん** · 2014/08/02(土) 12:22:30.70

規模が小さいうちは手抜きで簡単なコードを書くだろ？
最初から拡張性とかそういうものを考えて作りこまない。

で、規模が大きくなってきた時に、将来性のことを
考慮して作り変えればいいんだが、
最初の手抜きのコードをそのままに、手抜きを真似して
同じようなコードを追加するやつどうにかならんかね。

規模に応じたコードの書き換えをしない。できない。
発想がない。そういうい奴がクソコードを量産するんだよ。

**デフォルトの名無しさん** · 2014/08/02(土) 12:37:41.39

権限のない末端PGが現場の手続き無視してユニットテストのないコードを
勝手に修正する、自称リファクタリングは非常に迷惑。

日本の受託開発の仕事ではリファクタリングなんてするべきではない。

**デフォルトの名無しさん** · 2014/08/02(土) 12:42:59.05

>>383
ユニットテストが無いことが前提になってる時点で、
やっぱり、その程度の所が、リファクタリングを嫌ってるんだなとしか
思えないよ。残念だったね。君のところの技術不足を露呈しただけ。
えと、技術力不足であることを自覚してね？落ち込むところだよ。

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

最初から厳密に書けばいいんだよ
手抜きコピーが多いのは、そういうものかと思ってしまうからだ
自称上級者がスタートアップ書くことが多いが、手抜き繰り返して
しまいには自分自身が変な癖背負い込んでいくだろう
初期段階でよい方向に導くには、最初のやつががんばるしかない

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

人間誰しも、最初は初心者で
一年後には今よりも成長しているという
前提にたつと最初から完璧なコードを書くのは不可能

どんなに優れたコードを書いたとしても
一年後の自分はもっと優れたコードを書ける。

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

>>386
この程度の奴がリファクタしたがるんだよなあ…

リファクタってのはある設計から別の設計に軸足を移すことだ。
書き散らしたクソコードを書き直すのは、リリース前にやっておくべきそれ以前の問題なんだよ。

お前の末端の画面とか帳票とかは、誰も共通機能として使ってないから汚かろうがクソだろうが問題ないよ。
お前の自己満足のためにプロジェクトとめられてたまるか。
どんなクソでも、客の前にひりだしたクソはてめえのクソだ。受け入れて前に進め。

**デフォルトの名無しさん** · 2014/08/02(土) 14:06:28.03

大体最初からある程度ちゃんとしたプログラムも書けないやつに
まともなユニットテスト作れるわけないだろうが。

**デフォルトの名無しさん** · 2014/08/02(土) 14:26:29.65

理想だけど
組織には逆らえない

**デフォルトの名無しさん** · 2014/08/02(土) 14:42:12.73

関数の中身やprivateな関数のインターフェースを修正するようなリファクタリングと、
ライブラリのpublicなインターフェースを変更するような
影響範囲の大きいリファクタリングの話が混じってる気がする

後者はそう簡単じゃないよ
影響範囲に入る全ての開発者と調整が付かない限り変更できない
（勝手に変更したら、ライブラリ使用者側から見たら仕様変更だからリファクタリングにならない）

**デフォルトの名無しさん** · 2014/08/02(土) 14:44:44.99

初心者にオススメなのは、派生開発でコードを読むときに、動作確認をテストで書くことかな。これはとっつきやすい。
『レガシーコード改善ガイド』では「仕様化テスト」のところ。

**デフォルトの名無しさん** · 2014/08/02(土) 14:54:07.48

>>380
そんな意識の奴と仕事したくないわ

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

リファクタリングするなっていってる奴がいるけどさ、
時間が十分にあるという前提にたつと
とたんに何も言えなくなってしまう

それってリファクタリングがダメなのではなくて
時間がないという問題だから。

じゃあ、なんで時間が足りないんですか？
今までと同じやり方してるんじゃないですか？って
追い詰めると、泣き出しちゃうｗ

**デフォルトの名無しさん** · 2014/08/02(土) 15:21:48.08

>>390
そういう場合は、旧関数の互換性を保ちながら
新しい関数を作ればいいんだよ。

**デフォルトの名無しさん** · 2014/08/02(土) 15:32:36.71

>>390
そういうことのないように依存性を無くすようにプログラミングする
プログラマの規律が無いだけ

**デフォルトの名無しさん** · 2014/08/02(土) 17:35:26.06

当たり前のことを当たり前に理解してそれを前提としている人と、
当たり前のことなのに全く理解しないでそれを前提とできない人とが会話しているようだ。

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

ウォーターフォールだったり、詳細設計書で日本語プログラミングしたりしてるとこと
リファクタリングは相性悪いよ
開発の全体を見直さないと、一部だけ優れた手法を取り入れようとしても
歪みが出て上手く行かないんだよね

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

うまくいかないんじゃなくて
難しいだけだろ？

それを実行する力が技術力なわけで。

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

どうしても自分が書いたコードを書きなおしたい人がいるようだけど
そんなコードはいずれバグで書きなおされるんだから、あまり気にしない方が良い。
その情熱は悪くないけど、もっと前向きに使うべきだよ。

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

前向きって新しいコードを書くってこと？
残念だけど、開発ってのは既存のコードの修正がほとんどだよ。

新しい機能を追加するといっても
前よりも効率よく開発するために既存の部分を、
使いまわす（コピペじゃないからね！）するために
既存の部分を修正して使えるようにするんだから。

**デフォルトの名無しさん** · 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行もあるようなおバカ関数を数学的に定式化して改善するのは無意味なこと
見れば何をすべきかわかる