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

■ このスレッドは過去ログ倉庫に格納されています
2010/05/29(土) 17:25:56
テストも書かないでリファクタリングとかうけるｗ

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

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

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

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

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

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

で？
2011/11/08(火) 01:14:10.32
>>177
コンプレックス刺激されすぎｗ
2011/11/08(火) 01:17:58.36
単純なシチュエーションだと、今動いているものがあって
それに仕様変更や機能追加をする"前"にリファクタリングしたり

えーちょっと何やってんのか分からなぁ〜いって時に、リファクタリングして今の動きを確認したりする鴨

さすがに何も用事が無いのにリファクタリングはしないぞw
2011/11/08(火) 06:35:51.23
>>179
ローカルのＨＤＤの中で勝手にやってろレベルだなｗ
2011/11/08(火) 08:17:23.29
>>177
どうしたの？
したくないならしなくていいんだよ？

別にお前のコードのことなんて知らないし
2011/11/08(火) 12:07:50.87
仕様書を大雑把に

・機能仕様書：ユーザの観点からシステムがどのように動くか記述する
・技術仕様書：プログラムの内部実装について記述する

に分けたとき、機能仕様書を変更しないのがリファクタリング
技術仕様書は変更する必要がある

と、俺は解釈してるんだけど
2011/11/08(火) 22:53:38.54
>>182
そんな金になんない仕事やったらダメだよ
仕様どおりには動いているんだ
よほど現実からかけ離れた組み方でない限りはそんなところにお金を入れてはダメだ
2011/11/09(水) 00:34:09.76
リファクタリングの価値は
リファクタリングしたことによる将来のメンテナンスコストの低減分だと思うから、
純粋なリファクタリングをする意味ってあると思うけどね。

まあ、少なくとも、作ったコードを客に出すのが仕事の人は、
リファクタリングの価値を見出すのは難しいだろうね。
お客が腐ったコードをメンテナンスし続ける費用を負担してくれる限り、
工数がかかる方が、お金になるだろうから。
2011/11/09(水) 01:07:17.87
寧ろそうやって放置されたコードのメンテナンスの際にESP能力を発揮しながらリファクタリングして日銭稼いでますが何か。
2011/11/09(水) 22:25:08.24
>>184
でもドングリの背比べじゃない？
仕様にまで踏み込めないレベルの修正でなんか変わるの？
同じ人、もしくは似たようなレベルの人がやんでしょ？
2011/11/09(水) 23:19:04.89
>>186
同じようなレベルの人がやったら対して変わらんだろうね。
時間がなくて小手先で直したのを時間が取れる時にまともに直すとかかしら。

あほなプログラマが書いた動くけどわけわらんプログラムを
レビューで突き返したりするのもリファクタリングになると思うけど、放置するの？
2011/11/10(木) 00:11:30.20
>>187
でも設計レベルではなにも変わらないんしょ？
アホだろうがどうだろうが違いがでるレベルにならんのとちゃうか？
2011/11/10(木) 02:48:37.98
>>186
> 仕様にまで踏み込めないレベルの修正でなんか変わるの？

お前コード書いたことないだろ？
2011/11/10(木) 02:49:24.36
>>188
お前の言う「設計レベル」ってどういうことだ？

コードには設計があるのは知ってるよな？
それは機能のことじゃないぞ。
2011/11/10(木) 06:19:17.82
>>189
あるけど
そこでそんなに違いが出るとは思えないんだよね
大手もそう考えるから（いや実際そうなんだろう）ＰＧは派遣ばかりなわけだしね
2011/11/10(木) 22:10:19.47
http://www.os.cis.iwate-u.ac.jp/wikky/wikky.cgi?%E7%AC%AC2%E7%AB%A0%EF%BC%9A%E3%83%AA%E3%83%95%E3%82%A1%E3%82%AF%E3%82%BF%E3%83%AA%E3%83%B3%E3%82%B0%E3%81%AE%E5%8E%9F%E5%89%87

2.1 リファクタリングの歴史

