リファクタリングをただのコード修正と思ってる人へ
■ このスレッドは過去ログ倉庫に格納されています
テストも書かないでリファクタリングとかうけるｗ
まずな、リファクタリングでは機能追加・修正は行わない。
動作はまったく同じでコードをきれいに書き換えること。
書き換えるといっても、これなら同じ動きだろ？って推測でやってはいけない。
まずテストを書く。ユニットテストをできるように、
単一のクラスでインスタンスを作る。
汚いコードなのだからたいていは依存関係のせいで単一ではクラスが生成できない
それを生成するために、クラスの動作を書き換える。
といっても元のコードは修正しない。継承やプリプロセッサを使って
依存関係を断ち切るために既存のコードを上書きする。
どうしてもそれが不可能な場合には、決められた手順で最小のコード修正を行う
そうやって既存のクラスのユニットテストを行う。
それでやっとリファクタリングが行える。
既存のクラスのユニットテストを通るように新たなコードに修正、
もしくは新規作成して置き換える。
この手順と考え方を守ってないのはリファクタリングではない。
で？ ほんまやね。レス辿って明らかにおかしいのを見つけたがら言ったけどそれforのレスにかすりもしなかったわ。すまん。 下手に勘違いされると困るから補足しておくと、
汚いから修正するってだけならYAGNIでやるべきではないが、
その部分を修正していたり読む必要があるならば、
いつ必要しているの？今でしょ？ってことで
今すぐ必要としていることなわけだから、
そこを修正するのはYAGNIではない 読まなきゃ汚いと思わないんだから、矛盾してるような気がするけど。
必要ないのに汚いコードを読み始める酔狂な奴が居るとしたら別だけど。 > 読まなきゃ汚いと思わないんだから
いや、コードメトリクスツールなどをつかえば
読まなくても、客観的に汚いとわかる >>797
いつになったら何のことをリファクタリングと呼んでるか書いてくれるの？ 汚いから直すってのもリファクタリングと呼ぶと思うけど、
汚いから直すってのは実際の開発現場じゃなかなか難しいと思うよ
その汚さが原因で性能が出ないとか、機能追加できない、し辛いって明確な理由があれば別だけどね >>802
> その汚さが原因で性能が出ないとか、機能追加できない、し辛いって明確な理由があれば別だけどね
だから俺は聞いたんだよ？
そういうどうしても直さなければいけないときに
リファクタリングで安全に修正するのか？
それとも行き当たりばったりに修正してバグを入れるのか？って >>801
理解できる頭がないのに質問するなよw
何度も言ってるだろうがww リファクタリングを行うタイミングを間違ってるんだよね
俺は何らかの機能修正とかでコードをいじるときに
関連するところを少しづつなおす
大抵が数行程度で10分もかからずに終わる
こまめに修正しないで、手遅れになってからやろうとするから
大規模になってしまって、別途工数が〜とかいう話になるんだよ。
手遅れになってしまったものを修正する工数がないからと
手遅れなコードのままさらにコードを追加するから
さらに手遅れになっていくんだろうが >>806
多分解ってると思うけどその言い方は誤解を生むと思うぞ。
リファクタリングと機能追加は明確に分けるべきで、リファクタリングして、テスト走らせて振る舞いが変わってない事を確認してから機能追加に入るべき >>805
他人の否定はしてるけど、自分では何も言ってないよ君 >>807
うん。わかってる
> リファクタリングして、テスト走らせて振る舞いが変わってない事を確認してから機能追加に入るべき
どちらもあるよ。
機能追加してからリファクタリングする物の典型的な例がTDD
Red/Green/Refactor 通りの順番 > Red/Green/Refactor 通りの順番
これのことか？
Refactorはリファクタリングのことだよ
別の手法じゃなくて全く同じもの 1.機能追加前にテスト書く
2.追加コード書く
3.テスト
4.ダメならテストに通るまでコードいじる
もしかしてこれもリファクタリング扱いしてるの？ >>815
それはRed→Greenのところでしょ… 最近、特定のフラグ変数に関するif文の山をswitch構文に清書し直したんだけど、これってリファクタリング？ >>816
それさ、リファクタリングのいち定義であってリファクタリングではないから。 >>817
そのif文が変ならな。まともなif文なら書き換える必要がない。 >>817
ただswitch文にすると仕様変更時にswitch文では対応できなくなる可能性があるので逆かもしれない。 >>817
確かにswitchでかけるならばifよりswitchの方が少しだけ見やすくなるけど、
大抵はリファクタリングにはならないよ
巨大なswitchもリファクタリングすべき対象となる
何がダメなのかというと比較の回数がifのときと変わってないから。
比較が多い＝複雑なので、これは単なる書き方の違いでしかなくて
リファクタリングとまではいかない。重要なのは比較回数
じゃあどうすべきかというと、一番簡単な方法は
関数テーブル（ルックアップテーブル）を使う方法
大量のswitchでの比較が条件が揃えば0個にまで減る >>818
> それさ、リファクタリングのいち定義であって
> Red/Green/Refactor 通りの順番
がリファクタリングの定義に見えるんだ・・・
ここにはどこにもリファクタリングの定義なんてものは
書いてないんだが
>>816が言ってるのは、Red→Greenでやる内容は
リファクタリングじゃないよって言ってるだけでしょ
俺からも補足するが、リファクタリングは
動いているコードを、動いているコードに置き換えることだよ。
修正前と修正後のどちらかが動いていなければ
それはリファクタリングではない * Green
1.機能追加前にテスト書く
* Red
2.追加コード書く
3.テスト
4.ダメならテストに通るまでコードいじる
5.テストに通った。やったー完成だ！ ←ふざけんじゃないよ。なんだこのコピペだらけで無駄がばかりのクソコードは
* Green
6.リファクタリングする
7. 読みやすくなりました。←このコードならレビューする気になる。シンプルあとで読んだ人も理解しやすいだろう
8. 完成、1に戻る 現実にはこの5. テストに通っただけの状態で
完成としてしまうやつが多いんだよな。
そういうコードで許される環境っていうのは
コードレビューが行われていない。
コードを見ずにテストに通ればOKとしてしまう環境
そして向かうはデスマーチｗ 駄目だこりゃ。なんでそういう手順がリファクタリングなのか？ Refactorとリファクタリングが同じ意味の言葉だってのが伝わってないのかも知れないな あ、はい間違えました
> 6.リファクタリングする
これじゃ リファクタリンギング ですねｗ このスレってそもそも特定のリファクタリング作業のスレッドか。話がかみ合わないわけだ。 誰が特定のリファクタリング作業の話をしてるんだ？
誰がはどうでもいいや「特定の」ってどれのことだよ？ TDDの例出したからTDDに限定した話だって勘違いしてるんでしょ >>829
「特定の」がなにか言うだけだよ。
お前がちゃんと考えて発言しているなら
簡単な質問なはずだが？
もっとも俺はお前が何も考えてないってことを
あぶり出すために「特定の」が何か聞いたんだけどなｗ 定義から定まってないからなリファクタリングって
いや、実在するのか？ 殆どの用語は定義なんか定まってないよ
数学でさえ、ある用語に対して数学ではこういう定義で
使いましょうと決めているだけ ソースを組んだときと今とでチンコのポジションを若干変更した
これがリファクタリングである 特定の統合開発環境のリファクタリング機能をリファクタリングだと言ってるやつはいなくなったなw 俺の中では変数名の変更=リファクタリング
Visual Studioの機能名がそうだったから 俺の中では、マーチン ファウラーのリファクタリング本（古い方）に
のっているのがリファクタリング
変数名の変更ももちろんのってる
後はそのリファクタリングをどれだけ簡単に
正確に行えるかの違い。
ローカルスコープ程度で済むものなら良いけど
スコープが広い部分のリファクタリングは手動でやるのは大変
それを自動的に間違いなく行える、静的型付け言語＋IDEの力は偉大 あるスコープの中で外部から見た仕様を変えずに内部の設計を変えるのがリファクタリング 僕の知り合いの知り合いができたパソコン一台でお金持ちになれるやり方
役に立つかもしれません
グーグルで検索するといいかも『ネットで稼ぐ方法 モニアレフヌノ』
K2FKH ■ このスレッドは過去ログ倉庫に格納されています
