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

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

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

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

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

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

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

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

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

で？

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

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

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

他人の尻を拭くハメになったとき、リファクタリングが可能である唯一の条件は、
引継ぎ時点でリファクタリングされているソースコードであること、だ
そうでなかったらご愁傷様あきらめた方がいい

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

>>559
> リファクタリングは「現時点『運用中』の動いているシステムプログラム」に勝手に手を加えること。

なんでウソつくの？

本当と言い返せるものなら言い返していいんだぜ？ｗ
ただし、そんなことをしたら、ソースを要求するので
準備しておくこと。

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

恐怖駆動開発だな。
http://www.hanselman.com/blog/FearDrivenDevelopmentFDD.aspx

レガシーコードでテストが無い and/or コードに対する理解が無い
↓
エンバグ、ビルドを壊すことへの恐怖

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

>>557
新しいマシン買えばいいだけじゃないか
開発費とハードウェア費用どっちが高くつくと思ってるんだ

**デフォルトの名無しさん** · 2014/09/21(日) 01:19:15.97

りファクタリングって言うのは、オブジェクト指向の言語（これが大前提）で、
開発段階にあって、試作品が第一段階で問題なく動いて、
あとは性能やコードの見直しやｶｲｾﾞﾝだよねって段階で設計へフィードバックするプロセスですよ。
その後に顧客側のチェックと納品ですよね。

運用中のシステムに手を入れるという話では無いですよ。
ｶｲｾﾞﾝを全否定ならトヨタはどうなるんでしょうか？

**デフォルトの名無しさん** · 2014/09/21(日) 01:26:54.31

一度客に納入してさあ、次に改修の仕事がきたときにリファクタリングしていたから工数が減っていたとしてもなんのメリットもないんだよな。むしろ工数が少なきゃ金が取れない。リファクタリングした分取ったら水増し請求だ。

機能やバグについて同等で、メンテしやすさだけ向上させる工程なんて日本の一般的な開発ではインセンティブゼロだよ。趣味ならともかくプロの仕事なら。

最初からリファクタリングの作業も込みで工数見積もりなり、費用請求しろ、ってそんな見積もり見て納得する客いるわけないじゃん。最初から手直しいらない納品物にして下さい、と言われてオチ。

出来上がってテスト済みのソースをあれこれいじるなんてお遊びが入り込む余地はない。

**デフォルトの名無しさん** · 2014/09/21(日) 01:42:02.59

それと、テストという概念は個人がスクリプトやツール類を書く場合には絶対に生まれてこない発想で、
多人数で、複数の技能レベルの人が、仕様書をガイドに組織的に開発に関わる条件下で必然的に生じる仕事上の手続き。

個人がコード書く場合は、ソースコード全体、アルゴリズム、関数やクラスを全て把握しているので
テストコードをいちいち書く必要がない。だからデバックという手順はあっても、関数やクラスのテストコードを
いちいち書くという発想にはならない。コード修正も容易、エラーが発生してもその場で即対応できる個人レベルの作業としては正しい。

組織で開発する部門では他人が必要なコードを仕様化した関数やクラスの動作条件を定めているから、
それを大前提としてモジュール動作をテストする必要がある。一見して馬鹿げている行為に思えるのは、
アルゴリズムを提示せずトップダウン的に関数のIN/OUTのみで仕様を提示するためにモジュールのテストが必須になる。
チェックデータの側面についていえば情報管理上テストデータが必ず必須になる。それは本物と試験用のデータが違うということ。

テストコードは本人が書くと、世界は如何にばかげた行為に時間を費やしているのかと思うだけだが、
本来は書く側は最終コードが動作すると確認した上で、２重チェックとして仕様を作成した側がテストするためのコードなり手段を作るべきだな。
人が居ないというなら、テストコード書くのでなく、統合テスト的に動作チェックすべき。

**デフォルトの名無しさん** · 2014/09/21(日) 01:52:41.82

リファクタリングは工数水増しの手段ではない。

保守とは違うので、日本の開発やってる業界のインセンティブなど関係がない。
リファクタリングとは関係がないな。

見積もりの段階でリファクタリングなどの話は出てこない。
手直しが要るといって費用請求している段階で、それはリファクタリングの問題ではなく
失敗したプロジェクトや案件だということだろう。それを誤魔化す為に誰かが嘘として
リファクタリングと言ってるだけだろう。

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