リファクタリングの先駆け：1980年代以降Smalltalkの仕事をしていたWard CunninghamとKent Beckの2人

Smalltalkはリファクタリングに特に向いている環境

コンパイル、リンク、実行のサイクルが短く、コードを気軽に書き換えることができる

彼ら2人の考えはSmalltalk文化にリファクタリングの概念を定着させた

筆者「リファクタリング？そこまで重要ではないよ」→Kentと同じプロジェクトに携わり、
Kentのリファクタリングを目の当たりにする→ソフトウェアの生産性、品質に明らかな違いが…→筆者「！！」

上の経験からリファクタリングを重要視するようになった
2011/11/10(木) 23:19:30.99
>>192
そのストーリーって重要な部分なの？ｗ
しかもそんな馬鹿みたいな長文書いて大事な要点がちっとも書いてないじゃん

>ソフトウェアの生産性、品質に明らかな違いが…
明らかに大事なのってこの部分の詳細だろ

何がよくて品質がどうよくなったのか？

だろ？
お前の国語の能力低すぎてリファクタリングまで怪しくなるわｗ
2011/11/11(金) 21:19:14.97
>>193
そういう文句はオリジナルを書いた奴に言え。
2011/11/11(金) 23:32:49.89
自分の言葉で語れない奴はカス
2011/11/11(金) 23:58:46.50
お前のセリフに説得力はない
2011/11/12(土) 01:34:54.40
>>191
違いを理解できない能力なだけじゃないの？
2011/11/16(水) 20:57:29.42
重複の除去が有効とか書いてあるじゃん

前にやった仕事で、ほんの一部を除いて同一の機能を持つモジュール２つが
別々の人によってそれぞれ実装されてて
目玉飛び出そうになったのを思い出した
2011/11/16(水) 21:30:50.10
別にいいじゃん
その２つをくっつけることで後に呼び出し先Ａの機能を修正したいだけなのに
その機能がわざわざまとめられてるために
もう一つの呼び出し先Ｂのソースまで洗わないといけなくなるかもしんないだろ

まとめるのは必ずしも正解ではない
200デフォルトの名無しさん
垢版 |
2011/11/16(水) 22:33:28.29
>>199
必ずしも正解ではないのは正しいけど
同じような修正が必要になったときに片方の修正が忘れられることの方が多いと思われ
共通で使われてるメソッドの参照元を調べることより
クラスもメソッドも違うけど実は中身が同じでなければならなかったのを探すほうが大変な気が

分ける理由がないうちは一緒にしといて
必要になったら分ける方のが正しいと思う
2011/11/17(木) 01:17:42.75
ちなみに >>198 は
その両方を移植する仕事だった

「工数儲けた」と思ってたら
両者をソース読んで同一機能であることを確認した上で
一つにすりあわせて、その承認もらう羽目になったとさ

当然まともな設計書なんてありゃしないし
2011/11/17(木) 22:48:38.78
>>200
いや、お前の言ってることはGoogleやAppleでは正しいだろうな
だが、日本の工業製品ではＮＧ

もちろんいいたいことはわかるけど
それじゃ見積もりがとれないこの１点でＮＧ

色々な大手でたくさんのプロジェクトが走っていて
共通ライブラリなんて生まれないっつか生まれても消滅してしまう理由はここにある

修正の影響範囲が巨大すぎて見積もれない
また、修正時に全員が同じタイミングで対応できない
これも大きな問題だ
こっち動かなくなるのに「直したよ〜」とかメールくれられても困るだろ？
そっちに手がまわらないのにリリース前に真ライブラリでバグってリリース失敗であぼんとか話にならない

修正した本人は「いいんですーこれが本来あるべき姿なんです〜」って主張しようと
修正するほうは「糞が・・・」って思うっしょ？
まあ、ＭＳの出荷するもんにみんなが愚痴をこぼす瞬間だと思うけど
2011/11/17(木) 22:50:23.01
>>202
で、その壁を超えられる所が勝ち組で
超えられないところはどんどんブラック会社化するわけだ。

