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

■ このスレッドは過去ログ倉庫に格納されています
2010/05/29(土) 17:25:56
テストも書かないでリファクタリングとかうけるｗ

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

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

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

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

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

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

で？
2011/06/01(水) 22:28:19.38
共通処理をまとめるだけがリファクタリングではないし、
自動テストが伴わないものはリファクタリングとは呼ばない。
2011/06/01(水) 22:28:23.13
>>1
2011/06/01(水) 22:38:24.11
>>50
いや、上で書いたのはあくまで例だよ
上の例は処理をまとめることによって明らかに構造が汚くなってるよね？
この先もまとめたＰクラスにＡ〜Ｚへのどれかの追加が入るたびに
case B、case C・・・と追加されていくだろうね
そのときＰクラスを消滅する選択肢は誰か選べるんだろか？

こーゆーのってさ、その時点ででは確定しなくね？
じゃ、リファクタリングってなんのためにするの？

って根本的なところに目を向けたときに次の開発をしやすくするためでしょ？

したら、その仕様書もなしでリファクタリングをするってことは
仕様書もないのにプログラムの構造を「俺が好き」なだけの構造にただ意味もなく
書き換えてるだけのマスターベーションなんだよ
2011/06/01(水) 23:55:42.31
どこの幼房かしらんが、
case B、case Cとなるようなまとめ方はアフォがやるものだろ。
それはリファクタリング以前の問題。
2011/06/02(木) 06:38:02.16
>>53
ほうほう、それじゃ上記の例でＰの共通部分にＡのみに変更がかかったらどう修正する気？
2011/06/02(木) 08:30:37.53
>>54
Aが自前で実装すればいいんじゃね
それか、Pが取る引数を工夫して柔軟な対応ができるようにする
2011/06/02(木) 08:38:55.65
>>54
Aが自前で実装するように戻す。
あとそういうのは例えばStrategyパターンを使うべきで、共通化するものじゃない。
それすら分からないなら幼房。
2011/06/02(木) 21:05:01.86
>>55-56
>Aが自前で実装
だが、現実は絶対にcase Aを入れる
自分のソース見てみろ
今回は俺が逃げ道塞いだから自前で実装って言っただけだろ？ｗ
正気に戻ればＰクラスなんてつくらねーんだけどな
2011/06/02(木) 22:24:39.31
>>57
ガキみたいなこと言うなよ池沼
2011/06/02(木) 22:30:46.12
素直に継承するとか、デコレータパターンとか
ほかに影響に与えずに拡張なんていくらでもやりようがあると思うよ
2011/06/03(金) 04:53:30.73
>>57
いや、その場面でcaseとか、既にそういう実装だった場合を除いてしないと思うが…
2011/06/03(金) 06:40:24.29
>>60
違うな
大抵の場合、外部とのやりとりをＡ〜Ｚまでまとめない一心でＰクラスで作ってしまうから
Ａだけ切り離してもインターフェースがＰを通しているのでＰにＡへの変更を吸収してもらうほかないって感じになってるはず
じゃないとまとめたうまみないしねｗ
2011/06/03(金) 08:28:45.65
>>61
おまえは統失か。
2011/06/03(金) 08:32:19.79
結局>>49=>>52=>>54=>>57=>>61が何言いたいのかわからん。
1+1は？と聞かれてみんなが2と答えたら、田んぼの田だやーい間違った間違ったと
はしゃぐ鼻水垂らしたガキにしか見えないんだが。
2011/06/03(金) 12:43:00.66
>>63
せめて反論しろよ(笑)
2011/06/03(金) 20:59:55.04
>だが、現実は絶対にcase Aを入れる
>変更を吸収してもらうほかないって感じになってるはず
想像と主観だけ。
2011/06/03(金) 22:24:10.95
>>36
でFA
2011/06/03(金) 22:29:04.53
>>49はコーダーのレベルにすら達することの出来なかった落ちこぼれ
自分が何が分かってないかすらわかってない
2011/06/03(金) 22:47:12.11
>>67
具体的な反論よろしく
2011/06/03(金) 23:03:07.11
元々>>49が意味不明なこと言っているのが原因だろ。
>>49=>>68が具体的なコード出せ。そうしたら反論してやる。
まあ、コーダー未満の池沼だから出せないだろうが。
2011/06/03(金) 23:41:04.87
>>69
わかってないのは君だけじゃないの？
無駄だってわかりつつやるとお金もらえるからみんなやってるだけだよ
「なんのためにするリファクタリングなのか？」
って考えたらすぐに自分のやってることの無意味さに気がつくはず
現状の設計とマッチしてないから合わせるならわかるけど
それは開発段階で気がつくただの不具合だよね？