もし>>567が客側の意見であれば、失敗したプロジェクトや案件とは縁を切って
再出発したほうが開発側も、客側も気持ち的にはしあわせになれますよ。

**デフォルトの名無しさん** · 2014/09/21(日) 06:26:59.02

>>563

>http://ja.wikipedia.org/wiki/%E3%83%AA%E3%83%95%E3%82%A1%E3%82%AF%E3%82%BF%E3%83%AA%E3%83%B3%E3%82%B0_(%E3%83%97%E3%83%AD%E3%82%B0%E3%83%A9%E3%83%9F%E3%83%B3%E3%82%B0)

>リファクタリング登場の経緯と目的[編集]
>リファクタリングが登場する以前は、一度正常な動作をしたプログラムは二度と手を触れるべきではないと言われていた。
>下手に手を加えて動作が変わってしまうと、それに伴って関連する部分にも修正が加えられ、やがて修正はプロジェクト
>全体に波及し対処しきれなくなるかも知れない。またソフトウェアテストを十分に行い正常な動作が確認されたとしても、
>そのプログラムをわずかでも改変すれば、バグ (欠陥) が見つかったときに改変があったプログラムを疑わなければならない。

**デフォルトの名無しさん** · 2014/09/21(日) 06:35:53.53

>>566
>りファクタリングって言うのは、オブジェクト指向の言語（これが大前提）

は？wwwwwwwwwwwwwwwwwwww
オブジェクト指向とそうではない言語での違いを説明しろよ
オブジェクト指向という言葉になんか宗教的妄信でもしてるのか？

**デフォルトの名無しさん** · 2014/09/21(日) 09:08:44.80

必要なのはコードのリファクタリングではなく
チームメンバのリファクタリングである

**デフォルトの名無しさん** · 2014/09/21(日) 09:29:51.06

言い換えると、ソースコードをリファクタリング出来るように
チームメンバーの技術力を高めることである。

**デフォルトの名無しさん** · 2014/09/21(日) 09:47:59.75

> チームメンバのリファクタリングである
リファクタリングて振舞いを変えてはいかんのでは？

**デフォルトの名無しさん** · 2014/09/21(日) 12:25:58.75

例えばバグが多く、しかも非常にメンテしにくい糞コードがあったとする
この場合
1. バグを含んだままリファクタリングして、その後バグを直す
2. 先にバグを直して正しいテストを通る様にしてから、リファクタリングに着手する
どっち？

**デフォルトの名無しさん** · 2014/09/21(日) 12:33:35.65

>>576
原則としては2番

ただし、今既に十分なテストがあるのなら、
リファクタリングしてもよい。

ようするに「バグが有ることに気づいていなかった」と考える。

バグが有るといえども、その状態で使われていたのであれば、
問題ない範囲（把握している範囲）で使われていたわけで、
使われていた部分の動きが変わっていなければ何も問題ない。

適切に動いていないバグの部分の動きが変わった所で
誰も困らない。そもそもバグは仕様ではないのだから。

**デフォルトの名無しさん** · 2014/09/21(日) 13:51:42.60

>>576
2. 一択。
1. は死亡フラグ。

**デフォルトの名無しさん** · 2014/09/21(日) 15:34:48.90

ホント現実をみてないな
クソコードの影にクソ仕様書あり

仕様が網羅されていないクソ仕様書、そしてあってるのかあってないのかもわからんクソソース
そして、仕様を完全把握しているものは不在（いない）

コードを読みやすくする？直す？どーやってなおすんだよ正しい仕様不明なのに
手を入れなければ責任問題は自分にはかからない
正式に仕事として認可されるまでは、さわらずほっとく。こんなのが大量なんだ現実は

まともな仕様書を作るやつは、まともなプログラムも書いている。でもそれは修正等々なんて必要のないソース

リファクタリングの対象となるソースは、前者のクソコード、クソ仕様書のほうだ。正解が不明なのにどうやって直すんだ

**デフォルトの名無しさん** · 2014/09/21(日) 16:39:44.45

>>579
具体的に、クソコードになってしまう
クソ仕様の例を言ってみて。
思いつかないんだよね。