仕事、つまらないだろう？ｗ
2011/11/17(木) 22:55:03.81
>>203
でもいくらもないっしょ？
日本のＩＴって進化に失敗してて紙業務を電子化したような仕事のほうが多いよね？
韓国にもすっかり抜かれちゃったみたいで国内全員でｼｮﾎﾞｰﾝって感じじゃない？
研究開発分野と本当に極一部だけだろうね
まあ、いまそういう開発してても日本じゃいつ紙業務の電子化ＩＴにまわされるかわからないから
勝ち組って意味でいうと海外脱出組が勝ち組だろうね
2011/11/17(木) 22:58:57.20
>>204
ごめんな。

うち自社で作ったウェブサービス提供する会社なんだわ
HTML5系とかそっち系。

選ぶ会社の時点で勝ち負けが決まるよね。
仕事、つまらないだろう？ｗ
2011/11/17(木) 23:01:51.10
うちは少数精鋭なんで（使えない奴はやめさせられる）
同じコードをいくつも書くとかそんな無駄なことやってられないんだよね。

テストも人海戦術で同じことを何度もやるとか、時間的に無理だし、
もちろん手動テストは極力減らすので、変更したって
影響があるならすぐ分かる。
2011/11/17(木) 23:02:59.45
>>205
ウェブ系なんて工業製品とかわんねーけどな
あんなん汎用性見越して組む必要あるかね？

寿命が短いからどう組んでもどうとでも動くが正解だろ？
納期まで早い方が真
お前の世界こそプログラムを綺麗にまとめて褒める奴１人もいないと思うがな
2011/11/17(木) 23:38:17.66
>>207
汎用性見越して組むとか言ってないんだが。

無駄にある重複コードをまとめると言ってるだけ。
2011/11/17(木) 23:39:39.61
重複コードを作ると、納期が延びます。

修正があると、重複コードの分
修正量が増えます。

少しの修正であっちこっち修正して、
あっちこっちテストして納期伸ばしてるのは誰ですか？ｗ
2011/11/18(金) 00:57:17.23
>>209
それって何箇所？
１０箇所？２０箇所？程度なら貼ったほうが速いよね？
思いっきりまとめあげられてて難しい仕組みに頭ひねってソース解読しなきゃいけないぐらいだったら
単純コピーで貼ってあってくれたほうがまだソース読みやすいよね

っていうか件数が１００件いかない程度のコピペならお前が便所に席を立った間にやっておいてやるよ
この程度の件数だったらどう組んでも変わらない
2011/11/18(金) 01:28:11.79
>>210
お前適性ないんじゃね？

ぶっちゃけ、仕事楽しくないでしょ？
2011/11/18(金) 01:48:53.37
自分でやるんじゃなくて他人にやらせるんだろ
2011/11/18(金) 06:57:57.33
>>211
いや、楽しいよ
お前みたいな対象物のメリットとデメリットも判断できんようなの出し抜いて数字上げるのが何よりの快感だわ(笑)
結局、技術の上部だけしかすくえないひとって何も見えてないんだよね
新しいってだけである意味パニック状態になってる自分がなにより見えてない
2011/11/18(金) 07:32:36.75
数字を出しさえすればそれが全てだと思い込んでいることはよく判った。
さぞかし楽しい人生だろうねぇ。
2011/11/18(金) 11:48:05.79
>>213
お前性格屈折してるな
そうとういじめられたな
2011/11/18(金) 12:54:07.46
>>210
> 思いっきりまとめあげられてて難しい仕組みに頭ひねってソース解読しなきゃいけないぐらいだったら
> 単純コピーで貼ってあってくれたほうがまだソース読みやすいよね

