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

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

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

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

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

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

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

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

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

で？

[2 デフォルトの名無しさん 2010/05/29(土) 17:27:43]

Eclipseのリファクタリングは名前変更もリファクタリングのひとつなんだよなあ

[3 デフォルトの名無しさん 2010/05/29(土) 17:33:05]

リファクタリングは結果ではない。
プロセスだ。やり方だ。

コードがきれいになったからリファクタリングをしたと
思うのは間違いだ。

バグを入れないのは当たり前だが、コードの動作を変えずに
決められたた手順をもちい、クラス間の依存関係を減らすことで
ユニットテストできるようにする作業がリファクタリングだ。
テストコードが増えてなければ、それはコードを書き直しただけで
リファクタリングとは呼ばない。

リファクタリングブラウザとは、このリファクタリング作業を簡単にするための
ツールであり、リファクタリングブラウザの機能を使った作業（名前変更など）そのものは
リファクタリングではない。

[4 デフォルトの名無しさん 2010/05/29(土) 17:41:18]

本当のリファクタリングを知ると、
新たな設計方針にたどり着ける。

テストしやすい設計。
クラスを単独で生成できるように
依存関係（クラスが別のクラスを使用するなど）が
少ない設計。

publicメソッドの引数には、なるべくクラスを使わない。
クラス内部で別のクラスを生成しない（必要な場合は外部から渡す）

[5 デフォルトの名無しさん 2010/05/29(土) 17:59:47]

>クラス内部で別のクラスを生成しない（必要な場合は外部から渡す）
全部main(String [] arg)で作るんですねわかりま…

[6 デフォルトの名無しさん 2010/05/29(土) 18:00:34]

宇宙飛行士様が来たぞ

[7 デフォルトの名無しさん 2010/05/29(土) 18:07:01]

リファクタリングがしたいと思ったとき、
こういう考えの流れになっていないとだめ


リファクタリングしたい
　↓
リファクタリングするにはユニットテストコードが必要
　↓
既存のコードを（なるべく）修正せずにテストするにはどうするか。
　↓
（依存関係が無ければ簡単にテストコードを書けるが、たいていはそのままではテストコードかけないので）
既存のコード・クラスをどうやって他のコード・クラスとの依存関係から分離させるか。

この分離が一番大変な作業。
分離させることに成功したらあとは簡単。
ユニットテストを書いてコードを修正すればよい。

[8 デフォルトの名無しさん 2010/05/29(土) 18:17:41]

正直名前変更くらいしか使ってないな、それでも相当便利だが

[9 デフォルトの名無しさん 2010/05/29(土) 18:24:16]

>>8
名前変更（リファクタリングブラウザの機能）というのは、
例えて言うのなら小説を書く（リファクタリング）ときの文房具（リファクタリングブラウザ）と
同じ関係だよ。

文房具を使って文字を書いたり、消しゴムで消したりという作業は、
小説を書くための道具を使っているわけだが、
本質的には小説を書く行為そのものではない。

[10 デフォルトの名無しさん 2010/05/29(土) 23:54:35]

XXXはXXXXXであるべき、なんてXXは全くもってXXXだ。

[11 デフォルトの名無しさん 2010/05/30(日) 00:14:58]

>>1
その通りです。
何か嫌がらせされてる気がする。

[12 11 2010/05/30(日) 00:52:51]

ごめんなさい。取り乱しました。
ソフトウェアテストで良い本ありませんか。

[13 デフォルトの名無しさん 2010/05/30(日) 02:51:03]

>>12
レガシーコード改善ガイド

[14 デフォルトの名無しさん 2010/05/30(日) 10:13:00]

このスレッドは天才チンパンジー「アイちゃん」が
言語訓練のために立てたものです。

アイと研究員とのやり取りに利用するスレッドなので、
関係者以外は書きこまないで下さい。

　　　　　　　　　　　　　　　　　　京都大学霊長類研究所

[15 デフォルトの名無しさん 2010/05/30(日) 18:16:22]

>>14
だと思った
>>1の一行目で分かった

[16 デフォルトの名無しさん 2010/05/30(日) 19:47:36]

リ略をただのコード修正だと思わないでよ
コーダの思いがこもってるんだからあ

[17 デフォルトの名無しさん 2010/05/30(日) 22:16:42]

どおりで重いと思った

[18 デフォルトの名無しさん 2010/05/30(日) 22:34:43]

>>16
釘宮風にたのむ

[19 デフォルトの名無しさん 2010/05/30(日) 22:44:12]

ばーかばーか

[20 11 2010/05/31(月) 06:09:05]

>>13
ありがとうございます。
本見てみます。

[21 デフォルトの名無しさん 2010/05/31(月) 21:06:25]

>>19
チルノのパーフェクト算数教室？

[22 デフォルトの名無しさん 2010/06/01(火) 01:55:41]