将来どうするのか？もわからないのにどうしてコードに手を入れられるの？
仕様書無しでコードに手をいれるのはダメだダメだあれほど言ってたのになんでこういうオナニーは好きにやっちゃうの？
目的がわからないのに最適（？）なコードなんてわかるわけないじゃない
なんのためのリファクタリングなの？
すべてがおかしい、でもお金になるし偉い人もやってるからやる
ただ、それだけのもんだよこれは
2011/06/03(金) 23:56:03.20
>>70
やあ幼房。>>49を読んで意味が分かるのは池沼のおまえだけだ。
2011/06/04(土) 00:49:50.56
>>71
うっとおしいからやめろよ
変な言葉も聞きなれない横文字も使ってないし誰でもわかる内容だ
内容の意味がわからないのは経験が浅いからだろ
2011/06/04(土) 06:49:03.11
＞うっとおしいからやめろよ
日本語でOK。
2011/06/04(土) 20:32:27.75
>>49はリファクタリングの前にオブジェクト指向を勉強したほうがよい
2011/06/04(土) 21:55:36.94
よくわかってないプログラマとか
プログラム中で使用する文字列をすべてヘッダで#define切っちゃうのとかよくいる
使うその場に直接書いたほうがいいことに気がつくのはいつのことだろうか？
2011/06/04(土) 22:44:23.36
文字列は切り分けたほうがいいよ
聞きかじりで行儀の良いとされる作りにしようとして
多重定義したり実際の文字列探すまでが長かったりする
くそみたいな所が多すぎるからそう感じるんだろ
2011/06/04(土) 22:51:42.66
>>75
根拠は？
2011/06/04(土) 23:04:54.02
>>77
意味がねぇからさ
ソースをみた瞬間に文字列が直接書いてあればその時点で意味がわかる
それを#defineきったら今度は命名した奴のセンスに丸投げすることになる
それが必ずしもわかりいい名前をつけてくれるとは限らない
また、複数個所でこの文字列を使うことがあったとして・・・いや・・・ないだろ？ｗ
あるならなにかおかしいんだｗ

文字列の場合、数値とはちょっと違う事情があってこういう定数を#defineを切るのはあまり意味ない
2011/06/04(土) 23:07:46.71

また、数値の場合も俺は#defineを切る意味がないと思ってる
こんなこというとすぐに頭に血を上らせてソースでいきなり出てきた数値の意味が〜云々で怒るやつがいるが
俺はそうじゃなくてソースを読んで出てきた数値がわかるようなソースを書くべきだと思ってる

ちゃんとインスタンスの生成箇所をしっかり制御すればそもそもプログラム全域に一つの値が
複数使いまわされることなどほとんどない（はず）
数値計算（3.1415・・・）ですら特定のファイルにまとまる

しかし、プロジェクトにグローバルインスタンスホルダー（大域変数セット）などあると俺の言ってることは全く理解不能だと思う
2011/06/05(日) 00:50:06.75
こりゃまた、もの凄い珍説が飛び出したもんだ。
責務やカプセル化の話と、可読性とはイコールではないだろーに。
自分の説の論理的な飛躍に気づけないのか？
2011/06/05(日) 07:21:48.46
「必ずしも分かり易い名前を付けてくれるとは限らない」
「ちゃんとインスタンスの制御をしっかりすれば複数箇所に出てくることはほとんどない」