申し訳ありません
ifとforしか理解できない人もいるということを忘れていました
リファクタリングの過程でデザインパターンを適用してしまったことをお許しください
2011/11/18(金) 12:59:02.53
>>213
コピペもできるしリファクタリングもできる俺がそれを言うならまだわかるけど、
お前はコピペしかできないんだからさ、取捨選択の上でコピペを採用したみたいな言い方はやめてよ
もっともらしい後付けをしたところで、お前のカードはコピペしかないわけで
2011/11/18(金) 12:59:57.09
>>216
forすら理解してないかもよ
100回ループ廻すくらいならコピペするって言い出しかねん
2011/11/18(金) 15:50:01.61
正面から反論できないときは人格攻撃になるんですね
その時点で白旗あげてるっていうかなんていうか
2011/11/18(金) 19:16:21.49
>>219
だってー
低レベルな人を教育してあげる気なんて毛頭ないですしー
2011/11/18(金) 23:06:02.19
>>220
でも自分のやってることの説明できないってのは問題じゃない？
結局トレードオフの問題であって
やればやるほどとかどんな場面でもってわけじゃないってとこは否定できないわけでしょ
じゃあ、君のやり方は正しいの？また、他の人と差がでるのは何が決め手なの？
ってのは結局のところどこでも求められると思うんだけどね
それが説明できないなら君に用のある人なんていないと思うんだよね
みんな暇じゃないから(笑)
222デフォルトの名無しさん
垢版 |
2011/11/19(土) 16:25:48.92
へえ
2011/11/19(土) 16:38:24.26
トレードオフ考えてやるんだから
やっぱりリファクタリングは必要ってことね

リファクタリング全否定って人はいるのかしら
2011/11/19(土) 17:14:49.53
トレードオフはコードをまとめる話だろ？
リファクタリングはまったく必要ないよ
そもそも意味わからないもん
次の仕様が決まってる中でのコード修正ならわかるけど
次になんの予定もないのに何に向けてどう修正してるのかまったく理解できない
その修正はいいの？悪いの？
オナニーで終わってない？

これらを判断できる材料すらわからない
単に金をドブに捨ててるだけだと思う
2011/11/19(土) 17:30:26.36
汚いコード
ゴミ溜めが如くきったない部屋で過ごしてもなーんにも問題無い
↑
↓
チリ一つも落ちていないようなクリーンルームじゃないと過ごせない
綺麗なコード

って話だろ？ 何事もほどほどにしとけって事だよ
2011/11/19(土) 17:33:20.81
>>225
人の話を良く聞かないで進めちゃって失敗するほうじゃない？
2011/11/19(土) 18:59:16.42
>>224
キミがそのコードをずっとメンテナンスする責任者だとして、
どこかのプログラマが明らかにまとめるべきところまとめてこなかったり、
分けるべきところをを無理やりまとめてきたりした場合、
正しく動くという理由でそのままにしておくのかい？
2011/11/19(土) 19:28:32.54
>>227
作るときに設計書にあわせてもらいます
ソースだけ弄るってことはしません
2011/11/19(土) 19:33:14.80
ソース＝設計書だろ?
2011/11/19(土) 19:47:12.13
>>229
底辺乙
2011/11/19(土) 19:51:09.79
>>228
要するに仕様は変えずに設計を変えるんだろ
リファクタリングじゃないか
2011/11/19(土) 20:14:22.32
最高 綺麗で動く
↑　 汚いが動く
↓　 綺麗で動かない
最低 汚くて動かない

一番下のは捨ててよし
[動く／動かない] と [綺麗／汚い] の相関関係だお

汚いけど動くのは、綺麗だが動かないものより価値がある。
でも綺麗で動かないのを 動く にしやすいし、
汚いけど動くものも、後で何か変更するにあたって、動くのを保ちつつ綺麗にしておくと直しやすい。
「綺麗にする」のがリファクタリング。動かないものを動くようにすることとはイコールではない。関係はあるけど。
2011/11/19(土) 20:27:15.16
>>232 使用がバッチィからコードもバッチイって発想はないのか？
234232
垢版 |
2011/11/19(土) 20:45:33.70
仕様が汚いと動かすのが難しい
↑
↓
綺麗な仕様は動かしやすい
って関係はあると思うけど、コードと仕様は直接関係しないんじゃねの？
2011/11/19(土) 20:55:13.83
>>234
汚い仕様を何とか動かすために、 汚い姑息なコードを大量に入れてる
例なら山ほどあるよ
2011/11/19(土) 21:31:39.15
コードを綺麗/汚いで語るから話がおかしくなるんじゃないか。
リファクタリングって大なり小なり設計の問題の修正のことだと思うんだが。
オレがずれてるのか。
2011/11/19(土) 21:34:18.54
>>236
おれもそう思うよ. 仕様も設計の内だとも思うけど...
2011/11/19(土) 21:49:35.63
もちろん設計の問題とコードの綺麗/汚いは関係ありますが？