え…あぅ……わ、私そんなんじゃないのに…
これは、コード修正じゃなくてりふぁくたりんぐなんだから！
ちゃんと勉強してから出直しなさい！
なによ……わざわざしてあげるんだから…何か言いなさいよ！
あっ、べ、別にアンタのためにやるんじゃないんだから、
勘違いしないでよね！ばーかばーか！

[23 デフォルトの名無しさん 2010/06/01(火) 12:35:24]

なんか決まりがあって、そうしないとダメだって言ってるような頭固い人間がプログラムしてるのが間違いだろ。
目的に即してれば、細かいことは違ったって問題ないのに、それは手順としてあーだーこーだ・・・みっともない。

[24 デフォルトの名無しさん 2010/06/04(金) 19:59:43]

>>12
遅レスですまん

ファウラーの「リファクタリング」は必読
「パターン指向リファクタリング入門」はオススメ
あと、関連してデザインパターン関連の本を読んでおくといいかも

[25 デフォルトの名無しさん 2010/06/19(土) 17:52:31]

リファクタリングって流行らないね。
そもそもリファクタリングするために必要なユニットテスト技術も未熟だからか。
日本は技術レベルが低いよ。

愚痴はここまでにして、データベースのフィールドってリファクタリングするのに
厄介だよね。ただの文字列だと名前変更に追尾できない。

それはO/Rマッパー使ってもそうだけど、データベース関連はリファクタリングを念頭に置くと、
SQLとデータベースからクラスとして自動生成したほうがいいのかもしれない。
このクラス（仮にDBCLASSとする)ではデータベースのフィールドが一メソッド（プロパティ）になる。
これはビジネスロジックを書くいわゆるモデルではなく、データベースの構造をあらわすだけのクラス。

DBCLASSのプロパティを変更しても、DBCLASS内部でアクセスしているデータベースのフィールド名は変わらない。
逆にアクセス先のデータベースのフィールド名を変えると、DBCLASS内部でアクセスする
データベースのフィールド名も自動的に変わる。

[26 デフォルトの名無しさん 2010/06/19(土) 17:56:15]

ウェブアプリの場合、同じ問題が
フォームのクエリー名にも当てはまるんだよな。

要はデータではなく、意味がある名前であるキーを
ただの文字列として扱うのはやめようということ。

フォームのクエリー名を変更したら、
自動的にコードの名前に反映させたい。（逆もあり）
そのためのコードの生成機能が必要だよ。

[27 デフォルトの名無しさん 2010/06/19(土) 18:14:03]

>>26
いまだにフォームの設定かいたら、その部分のコードが自動生成されないの？
みんなふつうにやってるとおもったんだが気のせいであったか。

[28 デフォルトの名無しさん 2010/06/19(土) 18:22:48]

>>27
何の話？
自動生成されたとしても、それを文字列で扱っていたらだめだよ。
ようはリファクタリングブラウザで、それがキーとして認識されるような形になってほしい。
リファクタリングだけじゃなくて、コード補完もできるようになるから間違いが減るしね。
コンパイル時点でのエラー検出もおこなえるようになる。

[29 デフォルトの名無しさん 2010/06/19(土) 22:20:10]

社長に今なにやってる？と聞かれてリファクタリングしてます、と答えたら
いつも波風が立つのはなぜだろう

[30 デフォルトの名無しさん 2010/06/19(土) 22:24:56]

リファクタリングがなんなのか、メリットとデメリットについてなど
理解してないからだろ

こういう成功例を見せながら地道に説得していくしかないんじゃないの？
ttp://ascii.jp/elem/000/000/497/497905/

[31 デフォルトの名無しさん 2010/06/19(土) 23:08:32]

>>30
いい記事だった。
そこの社長ぐらい、うちんとこの社長も柔軟な頭だったらいいんだがなあ

[32 デフォルトの名無しさん 2010/06/20(日) 02:34:06]

理解させるには分かりやすいたとえが必要だと思う。
例えば平屋を拡張して2階、3階と増やしていったら、
1階にも手に入れないと、いつか倒壊しますよね?とか。

[33 デフォルトの名無しさん 2010/06/20(日) 06:23:44]

一階に手を入れたら倒壊しちゃいました、とか

[34 デフォルトの名無しさん 2010/06/20(日) 15:29:28]

そもそも本当に１階にも手を入れないと倒れるのか？
やってみたら意外と倒壊しないんじゃないの？、とか

[35 デフォルトの名無しさん 2010/06/20(日) 18:34:34]

理解のないシステム 会社はそれだよね。腐ったシステムを抱え続けると将来的にどれだけのコストになるかわかってない。
だから目先のコスト増に怯えて将来の飛躍の芽を摘んでしまう。

[36 デフォルトの名無しさん 2010/06/20(日) 20:56:47]

リファクタリングの重要性のわからん上司にどうわかってもらうかでずっと悩んでいたが、
理解のない人にはリファクタリングしているとはあえて言わないのも手だと
Ruby版リファクタ本に書いてあって目から鱗だったわ