**デフォルトの名無しさん** · 2014/09/21(日) 16:40:37.43

> コードを読みやすくする？直す？どーやってなおすんだよ正しい仕様不明なのに

それは、正しい仕様がなければ、
現在のコードの動きを仕様と考えればいいだけ。

**デフォルトの名無しさん** · 2014/09/21(日) 16:53:43.27

>>581
クソソース1万ステップもよみとーない
句読点のない文章みたいに処理の区切りがまったくないような文体で書かれたソースなんぞ誰が手をつけるか

**デフォルトの名無しさん** · 2014/09/21(日) 16:54:11.17

開発手法が根本からおかしい
リファクタリング以前の問題

**デフォルトの名無しさん** · 2014/09/21(日) 16:55:08.58

>>580
クソ仕様って誰が言った？
クソ仕様「書」って言ってるの。馬鹿なの？あほなの？無能なの？
おまえマ板の無職windowsさんでしょ

**デフォルトの名無しさん** · 2014/09/21(日) 17:12:48.09

>>584
じゃあ、そのクソ仕様書の具体例を
言ってみて。

**デフォルトの名無しさん** · 2014/09/21(日) 17:14:26.03

>>582
> 句読点のない文章みたいに処理の区切りがまったくないような文体で書かれたソースなんぞ誰が手をつけるか

でも、バグがあったら直さないといけないし、
仕様変更、機能追加があったら、手を付けないといけないよね？

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

うちのソースコードはほとんどが綺麗だから
句読点のない文章みたいに処理の区切りがまったくないような文体で書かれたソース
なんてほとんど無いよ。

そんな汚いソースがたくさんある所は、
手をつける箇所＝リファクタリングするべき場所でしょう。

**デフォルトの名無しさん** · 2014/09/21(日) 17:25:48.01

この板はガセネタをもとにした煽り合いのスレしかないみたいだな

・××と言われているが本当は○○
・こんなことも知らないの？

これが２ちゃんクヲリチーだな

**デフォルトの名無しさん** · 2014/09/21(日) 19:17:45.62

>>585
作ってあげるよ、クソ仕様書

機能：
　俺の心の中にあるいい塩梅で、業務を遂行する処理

以上

これは極端に書いたが、冗談抜きで口頭で仕様をやりとりしたのか
いっさい、仕様書に、当該機能部分の記載がない。

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

嫌なら辞めれば良いのに
って思う

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

>>590
どっちにたいして言ってるのかわからんよ、その文では

クソシステムが嫌と言ってる人に言ってるのか、
リファクタリングｗをしないやつはだめだって言ってるやつに言ってるのか

どっちにも解釈できる

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

クソソース1万ステップ読まなくていいようにするためにリファクタリングするんじゃないか

**デフォルトの名無しさん** · 2014/09/21(日) 21:45:48.38

マーチン・フラウアーのリファクタリング本てruby版とjava版て言語が違うだけで内容は重複してるの？
それとも別の内容が多いから両方買った方がいい？

**デフォルトの名無しさん** · 2014/09/21(日) 22:48:11.16

>>589
それがソースコードとなんの関係があるの？

その曖昧な仕様によって、作られる機能が
曖昧になるだろう。

だが、機能が曖昧になるだけで、
それを実現するコードの読みやすさは関係ないはずだ。

**デフォルトの名無しさん** · 2014/09/21(日) 23:01:02.38

>>593

>>454ででてるリンク先の一覧が内容の比較として使えるよ。
多くは重複しているが、それぞれ片方にしかないものもある。

と思ったが、Java版、新装版がでたんだったか。
旧版、新装版、両方持っているが新装版の方はまだ見てないやｗ

ぱっとみ片方にしかないものは、言語の特徴によるものっぽいから
重複率は同じか少し高くなるだけだろうね。

それでも俺はそのうちRuby版かうけどねｗ

**デフォルトの名無しさん** · 2014/09/22(月) 01:14:38.68

リファクタリング真理教か原理主義かしらんがウゼエ

**デフォルトの名無しさん** · 2014/09/22(月) 06:10:50.31

>>596
リファクタリングっつって真理教とか妄想するお前が一番オームくさい。

リファクタリング大勝利！！！