最初にきちんと設計をしたつもりでも、実装段階では想定したとおりに行かなかったり、抜けがあったりすることはよくあることです。
実際に書いているうちにいろいろ思いつくこともあります。ちょこっと例外的な処理を付け加えて、を繰り返し、コードは汚くなっていきます。
そうしてソースがスパゲッティ化し、メンテ不能のソースとなっていきます。

そうならないようにするためにリファクタリングがあります。
リファクタリングとは、仕様を変えることなく、ソースコードを改造することをいいます。
汚いソースコードでもプログラムは動きますが、メンテナンスするのは大変です。
汚いソースコードと綺麗なソースコードではメンテのしやすさが全く違います。
なのできるだけ綺麗なソースを書くように心がけ、汚くなったら速やかに書き直すことです。
後々のことを考えて、わかりやすいソースに直します。
2011/11/19(土) 22:15:38.43
>>238
> そうならないようにするためにリファクタリングがあります。

そうならないように設計を見直す方が先じゃないか?

小手先でどれだけいじっても, 汚い設計は汚いソースを
再生産するだけじゃないのか?

それだったら, 設計をリファクターすべきだ

ぶっちゃけ, ユーザーインターフェースが変わらなきゃ
仕様の範囲内だ
2011/11/19(土) 23:03:54.10
>>238
コピペはいらんよ。

汚い綺麗で語るとコードの可読性ばかりを問題にしてるように感じるって話。
だからリファクタリングがいらないとか言う奴がいるんじゃないの。

コードが綺麗であっても設計上の問題が存在することは当然あるよね。

コードの綺麗/汚いは設計の一部しか示していないと思うし、
その修正はリファクタリングの一部でしかないと思う。
2011/11/20(日) 07:43:51.29
>>240
したらただの仕様変更だよねそれって
まあ、名称にこだわる必要もないけど
2011/11/20(日) 08:21:15.92
関数、クラスの仕様は変わっても
システム全体の仕様は変わりません。

なので仕様変更にはあたりません。
2011/11/20(日) 08:21:59.02
設計変更と仕様変更は別の話といえばよかったか。
2011/11/20(日) 12:07:12.15
設計を仕様と見なしたら
仕様変更を伴わないコード変更って存在するのか？
2011/11/20(日) 12:08:20.66
aとかbとかわけのわからん変数名を
意味がある変数名に変更するとか。
2011/11/20(日) 13:09:50.85
I/F変更を伴うかどうかっていう観点じゃないの

ユーザに見える部分とか
担当者の異なるモジュール間とか
2011/11/20(日) 17:10:54.61
オリンパスコーディング
2011/11/20(日) 17:46:34.19
結局、
外から見た目の振る舞いが変わるか/変わらないかがポイントで、
外から見た目の振る舞い＝仕様であって
内部構造≒設計は、リファクタリングの対象
って事でおｋ？
2011/11/20(日) 18:02:36.08
>>248
個人的にはソレが正しいと思うけど
そう思ってない人がいる予感。
241とか
2011/11/20(日) 18:50:26.97
>>249
じゃあ、リファクタリングってのは設計変更までを指すってことでいい？
何やんだかさっぱりわからないけど
2011/11/20(日) 18:53:49.64
>>250
設計の範囲を定義しろ。
話はそれからだ。
2011/11/20(日) 21:17:25.23
>>251
そっちにまかせる
>>248がえらそうに宣言してるから>>248に決めてもらうか
2011/11/21(月) 09:59:01.46
(この人たち、なんで今さらこんな議論をしてるんだろう)
2011/11/21(月) 22:35:10.04
最初からずっとこのスレにいるのは
お前だけだよｗ
2011/11/22(火) 10:39:05.00
そうか、リファクタリング本を読んでるのは俺だけだったか
2011/11/23(水) 00:32:21.88
>>255
本の受け売りじゃなくて中身をちゃんと理解しろよ
2011/11/23(水) 01:19:14.75
そういう手合いはおそらくよんですらいない
買っただけ
2012/02/07(火) 13:45:03.37
改修が必要になったときに初めて
その場で interface をでっちあげて、その後、クラスお取替え

