アカウント名:
パスワード:
今の一般的なソフトウェアの製作過程でみれば、何らかの問題があるからリファクタリングするのであって、問題の出ていないソースコードに集中的なリファクタリングしても効果が見られないのは当然だという気がする。
もっとも、地道な研究というのも必要だとは思うし、将来的にはこういう技術の延長でプログラマがまだ気付いていない問題を顕在化する前に知らせるとか取り除いてくれるとかなら嬉しい。
いやあ、違うんじゃないですかね。リファクタリングは「動いているコードを触る」ということであって、基本的に挙動は変化しちゃいかんのですよ。挙動が変化するようなものはもはやリファクタリングじゃなく普通の修正です。なので、リファクタリングにパフォーマンス向上を求めることが筋違いではないかと。
ついでに言えば、コンピューターサイエンスの学生に評価をさせたようですけど、学生に「保守性」が本当に認識できるのか、という疑問が……。
問題というとやっぱり、ソフトウェアのバグみたいに聞こえてしまいますね。
ここで言いたいのは、機能拡張をしたいけれど、既にやっつけの拡張が多数集積していて見通しが悪すぎるとか。そういう問題です。それから単純なものだと、ほぼ全ての変数や関数が英数字二文字以内というソースコードは、余程短くない限り問題ありです。一息にコーディングするとき余計なことに気を散らしたくないのは判るけれど、関数名がすべて f0 とか f4 とかだったりは受け取れません。
ここに一票。
つまり、更なる機能追加の土台均しだから、リファクタリングそのものでコードが複雑になったとしても、その後の機能追加と併せて整合性がとれるなら意味があるはず。
最後のくだりだけについて反応。関数名については 全く同意しますが、最近 golang さんとかだと、変数名はなるべく短く、かつすぐ使い終わるように、というような方針が推奨されているようですよ。
>最近 golang さんとかだと、変数名はなるべく短く、かつすぐ使い終わるように、
これは変数のスコープは最小にしろ。スコープが十分小さければ変数は短くてもＯＫ。っていう、昔から言われていることを言い換えているだけでは。
昔はスコープ長かったけどね。初期のCは関数の先頭に全部書かなきゃいけなかったし、互換性のために長い間その方式を踏襲してたから。
むしろ名前の拒否反応は命名規則と習慣からくるんじゃないかな。以前、他人が書いたコードに
for (int ii = 0; ii < LENGTH; ii++) {
ってのに手を入れてた時にiiをiにしたくてしょうがなかったもの。頭でわかったつもりになってても、途中から
「iiってなんだっけ？ああ、ループ回してるんだったな。…(ちょっと先)…ところで、このii*iiってどういう意味だ？あ、あー、ループカウントを2乗してるのか、i * iのことだな。…(さらに先)…あれ、ptrからii引くのはいいけど、このiiってどっから出てきたんだよ。あー、わかった！くそ、思い出した！」
って感じになったから。jとかkとかnとかlだと全然気にならないんだけど、iiは生理的に受け付けないと自覚してしまった。
へたくその典型的ないいわけですね。
関数の先頭で宣言しないといけないからスコープが大きくなる? そもそもそんな長い関数書くなって話だ。
> って感じになったから。jとかkとかnとかlだと全然気にならないんだけど、iiは生理的に受け付けないと自覚してしまった。
iiは人が二人寄り添っているみたいで、リア充ばくはつしろ！みたいな？
まぁそうなんですが、golangのライブラリ(の一例)http://golang.org/src/io/ioutil/ioutil.go?s=1464:1510#L39 [golang.org]を眺めていると、むしろ変数が短いほうを優先しているように感じますね。
上記例では、ファイル情報(FileInfo)を fi と書いたりしていますが、なじみのAPIを使っているならともかく、コメントがないと 後で見返しても全く分からないと思うな。。
パフのプロジェクトではデバッグと称してリファクタリングしていたパフ
同じ部の他のプロジェクトで、リファクタリングの名の下に中身改変したあげくバグ出した奴がいたなぁ（遠い目）テストケースすら書いてなかったエセリファクタリングだったけど。
> いやあ、違うんじゃないですかね。> リファクタリングは「動いているコードを触る」ということであって、基本的に挙動は変化しちゃいかんのですよ。> 挙動が変化するようなものはもはやリファクタリングじゃなく普通の修正です。
コードが仕様書の人はそうなりますね。仕様がきちんと規定されていれば、その範囲で実装を自由に変えられるはず。
仕様書をちゃんと書かない人は、意図せずにそうなっているだけの実装が仕様になって、それに縛られて後々どうにもならなくなる。
リファクタリングも「修正」の一種であって、変数名
リファクタリングの定義はマーティン・ファウラーによって明確に決められていると思っていたが。この件については、「挙動を変えないで、改善を図る」、という最低ラインについては共通認識としてあるのではないか。立場によってリファクタリングが違う、とするのは我田引水に聞こえてしまう。
リファクタリングは、仕様書云々とは全く別のフェーズの話でしょう。十分なユニットテスト・結合テストを準備すれば、根拠をもった改善が可能だ、とする話であって、ここからずれたらやはりそれはただの「根拠のない修正」「仕様変更」に過ぎません。
> 仕様がきちんと規定されていれば、その範囲で実装を自由に変えられるはず。
ふつうリファクタリングが行うのは設計とコードのブラッシュアップですね同一仕様でも再設計再実装はリファクタリングとは言わない
> リファクタリングも「修正」の一種であって、
わざわざリファクタリングという用語で「修正」と区別して考えるわけですが
> 変数名だけの変更も、スコープを誤るとバグを作りこむことになる。
変数名の変更なんてツールでしますからよほどマヌケでなければエンバグなんてしません
> 広い意味でパフォーマンス向上させるようなリファクタリングも可能かもしれませんね。
リファクタリングでは動作の最適化はしません
元コメ> 仕様がきちんと規定されていれば、その範囲で実装を自由に変えられるはず。
元コメは仕様の範囲なら全面的に自由な再設計するのもリファクタリング呼ばわりだ
> 再実装するときに再設計が必要になるほどに> 自由度がないのは「仕様がない」ことの弊害でしかない。
ふつうは実装が酷いからリファクタリングするわけだ実装が酷い原因は往々にして設計ミスなのだから、設計の修正も必要だろう設計ミスが酷ければ修正では済まず再設計になるが、そうなってしまうともう工数的にもリファクタリングとはふつうは言わない
仕様がなければ破綻しやすいのは当然だが、再設計が必要になってしまうのは設計ミスが原因であって仕様がないことはとりあえず関係ない
> 部分において見れば再実装に発展するくらいは普通にあるし、
部分においてだろだからそれぐらいが「ふつう」のリファクタリング
なんだ、リファクタリングって変数や関数の名前を修正することなのか。設計修正しちゃダメなのなら、メリットもほとんどないし、やらなくていいや。
リファクタリングという発想は90年代になって初めて出てきてそのご急速に受け入れられたわけだが、どうしてその中身が
> 仕様設計を変えずに実装設計をやりなおすのがリファクタリングなんだ。
というお粗末なものだと思えるのか、パフには理解できないパフ
plaudaが日記に引きこもって何か書いているが、リファクタリングとはまず運動、その背後にある思想なのだよ手法が枝葉末節だとは言わないが、開発プロセスに対する考え方がなにより重要で、それが90年代になって初めて明確にされたというわけだ
単にリファクタリングを知らない人の言いぐさだなあ。
やってみるといいですよ。
リファクタリングツールを使うのがリファクタリングだろう。リファクタリングを知らない意見としか思わない。
> リファクタリングツールを使うのがリファクタリングだろう。ツールの使い方を必死で覚えてる人とか、本気でそう思ってる人がいそう。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
物事のやり方は一つではない -- Perlな人
そもそも手を入れる必要が無いのなら・・・ (スコア:1)
今の一般的なソフトウェアの製作過程でみれば、何らかの問題があるからリファクタリングするのであって、問題の出ていないソースコードに集中的なリファクタリングしても効果が見られないのは当然だという気がする。
もっとも、地道な研究というのも必要だとは思うし、将来的にはこういう技術の延長でプログラマがまだ気付いていない問題を顕在化する前に知らせるとか取り除いてくれるとかなら嬉しい。
Re:そもそも手を入れる必要が無いのなら・・・ (スコア:2, すばらしい洞察)
いやあ、違うんじゃないですかね。
リファクタリングは「動いているコードを触る」ということであって、基本的に挙動は変化しちゃいかんのですよ。
挙動が変化するようなものはもはやリファクタリングじゃなく普通の修正です。
なので、リファクタリングにパフォーマンス向上を求めることが筋違いではないかと。
ついでに言えば、コンピューターサイエンスの学生に評価をさせたようですけど、学生に「保守性」が本当に認識できるのか、という疑問が……。
Re:そもそも手を入れる必要が無いのなら・・・ (スコア:1)
問題というとやっぱり、ソフトウェアのバグみたいに聞こえてしまいますね。
ここで言いたいのは、機能拡張をしたいけれど、既にやっつけの拡張が多数集積していて見通しが悪すぎるとか。そういう問題です。
それから単純なものだと、ほぼ全ての変数や関数が英数字二文字以内というソースコードは、余程短くない限り問題ありです。
一息にコーディングするとき余計なことに気を散らしたくないのは判るけれど、関数名がすべて f0 とか f4 とかだったりは受け取れません。
Re: (スコア:0)
ここに一票。
つまり、更なる機能追加の土台均しだから、リファクタリングそのものでコードが複雑になったとしても、その後の機能追加と併せて整合性がとれるなら意味があるはず。
Re: (スコア:0)
最後のくだりだけについて反応。
関数名については 全く同意しますが、
最近 golang さんとかだと、変数名はなるべく短く、かつすぐ使い終わるように、
というような方針が推奨されているようですよ。
Re:そもそも手を入れる必要が無いのなら・・・ (スコア:3)
>最近 golang さんとかだと、変数名はなるべく短く、かつすぐ使い終わるように、
これは変数のスコープは最小にしろ。スコープが十分小さければ変数は短くてもＯＫ。
っていう、昔から言われていることを言い換えているだけでは。
Re: (スコア:0)
昔はスコープ長かったけどね。初期のCは関数の先頭に全部書かなきゃいけなかったし、互換性のために長い間その方式を踏襲してたから。
むしろ名前の拒否反応は命名規則と習慣からくるんじゃないかな。以前、他人が書いたコードに
ってのに手を入れてた時にiiをiにしたくてしょうがなかったもの。頭でわかったつもりになってても、途中から
「iiってなんだっけ？ああ、ループ回してるんだったな。…(ちょっと先)…ところで、このii*iiってどういう意味だ？あ、あー、ループカウントを2乗してるのか、i * iのことだな。…(さらに先)…あれ、ptrからii引くのはいいけど、このiiってどっから出てきたんだよ。あー、わかった！くそ、思い出した！」
って感じになったから。jとかkとかnとかlだと全然気にならないんだけど、iiは生理的に受け付けないと自覚してしまった。
Re: (スコア:0)
へたくその典型的ないいわけですね。
関数の先頭で宣言しないといけないからスコープが大きくなる? そもそもそんな長い関数書くなって話だ。
Re: (スコア:0)
> って感じになったから。jとかkとかnとかlだと全然気にならないんだけど、iiは生理的に受け付けないと自覚してしまった。
iiは人が二人寄り添っているみたいで、リア充ばくはつしろ！みたいな？
Re:そもそも手を入れる必要が無いのなら・・・ (スコア:3, おもしろおかしい)
Re: (スコア:0)
まぁそうなんですが、golangのライブラリ(の一例)
http://golang.org/src/io/ioutil/ioutil.go?s=1464:1510#L39 [golang.org]
を眺めていると、
むしろ変数が短いほうを優先しているように感じますね。
上記例では、ファイル情報(FileInfo)を fi と書いたりしていますが、
なじみのAPIを使っているならともかく、
コメントがないと 後で見返しても全く分からないと思うな。。
Re: (スコア:0)
パフのプロジェクトではデバッグと称してリファクタリングしていたパフ
Re: (スコア:0)
同じ部の他のプロジェクトで、リファクタリングの名の下に中身改変したあげくバグ出した奴がいたなぁ（遠い目）
テストケースすら書いてなかったエセリファクタリングだったけど。
Re: (スコア:0)
> いやあ、違うんじゃないですかね。
> リファクタリングは「動いているコードを触る」ということであって、基本的に挙動は変化しちゃいかんのですよ。
> 挙動が変化するようなものはもはやリファクタリングじゃなく普通の修正です。
コードが仕様書の人はそうなりますね。
仕様がきちんと規定されていれば、その範囲で実装を自由に変えられるはず。
仕様書をちゃんと書かない人は、意図せずにそうなっているだけの実装が
仕様になって、それに縛られて後々どうにもならなくなる。
リファクタリングも「修正」の一種であって、変数名
Re:そもそも手を入れる必要が無いのなら・・・ (スコア:1)
リファクタリングの定義はマーティン・ファウラーによって明確に決められていると思っていたが。
この件については、「挙動を変えないで、改善を図る」、という最低ラインについては共通認識として
あるのではないか。
立場によってリファクタリングが違う、とするのは我田引水に聞こえてしまう。
リファクタリングは、仕様書云々とは全く別のフェーズの話でしょう。
十分なユニットテスト・結合テストを準備すれば、根拠をもった改善が可能だ、とする
話であって、ここからずれたらやはりそれはただの「根拠のない修正」「仕様変更」
に過ぎません。
Re: (スコア:0)
> 仕様がきちんと規定されていれば、その範囲で実装を自由に変えられるはず。
ふつうリファクタリングが行うのは設計とコードのブラッシュアップですね
同一仕様でも再設計再実装はリファクタリングとは言わない
> リファクタリングも「修正」の一種であって、
わざわざリファクタリングという用語で「修正」と区別して考えるわけですが
> 変数名だけの変更も、スコープを誤るとバグを作りこむことになる。
変数名の変更なんてツールでしますからよほどマヌケでなければエンバグなんてしません
> 広い意味でパフォーマンス向上させるようなリファクタリングも可能かもしれませんね。
リファクタリングでは動作の最適化はしません
Re: (スコア:0)
元コメ> 仕様がきちんと規定されていれば、その範囲で実装を自由に変えられるはず。
元コメは仕様の範囲なら全面的に自由な再設計するのもリファクタリング呼ばわりだ
> 再実装するときに再設計が必要になるほどに
> 自由度がないのは「仕様がない」ことの弊害でしかない。
ふつうは実装が酷いからリファクタリングするわけだ
実装が酷い原因は往々にして設計ミスなのだから、設計の修正も必要だろう
設計ミスが酷ければ修正では済まず再設計になるが、そうなってしまうともう工数的にもリファクタリングとはふつうは言わない
仕様がなければ破綻しやすいのは当然だが、再設計が必要になってしまうのは設計ミスが原因であって仕様がないことはとりあえず関係ない
> 部分において見れば再実装に発展するくらいは普通にあるし、
部分においてだろ
だからそれぐらいが「ふつう」のリファクタリング
Re: (スコア:0)
なんだ、リファクタリングって変数や関数の名前を修正することなのか。
設計修正しちゃダメなのなら、メリットもほとんどないし、やらなくていいや。
Re: (スコア:0)
リファクタリングという発想は90年代になって初めて出てきてそのご急速に受け入れられたわけだが、どうしてその中身が
> 仕様設計を変えずに実装設計をやりなおすのがリファクタリングなんだ。
というお粗末なものだと思えるのか、パフには理解できないパフ
Re: (スコア:0)
plaudaが日記に引きこもって何か書いているが、
リファクタリングとはまず運動、その背後にある思想なのだよ
手法が枝葉末節だとは言わないが、開発プロセスに対する考え方がなにより重要で、それが90年代になって初めて明確にされたというわけだ
Re: (スコア:0)
単にリファクタリングを知らない人の言いぐさだなあ。
やってみるといいですよ。
Re: (スコア:0)
リファクタリングツールを使うのがリファクタリングだろう。
リファクタリングを知らない意見としか思わない。
Re: (スコア:0)
> リファクタリングツールを使うのがリファクタリングだろう。
ツールの使い方を必死で覚えてる人とか、本気でそう思ってる人がいそう。