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