**デフォルトの名無しさん** · 2014/09/22(月) 06:22:02.06

Aさんがリファクタリングしました。
Bさんが読みましたAさんのリファクタリングがクソです。Bさん直しました。
Cさん見ましたBさんのソースコードクソです。Cさん直しました。
永遠と、、、、、

個人の力量、感性によって結果が大きく作用してしまうものは、学術的工学的な基本がないからどうにもならない。

**デフォルトの名無しさん** · 2014/09/22(月) 08:09:32.93

普通は、

Aさんがリファクタリングしました。
Bさんが読みましたAさんのリファクタリングがクソです。Bさん直しました。
Cさん見ましたBさんのソースコードクソです。Cさん直しました。

Cさんリファクタリング大勝利！！！・・・でしょ？

**デフォルトの名無しさん** · 2014/09/22(月) 08:34:50.21

Class レイザラモンFoo Extends Object
Public サルinit(void);
Public　クエリFoo(String SQL文はクソ);
Protect ないですFoo(void);
Destractor システム緊急停止オペ呼んでくさいFoo(void);
End Class

こんな仕様のクラスを業務システムのスーパークラスにしてあとは全て継承
という仕様は誰だって疑問を持つと思うんだが、そこを直すのがリファクタリング。

リファクタリング大勝利！！！

**デフォルトの名無しさん** · 2014/09/22(月) 11:41:29.79

>>598
それリファクタリング関係ないしｗ

なぜなら、俺が作ったコードを誰かが編集した時に、
変な修正の仕方をされることがあるから。

それを直すのがリファクタリングなわけ。

**デフォルトの名無しさん** · 2014/09/22(月) 12:15:28.88

>>599
再びAさんが担当した時、Cさんのコードを読めず仕事になりませんでした。
Cさんリファクタリング大勝利！！！

**デフォルトの名無しさん** · 2014/09/22(月) 13:03:42.75

優れたの方コードを採用すればいいだけだろ。

**デフォルトの名無しさん** · 2014/09/22(月) 13:12:39.94

個人の知識の違いによってソースの見え方が違うからな
アホが天才のコードを見ると何じゃこりゃってなるし、逆もまた然り

**デフォルトの名無しさん** · 2014/09/22(月) 13:51:20.75

知識って・・・そんなの一機能5分もあれば
知らない状態から理解できるだろ。

どんだけ素人なんだ？

つーか知らない時点で、判断できないわけで
議論からはお役御免なわけだが

**デフォルトの名無しさん** · 2014/09/22(月) 13:53:03.85

それに、知らないなら何をやっているか
理解できないわけで、リファクタリング出来るわけがないな。

**デフォルトの名無しさん** · 2014/09/22(月) 17:49:10.78

おれはやらな～いw

これでリファクタリングは崩壊するwww

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

アホみたいな話だが結局>>598が真理だよな。
リファクタリングする人は、自分のコードもいずれリファクタリングされる事を受けいれねばならん。

**デフォルトの名無しさん** · 2014/09/22(月) 20:32:19.28

リファクタリングはただのコード修正と思ってもらってかまわない

**デフォルトの名無しさん** · 2014/09/22(月) 20:44:04.47

リファクタリングするよ派はここでなにしてんの？しないよ派とじゃれあってるのが楽しいの？
やり合ってる本人は議論してるつもりかもしれないけど、外から見てるとしょうもなさすぎてｗｗ

**デフォルトの名無しさん** · 2014/09/22(月) 21:11:07.07

>>607
それは単に、プログラム？なにそれおいしいの？
動けばいいでしょ？って言ってるだけでしょう？
そんな会社はリファクタリング以前に
仕事が終わってる。

**デフォルトの名無しさん** · 2014/09/22(月) 22:45:37.55

>>1が考えるようなことは誰もが考えてる。
その結果、新しい開発言語が生まれているということを理解できないのか？
過去、多くの開発手法・開発スタイルが提唱されたが、
社会に受け入れられたものは、「理論」と「それを強制する新しい開発言語」が常にワンセットになっていた

