アカウント名:
パスワード:
今の一般的なソフトウェアの製作過程でみれば、何らかの問題があるからリファクタリングするのであって、問題の出ていないソースコードに集中的なリファクタリングしても効果が見られないのは当然だという気がする。
もっとも、地道な研究というのも必要だとは思うし、将来的にはこういう技術の延長でプログラマがまだ気付いていない問題を顕在化する前に知らせるとか取り除いてくれるとかなら嬉しい。
いやあ、違うんじゃないですかね。リファクタリングは「動いているコードを触る」ということであって、基本的に挙動は変化しちゃいかんのですよ。挙動が変化するようなものはもはやリファクタリングじゃなく普通の修正です。なので、リファクタリングにパフォーマンス向上を求めることが筋違いではないかと。
ついでに言えば、コンピューターサイエンスの学生に評価をさせたようですけど、学生に「保守性」が本当に認識できるのか、という疑問が……。
> いやあ、違うんじゃないですかね。> リファクタリングは「動いているコードを触る」ということであって、基本的に挙動は変化しちゃいかんのですよ。> 挙動が変化するようなものはもはやリファクタリングじゃなく普通の修正です。
コードが仕様書の人はそうなりますね。仕様がきちんと規定されていれば、その範囲で実装を自由に変えられるはず。
仕様書をちゃんと書かない人は、意図せずにそうなっているだけの実装が仕様になって、それに縛られて後々どうにもならなくなる。
リファクタリングも「修正」の一種であって、変数名だけの変更も、スコープを誤るとバグを作りこむことになる。挙動の変化がないことを証明するのは、テストケースでしょう。コンパクトな仕様からは、コンパクトなテストケースが作れます。
挙動が変化しないことを証明するためテストケースを十分少なく押さえられれば、広い意味でパフォーマンス向上させるようなリファクタリングも可能かもしれませんね。
長く使われるプログラムほど、外部から見た動作を仕様で明確に縛っておくことが大切。
リファクタリングの定義はマーティン・ファウラーによって明確に決められていると思っていたが。この件については、「挙動を変えないで、改善を図る」、という最低ラインについては共通認識としてあるのではないか。立場によってリファクタリングが違う、とするのは我田引水に聞こえてしまう。
リファクタリングは、仕様書云々とは全く別のフェーズの話でしょう。十分なユニットテスト・結合テストを準備すれば、根拠をもった改善が可能だ、とする話であって、ここからずれたらやはりそれはただの「根拠のない修正」「仕様変更」に過ぎません。
> 仕様がきちんと規定されていれば、その範囲で実装を自由に変えられるはず。
ふつうリファクタリングが行うのは設計とコードのブラッシュアップですね同一仕様でも再設計再実装はリファクタリングとは言わない
> リファクタリングも「修正」の一種であって、
わざわざリファクタリングという用語で「修正」と区別して考えるわけですが
> 変数名だけの変更も、スコープを誤るとバグを作りこむことになる。
変数名の変更なんてツールでしますからよほどマヌケでなければエンバグなんてしません
> 広い意味でパフォーマンス向上させるようなリファクタリングも可能かもしれませんね。
リファクタリングでは動作の最適化はしません
元コメ> 仕様がきちんと規定されていれば、その範囲で実装を自由に変えられるはず。
元コメは仕様の範囲なら全面的に自由な再設計するのもリファクタリング呼ばわりだ
> 再実装するときに再設計が必要になるほどに> 自由度がないのは「仕様がない」ことの弊害でしかない。
ふつうは実装が酷いからリファクタリングするわけだ実装が酷い原因は往々にして設計ミスなのだから、設計の修正も必要だろう設計ミスが酷ければ修正では済まず再設計になるが、そうなってしまうともう工数的にもリファクタリングとはふつうは言わない
仕様がなければ破綻しやすいのは当然だが、再設計が必要になってしまうのは設計ミスが原因であって仕様がないことはとりあえず関係ない
> 部分において見れば再実装に発展するくらいは普通にあるし、
部分においてだろだからそれぐらいが「ふつう」のリファクタリング
なんだ、リファクタリングって変数や関数の名前を修正することなのか。設計修正しちゃダメなのなら、メリットもほとんどないし、やらなくていいや。
リファクタリングという発想は90年代になって初めて出てきてそのご急速に受け入れられたわけだが、どうしてその中身が
> 仕様設計を変えずに実装設計をやりなおすのがリファクタリングなんだ。
というお粗末なものだと思えるのか、パフには理解できないパフ
plaudaが日記に引きこもって何か書いているが、リファクタリングとはまず運動、その背後にある思想なのだよ手法が枝葉末節だとは言わないが、開発プロセスに対する考え方がなにより重要で、それが90年代になって初めて明確にされたというわけだ
単にリファクタリングを知らない人の言いぐさだなあ。
やってみるといいですよ。
リファクタリングツールを使うのがリファクタリングだろう。リファクタリングを知らない意見としか思わない。
> リファクタリングツールを使うのがリファクタリングだろう。ツールの使い方を必死で覚えてる人とか、本気でそう思ってる人がいそう。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
「毎々お世話になっております。仕様書を頂きたく。」「拝承」 -- ある会社の日常
そもそも手を入れる必要が無いのなら・・・ (スコア:1)
今の一般的なソフトウェアの製作過程でみれば、何らかの問題があるからリファクタリングするのであって、問題の出ていないソースコードに集中的なリファクタリングしても効果が見られないのは当然だという気がする。
もっとも、地道な研究というのも必要だとは思うし、将来的にはこういう技術の延長でプログラマがまだ気付いていない問題を顕在化する前に知らせるとか取り除いてくれるとかなら嬉しい。
Re: (スコア:2, すばらしい洞察)
いやあ、違うんじゃないですかね。
リファクタリングは「動いているコードを触る」ということであって、基本的に挙動は変化しちゃいかんのですよ。
挙動が変化するようなものはもはやリファクタリングじゃなく普通の修正です。
なので、リファクタリングにパフォーマンス向上を求めることが筋違いではないかと。
ついでに言えば、コンピューターサイエンスの学生に評価をさせたようですけど、学生に「保守性」が本当に認識できるのか、という疑問が……。
Re:そもそも手を入れる必要が無いのなら・・・ (スコア:0)
> いやあ、違うんじゃないですかね。
> リファクタリングは「動いているコードを触る」ということであって、基本的に挙動は変化しちゃいかんのですよ。
> 挙動が変化するようなものはもはやリファクタリングじゃなく普通の修正です。
コードが仕様書の人はそうなりますね。
仕様がきちんと規定されていれば、その範囲で実装を自由に変えられるはず。
仕様書をちゃんと書かない人は、意図せずにそうなっているだけの実装が
仕様になって、それに縛られて後々どうにもならなくなる。
リファクタリングも「修正」の一種であって、変数名だけの変更も、
スコープを誤るとバグを作りこむことになる。
挙動の変化がないことを証明するのは、テストケースでしょう。
コンパクトな仕様からは、コンパクトなテストケースが作れます。
挙動が変化しないことを証明するためテストケースを
十分少なく押さえられれば、広い意味でパフォーマンス向上させるような
リファクタリングも可能かもしれませんね。
長く使われるプログラムほど、外部から見た動作を仕様で明確に縛っておくことが大切。
Re:そもそも手を入れる必要が無いのなら・・・ (スコア:1)
リファクタリングの定義はマーティン・ファウラーによって明確に決められていると思っていたが。
この件については、「挙動を変えないで、改善を図る」、という最低ラインについては共通認識として
あるのではないか。
立場によってリファクタリングが違う、とするのは我田引水に聞こえてしまう。
リファクタリングは、仕様書云々とは全く別のフェーズの話でしょう。
十分なユニットテスト・結合テストを準備すれば、根拠をもった改善が可能だ、とする
話であって、ここからずれたらやはりそれはただの「根拠のない修正」「仕様変更」
に過ぎません。
Re: (スコア:0)
> 仕様がきちんと規定されていれば、その範囲で実装を自由に変えられるはず。
ふつうリファクタリングが行うのは設計とコードのブラッシュアップですね
同一仕様でも再設計再実装はリファクタリングとは言わない
> リファクタリングも「修正」の一種であって、
わざわざリファクタリングという用語で「修正」と区別して考えるわけですが
> 変数名だけの変更も、スコープを誤るとバグを作りこむことになる。
変数名の変更なんてツールでしますからよほどマヌケでなければエンバグなんてしません
> 広い意味でパフォーマンス向上させるようなリファクタリングも可能かもしれませんね。
リファクタリングでは動作の最適化はしません
Re: (スコア:0)
元コメ> 仕様がきちんと規定されていれば、その範囲で実装を自由に変えられるはず。
元コメは仕様の範囲なら全面的に自由な再設計するのもリファクタリング呼ばわりだ
> 再実装するときに再設計が必要になるほどに
> 自由度がないのは「仕様がない」ことの弊害でしかない。
ふつうは実装が酷いからリファクタリングするわけだ
実装が酷い原因は往々にして設計ミスなのだから、設計の修正も必要だろう
設計ミスが酷ければ修正では済まず再設計になるが、そうなってしまうともう工数的にもリファクタリングとはふつうは言わない
仕様がなければ破綻しやすいのは当然だが、再設計が必要になってしまうのは設計ミスが原因であって仕様がないことはとりあえず関係ない
> 部分において見れば再実装に発展するくらいは普通にあるし、
部分においてだろ
だからそれぐらいが「ふつう」のリファクタリング
Re: (スコア:0)
なんだ、リファクタリングって変数や関数の名前を修正することなのか。
設計修正しちゃダメなのなら、メリットもほとんどないし、やらなくていいや。
Re: (スコア:0)
リファクタリングという発想は90年代になって初めて出てきてそのご急速に受け入れられたわけだが、どうしてその中身が
> 仕様設計を変えずに実装設計をやりなおすのがリファクタリングなんだ。
というお粗末なものだと思えるのか、パフには理解できないパフ
Re: (スコア:0)
plaudaが日記に引きこもって何か書いているが、
リファクタリングとはまず運動、その背後にある思想なのだよ
手法が枝葉末節だとは言わないが、開発プロセスに対する考え方がなにより重要で、それが90年代になって初めて明確にされたというわけだ
Re: (スコア:0)
単にリファクタリングを知らない人の言いぐさだなあ。
やってみるといいですよ。
Re: (スコア:0)
リファクタリングツールを使うのがリファクタリングだろう。
リファクタリングを知らない意見としか思わない。
Re: (スコア:0)
> リファクタリングツールを使うのがリファクタリングだろう。
ツールの使い方を必死で覚えてる人とか、本気でそう思ってる人がいそう。