まともな名前すら付けられん人間が「しっかりとしたインスタンスの制御」なんてやると思うかい？
2011/06/05(日) 07:49:17.22
>>81
インスタンスの管理なんてやる必要があるのはグローバル変数使ってるからだろ？
2011/06/05(日) 07:54:59.13
>>82
だとすれば

＞ちゃんとインスタンスの生成箇所をしっかり制御すればそもそもプログラム全域に一つの値が
＞複数使いまわされることなどほとんどない（はず）

ってのはグローバル変数使ってる前提なのか
2011/06/05(日) 08:21:32.31
>>83
なんでそうなるの？
いままでグローバル変数にばっかたよってるからそういう脳みそしかないんでしょ？
2011/06/05(日) 09:03:52.51
いや俺の脳みそ云々の問題でなく、矛盾してるんだってば
管理が要らないのか要るのか、どっちなのさ
2011/06/05(日) 09:31:51.48
>>85
それとグローバル変数がどうして関係あると思ったの？
2011/06/05(日) 09:39:59.44
>>86
それは>>82に言ってよ
2011/06/05(日) 09:43:54.09
>>83での「だとすれば」がどういう意味もってるのかわからない
なにが「だとすれば」なの？
馬鹿だからグローバル使うしか方法わからないだけじゃない？
いままでプログラム組んでてこの程度ってすごくみじめ
2011/06/05(日) 10:04:45.71
グローバル変数を使わなければ管理が要らないなら
何故にインスタンスの制御とかの話になったの？
要らないんでしょ？
2011/06/05(日) 12:27:20.48
>>89
グローバル変数使わなければね
俺の言ってることなにか矛盾してる？
2011/06/05(日) 12:35:52.01
>>90
「何故」と理由を聞いてるのだが
2011/06/05(日) 12:53:18.34
>>91
あんまり気にしなくていいよ
「ちゃんとインスタンスの生成箇所をしっかり制御すれば」＝「グローバル変数なんて使うほどお馬鹿じゃなければ」
って意味だからｗ
2011/06/05(日) 14:26:48.94
>>92
ちょっと待て、たかがグローバル変数を使わないだけのことを
「ちゃんとインスタンスの生成箇所をしっかり制御」
なんて仰々しく書いてたのか
2011/06/05(日) 14:28:38.99
>>93
仰々しく書いたつもりはないけど
君にはできないことだよねｗ
2011/06/05(日) 15:03:32.48
>>94
何故そう思った？
96デフォルトの名無しさん
垢版 |
2011/10/09(日) 01:02:25.28
ああげ
2011/10/09(日) 04:44:50.43
#define 使うな、までは同意できたんだがなあ…
2011/10/09(日) 12:05:06.67
リファクタリングとリエンジニアリングの関係は？
2011/10/09(日) 18:39:07.21
リファクタリングなんて、簡単な概念でしょ。

たとえば、多角形を表示するプログラムがあったとする。
それは実際は三角形を表示するプログラムを反復実行してるとする。

三角形を表示するプログラムは、線を表示するプログラムを反復実行してるとする。

線を表示するプログラムは、点を表示するプログラムを反復実行してるとする。

すると、
点を表示するプログラムを、高速に書き換えれば、
これに依存した全てのプログラムが、その内容を変更しなくとも、高速化する。

ってのがリファクタリング。
これのポイントは、修正したのは点を表示するプログラムだけで、それ以外は一切変更していないのに、他も高速化できること。
このためには、インターフェースを極力保ったままで、中身だけを変更することが重要になる。
これがリファクタリングと、普通のコード修正との違い。
2011/10/09(日) 18:57:05.08
http://capsctrl.que.jp/kdmsnr/wiki/bliki/?IsOptimizationRefactoring
2011/10/09(日) 19:57:12.25
>>99
近いが微妙にはずれている。