「超絶スパゲッティコード」を少しでもまともにするために
　　原因の「goto」を取り除く方法として、「gotoレス」という理論とともに「3つの基本構造を使うようにした、構造化プログラミング言語」が生まれ
「グローバル変数の多用がデバッグを困難にする問題」を少しでもまともにするために
　　原因の「不必要にメモリをどこからでもアクセスできる状態」を取り除くため「カプセル化」が提唱され、オブジェクト指向言語に組み込まれ
等々・・・・。

何を持ってリファクタリングといいたいのかわからないが、汚いコードを綺麗なコードになおすというなら。
リファクタリングが成功したといえる、最終のコードはどのようなものなのか。具体的に示す必要がある。
プログラムとして存在するあらゆるコードパターンに対応した、綺麗なコードを示してくれ。
それを明示できないうちは>>598の意見が正しい。
個人の感性次第なら、汚いコードと周りは言うが書いているプログラマにとってはリファクタリング不要な綺麗なコードと判断するだろう。

先人達は、その時代のプログラムコードの問題を考えた。
その答えが、理論を具現化した新プログラミング言語の開発だ。

>>1はしのごのいうなら、リファクタリング後の形になるプログラミング言語を生み出せ。
どんな馬鹿でも、その綺麗なプログラミングになるプログラミング言語を。

**デフォルトの名無しさん** · 2014/09/22(月) 22:52:50.40

>612
新しい言語というから何かと思えば
gotoレスとかカプセル化とか

全然新しくないじゃないか。
30年ぐらい前の話だろ。

**デフォルトの名無しさん** · 2014/09/22(月) 22:55:02.43

> 何を持ってリファクタリングといいたいのかわからないが
無知は勉強すればいいだけ。恥ずかしいことなんて無いよ！
>>423, >>426あたりを読むといいよ。

リファクタリングの誤用
ttp://capsctrl.que.jp/kdmsnr/wiki/bliki/?RefactoringMalapropism
リファクタリングの境界線
ttp://capsctrl.que.jp/kdmsnr/wiki/bliki/?RefactoringBoundary
インタフェースの変更はリファクタリングか
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/22(月) 22:58:10.11

>>614を見ればわかるけど、

リファクタリングを
汚いコードを綺麗なコードに直すこと
とは書いてないんだよね。

なんでこんなふうに間違って解釈してるのかな？

それって、汚いコードが（あなたの所に）多いってだけで、
リファクタリング以前の解決するべき問題だよね？

リファクタリングとはソフトウェアの変化とともに、
あるべき設計に安全に変化させる方法のこと。

**デフォルトの名無しさん** · 2014/09/22(月) 23:03:19.25

>>613
あ？３０年前だ？
がきんちょがてきとーなことぬかしてんじゃねーぞ？
３０年前のコードならgoto乱発が現役だ
汎用機に大量にその証拠があるわ
どあほが。

**デフォルトの名無しさん** · 2014/09/22(月) 23:04:10.78

>>615
具体性がございません。
個人の感性次第でよろしいですか？
なら退職時、全部アセンブラコードだけにしちゃいますがｗ

**デフォルトの名無しさん** · 2014/09/22(月) 23:24:14.03

>>615
（お前にとっての）あるべき設計だな

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

このスレも

↓のスレも
ソースコード品質検定試験が世の中には必要だ
http://kanae.2ch.net/test/read.cgi/prog/1411354584/

同一人物が立てたスレだと自白しました。
そして、人物の正体も自白しました。

>5 名前：仕様書無しさん[sage] 投稿日：2014/09/22(月) 17:48:09.54
>無職Windowsしか使えないリファクタリング馬鹿がまたスレたてやがった
>
>6 名前：仕様書無しさん[sage] 投稿日：2014/09/22(月) 21:31:27.59
>>>5
>たてたね。それで？
>
>なにか言い返したいことがあるのなら
>いっていいだぜ？ｗ
>
>7 自分：仕様書無しさん[sage] 投稿日：2014/09/23(火) 07:22:55.61
>>>5
>自然と、「無職」「Windowsしか使えない」「ム板でリファクタリングスレ」を立てたことを認めているww

さすが、無職でWindowsしか使えないだけはあるw
だれも同調してくれないww　説得力もカリスマ性も感じないからなw

**デフォルトの名無しさん** · 2014/09/23(火) 12:26:15.85

>>617
具体例はここに書いてあるよ。

