- 1 ：デフォルトの名無しさん：2010/05/29(土) 17:25:56
- テストも書かないでリファクタリングとかうけるｗ
まずな、リファクタリングでは機能追加・修正は行わない。
動作はまったく同じでコードをきれいに書き換えること。
書き換えるといっても、これなら同じ動きだろ？って推測でやってはいけない。
まずテストを書く。ユニットテストをできるように、
単一のクラスでインスタンスを作る。
汚いコードなのだからたいていは依存関係のせいで単一ではクラスが生成できない
それを生成するために、クラスの動作を書き換える。
といっても元のコードは修正しない。継承やプリプロセッサを使って
依存関係を断ち切るために既存のコードを上書きする。
どうしてもそれが不可能な場合には、決められた手順で最小のコード修正を行う
そうやって既存のクラスのユニットテストを行う。
それでやっとリファクタリングが行える。
既存のクラスのユニットテストを通るように新たなコードに修正、
もしくは新規作成して置き換える。
この手順と考え方を守ってないのはリファクタリングではない。
で？
- 49 ：デフォルトの名無しさん：2011/06/01(水) 22:25:20.30
- リファクタリングなんてやって意味があると思ってる奴は消防
Ａ〜Ｚまであるクラスの共通処理をＰクラスとして纏めたとするわな
したら、ＰクラスをいじるたびにＡ〜Ｚまでの影響範囲を調べなあかんのやで
仮にＡにしか関係しないＰに入ってしまった共通処理を弄るのだって
一度結合したらはがしてＡクラス特有の処理としてＰクラスからＡクラスを避ける処理なんて
結構、邪魔な処理になるで
それでもＰとしてまとめてしまったらＡ〜Ｚまでサポートしていかなあかんのやで
リファクタリング、結構、だが、誰がこの未来を予測できる？
Ａ〜Ｚまでの共通処理が走ってるＰクラスを蹴飛ばしてＰＡクラスを新しく作って
Ａ−ＰＡ、Ｂ〜Ｚ−Ｐの関係を新しくぶった切るような切込みはできんやろ？
せいぜいＰの処理にcase Aを入れるような修正が精一杯やないか？
今後を考えてリファクタリングなんてする意味があるんか？
- 53 ：デフォルトの名無しさん：2011/06/01(水) 23:55:42.31
- どこの幼房かしらんが、
case B、case Cとなるようなまとめ方はアフォがやるものだろ。
それはリファクタリング以前の問題。
- 54 ：デフォルトの名無しさん：2011/06/02(木) 06:38:02.16
- >>53
ほうほう、それじゃ上記の例でＰの共通部分にＡのみに変更がかかったらどう修正する気？
- 55 ：デフォルトの名無しさん：2011/06/02(木) 08:30:37.53
- >>54
Aが自前で実装すればいいんじゃね
それか、Pが取る引数を工夫して柔軟な対応ができるようにする
- 57 ：デフォルトの名無しさん：2011/06/02(木) 21:05:01.86
- >>55-56
>Aが自前で実装
だが、現実は絶対にcase Aを入れる
自分のソース見てみろ
今回は俺が逃げ道塞いだから自前で実装って言っただけだろ？ｗ
正気に戻ればＰクラスなんてつくらねーんだけどな
- 81 ：デフォルトの名無しさん：2011/06/05(日) 07:21:48.46
- 「必ずしも分かり易い名前を付けてくれるとは限らない」
「ちゃんとインスタンスの制御をしっかりすれば複数箇所に出てくることはほとんどない」
まともな名前すら付けられん人間が「しっかりとしたインスタンスの制御」なんてやると思うかい？
- 89 ：デフォルトの名無しさん：2011/06/05(日) 10:04:45.71
- グローバル変数を使わなければ管理が要らないなら
何故にインスタンスの制御とかの話になったの？
要らないんでしょ？
- 90 ：デフォルトの名無しさん：2011/06/05(日) 12:27:20.48
- >>89
グローバル変数使わなければね
俺の言ってることなにか矛盾してる？
- 122 ：デフォルトの名無しさん：2011/10/29(土) 11:34:19.34
- 時間と共に増大する複雑性への対処では。
書いたソースが自分たちのものになるのかで大きく価値が異なると思う。
複雑性が増すと修正にかかる工数が増えるけど、それを良しとするか悪しとするか。
- 123 ：デフォルトの名無しさん：2011/10/29(土) 18:57:08.38
- 果てしなく続くメンテナンスと機能追加を前提として
それぞれのモジュールの精度を高めるために必要な準備作業
じゃないかな
- 125 ：デフォルトの名無しさん：2011/10/29(土) 23:05:14.32
- >>122
>時間と共に増大する複雑性への対処では。
何？複雑性って？
仕様とコードが乖離してるの？
そもそも仕様や設計がまずいの？
仕様や設計はバッチリなのにコードだけ綺麗にしようとしてる？（場面がまったく浮かばないけど）
>>123
精度？よくわからないけど
精度が高い状態と低い状態があって
それを判断する手段があるって言ってる？
高い状態はどうなってて、低い状態はどうなってるってのを説明してほしいんだけど？
- 130 ：デフォルトの名無しさん：2011/10/30(日) 02:01:00.62
- 余計なもんなんかいれない。
"必要だから" 入れてる。
- 132 ：デフォルトの名無しさん：2011/10/30(日) 09:42:26.14
- >>130
でもそれって仕様書にないよね？
どうやって説明するの？
これまで派遣やってきたけど
そういうの許してる大手なんてみたことないけど
- 135 ：デフォルトの名無しさん：2011/10/30(日) 12:08:51.05
- >>132
じゃあ聞くが、お前の所の仕様書には、
ifやforやローカル変数名が書いてあるのか？
使用する命令はそれ以外のものは
一切使ったらいけないと書いてあるのか？
- 136 ：デフォルトの名無しさん：2011/10/31(月) 03:11:52.86
- >>135
そんな話はしてないじゃん
でもこっちの場合はそういう制御文にとどまらないもんができちゃうよね？
必要のないクラスだったり関数だったり
- 137 ：デフォルトの名無しさん：2011/10/31(月) 12:33:30.90
- >>136
なんか勘違いしてね？
必要ないものってなんのこと言ってんの？
- 147 ：デフォルトの名無しさん：2011/11/01(火) 22:09:32.23
- 他の言語では作る必要の無いクラスを作らされたら
ゴミクラスと言いたくもなるわい
- 174 ：デフォルトの名無しさん：2011/11/07(月) 06:29:39.93
- 仕様変更にまで手をいれない修正だったら俺はする意味ないと思うけどね
いいと思ってるのは自分だけっていう典型だと思う
- 184 ：デフォルトの名無しさん：2011/11/09(水) 00:34:09.76
- リファクタリングの価値は
リファクタリングしたことによる将来のメンテナンスコストの低減分だと思うから、
純粋なリファクタリングをする意味ってあると思うけどね。
まあ、少なくとも、作ったコードを客に出すのが仕事の人は、
リファクタリングの価値を見出すのは難しいだろうね。
お客が腐ったコードをメンテナンスし続ける費用を負担してくれる限り、
工数がかかる方が、お金になるだろうから。
- 186 ：デフォルトの名無しさん：2011/11/09(水) 22:25:08.24
- >>184
でもドングリの背比べじゃない？
仕様にまで踏み込めないレベルの修正でなんか変わるの？
同じ人、もしくは似たようなレベルの人がやんでしょ？
- 199 ：デフォルトの名無しさん：2011/11/16(水) 21:30:50.10
- 別にいいじゃん
その２つをくっつけることで後に呼び出し先Ａの機能を修正したいだけなのに
その機能がわざわざまとめられてるために
もう一つの呼び出し先Ｂのソースまで洗わないといけなくなるかもしんないだろ
まとめるのは必ずしも正解ではない
- 200 ：デフォルトの名無しさん：2011/11/16(水) 22:33:28.29
- >>199
必ずしも正解ではないのは正しいけど
同じような修正が必要になったときに片方の修正が忘れられることの方が多いと思われ
共通で使われてるメソッドの参照元を調べることより
クラスもメソッドも違うけど実は中身が同じでなければならなかったのを探すほうが大変な気が
分ける理由がないうちは一緒にしといて
必要になったら分ける方のが正しいと思う
- 202 ：デフォルトの名無しさん：2011/11/17(木) 22:48:38.78
- >>200
いや、お前の言ってることはGoogleやAppleでは正しいだろうな
だが、日本の工業製品ではＮＧ
もちろんいいたいことはわかるけど
それじゃ見積もりがとれないこの１点でＮＧ
色々な大手でたくさんのプロジェクトが走っていて
共通ライブラリなんて生まれないっつか生まれても消滅してしまう理由はここにある
修正の影響範囲が巨大すぎて見積もれない
また、修正時に全員が同じタイミングで対応できない
これも大きな問題だ
こっち動かなくなるのに「直したよ〜」とかメールくれられても困るだろ？
そっちに手がまわらないのにリリース前に真ライブラリでバグってリリース失敗であぼんとか話にならない
修正した本人は「いいんですーこれが本来あるべき姿なんです〜」って主張しようと
修正するほうは「糞が・・・」って思うっしょ？
まあ、ＭＳの出荷するもんにみんなが愚痴をこぼす瞬間だと思うけど
- 203 ：デフォルトの名無しさん：2011/11/17(木) 22:50:23.01
- >>202
で、その壁を超えられる所が勝ち組で
超えられないところはどんどんブラック会社化するわけだ。
仕事、つまらないだろう？ｗ
- 209 ：デフォルトの名無しさん：2011/11/17(木) 23:39:39.61
- 重複コードを作ると、納期が延びます。
修正があると、重複コードの分
修正量が増えます。
少しの修正であっちこっち修正して、
あっちこっちテストして納期伸ばしてるのは誰ですか？ｗ
- 210 ：デフォルトの名無しさん：2011/11/18(金) 00:57:17.23
- >>209
それって何箇所？
１０箇所？２０箇所？程度なら貼ったほうが速いよね？
思いっきりまとめあげられてて難しい仕組みに頭ひねってソース解読しなきゃいけないぐらいだったら
単純コピーで貼ってあってくれたほうがまだソース読みやすいよね
っていうか件数が１００件いかない程度のコピペならお前が便所に席を立った間にやっておいてやるよ
この程度の件数だったらどう組んでも変わらない
- 211 ：デフォルトの名無しさん：2011/11/18(金) 01:28:11.79
- >>210
お前適性ないんじゃね？
ぶっちゃけ、仕事楽しくないでしょ？
- 224 ：デフォルトの名無しさん：2011/11/19(土) 17:14:49.53
- トレードオフはコードをまとめる話だろ？
リファクタリングはまったく必要ないよ
そもそも意味わからないもん
次の仕様が決まってる中でのコード修正ならわかるけど
次になんの予定もないのに何に向けてどう修正してるのかまったく理解できない
その修正はいいの？悪いの？
オナニーで終わってない？
これらを判断できる材料すらわからない
単に金をドブに捨ててるだけだと思う
- 232 ：デフォルトの名無しさん：2011/11/19(土) 20:14:22.32
- 最高 綺麗で動く
↑ 汚いが動く
↓ 綺麗で動かない
最低 汚くて動かない
一番下のは捨ててよし
[動く／動かない] と [綺麗／汚い] の相関関係だお
汚いけど動くのは、綺麗だが動かないものより価値がある。
でも綺麗で動かないのを 動く にしやすいし、
汚いけど動くものも、後で何か変更するにあたって、動くのを保ちつつ綺麗にしておくと直しやすい。
「綺麗にする」のがリファクタリング。動かないものを動くようにすることとはイコールではない。関係はあるけど。
- 238 ：デフォルトの名無しさん：2011/11/19(土) 21:49:35.63
- もちろん設計の問題とコードの綺麗/汚いは関係ありますが？
最初にきちんと設計をしたつもりでも、実装段階では想定したとおりに行かなかったり、抜けがあったりすることはよくあることです。
実際に書いているうちにいろいろ思いつくこともあります。ちょこっと例外的な処理を付け加えて、を繰り返し、コードは汚くなっていきます。
そうしてソースがスパゲッティ化し、メンテ不能のソースとなっていきます。
そうならないようにするためにリファクタリングがあります。
リファクタリングとは、仕様を変えることなく、ソースコードを改造することをいいます。
汚いソースコードでもプログラムは動きますが、メンテナンスするのは大変です。
汚いソースコードと綺麗なソースコードではメンテのしやすさが全く違います。
なのできるだけ綺麗なソースを書くように心がけ、汚くなったら速やかに書き直すことです。
後々のことを考えて、わかりやすいソースに直します。
- 248 ：デフォルトの名無しさん：2011/11/20(日) 17:46:34.19
- 結局、
外から見た目の振る舞いが変わるか/変わらないかがポイントで、
外から見た目の振る舞い＝仕様であって
内部構造≒設計は、リファクタリングの対象
って事でおｋ？
- 249 ：デフォルトの名無しさん：2011/11/20(日) 18:02:36.08
- >>248
個人的にはソレが正しいと思うけど
そう思ってない人がいる予感。
241とか
- 309 ：デフォルトの名無しさん：2014/07/27(日) 09:55:49.81 ID:xgsJlmZ9
- いやあるよ。
だいたい仕様変更が入ったときって、仕様書の画面毎とかだかし、
テストも仕様書毎につくるから、共通化してもテストの工数あんま減らんし。
修正になった仕様書の枚数と、手をいれる工数が一致してるとすごく客に説明しやすい。
>似てる処理を共通化できないのは
断じて違う。「似てる処理」を共通化するんじゃない。部品を共通化するんだ。
このへん誤解してなんど泣いたことか。
おまえのその考え方はスパゲッティまっしぐら。
- 310 ：デフォルトの名無しさん：2014/07/27(日) 09:59:56.78 ID:EfhXqtXt
- >>309
どんな考えでもいいけど何かしらの共通化がされてたら
> 修正になった仕様書の枚数と、手をいれる工数が一致
これは成立しないぞ
まず自分の矛盾に気付くのが先のようだ。
- 311 ：デフォルトの名無しさん：2014/07/27(日) 10:34:57.72 ID:xgsJlmZ9
- >>310
青いのう
部品を共通化するって考え方が徹底してれば、だいたいの場合は一致するもんだ。
もちろん客に説明するより少ない工数で済むならそれでいいよ？
問題は、「似てる処理」を共通化してると、工数が仕様書の改修量よりずっと膨らむことがあるってことなんだ。
ささいな修正が全体に影響してテストが膨らんだり、結局コピペで新たにクラス作らなくちゃいけなくなったりな
うん、これも共通化してるなら何でも同じとか言われそうだな
現実のブツ無しだと説明が難しいが…
- 312 ：デフォルトの名無しさん：2014/07/27(日) 10:58:40.58 ID:EfhXqtXt
- >>311
説明が難しいのはお前が「部品」とかいうオレオレ言語使って自己満足してるからだ。
ワケの分からん独自理論開発するまえに基本をしっかり勉強しろ。
- 315 ：デフォルトの名無しさん：2014/07/27(日) 11:22:29.85 ID:xgsJlmZ9
- >>312
独自理論じゃないよ！みんなそう言ってるよ！
お前こそ本読んで知った気になってるだけだろ！頭でっかちめ
確かに、だいたい初心者向けの本には同じ処理を共通化すべしとか適当に書いてあるから、
実際の経験がないと理解しづらい部分ではある。
- 352 ：デフォルトの名無しさん：2014/07/30(水) 23:20:51.69 ID:B3MDpURs
- どう考えてもすぐリファクタする方が低脳だろｗ
リファクタしたがる奴の傾向として
・理解力の不足。
自分に理解できないものをすぐ諦めてクソ呼ばわりする。
他人の書いたコードの一貫したポリシーや目的を汲み取れないから、先人が用意してくれた便利なライブラリも使えない。
理解できないから規約も無視しがちで、彼の書いたところだけ作りがおかしい。
・謙虚さの不足。
相手を見下して、自分のほうがいいものが作れると根拠なく信じてる。
すでに用意されているものを再発明するだけならまだいいが、
しばしば完成されたフレームワークの重要な部分にクソを差し込んでめちゃくちゃにする。
・計画性の不足。
先の見通しが利かないから、行き当たりばったりでクソしか作れない。
リファクタも行き当たりばったりにやるから、クソが超臭うクソになるだけということになりがち。
挙句に自分で訳がわからなくなって、成果物を全部消したりする。
・客観性の不足
自分のやったことの成果を、客観的に見ることが出来ない。
リファクタしたことで、掛けた工数がどれくらいでペイしたとか、数字で物事を考えられない。
彼がリファクタするのは、単に楽しいから。本人は仕事してる気になってるが、周囲から見ると遊んでるだけ。
という感じ。
そもそも最初からちゃんと書く能力があったら、リファクタしたいと思うことは少ないはず。
- 353 ：デフォルトの名無しさん：2014/07/30(水) 23:55:14.83 ID:2joTlTTw
- >>352
> ・理解力の不足。
> 自分に理解できないものをすぐ諦めてクソ呼ばわりする。
> 他人の書いたコードの一貫したポリシーや目的を汲み取れないから、先人が用意してくれた便利なライブラリも使えない。
> 理解できないから規約も無視しがちで、彼の書いたところだけ作りがおかしい。
>
> ・謙虚さの不足。
> 相手を見下して、自分のほうがいいものが作れると根拠なく信じてる。
> すでに用意されているものを再発明するだけならまだいいが、
> しばしば完成されたフレームワークの重要な部分にクソを差し込んでめちゃくちゃにする。
とりあえず、最初の二つだけで良いから
リファクタリングとの関係を論理的に説明してみ？
- 354 ：デフォルトの名無しさん：2014/07/31(木) 00:02:21.65 ID:Jagb4X9u
- >>353
他人の書いたコードを書き換えたがるんだよ…
自分に理解できないからクソだ。という理屈で。
クソに感じるのは自分の能力が足りないせいだということに気づかない。
- 359 ：デフォルトの名無しさん：2014/07/31(木) 00:54:29.60 ID:jvFYVzT/
- > 散々テストしたはずなのに客先に持ってったら動きが変わってて
それリファクタリングになってないから
リファクタリングじゃない話を使ってリファクタリング批判してどうすんだよ
- 409 ：デフォルトの名無しさん：2014/08/03(日) 00:45:38.31 ID:CSranqfK
- 一応UMLでシーケンス図とクラスとPublicメソッドだけはきっちり作ってるな
DBアクセスとかあたりまで
そっから先はprivateで実装して
アプリのフレームワークに依存しないメソッドとかクラスとかはプCommonフォルダに各自放り込んでもらう
で上手くいくと思ったけど
Commonがかなりカオスなことに
http://peace.2ch.net/test/read.cgi/tech/1275121556/l50/../
0 件のコメント:
コメントを投稿