これでいい気がしてきた
2012/02/07(火) 20:02:48.59
それでいい
260デフォルトの名無しさん
垢版 |
2012/03/24(土) 14:35:39.62
リファクタリングを身に付けるとコードレベルでの設計力が上がりますか？
2012/03/24(土) 16:05:22.68
設計力は下がります
でも組んだ後の問題に対する対応力は上がります
262デフォルトの名無しさん
垢版 |
2012/03/24(土) 17:35:34.20
>>261
何故、設計力は下がるのですか？
2012/03/24(土) 21:11:33.51
設計力あがるだろ

正しい設計のコードに
変化させるのがリファクタリングだ。
2012/03/24(土) 21:36:47.86
>>49-52で結論は出てる
リファクタリングはオナニー
好きにやればいい
公開オナニー好きでも床オナ好きでもその方法を誰も咎めることはできない
2012/03/24(土) 21:51:30.52
オナニー？　自己満足と言いたいのかもしれないが。
仕事でやるのなら自己満足じゃないぞ。
みんなの満足。

2012/03/24(土) 22:21:58.07
みんなでオナニー
2012/03/25(日) 12:10:02.63
分散マスタベーション
2012/04/22(日) 22:43:46.10
密に結合した処理を処理を疎になるようにするとか
処理が対象になるようにシーケンス直すとか
って意味があるリファクタリングだと思うけど
こういうのはリファクタリングっていわんの？
2012/08/05(日) 00:31:39.26
>クラス内部で別のクラスを生成しない
>>4のこの話って完全にはDIでも使わなきゃ無理だけど、
FactoryMethodで解決できるよね。

>publicメソッドの引数には、なるべくクラスを使わない。
完全抽象化クラスに類するもの限定ってなら正しいけど、
intや文字列型だけってのは無いよね。スタブ渡せば済む話だし。
2012/08/05(日) 01:11:40.91
言葉の揚げ足取りに終始しててウザいだけのスレになっちゃってるなｗ
271デフォルトの名無しさん
垢版 |
2012/10/14(日) 16:17:10.72
大規模アプリには
必ずリファクタリングが必要。
開発工程の一つに加えていいレベル。
272デフォルトの名無しさん
垢版 |
2012/10/15(月) 15:52:21.57
VB6で幾度となく機能追加が行われたコードをぼんやり眺めてると
リファクタリング？何それおいしいの？
という気分になってくる。
2012/10/16(火) 18:14:20.05
>>272
そういうコードこそ、リファクタリングが楽しいんじゃないの？
274272
垢版 |
2012/10/16(火) 18:35:14.51
趣味でやるならすごく楽しい。一人でやるのなら絶対リファクタリングしてる。
けど仕事となると時間が取れない。
さらなる機能追加と他言語への移植作業用のドキュメントが優先になってまつorz
移植作業前にリファクタリングできたら解読も楽だろうになあ。
そんなことより成果物（ドキュメント）が優先だってさ。しゃーねーや。
2013/07/11(木) NY:AN:NY.AN
refakuta
2013/07/11(木) NY:AN:NY.AN
リファク太
2014/01/10(金) 07:46:54.18
リファクトスタンダード
■ このスレッドは過去ログ倉庫に格納されています
5ちゃんねるの広告が気に入らない場合は、こちらをクリックしてください。
ニューススポーツなんでも実況