> >>614を見ればわかるけど、
>
> リファクタリングを
> 汚いコードを綺麗なコードに直すこと
> とは書いてないんだよね。

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

まだ無職が語るの？
恥ずかしいからお前の社会的立場を恥ずかしくない位置にリファクタリングしてからプログラムのリファクタリングを語れよw

**デフォルトの名無しさん** · 2014/09/23(火) 16:45:57.11

しかし、この超売り手市場なのに就職出来ないって、相当無能なんだな

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

いやぁ馬鹿スレを止めてくれてありがたい

完全に自爆だけどな(笑

**デフォルトの名無しさん** · 2014/09/25(木) 08:00:06.24

え？
マジで！？いろいろ見て回ってきたけど
ゲーム作りたくてプログラマになったけど、就職できず、Windowsしか扱えないので、派遣でコボルやるもクビになって無職
なの？！( ；´Д｀)

そんな身分で、現役のプロのプログラマにプログラム、プログラミングにたついて講釈たれてたの？
ε-(´∀｀; )

どんだけ、恥知らずというか、身の程知らずというか、小保方というか。
空いた口が塞がらないわ(^◇^;)

マジでお前自信をリファクタしろよ(・Д・)ノ

**デフォルトの名無しさん** · 2014/09/25(木) 12:50:36.36

という妄想を書く人って、
実社会では自分が落ちこぼれなのかな。

**デフォルトの名無しさん** · 2014/09/25(木) 17:28:15.70

不用意に自供しといて妄想とかw

**デフォルトの名無しさん** · 2014/10/05(日) 23:35:12.83

リファクタリング良さそうなんだけど、いろいろ疑問点があります

上で内部的インターフェイスの変更もリファクタリングに含まれるという話がありましたが
インターフェイスを作り変えたら対応するテストケースも作り変える必要がありますよね？

その場合、リファクタリング内でテストケースに手を付けて
インターフェイスとテストケースを同時に作ってしまっていいものでしょうか？

外部的インターフェイスに指定したテストケースのみパスすれば
問題ないと考えるのでしょうか？

**デフォルトの名無しさん** · 2014/10/07(火) 01:36:41.20

テストケースは全部通さないと駄目だよ
人間の書くテストが全部網羅してるとも限らないから
テストの穴を突いた部分が他所で影響してるかもしれない
原則としてよほどの事でもない限り一度リリースしたら手をつけないがベスト
リファクタリングなんて幻想だからやめなさい

**デフォルトの名無しさん** · 2014/10/07(火) 09:53:16.20

インタフェースを作り替えたらテストも必要
というかテストできない・しづらいインタフェースを作ったらあかん

**627** · 2014/10/07(火) 20:19:23.95

>>628
＞テストケースは全部通さないと駄目だよ

内部動作をリファクタリングする場合はそうだと思います。

＞人間の書くテストが全部網羅してるとも限らないから
＞テストの穴を突いた部分が他所で影響してるかもしれない

１００％のテストはないけど、十分捕捉率の高いテストと
十分機能変更の余地が低いリファクタリング手法の組み合わせで
実用になるというのがリファクタリングの主張ですよね。

内部動作のリファクタリグだけならそれでいいんですけど、
ただやっぱりインターフェイスの拡張・取捨選択も
やりたくて、そういう場合どうすればいいのかなと。

＞原則としてよほどの事でもない限り一度リリースしたら手をつけないがベスト

一度リリースしたっきりでソースのことを忘れ去っても
大丈夫なプロジェクトならそうかもしれませんが、
リファクタリングがターゲットにするプロジェクトは
リリースした後に（リファクタリングするしないに関わらず）
何度も手を付けてメンテナンスすることが要求されるような
継続性のあるプロジェクトではないでしょうか？

＞リファクタリングなんて幻想だからやめなさい

上手くいくと言っている人も多いので、
安易に幻想だと断定もできないように思います。
幻想だとはっきり納得出来たらやめます。

**627** · 2014/10/07(火) 20:20:02.46

>>629
＞インタフェースを作り替えたらテストも必要
＞というかテストできない・しづらいインタフェースを作ったらあかん

テストしづらくはないのですが、
例えば１つ１つの public メソッドにテストを書いていたら
とても作業が時間内に終わらないというような、
時間がかかってしまう的な問題です。

でも public メソッドはクラスの持つインターフェイスだから
テストは必要ってことですか？

**デフォルトの名無しさん** · 2014/10/08(水) 15:43:43.04

ただ、そのテストのメンテナンス、テストを減らしたり、改善したり、
そういう話はまだ多くないんですね。(例えば)テストが増えてくると、
全部のテスト通すのに 3 時間かかったりとか、テストの量自体が問題になってくる。
またテストが実装に深く依存してて、リファクタリングしたらテストが
ばーっと真っ赤*49になっちゃうからやめようみたいな話とか。

テストをたくさん書けば良いってものじゃないんですよ。
設計の改善を前後で担保するためのテストだったはずなのに、
設計改善の邪魔をしてるんじゃないか？と。
テストが変更のコストを一定にするという夢を俺たちは見てやってきたのに、
テストが増えると変更コストが上がっていないかい？という問題に対してどう戦うか、
それが今の TDD の主戦場だと思っています。

http://www.ogis-ri.co.jp/otc/hiroba/others/OORing/interview43.html

**デフォルトの名無しさん** · 2014/10/08(水) 17:47:03.08

>>632
下手なテストを書くとそうなるって話ですね。

**デフォルトの名無しさん** · 2014/10/08(水) 23:56:17.82

よくわからんが何かの言い訳に使えそうな

**デフォルトの名無しさん** · 2014/10/09(木) 10:21:37.01

テストできない・しづらいインタフェースを作ったらあかん

**デフォルトの名無しさん** · 2014/10/09(木) 20:44:29.80

ボタン一個一発こそ至高

**デフォルトの名無しさん** · 2014/10/12(日) 07:13:20.02

>>627
有能な人材だけで構成されているなら可能
でも有能な人材はそもそもそんなコードを書かない
つまり、現実では実現不能ということ。

よく考えてよ。
ゲーム会社への就職も面接すらいけずに終わり、他の会社も全滅、登録派遣しかなく
ようやく派遣されたCOBOLでクビになり、
自分は有能だと思い込んでいるケドWindowsしか使えない
無職の人の立てたスレだよ？

**デフォルトの名無しさん** · 2014/10/12(日) 13:23:31.01

>>637
返信ありがとうございます

＞よく考えてよ。
誰が立てたかでなく、何を言っているかで判断しています

＞有能な人材だけで構成されているなら可能
627 では可能かどうかという聞き方はしていないのですが、
627 のどの部分を指して可能と言われているのでしょうか？

＞でも有能な人材はそもそもそんなコードを書かない
これも、627 ではどんなコードかに関して言及していないと
思うのですが、そんなコードというのは何を指しているのでしょうか？

**デフォルトの名無しさん** · 2014/10/12(日) 14:51:47.69

世の中に汚いコードが溢れてるってことだなｗ

リファクタリングは汚いコードを直すことじゃないよ。
コードは修正するたびに（≒機能追加）
どんどんコードが増えていく。

素人集団は、コードの既存部分を直さずに追加するだけで終わらせる。

有能な人材はそもそも汚いコードを書かないというが、
それは、有能な人材は、リファクタリングをしながら機能追加していくから
汚いコードに"成長しない" ということを意味する。

**デフォルトの名無しさん** · 2014/10/12(日) 15:32:46.02

設計がまずかったり場当たり的に組んでしまったりして
いったん汚いコードになってしまったらもう手遅れですか？

汚いコードをインターフェイスを変えつつ
改善していきたいと思っているのですが

**デフォルトの名無しさん** · 2014/10/12(日) 16:01:06.81

>>648
「汚いコード」のうちは未完成と考えるよ。

設計書だってレポートだって小説だって
書いた最初は下書きでそれから清書するもんだろ？

**デフォルトの名無しさん** · 2014/10/13(月) 12:31:48.66

コードが汚いとか騒ぐやつは総じて低スキル

**デフォルトの名無しさん** · 2014/10/13(月) 17:48:27.91

>>640
汚いのを綺麗にする行為をリファクタリングとは"呼ばない"

これが原理主義者の主張するところである

**デフォルトの名無しさん** · 2014/10/13(月) 21:27:10.38

>>643
ではリファクタリグしたとしても汚いコードは汚いままなのですね