リファクタリングと高速化は無関係。
リファクタリングした結果、高速化することもあれば
（他にメリットがあるならば）逆に遅くなることもある

インターフェースも変えないこともあれば変えることもある。
リファクタリング本にもしっかり、「インターフェースを変えるリファクタリング」が載っている。

リファクタリングの目的はアプリ全体の動きを変えずに、ソースコードを綺麗に改善すること。
ただこの目的を達成するために、適当に修正するのとリファクタリングとでは違うものがある。
それはリファクタリングはちゃんとした手順でやるものだということ、
この手順に従うことが、修正とリファクタリングの違い。

どういった手順があるかは、リファクタリング本に書いてある。
この手順に従って修正することでバグを入れずに修正することが可能になる。
102デフォルトの名無しさん
垢版 |
2011/10/09(日) 23:20:59.42
高速化は変更の具体例として挙げているだけで、
高速化がリファクタリングだとは言っていないだろ。
2011/10/09(日) 23:59:37.52
>>101
I/F変えたら機能変更だろ。
リファクタリングの範囲をどこまで取るかであって
その範囲で内部I/Fは変わることがある。

手順がどーのだって、効果的な手法がそうだってだけで、
ある作業がリファクタリングかどうかの判断に手順は関係ない。
2011/10/10(月) 00:31:27.92
>>103
> I/F変えたら機能変更だろ。
え？ そんな事言ってもなぁ。
インターフェースを変えるリファクタリングはたくさんある。

メソッドの移動、クラスのインライン化、メソッド名の変更
引数の追加、引数オブジェクトの導入、メソッドの隠蔽
メソッドの引き上げ、階層の平坦化、継承の分割、他

リファクタリングの目的は、高速化という今すぐに効果があるメリットのためではなく、
過去にその場しのぎで対応したコードの修正とか、設計上まずいコードの修正とか
過去の負債、将来への投資として行うものだよ。

設計がまずい＝インターフェースがまずいってことはよくある話で、
コードを改善するためには、インターフェースを変えなければいけないということも当然ある。
2011/10/10(月) 00:40:22.19
なんでこいつら10年前の議論してるの？
2011/10/10(月) 00:53:59.26
したらいけないの？
2011/10/10(月) 01:04:25.82
>>103
> I/F変えたら機能変更だろ。

インターフェースが機能になってるのは
ライブラリぐらいなもんだろ。

システム（アプリ）の動作さえ変えなければ
リファクタリングでインターフェース変えたっていいんだよ。。

インターフェースが変わりますって他の開発者への通知が
必要なことがあるかもしれないが、それは、通知すればいいだけの話。

それが世界中巻き込んで大変なことになろうが、
社内の一部だけしか関係ない小さなものだろうが、
「やってはいけないこと」ではない。
2011/10/10(月) 12:55:38.15
＞インターフェースが変わりますって他の開発者への通知が
＞必要なことがあるかもしれないが、それは、通知すればいいだけの話。

幸せな環境だ・・・
2011/10/10(月) 15:07:45.53
>>108
かわいそうな環境の人？ｗ


そういう場合に、古い関数を
DeprecatedやObsoleteと書いて
リファクタリングする方法もあるよ
2011/10/10(月) 15:29:15.75
おお、Javaがやってる方法じゃん
Java PGは可哀想な子だからな
2011/10/10(月) 15:31:03.21
DeprecatedやObsoleteは
どの言語でもやってることだろ。

なんかこう、俺とは一段以上 下のレベルの
奴しか見当たらんよなｗ
2011/10/10(月) 15:49:03.28
そう。どの言語でもやってる。
何故ならインターフェースなどそう簡単に変更できないからだ。

それなのに
> 必要なことがあるかもしれないが、それは、通知すればいいだけの話。
のような事を書くほど低レベルのPGはJava PGだけだと予想して釣ってみたが、
やっぱりその通りだったねw
2011/10/10(月) 15:55:41.96
「なんかこう、俺とは一段以上下のレベルの奴しか見当たらんよなｗ」(キリッ
2011/10/10(月) 16:24:50.97
>>112
意味がわからんｗ

インターフェースが簡単に変更できないからって、
絶対に変更できないわけじゃないだろ。

お前頭が硬すぎじゃね？
2011/10/10(月) 16:48:43.88
めんどくさいからコードに対する変更はもう全部リファクタリングでいいよ
116108
垢版 |
2011/10/10(月) 19:15:25.35
>>109
若干かわいそうな環境かも。

機能毎に縦割りでリーダーが立ってて
「こっちは機能追加が進んでて人居ない」とか
「影響が大きい」とか言われて
とてもじゃないが変えられない。

それでも自担当の部分だけでもリファクタリングする工数が
貰えるだけマシなのかも知れんけどね。
2011/10/10(月) 21:13:00.47
JavaのPGやってるけど
privateメソッドを修正するだけでもJAVADOCの修正とかユニットテストが更新されるからって
チーム内でそれを拒む人いるんだよなー
ってか、お前が俺のソースコピペして、俺がその責任背負わなくなくなるのが嫌なんだろｗｗｗどうせｗｗｗ
2011/10/25(火) 13:23:05.69
リファクタリング中は考えることを止めよう
http://www.infoq.com/jp/news/2011/10/thinking-and-refactoring
2011/10/29(土) 00:57:02.72
やっぱり目的が意味不明
設計ミスならリファクタリングという形で手を出すべきじゃないし
汎用性の向上にしても次の開発やバージョンアップの仕様書があってこその修正だ

単純にリファクタリングってのが何を目的としてるのかどの文献を読んでもまったく意味不明
2011/10/29(土) 03:24:37.60
>>119
でっていう

教えてほしいならそう言えよｗ
そうでないのなら、やり方はひとつじゃないんだし、お前の好きなようにやれば？
2011/10/29(土) 05:48:50.42
>>120
じゃあ、質問だけど
これは何を目的とした作業なの？
122デフォルトの名無しさん
垢版 |
2011/10/29(土) 11:34:19.34
時間と共に増大する複雑性への対処では。

書いたソースが自分たちのものになるのかで大きく価値が異なると思う。
複雑性が増すと修正にかかる工数が増えるけど、それを良しとするか悪しとするか。
2011/10/29(土) 18:57:08.38
果てしなく続くメンテナンスと機能追加を前提として
それぞれのモジュールの精度を高めるために必要な準備作業

じゃないかな
2011/10/29(土) 22:48:37.21
何いってるのかさっぱりわからない
じゃ、質問をかえる
その作業いつ終わるの？
2011/10/29(土) 23:05:14.32
>>122
>時間と共に増大する複雑性への対処では。
何？複雑性って？
仕様とコードが乖離してるの？
そもそも仕様や設計がまずいの？
仕様や設計はバッチリなのにコードだけ綺麗にしようとしてる？（場面がまったく浮かばないけど）


>>123
精度？よくわからないけど
精度が高い状態と低い状態があって
それを判断する手段があるって言ってる？
高い状態はどうなってて、低い状態はどうなってるってのを説明してほしいんだけど？
2011/10/29(土) 23:30:50.35
効果も含めて微ファクタリング
2011/10/30(日) 00:00:06.96
>>125
仕様が変わることによって設計がそぐわなくなったときの対処についてはどう考えているの？

仕様や設計がまずいといえばそれまでだけど、
完璧な仕様や設計は期待できないでしょ
2011/10/30(日) 00:12:36.90
最初から間違えなければいい。
2011/10/30(日) 01:44:30.53
>>127
んー
それをコードにいれちゃうのはなんかちがうなーって思う
だって説明として仕様や設計に入ってもいないクラスが
自分の考える汎用性のためだけに入ってるってことでしょ？

まあ、昔の俺ならそういうコードいいと思ったけど

最近はこういう見切り発進みたいなコードをちっともいいと思わなくなった
むしろ余計なもん入れちゃうのってどうよ？って思う
2011/10/30(日) 02:01:00.62
余計なもんなんかいれない。

”必要だから” 入れてる。
2011/10/30(日) 02:32:58.38
>>129
自分の考えるよりよいコードを実現するためのひとつの手段がリファクタリングなのであって、
お前がリファクタリングは不要と考えるならそれはそれでいいんじゃね
リファクタリングしなくていいよ
2011/10/30(日) 09:42:26.14
>>130
でもそれって仕様書にないよね？
どうやって説明するの？
これまで派遣やってきたけど
そういうの許してる大手なんてみたことないけど
2011/10/30(日) 11:29:33.88
>>129
見切り発進と思うのなら、修正した方が良いと思った内容を提案してみては。

受け入れるかは組織なり人なりタイミングによると思うけど、
少なくともうちだったら、そういう提案してくれる人は歓迎するけどなあ。
その人の持つ技術力の評価や信頼にも繋がるし。
2011/10/30(日) 11:55:22.16
>>132
大手なんて10年は遅れてるじゃん
ゴミコード量産の現場でリファクタリングしようなんて、俺だって思わないな
メンテする奴が死ねばいい
2011/10/30(日) 12:08:51.05
>>132
じゃあ聞くが、お前の所の仕様書には、
ifやforやローカル変数名が書いてあるのか？

使用する命令はそれ以外のものは
一切使ったらいけないと書いてあるのか？
2011/10/31(月) 03:11:52.86
>>135
そんな話はしてないじゃん
でもこっちの場合はそういう制御文にとどまらないもんができちゃうよね？
必要のないクラスだったり関数だったり
2011/10/31(月) 12:33:30.90
>>136
なんか勘違いしてね？
必要ないものってなんのこと言ってんの？
2011/10/31(月) 21:45:02.67
>>136
世の中に必要なクラス・関数を網羅した
仕様書なんて無いよ。
2011/11/01(火) 00:54:41.88
>>137
仕様と関係ないソース
汎用性のために入れましたって言うんでしょ？
2011/11/01(火) 00:57:56.17
この表現でわからないならデザパタ使うと出てくるゴミクラスなんか全部該当すると思う
2011/11/01(火) 06:03:18.76
>>139
仕様と関係ない関数は不要なので、コードはすべてmainの中に書いてくださいね
2011/11/01(火) 07:41:02.59
>>141
いくらなんでもそれは話が飛びすぎてて馬鹿っぽい
2011/11/01(火) 08:04:06.10
デザパタでぽこぽこ生まれるゴミクラス問題は
特定の言語に固有の問題であって、リファクタリングの問題じゃなくね？
http://www.norvig.com/design-patterns/
2011/11/01(火) 20:58:54.49
>>143
リファクタリングは保守の一つなのだから、
コードを修正するならば言語に関係なく発生する問題。


リファクタリングとデザパタは
特定の言語固有とか言う以前に、全く関係ない話題。

ついでにデザパタで作るのはゴミクラスではなく必要なクラス。
2011/11/01(火) 21:19:29.93
>>142
よう、レガシー
2011/11/01(火) 21:21:02.73
Sir! FUTURE!!
2011/11/01(火) 22:09:32.23
他の言語では作る必要の無いクラスを作らされたら
ゴミクラスと言いたくもなるわい
2011/11/01(火) 22:12:41.23
>>147
たとえばどんなの？
2011/11/01(火) 22:14:56.95
他の言語では、定義する必要がない型を
定義しても、ゴミ定義とは言わないだろ。

単に、エラーを見つけやすい方法で書くか、
短いコードだから省略して書くかの違いでしか無い。
■ このスレッドは過去ログ倉庫に格納されています
5ちゃんねるの広告が気に入らない場合は、こちらをクリックしてください。
ニューススポーツなんでも実況