11/10/10 15:49:03.28 .net
そう。どの言語でもやってる。
何故ならインターフェースなどそう簡単に変更できないからだ。
それなのに
> 必要なことがあるかもしれないが、それは、通知すればいいだけの話。
のような事を書くほど低レベルのPGはJava PGだけだと予想して釣ってみたが、
やっぱりその通りだったねw
113:デフォルトの名無しさん
11/10/10 15:55:41.96 .net
「なんかこう、俺とは一段以上下のレベルの奴しか見当たらんよなｗ」(キリッ
114:デフォルトの名無しさん
11/10/10 16:24:50.97 .net
>>112
意味がわからんｗ
インターフェースが簡単に変更できないからって、
絶対に変更できないわけじゃないだろ。
お前頭が硬すぎじゃね？
115:デフォルトの名無しさん
11/10/10 16:48:43.88 .net
めんどくさいからコードに対する変更はもう全部リファクタリングでいいよ
116:108
11/10/10 19:15:25.35 .net
>>109
若干かわいそうな環境かも。
機能毎に縦割りでリーダーが立ってて
「こっちは機能追加が進んでて人居ない」とか
「影響が大きい」とか言われて
とてもじゃないが変えられない。
それでも自担当の部分だけでもリファクタリングする工数が
貰えるだけマシなのかも知れんけどね。
117:デフォルトの名無しさん
11/10/10 21:13:00.47 .net
JavaのPGやってるけど
privateメソッドを修正するだけでもJAVADOCの修正とかユニットテストが更新されるからって
チーム内でそれを拒む人いるんだよなー
ってか、お前が俺のソースコピペして、俺がその責任背負わなくなくなるのが嫌なんだろｗｗｗどうせｗｗｗ
118:デフォルトの名無しさん
11/10/25 13:23:05.69 .net
リファクタリング中は考えることを止めよう
URLﾘﾝｸ(www.infoq.com)
119:デフォルトの名無しさん
11/10/29 00:57:02.72 .net
やっぱり目的が意味不明
設計ミスならリファクタリングという形で手を出すべきじゃないし
汎用性の向上にしても次の開発やバージョンアップの仕様書があってこその修正だ
単純にリファクタリングってのが何を目的としてるのかどの文献を読んでもまったく意味不明
120:デフォルトの名無しさん
11/10/29 03:24:37.60 .net
>>119
でっていう
教えてほしいならそう言えよｗ
そうでないのなら、やり方はひとつじゃないんだし、お前の好きなようにやれば？
121:デフォルトの名無しさん
11/10/29 05:48:50.42 .net
>>120
じゃあ、質問だけど
これは何を目的とした作業なの？
122:デフォルトの名無しさん
11/10/29 11:34:19.34 .net
時間と共に増大する複雑性への対処では。
書いたソースが自分たちのものになるのかで大きく価値が異なると思う。
複雑性が増すと修正にかかる工数が増えるけど、それを良しとするか悪しとするか。
123:デフォルトの名無しさん
11/10/29 18:57:08.38 .net
果てしなく続くメンテナンスと機能追加を前提として
それぞれのモジュールの精度を高めるために必要な準備作業
じゃないかな
124:デフォルトの名無しさん
11/10/29 22:48:37.21 .net
何いってるのかさっぱりわからない
じゃ、質問をかえる
その作業いつ終わるの？
125:デフォルトの名無しさん
11/10/29 23:05:14.32 .net
>>122
>時間と共に増大する複雑性への対処では。
何？複雑性って？
仕様とコードが乖離してるの？
そもそも仕様や設計がまずいの？
仕様や設計はバッチリなのにコードだけ綺麗にしようとしてる？（場面がまったく浮かばないけど）
>>123
精度？よくわからないけど
精度が高い状態と低い状態があって
それを判断する手段があるって言ってる？
高い状態はどうなってて、低い状態はどうなってるってのを説明してほしいんだけど？
126:デフォルトの名無しさん
11/10/29 23:30:50.35 .net
効果も含めて微ファクタリング
127:デフォルトの名無しさん
11/10/30 00:00:06.96 .net
>>125
仕様が変わることによって設計がそぐわなくなったときの対処についてはどう考えているの？
仕様や設計がまずいといえばそれまでだけど、
完璧な仕様や設計は期待できないでしょ
128:デフォルトの名無しさん
11/10/30 00:12:36.90 .net
最初から間違えなければいい。
129:デフォルトの名無しさん
11/10/30 01:44:30.53 .net
>>127
んー
それをコードにいれちゃうのはなんかちがうなーって思う
だって説明として仕様や設計に入ってもいないクラスが
自分の考える汎用性のためだけに入ってるってことでしょ？
まあ、昔の俺ならそういうコードいいと思ったけど
最近はこういう見切り発進みたいなコードをちっともいいと思わなくなった
むしろ余計なもん入れちゃうのってどうよ？って思う
130:デフォルトの名無しさん
11/10/30 02:01:00.62 .net
余計なもんなんかいれない。
”必要だから” 入れてる。
131:デフォルトの名無しさん
11/10/30 02:32:58.38 .net
>>129
自分の考えるよりよいコードを実現するためのひとつの手段がリファクタリングなのであって、
お前がリファクタリングは不要と考えるならそれはそれでいいんじゃね
リファクタリングしなくていいよ
132:デフォルトの名無しさん
11/10/30 09:42:26.14 .net
>>130
でもそれって仕様書にないよね？
どうやって説明するの？
これまで派遣やってきたけど
そういうの許してる大手なんてみたことないけど
133:デフォルトの名無しさん
11/10/30 11:29:33.88 .net
>>129
見切り発進と思うのなら、修正した方が良いと思った内容を提案してみては。
受け入れるかは組織なり人なりタイミングによると思うけど、
少なくともうちだったら、そういう提案してくれる人は歓迎するけどなあ。
その人の持つ技術力の評価や信頼にも繋がるし。
134:デフォルトの名無しさん
11/10/30 11:55:22.16 .net
>>132
大手なんて10年は遅れてるじゃん
ゴミコード量産の現場でリファクタリングしようなんて、俺だって思わないな
メンテする奴が死ねばいい
135:デフォルトの名無しさん
11/10/30 12:08:51.05 .net
>>132
じゃあ聞くが、お前の所の仕様書には、
ifやforやローカル変数名が書いてあるのか？
使用する命令はそれ以外のものは
一切使ったらいけないと書いてあるのか？
136:デフォルトの名無しさん
11/10/31 03:11:52.86 .net
>>135
そんな話はしてないじゃん
でもこっちの場合はそういう制御文にとどまらないもんができちゃうよね？
必要のないクラスだったり関数だったり
137:デフォルトの名無しさん
11/10/31 12:33:30.90 .net
>>136
なんか勘違いしてね？
必要ないものってなんのこと言ってんの？
138:デフォルトの名無しさん
11/10/31 21:45:02.67 .net
>>136
世の中に必要なクラス・関数を網羅した
仕様書なんて無いよ。
139:デフォルトの名無しさん
11/11/01 00:54:41.88 .net
>>137
仕様と関係ないソース
汎用性のために入れましたって言うんでしょ？
140:デフォルトの名無しさん
11/11/01 00:57:56.17 .net
この表現でわからないならデザパタ使うと出てくるゴミクラスなんか全部該当すると思う
141:デフォルトの名無しさん
11/11/01 06:03:18.76 .net
>>139
仕様と関係ない関数は不要なので、コードはすべてmainの中に書いてくださいね
142:デフォルトの名無しさん
11/11/01 07:41:02.59 .net
>>141
いくらなんでもそれは話が飛びすぎてて馬鹿っぽい
143:デフォルトの名無しさん
11/11/01 08:04:06.10 .net
デザパタでぽこぽこ生まれるゴミクラス問題は
特定の言語に固有の問題であって、リファクタリングの問題じゃなくね？
URLﾘﾝｸ(www.norvig.com)
144:デフォルトの名無しさん
11/11/01 20:58:54.49 .net
>>143
リファクタリングは保守の一つなのだから、
コードを修正するならば言語に関係なく発生する問題。
リファクタリングとデザパタは
特定の言語固有とか言う以前に、全く関係ない話題。
ついでにデザパタで作るのはゴミクラスではなく必要なクラス。
145:デフォルトの名無しさん
11/11/01 21:19:29.93 .net
>>142
よう、レガシー
146:デフォルトの名無しさん
11/11/01 21:21:02.73 .net
Sir! FUTURE!!
147:デフォルトの名無しさん
11/11/01 22:09:32.23 .net
他の言語では作る必要の無いクラスを作らされたら
ゴミクラスと言いたくもなるわい
148:デフォルトの名無しさん
11/11/01 22:12:41.23 .net
>>147
たとえばどんなの？
149:デフォルトの名無しさん
11/11/01 22:14:56.95 .net
他の言語では、定義する必要がない型を
定義しても、ゴミ定義とは言わないだろ。
単に、エラーを見つけやすい方法で書くか、
短いコードだから省略して書くかの違いでしか無い。
150:デフォルトの名無しさん
11/11/01 22:26:33.69 .net
>>148
Strategyパターンはファーストクラスの関数があれば
クラスを作る必要は無いな
151:デフォルトの名無しさん
11/11/01 22:28:50.74 .net
うん。だからそれは、インターフェースを守った
きっちりとしたアプリを作るかどうかの違い。
152:デフォルトの名無しさん
11/11/01 22:36:13.61 .net
きっちりしてるというのはどういう意味だ？
静的型検査という意味なら勘違いも甚だしいぞ
153:デフォルトの名無しさん
11/11/01 22:41:00.77 .net
>>152
コード上に、インターフェースがちゃんと表現されているという意味。
インターフェースを守らない、間違ったコードは組み込めないという意味でもある。
154:デフォルトの名無しさん
11/11/01 23:28:25.82 .net
>>150
ファーストクラスの関数がなかったら？
155:デフォルトの名無しさん
11/11/01 23:53:30.12 .net
>>153
だから、それは静的型検査という意味じゃないのか？
>>154
無名クラスがあれば代用可能
無名クラスも無い？あきらめろ
156:デフォルトの名無しさん
11/11/02 00:43:25.84 .net
このように、言語によって
クラスが必要かどうかは違ってくるというのに、
設計書と呼ばれるものに、そこまでちゃんとクラスを書いているのか？
普通は書かないだろ。
だから、設計書と呼ばれているものは、実は設計書ではない。
コードこそが設計書そのものなんだ。
157:デフォルトの名無しさん
11/11/02 07:35:25.31 .net
>>156
>だから、設計書と呼ばれているものは、実は設計書ではない。
>コードこそが設計書そのものなんだ。
そりゃ違うだろ
設計書と呼ばれてるものも設計書
ただ、粒度が異なるだけ
158:デフォルトの名無しさん
11/11/02 21:53:07.67 .net
ただなぁ， 世に存在するうちの設計書で,
なぜこれが必要か
といった， 設計ポリシーとともに書かれているものは， ごく稀
で， 最後には
ソース読め
状態になると思ってるんだ
159:デフォルトの名無しさん
11/11/03 01:04:35.79 .net
仕様書は役に立たないがテストの手順書はとても役に立つな
なにをやるための機能なのか一発でわかる
対して仕様書は嘘、間違い、抜け、バージョン違い、勘違い
更新忘れ、認識間違いばっかりになってほとんど役に立たない
仕様書いらなくね？
っていうかテスト手順書でよくね？
ちなみにおそらくテスト手順書は仕様書を見て作られてはいないだろうな
やってみて「ふーん・・・これだろ？これが仕様だろ？な？」的な感じだと思う
160:デフォルトの名無しさん
11/11/03 11:16:22.26 .net
仕様書とソース・プログラムの挙動が不一致ならバグ認定、即修正
っていうレベルのもの以外は仕様書に書くな！！！！
161:デフォルトの名無しさん
11/11/03 19:08:42.55 .net
>>160
ショートカットとか本当にどうでもいいもののリスト作ってるひまあったら他のことやれよな
162:デフォルトの名無しさん
11/11/04 00:04:28.66 .net
>>134
> ゴミコード量産の現場でリファクタリングしようなんて、俺だって思わないな
なんかすごくよくわかる。発注しまくりでゴミコード量産しまくりで身動きが取れないわ
163:デフォルトの名無しさん
11/11/04 20:57:42.11 .net
うちのプロジェクトjavaソースだけでついに1万個を超えた
リファクタとかいうレベルじゃねーだろ
164:デフォルトの名無しさん
11/11/04 22:40:52.09 .net
>>163
すごいな
まんこの部分だけ強調して三回ぐらいは口にしたいよね
165:デフォルトの名無しさん
11/11/06 10:59:30.75 .net
javaでもすでに10年物のソースコードとかあるからな
166:uy
11/11/06 16:44:42.65 .net
リファクタリングとか、
１０万行のソースコードがあったとして、
その１０万行のソースコードを、読んだってレベルじゃなくて、そうとう熟知した状態で
１人で行わなきゃならない
ていうか、それできるレベルなら、多分最初から書き直したほうが綺麗に書ける
まぁそれは理想で
ＳＥ共のいってるりファクタリングは機能ごとに、ちょこっとずつ最適化していく程度のものを言ってるよね
自分の能力でソースコード全体を見渡せる範囲で何とかするリファクタリング
なんていうか、それはね
まず木で作られた線路を、途中から鉄にして、さらに途中から銅にしたようなもので、本当に器用に継ぎ接ぎをしてるだけ
その継ぎ接ぎ部分はとてもシビアになるし、バグが出ても特定不可能で、
「よくわかんないけど、○○にすると落ちるから☆☆にしといてｗｗｗｗｗｗｗｗｗｗｗｗｗっうぇｗｗｗｗなんで落ちてんのｗｗｗっうぇｗｗｗｗ」みたいな状況にもなりかねない
ソース全体を見渡しているわけでもないリファクタリング作業なんてのは、あまりやりすぎると
ゼロから書き直す以上の労力をいつの間にか注いでいる事にもなりかねないので
最低限以上はやっちゃいけない
167:デフォルトの名無しさん
11/11/06 16:52:16.13 .net
>>166
お前は、ただのコード修正をリファクタリングと言ってるだけだね。
リファクタリングは単なる「コード修正」とは違うもの。
リファクタリングは「既存の動きに影響を与えない方法を使ってコードを修正すること」
既存の動きに影響を与えない方法ってのがあるんだよ。
これを使わないとリファクタリングにはならない。
行き当たりばったりの思いつき修正とはわけが違う。
論理的に考えぬかれた体系化されたテクニック。
それカタログ化して解説した本が、世の中にでてるリファクタリング本
168:デフォルトの名無しさん
11/11/06 17:24:22.30 .net
＞リファクタリングとか、
＞１０万行のソースコードがあったとして、
＞その１０万行のソースコードを、読んだってレベルじゃなくて、そうとう熟知した状態で
＞１人で行わなきゃならない
＞ていうか、それできるレベルなら、多分最初から書き直したほうが綺麗に書ける
とてもじゃないが、まともに教育を受けた人間の書いた日本語には見えない。
169:デフォルトの名無しさん
11/11/06 21:45:33.79 .net
> 「既存の動きに影響を与えない方法を使ってコードを修正すること」
ここで仕様をリファクターする必要を考慮しないのがリファクタリング厨
170:デフォルトの名無しさん
11/11/06 22:13:45.01 .net
>>169
リファクタリングは仕様を変えないのが原則です。
仕様を変えたほうがいいこともあるが、
それは修正であってリファクタリングではありません。
あたまがわるーい。
171:デフォルトの名無しさん
11/11/06 22:17:40.89 .net
ユーザーインターフェースかわんなきゃリファクタリングと言ってみるtest
172:デフォルトの名無しさん
11/11/06 23:12:56.73 .net
>>170
ちゃんと読め。
173:デフォルトの名無しさん
11/11/07 02:11:07.98 .net
> 仕様をリファクター
はぁ？
んなもんリファクタリングじゃあなーいと言ってやれ。ドキュメントをリファクタリングしちゃるとか言ってる奴、それもリファクタリングじゃねーぞコラ。そういうのは、リストラクチャリング（再構築）というのだッ。
174:デフォルトの名無しさん
11/11/07 06:29:39.93 .net
仕様変更にまで手をいれない修正だったら俺はする意味ないと思うけどね
いいと思ってるのは自分だけっていう典型だと思う
175:デフォルトの名無しさん
11/11/07 22:24:06.07 .net
試験とか全部やり直しになるけどそこまでコードに重心置けないです
しかも動作は変わらないとかね
176:デフォルトの名無しさん
11/11/07 22:56:57.01 .net
>>174-175
あんたたちに言いたいことは、全て本の最初に、
それは違うよって書いてあります。
つまり、そのレスはFAQで答えがバッチリ出てるので、
今更議論するような話ではないです。
177:デフォルトの名無しさん
11/11/08 00:14:11.06 .net
>>176
とかいって逃げたいから自分の言葉で説明しないで本に書いてあるとか言ってるんでしょ？
わかるよ
説明できない人ってみんなそうだもの
あんたもいっしょ
残念だけどここ本質なのよね
そもそもリファクタリングっていう行動自体意味がわからない
将来どう変わるか？の仕様もないのに汎用性？
何に対していってるの？あれほど仕様書に重点をおいてるのに
なんでコードレベルでソフトウェアの方向性がわかるの？
それと何度もいうけど全体の工数からいったら実装なんてすげー短い期間なのに
リファクタリングなんてしなくていいんだよ
馬鹿かよ
設計や仕様決めに時間割いたほうがいいの、わかった？御馬鹿ちゃん？
人件費みたって派遣ＰＧと正社員様様と比べて比較になるわけねーだろ
そんな糞みたいな脳みそしかないんだったら技術者なんてやめちゃえばいいのに
178:デフォルトの名無しさん
11/11/08 01:14:10.32 .net
>>177
コンプレックス刺激されすぎｗ
179:デフォルトの名無しさん
11/11/08 01:17:58.36 .net
単純なシチュエーションだと、今動いているものがあって
それに仕様変更や機能追加をする"前"にリファクタリングしたり
えーちょっと何やってんのか分からなぁ～いって時に、リファクタリングして今の動きを確認したりする鴨
さすがに何も用事が無いのにリファクタリングはしないぞw
180:デフォルトの名無しさん
11/11/08 06:35:51.23 .net
>>179
ローカルのＨＤＤの中で勝手にやってろレベルだなｗ
181:デフォルトの名無しさん
11/11/08 08:17:23.29 .net
>>177
どうしたの？
したくないならしなくていいんだよ？
別にお前のコードのことなんて知らないし
182:デフォルトの名無しさん
11/11/08 12:07:50.87 .net
仕様書を大雑把に
・機能仕様書：ユーザの観点からシステムがどのように動くか記述する
・技術仕様書：プログラムの内部実装について記述する
に分けたとき、機能仕様書を変更しないのがリファクタリング
技術仕様書は変更する必要がある
と、俺は解釈してるんだけど
183:デフォルトの名無しさん
11/11/08 22:53:38.54 .net
>>182
そんな金になんない仕事やったらダメだよ
仕様どおりには動いているんだ
よほど現実からかけ離れた組み方でない限りはそんなところにお金を入れてはダメだ
184:デフォルトの名無しさん
11/11/09 00:34:09.76 .net
リファクタリングの価値は
リファクタリングしたことによる将来のメンテナンスコストの低減分だと思うから、
純粋なリファクタリングをする意味ってあると思うけどね。
まあ、少なくとも、作ったコードを客に出すのが仕事の人は、
リファクタリングの価値を見出すのは難しいだろうね。
お客が腐ったコードをメンテナンスし続ける費用を負担してくれる限り、
工数がかかる方が、お金になるだろうから。
185:デフォルトの名無しさん
11/11/09 01:07:17.87 .net
寧ろそうやって放置されたコードのメンテナンスの際にESP能力を発揮しながらリファクタリングして日銭稼いでますが何か。
186:デフォルトの名無しさん
11/11/09 22:25:08.24 .net
>>184
でもドングリの背比べじゃない？
仕様にまで踏み込めないレベルの修正でなんか変わるの？
同じ人、もしくは似たようなレベルの人がやんでしょ？
187:デフォルトの名無しさん
11/11/09 23:19:04.89 .net
>>186
同じようなレベルの人がやったら対して変わらんだろうね。
時間がなくて小手先で直したのを時間が取れる時にまともに直すとかかしら。
あほなプログラマが書いた動くけどわけわらんプログラムを
レビューで突き返したりするのもリファクタリングになると思うけど、放置するの？
188:デフォルトの名無しさん
11/11/10 00:11:30.20 .net
>>187
でも設計レベルではなにも変わらないんしょ？
アホだろうがどうだろうが違いがでるレベルにならんのとちゃうか？
189:デフォルトの名無しさん
11/11/10 02:48:37.98 .net
>>186
> 仕様にまで踏み込めないレベルの修正でなんか変わるの？
お前コード書いたことないだろ？
190:デフォルトの名無しさん
11/11/10 02:49:24.36 .net
>>188
お前の言う「設計レベル」ってどういうことだ？
コードには設計があるのは知ってるよな？
それは機能のことじゃないぞ。
191:デフォルトの名無しさん
11/11/10 06:19:17.82 .net
>>189
あるけど
そこでそんなに違いが出るとは思えないんだよね
大手もそう考えるから（いや実際そうなんだろう）ＰＧは派遣ばかりなわけだしね
192:デフォルトの名無しさん
11/11/10 22:10:19.47 .net
URLﾘﾝｸ(www.os.cis.iwate-u.ac.jp)
2.1 リファクタリングの歴史
リファクタリングの先駆け：1980年代以降Smalltalkの仕事をしていたWard CunninghamとKent Beckの2人
Smalltalkはリファクタリングに特に向いている環境
コンパイル、リンク、実行のサイクルが短く、コードを気軽に書き換えることができる
彼ら2人の考えはSmalltalk文化にリファクタリングの概念を定着させた
筆者「リファクタリング？そこまで重要ではないよ」→Kentと同じプロジェクトに携わり、
Kentのリファクタリングを目の当たりにする→ソフトウェアの生産性、品質に明らかな違いが…→筆者「！！」
上の経験からリファクタリングを重要視するようになった
193:デフォルトの名無しさん
11/11/10 23:19:30.99 .net
>>192
そのストーリーって重要な部分なの？ｗ
しかもそんな馬鹿みたいな長文書いて大事な要点がちっとも書いてないじゃん
>ソフトウェアの生産性、品質に明らかな違いが…
明らかに大事なのってこの部分の詳細だろ
何がよくて品質がどうよくなったのか？
だろ？
お前の国語の能力低すぎてリファクタリングまで怪しくなるわｗ
194:デフォルトの名無しさん
11/11/11 21:19:14.97 .net
>>193
そういう文句はオリジナルを書いた奴に言え。
195:デフォルトの名無しさん
11/11/11 23:32:49.89 .net
自分の言葉で語れない奴はカス
196:デフォルトの名無しさん
11/11/11 23:58:46.50 .net
お前のセリフに説得力はない
197:デフォルトの名無しさん
11/11/12 01:34:54.40 .net
>>191
違いを理解できない能力なだけじゃないの？
198:デフォルトの名無しさん
11/11/16 20:57:29.42 .net
重複の除去が有効とか書いてあるじゃん
前にやった仕事で、ほんの一部を除いて同一の機能を持つモジュール２つが
別々の人によってそれぞれ実装されてて
目玉飛び出そうになったのを思い出した
199:デフォルトの名無しさん
11/11/16 21:30:50.10 .net
別にいいじゃん
その２つをくっつけることで後に呼び出し先Ａの機能を修正したいだけなのに
その機能がわざわざまとめられてるために
もう一つの呼び出し先Ｂのソースまで洗わないといけなくなるかもしんないだろ
まとめるのは必ずしも正解ではない
200:デフォルトの名無しさん
11/11/16 22:33:28.29 .net
>>199
必ずしも正解ではないのは正しいけど
同じような修正が必要になったときに片方の修正が忘れられることの方が多いと思われ
共通で使われてるメソッドの参照元を調べることより
クラスもメソッドも違うけど実は中身が同じでなければならなかったのを探すほうが大変な気が
分ける理由がないうちは一緒にしといて
必要になったら分ける方のが正しいと思う
201:デフォルトの名無しさん
11/11/17 01:17:42.75 .net
ちなみに >>198 は
その両方を移植する仕事だった
「工数儲けた」と思ってたら
両者をソース読んで同一機能であることを確認した上で
一つにすりあわせて、その承認もらう羽目になったとさ
当然まともな設計書なんてありゃしないし
202:デフォルトの名無しさん
11/11/17 22:48:38.78 .net
>>200
いや、お前の言ってることはGoogleやAppleでは正しいだろうな
だが、日本の工業製品ではＮＧ
もちろんいいたいことはわかるけど
それじゃ見積もりがとれないこの１点でＮＧ
色々な大手でたくさんのプロジェクトが走っていて
共通ライブラリなんて生まれないっつか生まれても消滅してしまう理由はここにある
修正の影響範囲が巨大すぎて見積もれない
また、修正時に全員が同じタイミングで対応できない
これも大きな問題だ
こっち動かなくなるのに「直したよ～」とかメールくれられても困るだろ？
そっちに手がまわらないのにリリース前に真ライブラリでバグってリリース失敗であぼんとか話にならない
修正した本人は「いいんですーこれが本来あるべき姿なんです～」って主張しようと
修正するほうは「糞が・・・」って思うっしょ？
まあ、ＭＳの出荷するもんにみんなが愚痴をこぼす瞬間だと思うけど
203:デフォルトの名無しさん
11/11/17 22:50:23.01 .net
>>202
で、その壁を超えられる所が勝ち組で
超えられないところはどんどんブラック会社化するわけだ。
仕事、つまらないだろう？ｗ
204:デフォルトの名無しさん
11/11/17 22:55:03.81 .net
>>203
でもいくらもないっしょ？
日本のＩＴって進化に失敗してて紙業務を電子化したような仕事のほうが多いよね？
韓国にもすっかり抜かれちゃったみたいで国内全員でｼｮﾎﾞｰﾝって感じじゃない？
研究開発分野と本当に極一部だけだろうね
まあ、いまそういう開発してても日本じゃいつ紙業務の電子化ＩＴにまわされるかわからないから
勝ち組って意味でいうと海外脱出組が勝ち組だろうね
205:デフォルトの名無しさん
11/11/17 22:58:57.20 .net
>>204
ごめんな。
うち自社で作ったウェブサービス提供する会社なんだわ
HTML5系とかそっち系。
選ぶ会社の時点で勝ち負けが決まるよね。
仕事、つまらないだろう？ｗ
206:デフォルトの名無しさん
11/11/17 23:01:51.10 .net
うちは少数精鋭なんで（使えない奴はやめさせられる）
同じコードをいくつも書くとかそんな無駄なことやってられないんだよね。
テストも人海戦術で同じことを何度もやるとか、時間的に無理だし、
もちろん手動テストは極力減らすので、変更したって
影響があるならすぐ分かる。
207:デフォルトの名無しさん
11/11/17 23:02:59.45 .net
>>205
ウェブ系なんて工業製品とかわんねーけどな
あんなん汎用性見越して組む必要あるかね？
寿命が短いからどう組んでもどうとでも動くが正解だろ？
納期まで早い方が真
お前の世界こそプログラムを綺麗にまとめて褒める奴１人もいないと思うがな
208:デフォルトの名無しさん
11/11/17 23:38:17.66 .net
>>207
汎用性見越して組むとか言ってないんだが。
無駄にある重複コードをまとめると言ってるだけ。
209:デフォルトの名無しさん
11/11/17 23:39:39.61 .net
重複コードを作ると、納期が延びます。
修正があると、重複コードの分
修正量が増えます。
少しの修正であっちこっち修正して、
あっちこっちテストして納期伸ばしてるのは誰ですか？ｗ
210:デフォルトの名無しさん
11/11/18 00:57:17.23 .net
>>209
それって何箇所？
１０箇所？２０箇所？程度なら貼ったほうが速いよね？
思いっきりまとめあげられてて難しい仕組みに頭ひねってソース解読しなきゃいけないぐらいだったら
単純コピーで貼ってあってくれたほうがまだソース読みやすいよね
っていうか件数が１００件いかない程度のコピペならお前が便所に席を立った間にやっておいてやるよ
この程度の件数だったらどう組んでも変わらない
211:デフォルトの名無しさん
11/11/18 01:28:11.79 .net
>>210
お前適性ないんじゃね？
ぶっちゃけ、仕事楽しくないでしょ？
212:デフォルトの名無しさん
11/11/18 01:48:53.37 .net
自分でやるんじゃなくて他人にやらせるんだろ
213:デフォルトの名無しさん
11/11/18 06:57:57.33 .net
>>211
いや、楽しいよ
お前みたいな対象物のメリットとデメリットも判断できんようなの出し抜いて数字上げるのが何よりの快感だわ(笑)
結局、技術の上部だけしかすくえないひとって何も見えてないんだよね
新しいってだけである意味パニック状態になってる自分がなにより見えてない
214:デフォルトの名無しさん
11/11/18 07:32:36.75 .net
数字を出しさえすればそれが全てだと思い込んでいることはよく判った。
さぞかし楽しい人生だろうねぇ。
215:デフォルトの名無しさん
11/11/18 11:48:05.79 .net
>>213
お前性格屈折してるな
そうとういじめられたな
216:デフォルトの名無しさん
11/11/18 12:54:07.46 .net
>>210
> 思いっきりまとめあげられてて難しい仕組みに頭ひねってソース解読しなきゃいけないぐらいだったら
> 単純コピーで貼ってあってくれたほうがまだソース読みやすいよね
申し訳ありません
ifとforしか理解できない人もいるということを忘れていました
リファクタリングの過程でデザインパターンを適用してしまったことをお許しください
217:デフォルトの名無しさん
11/11/18 12:59:02.53 .net
>>213
コピペもできるしリファクタリングもできる俺がそれを言うならまだわかるけど、
お前はコピペしかできないんだからさ、取捨選択の上でコピペを採用したみたいな言い方はやめてよ
もっともらしい後付けをしたところで、お前のカードはコピペしかないわけで
218:デフォルトの名無しさん
11/11/18 12:59:57.09 .net
>>216
forすら理解してないかもよ
100回ループ廻すくらいならコピペするって言い出しかねん
219:デフォルトの名無しさん
11/11/18 15:50:01.61 .net
正面から反論できないときは人格攻撃になるんですね
その時点で白旗あげてるっていうかなんていうか
220:デフォルトの名無しさん
11/11/18 19:16:21.49 .net
>>219
だってー
低レベルな人を教育してあげる気なんて毛頭ないですしー
221:デフォルトの名無しさん
11/11/18 23:06:02.19 .net
>>220
でも自分のやってることの説明できないってのは問題じゃない？
結局トレードオフの問題であって
やればやるほどとかどんな場面でもってわけじゃないってとこは否定できないわけでしょ
じゃあ、君のやり方は正しいの？また、他の人と差がでるのは何が決め手なの？
ってのは結局のところどこでも求められると思うんだけどね
それが説明できないなら君に用のある人なんていないと思うんだよね
みんな暇じゃないから(笑)
222:デフォルトの名無しさん
11/11/19 16:25:48.92 .net
へえ
223:デフォルトの名無しさん
11/11/19 16:38:24.26 .net
トレードオフ考えてやるんだから
やっぱりリファクタリングは必要ってことね
リファクタリング全否定って人はいるのかしら
224:デフォルトの名無しさん
11/11/19 17:14:49.53 .net
トレードオフはコードをまとめる話だろ？
リファクタリングはまったく必要ないよ
そもそも意味わからないもん
次の仕様が決まってる中でのコード修正ならわかるけど
次になんの予定もないのに何に向けてどう修正してるのかまったく理解できない
その修正はいいの？悪いの？
オナニーで終わってない？
これらを判断できる材料すらわからない
単に金をドブに捨ててるだけだと思う
225:デフォルトの名無しさん
11/11/19 17:30:26.36 .net
汚いコード
ゴミ溜めが如くきったない部屋で過ごしてもなーんにも問題無い
↑
↓
チリ一つも落ちていないようなクリーンルームじゃないと過ごせない
綺麗なコード
って話だろ？ 何事もほどほどにしとけって事だよ
226:デフォルトの名無しさん
11/11/19 17:33:20.81 .net
>>225
人の話を良く聞かないで進めちゃって失敗するほうじゃない？
227:デフォルトの名無しさん
11/11/19 18:59:16.42 .net
>>224
キミがそのコードをずっとメンテナンスする責任者だとして、
どこかのプログラマが明らかにまとめるべきところまとめてこなかったり、
分けるべきところをを無理やりまとめてきたりした場合、
正しく動くという理由でそのままにしておくのかい？
228:デフォルトの名無しさん
11/11/19 19:28:32.54 .net
>>227
作るときに設計書にあわせてもらいます
ソースだけ弄るってことはしません
229:デフォルトの名無しさん
11/11/19 19:33:14.80 .net
ソース＝設計書だろ?
230:デフォルトの名無しさん
11/11/19 19:47:12.13 .net
>>229
底辺乙
231:デフォルトの名無しさん
11/11/19 19:51:09.79 .net
>>228
要するに仕様は変えずに設計を変えるんだろ
リファクタリングじゃないか
232:デフォルトの名無しさん
11/11/19 20:14:22.32 .net
最高 綺麗で動く
↑ 汚いが動く
↓ 綺麗で動かない
最低 汚くて動かない
一番下のは捨ててよし
[動く／動かない] と [綺麗／汚い] の相関関係だお
汚いけど動くのは、綺麗だが動かないものより価値がある。
でも綺麗で動かないのを 動く にしやすいし、
汚いけど動くものも、後で何か変更するにあたって、動くのを保ちつつ綺麗にしておくと直しやすい。
「綺麗にする」のがリファクタリング。動かないものを動くようにすることとはイコールではない。関係はあるけど。
233:デフォルトの名無しさん
11/11/19 20:27:15.16 .net
>>232 使用がバッチィからコードもバッチイって発想はないのか？
234:232
11/11/19 20:45:33.70 .net
仕様が汚いと動かすのが難しい
↑
↓
綺麗な仕様は動かしやすい
って関係はあると思うけど、コードと仕様は直接関係しないんじゃねの？
235:デフォルトの名無しさん
11/11/19 20:55:13.83 .net
>>234
汚い仕様を何とか動かすために、 汚い姑息なコードを大量に入れてる
例なら山ほどあるよ
236:デフォルトの名無しさん
11/11/19 21:31:39.15 .net
コードを綺麗/汚いで語るから話がおかしくなるんじゃないか。
リファクタリングって大なり小なり設計の問題の修正のことだと思うんだが。
オレがずれてるのか。
237:デフォルトの名無しさん
11/11/19 21:34:18.54 .net
>>236
おれもそう思うよ. 仕様も設計の内だとも思うけど...
238:デフォルトの名無しさん
11/11/19 21:49:35.63 .net
もちろん設計の問題とコードの綺麗/汚いは関係ありますが？
最初にきちんと設計をしたつもりでも、実装段階では想定したとおりに行かなかったり、抜けがあったりすることはよくあることです。
実際に書いているうちにいろいろ思いつくこともあります。ちょこっと例外的な処理を付け加えて、を繰り返し、コードは汚くなっていきます。
そうしてソースがスパゲッティ化し、メンテ不能のソースとなっていきます。
そうならないようにするためにリファクタリングがあります。
リファクタリングとは、仕様を変えることなく、ソースコードを改造することをいいます。
汚いソースコードでもプログラムは動きますが、メンテナンスするのは大変です。
汚いソースコードと綺麗なソースコードではメンテのしやすさが全く違います。
なのできるだけ綺麗なソースを書くように心がけ、汚くなったら速やかに書き直すことです。
後々のことを考えて、わかりやすいソースに直します。
239:デフォルトの名無しさん
11/11/19 22:15:38.43 .net
>>238
> そうならないようにするためにリファクタリングがあります。
そうならないように設計を見直す方が先じゃないか?
小手先でどれだけいじっても, 汚い設計は汚いソースを
再生産するだけじゃないのか?
それだったら, 設計をリファクターすべきだ
ぶっちゃけ, ユーザーインターフェースが変わらなきゃ
仕様の範囲内だ
240:デフォルトの名無しさん
11/11/19 23:03:54.10 .net
>>238
コピペはいらんよ。
汚い綺麗で語るとコードの可読性ばかりを問題にしてるように感じるって話。
だからリファクタリングがいらないとか言う奴がいるんじゃないの。
コードが綺麗であっても設計上の問題が存在することは当然あるよね。
コードの綺麗/汚いは設計の一部しか示していないと思うし、
その修正はリファクタリングの一部でしかないと思う。
241:デフォルトの名無しさん
11/11/20 07:43:51.29 .net
>>240
したらただの仕様変更だよねそれって
まあ、名称にこだわる必要もないけど
242:デフォルトの名無しさん
11/11/20 08:21:15.92 .net
関数、クラスの仕様は変わっても
システム全体の仕様は変わりません。
なので仕様変更にはあたりません。
243:デフォルトの名無しさん
11/11/20 08:21:59.02 .net
設計変更と仕様変更は別の話といえばよかったか。
244:デフォルトの名無しさん
11/11/20 12:07:12.15 .net
設計を仕様と見なしたら
仕様変更を伴わないコード変更って存在するのか？
245:デフォルトの名無しさん
11/11/20 12:08:20.66 .net
aとかbとかわけのわからん変数名を
意味がある変数名に変更するとか。
246:デフォルトの名無しさん
11/11/20 13:09:50.85 .net
I/F変更を伴うかどうかっていう観点じゃないの
ユーザに見える部分とか
担当者の異なるモジュール間とか
247:デフォルトの名無しさん
11/11/20 17:10:54.61 .net
オリンパスコーディング
248:デフォルトの名無しさん
11/11/20 17:46:34.19 .net
結局、
外から見た目の振る舞いが変わるか/変わらないかがポイントで、
外から見た目の振る舞い＝仕様であって
内部構造≒設計は、リファクタリングの対象
って事でおｋ？
249:デフォルトの名無しさん
11/11/20 18:02:36.08 .net
>>248
個人的にはソレが正しいと思うけど
そう思ってない人がいる予感。
241とか
250:デフォルトの名無しさん
11/11/20 18:50:26.97 .net
>>249
じゃあ、リファクタリングってのは設計変更までを指すってことでいい？
何やんだかさっぱりわからないけど
251:デフォルトの名無しさん
11/11/20 18:53:49.64 .net
>>250
設計の範囲を定義しろ。
話はそれからだ。
252:デフォルトの名無しさん
11/11/20 21:17:25.23 .net
>>251
そっちにまかせる
>>248がえらそうに宣言してるから>>248に決めてもらうか
253:デフォルトの名無しさん
11/11/21 09:59:01.46 .net
(この人たち、なんで今さらこんな議論をしてるんだろう)
254:デフォルトの名無しさん
11/11/21 22:35:10.04 .net
最初からずっとこのスレにいるのは
お前だけだよｗ
255:デフォルトの名無しさん
11/11/22 10:39:05.00 .net
そうか、リファクタリング本を読んでるのは俺だけだったか
256:デフォルトの名無しさん
11/11/23 00:32:21.88 .net
>>255
本の受け売りじゃなくて中身をちゃんと理解しろよ
257:デフォルトの名無しさん
11/11/23 01:19:14.75 .net
そういう手合いはおそらくよんですらいない
買っただけ
258:デフォルトの名無しさん
12/02/07 13:45:03.37 .net
改修が必要になったときに初めて
その場で interface をでっちあげて、その後、クラスお取替え
これでいい気がしてきた
259:デフォルトの名無しさん
12/02/07 20:02:48.59 .net
それでいい
260:デフォルトの名無しさん
12/03/24 14:35:39.62 .net
リファクタリングを身に付けるとコードレベルでの設計力が上がりますか？
261:デフォルトの名無しさん
12/03/24 16:05:22.68 .net
設計力は下がります
でも組んだ後の問題に対する対応力は上がります
262:デフォルトの名無しさん
12/03/24 17:35:34.20 .net
>>261
何故、設計力は下がるのですか？
263:デフォルトの名無しさん
12/03/24 21:11:33.51 .net
設計力あがるだろ
正しい設計のコードに
変化させるのがリファクタリングだ。
264:デフォルトの名無しさん
12/03/24 21:36:47.86 .net
>>49-52で結論は出てる
リファクタリングはオナニー
好きにやればいい
公開オナニー好きでも床オナ好きでもその方法を誰も咎めることはできない
265:デフォルトの名無しさん
12/03/24 21:51:30.52 .net
オナニー？ 自己満足と言いたいのかもしれないが。
仕事でやるのなら自己満足じゃないぞ。
みんなの満足。
266:デフォルトの名無しさん
12/03/24 22:21:58.07 .net
みんなでオナニー
267:デフォルトの名無しさん
12/03/25 12:10:02.63 .net
分散マスタベーション
268:デフォルトの名無しさん
12/04/22 22:43:46.10 .net
密に結合した処理を処理を疎になるようにするとか
処理が対象になるようにシーケンス直すとか
って意味があるリファクタリングだと思うけど
こういうのはリファクタリングっていわんの？
269:デフォルトの名無しさん
12/08/05 00:31:39.26 .net
>クラス内部で別のクラスを生成しない
>>4のこの話って完全にはDIでも使わなきゃ無理だけど、
FactoryMethodで解決できるよね。
>publicメソッドの引数には、なるべくクラスを使わない。
完全抽象化クラスに類するもの限定ってなら正しいけど、
intや文字列型だけってのは無いよね。スタブ渡せば済む話だし。
270:デフォルトの名無しさん
12/08/05 01:11:40.91 .net
言葉の揚げ足取りに終始しててウザいだけのスレになっちゃってるなｗ
271:デフォルトの名無しさん
12/10/14 16:17:10.72 .net
大規模アプリには
必ずリファクタリングが必要。
開発工程の一つに加えていいレベル。
272:デフォルトの名無しさん
12/10/15 15:52:21.57 .net
VB6で幾度となく機能追加が行われたコードをぼんやり眺めてると
リファクタリング？何それおいしいの？
という気分になってくる。
273:デフォルトの名無しさん
12/10/16 18:14:20.05 .net
>>272
そういうコードこそ、リファクタリングが楽しいんじゃないの？
274:272
12/10/16 18:35:14.51 .net
趣味でやるならすごく楽しい。一人でやるのなら絶対リファクタリングしてる。
けど仕事となると時間が取れない。
さらなる機能追加と他言語への移植作業用のドキュメントが優先になってまつorz
移植作業前にリファクタリングできたら解読も楽だろうになあ。
そんなことより成果物（ドキュメント）が優先だってさ。しゃーねーや。
275: 忍法帖【Lv=40,xxxPT】(0+0：5)
13/07/11 NY:AN:NY.AN .net
refakuta
276:デフォルトの名無しさん
13/07/11 NY:AN:NY.AN .net
リファク太
277: ◆unko./w.Osri
14/01/10 07:46:54.18 .net
リファクトスタンダード
278:デフォルトの名無しさん
14/01/21 23:03:30.89 .net
リファクタリング本はかなり勉強になったな。
ぐちゃぐちゃなコードしか書けなかったのが、リファクタリングしまくってたら
最初からオブジェクト指向やらデザインパターンやらを考慮したコードが書けるようになってた。
279:デフォルトの名無しさん
14/07/25 07:34:43.94 FDyePLlK.net
好きにすれば？どうせ個人でやってんだろ
一人ならほんと楽しいよねリファクタ。
業務でリファクタなんかできねーよ
リリースしてから何年も動いてるパッケージに手入れられるわけないだろ！
280:デフォルトの名無しさん
14/07/25 10:51:25.65 nHudeAGx.net
業務でリファクタリングの時は、バグの種類にもよるけど基本的にはそのまま。
勿論、リファクタリング後に修正することを見越してリファクタリングすることになる。
実は、バグを見つける為にリファクタリングすることもあるので、「できねーよ」で済まない場合もあるのよ。
281:デフォルトの名無しさん
14/07/25 11:26:11.42 PjU5XzSY.net
バグを見つけるためにリファクタリングをすることはあるが
改修はリファクタリング前のコードに対して行うことになるなぁ
282:デフォルトの名無しさん
14/07/25 12:21:15.76 CQdwbNpj.net
リファクタリングとは
テストの合格を維持したままの
コードの修正でしょ
283:デフォルトの名無しさん
14/07/25 12:41:48.16 mmV7Js8i.net
上を納得というか安心させるための無駄検証にコストを掛けた後だと
いじくれないというのはわかる
だがサブシステムを小分けして
その範囲内で裁量をもたせられるようにしてないのはアカン
284:デフォルトの名無しさん
14/07/25 13:58:36.59 fPj1ZcPi.net
>>281
> 改修はリファクタリング前のコードに対して行うことになるなぁ
それって人件費を無駄に捨ててるじゃないか？
会社に損害与えてるよ。
プロ意識無いのかね？
285:デフォルトの名無しさん
14/07/25 20:12:11.75 zPq/iOJh.net
リファクタリングしたがる人とは仕事したくないよね
286:デフォルトの名無しさん
14/07/25 20:12:41.10 Fz0v1PBn.net
でも実は一発目無計画で作ってリファクタリングするのが一番品質がいい
287:デフォルトの名無しさん
14/07/25 21:18:52.98 JraUdqnP.net
一発目無計画っていうのがありえなさすぎ。
趣味のプログラミングだろそれは。
288:デフォルトの名無しさん
14/07/25 22:15:52.25 Xbv85is1.net
>>286
それは全然不思議じゃないね。
下書きだと思えばいい。
一発で書くよりも、下書きして全体を理解してから
清書する。
289:デフォルトの名無しさん
14/07/25 23:03:10.49 mmV7Js8i.net
神ならざる身で限界を知りつつも最善を目指す手法ではないか
290:デフォルトの名無しさん
14/07/25 23:24:21.34 oKdTZN9u.net
考え方の違いなんだよね。この業界に「ボーイスカウトの規則」っていう言葉があるらしい。
URLﾘﾝｸ(qiita.com)
> ボーイスカウトが、来る前よりも帰った後の方が山をきれいにしておくことにちなんだ規則。
> ソフトウェア開発においては「モジュールをチェックインする際には、必ずチェックアウト時よりも美しくする」ことを意味する。
リファクタリングしない人って、ただ動けばいい、コードが怖くて触れない。
他の部分はいじらないですませようとしちゃう。
修正しない部分なら見て見ぬふりもいいが、修正するなら、
そのまわりを綺麗にしろと。
それが出来ない人は、バグも多いんだよ。してシンプルにしてないから。
複雑なものはバグが多い。複雑だからコードを理解していない。
理解してないからバグが出る。当たり前の話。
291:デフォルトの名無しさん
14/07/25 23:31:13.15 zPq/iOJh.net
そういう自己満足だけの身勝手な修正が一番たちが悪いんだよ
292:デフォルトの名無しさん
14/07/25 23:33:03.76 oKdTZN9u.net
>>291
なんでですか？
まずきれいなコードのほうが、メンテナンス性が高くなり
バグが減り、開発コストも下がります。
ここは、否定しませんよね？
じゃあ、最終目標は「修正」するべきであってます。
あなたは、まったく筋違いの否定をしているのでは？
293:デフォルトの名無しさん
14/07/25 23:42:25.29 zPq/iOJh.net
>>292
そもそも前提が間違ってる。
きれいなコードって何だ？お前のオナニーだろ？
コード修正したいなら、きちんと設計のレビューを受けてチームの了承得てからにしろ。
294:デフォルトの名無しさん
14/07/26 00:11:53.24 NIQWGSzg.net
コードがスパゲティになってしまって、
簡単な機能追加ですら2週間もかかるようになってしまってた
（しかも、テストを繰り返しても正しさに自身が持てなかった）のが、
3週間ほど時間をかけてリファクタリングした結果
簡単な機能追加なら1時間もかからず行えるようになりました
295:デフォルトの名無しさん
14/07/26 01:29:58.80 b/ARCjIF.net
今どきスパゲティコードなど、そうそうお目にかかるもんじゃない
296:デフォルトの名無しさん
14/07/26 02:28:53.78 +7Kb6odc.net
リファクタリングするもしないも、そのソフトの特性や現場事情があんだから、
まずそういう情報がないとなんとも言えねーだろ。
共通して言えるのは独断で判断するなってことだよ。
297:デフォルトの名無しさん
14/07/26 08:38:26.34 NIQWGSzg.net
>>295
ちゃんとリファクタリングするようになったからね
298:デフォルトの名無しさん
14/07/26 09:05:17.83 EislOxX9.net
設計の手法が確立してきたからだろｗ
299:デフォルトの名無しさん
14/07/26 09:15:20.20 HnYXSVS2.net
リファクタリングする前のコードを保存しておいて
リファクタリングしてテストに合格したら
前のコードを消去すれば安全だよ
300:デフォルトの名無しさん
14/07/26 09:33:49.93 NIQWGSzg.net
>>299
マトモなバージョン管理システムとBTSは導入済み前提でしょうよ
でなきゃリファクタリングなんて無理
301:デフォルトの名無しさん
14/07/26 11:28:39.87 lCiymgo1.net
>>287
神が降りてきて、わぁぁぁぁぁってプログラム書く手が動くような事あるだろ？
302:デフォルトの名無しさん
14/07/26 11:34:58.07 EislOxX9.net
業務ではないなｗ
303:デフォルトの名無しさん
14/07/26 13:52:30.19 F6Vf17wA.net
最近ソフトウェアが壊れていくプロセスってのが
わかりだしてきたよ。
いくつかパターンがあってね、名前でもつけて
近いうちに何処かで発表したいかなって思ってる。
たとえばモノマネパターン。
周りにあるコードを真似て書こうとするパターン。
このような関数があったとする。
function foo(name) {
var funcTable = {
func1: functioni() {・・・},
func2: functioni() {・・・},
func3: functioni() {・・・},
};
funcTable[name]();
}
それを真似してこんなコードを書く
function bar() {
var name = 'func1';
var funcTable = {
func1: functioni() {・・・},
};
funcTable[name]();
}
もし0からコードを書かせたらこんなアホなコードを書くわけがないのに、
なぜか周りにあるコードを真似して書こうとする。
304:デフォルトの名無しさん
14/07/26 15:29:59.33 EislOxX9.net
クソコード書いて、次は誰かがもっといいコード書くだろうからそれマネしようとか思ってたら
俺のクソがプロジェクト中にコピペされて救いようがなくなってたことならある
305:デフォルトの名無しさん
14/07/26 23:32:58.38 F6Vf17wA.net
>>304
それそれ、誰もが知ってるコピペパターンｗ
できれば最初からクソコード書くなって話でもあるが、
それは仕方ない。誰でも成長するものなのだから＝後の自分はもっと綺麗に書ける。
なのに、昔の初心者のコードを真似る奴が多い多い。
それやってると、初心者のコードをありがたがって参考にしてどうするの？ｗ
話それたけど、本来はコピペするなら再利用できる形にリファクタリングして
それを呼び出さないといけない。そしてこれは絶対にやるべきリファクタリングの一つ。
ただし、無関係な処理なのに形が似ている（しかしわずかに違う）のを
無理やり共通化して複雑化させるパターンもあるので注意。
そういう場合でもコードはなるべくシンプルになるようにしなくちゃいけないのだが、
モノマネパターンの通り、なぜか同じ形を真似ようとする。
できないわけじゃないのに真似をする。何も考えてないのかねって思う。
306:デフォルトの名無しさん
14/07/27 02:21:16.13 xgsJlmZ9.net
仕様書が別になってたらどんなに処理が似てても別にするなあ
307:デフォルトの名無しさん
14/07/27 09:42:53.89 r3KMo0jq.net
似てる処理を共通化できないのは設計がきちんと出来てない証拠
仕樣的に別物とか関係ない
308:デフォルトの名無しさん
14/07/27 09:55:49.81 xgsJlmZ9.net
いやあるよ。
だいたい仕様変更が入ったときって、仕様書の画面毎とかだかし、
テストも仕様書毎につくるから、共通化してもテストの工数あんま減らんし。
修正になった仕様書の枚数と、手をいれる工数が一致してるとすごく客に説明しやすい。
>似てる処理を共通化できないのは
断じて違う。「似てる処理」を共通化するんじゃない。部品を共通化するんだ。
このへん誤解してなんど泣いたことか。
おまえのその考え方はスパゲッティまっしぐら。
309:デフォルトの名無しさん
14/07/27 09:59:56.78 EfhXqtXt.net
>>308
どんな考えでもいいけど何かしらの共通化がされてたら
> 修正になった仕様書の枚数と、手をいれる工数が一致
これは成立しないぞ
まず自分の矛盾に気付くのが先のようだ。
310:デフォルトの名無しさん
14/07/27 10:34:57.72 xgsJlmZ9.net
>>309
青いのう
部品を共通化するって考え方が徹底してれば、だいたいの場合は一致するもんだ。
もちろん客に説明するより少ない工数で済むならそれでいいよ？
問題は、「似てる処理」を共通化してると、工数が仕様書の改修量よりずっと膨らむことがあるってことなんだ。
ささいな修正が全体に影響してテストが膨らんだり、結局コピペで新たにクラス作らなくちゃいけなくなったりな
うん、これも共通化してるなら何でも同じとか言われそうだな
現実のブツ無しだと説明が難しいが…
311:デフォルトの名無しさん
14/07/27 10:58:40.58 EfhXqtXt.net
>>310
説明が難しいのはお前が「部品」とかいうオレオレ言語使って自己満足してるからだ。
ワケの分からん独自理論開発するまえに基本をしっかり勉強しろ。
312:デフォルトの名無しさん
14/07/27 11:02:04.82 M1h0x0Bb.net
>>310
甘いのう
残念ながら今時の設計者の中にはコードを全く書けないやつが少なからず居る
よって、共通化なんて幻想に過ぎぬわwww
313:デフォルトの名無しさん
14/07/27 11:19:32.95 aZ1TYiI9.net
func1(){
a b c d
}
↓
func0{
a b
}
func11(){
func0() c d
}
func12()
func0() e f
}
上のような共通化は似てる処理と部品どっちが主張しているんだ？
314:デフォルトの名無しさん
14/07/27 11:22:29.85 xgsJlmZ9.net
>>311
独自理論じゃないよ！みんなそう言ってるよ！
お前こそ本読んで知った気になってるだけだろ！頭でっかちめ
確かに、だいたい初心者向けの本には同じ処理を共通化すべしとか適当に書いてあるから、
実際の経験がないと理解しづらい部分ではある。
315:デフォルトの名無しさん
14/07/27 13:06:38.84 oB6jVO7Z.net
>>314
「部品」で意味してるのは何なんですか？
316:デフォルトの名無しさん
14/07/27 14:19:58.36 xgsJlmZ9.net
>>315
ごめん。一般的じゃなかった。
「機能」って読み替えて。
317:デフォルトの名無しさん
14/07/27 14:22:31.05 5m0dj4Xz.net
人間は細胞でできているだろ
プログラムも細胞で作れば上手くいく
俺の独自理論だけど
318:デフォルトの名無しさん
14/07/27 14:35:22.28 b6NTPR2W.net
うだうだ言わずに 60兆個の細胞を持ってこい
319:デフォルトの名無しさん
14/07/27 15:03:56.50 kK8gelhu.net
共通化するときの決まりの一つとして、
全く同じコードの時に共通化するのであって
似ているコードを共通化してはいけない。
似ているコードをむりゃリ共通化しようとすると、
引数で処理を分岐することになる。
aが渡されればAの処理を、
bが渡されればBの処理をみたいに。
引数で分岐しだすとアウトだな。
320:デフォルトの名無しさん
14/07/27 15:10:03.90 oB6jVO7Z.net
>>316
あーなるほど
わざわざありがとうございます
321:デフォルトの名無しさん
14/07/27 18:36:01.67 b6NTPR2W.net
経験的にforの内部、ifの内部は関数にまとめると都合よいことが多い
そして気が付くと xxhelper, xximpl, xxsub といった関数であふれるｗ
322:デフォルトの名無しさん
14/07/27 22:38:54.70 j6qWMrth.net
>>319
似ている理由を吟味するのがリファクタリングだろ。
似ている理由を吟味した結果、同じことをちょっと違った実装しているだけと気付けば問題なく共通化できる。
323:デフォルトの名無しさん
14/07/28 00:24:14.35 PUM3vemV.net
>>322
設計段階で、最初から同じものだと分かってるものでさえのちのち弊害出てくるのに。
後付けでコード眺めて似てるじゃんとか思っただけのもんがまともに共通化できるわけないだろうが
324:デフォルトの名無しさん
14/07/28 09:35:31.93 DND3Jclf.net
それを吟味するってことだろ。JK
325:デフォルトの名無しさん
14/07/28 19:34:15.48 dU5jf/g6.net
コードの字面で共通化とか言ってたらそら失敗するわ
326:デフォルトの名無しさん
14/07/28 22:31:59.96 ZMdkhV+Q.net
共有化するには物事を抽象化するセンスが問われるから、
低能が共有化しようとして失敗するのは良く分かるよ
それに、言語によってはクロージャやメタプログラミングが無かったり
有っても扱い難かったりして、実現可能な抽象化が限られるケースもある
327:デフォルトの名無しさん
14/07/28 23:39:29.31 PUM3vemV.net
クロージャｗメタプログラミングｗ
どんだけ狭い視点で話してんだよ
それかなにか、お前は世界中で使われるライブラリの設計者かなにかか？ｗ
お前のコードとか会社に出たら即ゴミ箱行きだよｗｗ
ただの帳票出力で得意げにtemplate使ってんじゃねえｗｗｗｗ後引き継ぐ奴の身になれ
死ね。くさかどああｋｊｓｄふぁｊ；ｆじゃ死ねええええ
328:デフォルトの名無しさん
14/07/29 00:32:02.60 A/TMSH0w.net
トラウマだったのね。
329:デフォルトの名無しさん
14/07/29 09:33:14.47 Rzs2MIMk.net
自分の経験上、>>327みたいにプログラミング言語の機能の話を
狭い視点とか言い出す奴って
コードをロクに書けないSEモドキに多くて、
そういう奴に限ってリファクタリングにも否定的なんだよね
コード読めないからリファクタリングの価値を実感出来ないのかな？
330:デフォルトの名無しさん
14/07/29 13:10:26.45 DxicYUyC.net
夏休みの学生が妄想で書き込むスレ
331:デフォルトの名無しさん
14/07/29 18:26:00.62 Wf2KiU9x.net
自分と同じドカタ仕事してる奴以外は
全て学生に見えてしまう様になったら病気です
332:デフォルトの名無しさん
14/07/29 20:26:27.73 vPKzHxKl.net
自分の経験上、リファクタリングしたがる奴は例外なく低スキル。
333:デフォルトの名無しさん
14/07/29 20:36:44.73 ahLU5tbJ.net
アホに効果を実感させるところまでが能力の内です
334:デフォルトの名無しさん
14/07/29 21:31:45.45 X6c6OHYr.net
アホSEがExcel仕様書の罫線を二重罫線に書き換えて
仕事したつもりになってるのに比べたら
比較にならないレベルの価値があるよ > リファクタリング
335:デフォルトの名無しさん
14/07/29 21:41:52.70 jt6qgrVo.net
２重罫線を大事にする客だって多いわ。
客はコードの中じゃなくて、資料とか見るんだわ。
リファクタリングなんかしたらね、
なんかちょっと挙動変わってるんだけど？
障害じゃないけど勝手に変えちゃ駄目でしょ。
うん？次からは言います？いや、そもそも動いてるもん変えなくていいよ
って話になる。
なんでもかんでもリファクタリングだのオブジェクト指向だの、
時と状況関係なしにやろうとするアホが多いんだよな。
336:デフォルトの名無しさん
14/07/29 22:05:08.74 Lzz8ZlFD.net
工数改善の見通しが数字で説明できるならともかく
実感とかで勝手にリファクタされたらたまらんわｗ
337:デフォルトの名無しさん
14/07/29 22:24:39.47 7mGq5kmY.net
受託開発やってるところと
自社サービスの開発やってるところは
何もかもが全然違うんだから、
分けて議論しないと平行線のまま
338:デフォルトの名無しさん
14/07/29 22:32:24.06 jt6qgrVo.net
SEがどーのこーの言ってるんだから受託だろ
339:デフォルトの名無しさん
14/07/29 22:51:00.80 X6c6OHYr.net
受託なんてドカタを人月で売って稼ぐビジネスモデルなんだから、
リファクタリングでコードを拡張しやすく保ち、
機能拡張を他社より速く行う事で競争優位に立つ
とか、そういうのは関係ないじゃん？
お前らマクドナルドのパートと大差無いんだから、
技術者の議論に入ってきちゃダメだよ
340:デフォルトの名無しさん
14/07/29 23:05:38.45 Lzz8ZlFD.net
>>339
ほー。
具体的にどういう課題があってどんなリファクタして、プロジェクトがどの程度成果上げたのか具体的に説明してみ？
壊れたレコードみたいに本で読んだこと繰り返して、しかも理解が浅くて現実が見えてないっぽいから
底辺派遣てすぐばれるよｗ
341:デフォルトの名無しさん
14/07/29 23:07:53.67 fZzOasD9.net
>>340
現実つーかレスの意味が見えてないのはお前のほうだな
342:デフォルトの名無しさん
14/07/29 23:56:17.33 vPKzHxKl.net
何か高度な裏の意味があるらしい
343:デフォルトの名無しさん
14/07/30 00:19:39.30 2joTlTTw.net
自社サービスで食っていけてるってだけで圧倒的な成果だろうな
労働集約型な受託開発なんて価格競争で擦り減るばかりで
エンジニアに何のメリットもないし、早く脱出すべきなんだけど
脱出するためのスキルが溜まらない負のスパイラル
344:デフォルトの名無しさん
14/07/30 09:05:15.28 NitIOFnC.net
SEが設計してコーダがコード書くってスタイルと
リファクタリングは相性悪いだろうな
345:デフォルトの名無しさん
14/07/30 11:16:11.07 l4R9UcQd.net
SEの設計が日本語プログラミングになってるからな。
日本語と一対一のコードでないとめんどくさいことになる。
346:デフォルトの名無しさん
14/07/30 18:54:49.24 z3bvSX8e.net
>>345
それで食えないスパゲティの一丁上がりかw
347:デフォルトの名無しさん
14/07/30 20:26:49.42 njRDxY7Y.net
リファクタリングは1にも2にも自分のためにやるものだ
デスマーチを充実したアフターファイブに変えたければやっとけｗ
348:デフォルトの名無しさん
14/07/30 21:00:14.66 JOmnGzMa.net
>>345
その日本語プログラミングではBASICにも劣る
抽象化しか出来ないのが問題なんだよね
349:デフォルトの名無しさん
14/07/30 21:00:10.81 O2fC1zxl.net
そしてリファクタスパイラルへ…
350:デフォルトの名無しさん
14/07/30 22:54:34.89 xH5zP1F6.net
リファクタリング否定派は技術力に乏しく低脳という風潮
一理ある
351:デフォルトの名無しさん
14/07/30 23:20:51.69 B3MDpURs.net
どう考えてもすぐリファクタする方が低脳だろｗ
リファクタしたがる奴の傾向として
・理解力の不足。
自分に理解できないものをすぐ諦めてクソ呼ばわりする。
他人の書いたコードの一貫したポリシーや目的を汲み取れないから、先人が用意してくれた便利なライブラリも使えない。
理解できないから規約も無視しがちで、彼の書いたところだけ作りがおかしい。
・謙虚さの不足。
相手を見下して、自分のほうがいいものが作れると根拠なく信じてる。
すでに用意されているものを再発明するだけならまだいいが、
しばしば完成されたフレームワークの重要な部分にクソを差し込んでめちゃくちゃにする。
・計画性の不足。
先の見通しが利かないから、行き当たりばったりでクソしか作れない。
リファクタも行き当たりばったりにやるから、クソが超臭うクソになるだけということになりがち。
挙句に自分で訳がわからなくなって、成果物を全部消したりする。
・客観性の不足
自分のやったことの成果を、客観的に見ることが出来ない。
リファクタしたことで、掛けた工数がどれくらいでペイしたとか、数字で物事を考えられない。
彼がリファクタするのは、単に楽しいから。本人は仕事してる気になってるが、周囲から見ると遊んでるだけ。
という感じ。
そもそも最初からちゃんと書く能力があったら、リファクタしたいと思うことは少ないはず。
352:デフォルトの名無しさん
14/07/30 23:55:14.83 2joTlTTw.net
>>351
> ・理解力の不足。
> 自分に理解できないものをすぐ諦めてクソ呼ばわりする。
> 他人の書いたコードの一貫したポリシーや目的を汲み取れないから、先人が用意してくれた便利なライブラリも使えない。
> 理解できないから規約も無視しがちで、彼の書いたところだけ作りがおかしい。
>
> ・謙虚さの不足。
> 相手を見下して、自分のほうがいいものが作れると根拠なく信じてる。
> すでに用意されているものを再発明するだけならまだいいが、
> しばしば完成されたフレームワークの重要な部分にクソを差し込んでめちゃくちゃにする。
とりあえず、最初の二つだけで良いから
リファクタリングとの関係を論理的に説明してみ？
353:デフォルトの名無しさん
14/07/31 00:02:21.65 Jagb4X9u.net
>>352
他人の書いたコードを書き換えたがるんだよ…
自分に理解できないからクソだ。という理屈で。
クソに感じるのは自分の能力が足りないせいだということに気づかない。
354:デフォルトの名無しさん
14/07/31 00:08:01.18 jvFYVzT/.net
そんな奴、実際には見た事無いが
受託開発だとレベル低いから居るのかもしれんね
355:デフォルトの名無しさん
14/07/31 00:28:09.58 1DTVAKx3.net
>>353
具体的にはどう書き換えられたの？
共通化できる処理を各所にバラバラに書き散らかしてたのを
シンプルにまとめられた挙句
「DRYも理解出来ないアホが開発に関わるとか意味が分からない」
って言われたとか？
356:デフォルトの名無しさん
14/07/31 00:49:44.01 OYcKACC5.net
コードオナニストは、常にコード以外の観点が欠けているのが特徴。
いくら諭しても話が噛み合わず、日夜コードのブラッシュアップに励んでいる。
357:デフォルトの名無しさん
14/07/31 00:51:52.79 Jagb4X9u.net
>>355
知らん。問答無用で差し戻したから。
散々テストしたはずなのに客先に持ってったら動きが変わってて
共通モジュールに手が入ってたんで何やったのか聞いたら「わかりにくかったんでリファクタしました。」
何年も動いた実績あるモジュールにそんな理由でいじんなアホか死ね
>「共通化できる処理を各所に（略」
うん。そうだな…だいたい君と同じぐらいの理解度の奴だったよ。
358:デフォルトの名無しさん
14/07/31 00:54:29.60 jvFYVzT/.net
> 散々テストしたはずなのに客先に持ってったら動きが変わってて
それリファクタリングになってないから
リファクタリングじゃない話を使ってリファクタリング批判してどうすんだよ
359:デフォルトの名無しさん
14/07/31 01:01:10.62 Jagb4X9u.net
>>358
別にリファクタは批判してないよ？
考えもなしにリファクタしたがる奴を批判してるんだ。
360:デフォルトの名無しさん
14/07/31 01:07:13.72 jvFYVzT/.net
>>359
お前んところがレベル低くて、勝手にコードぶっ壊す馬鹿が居るってだけの
リファクタリングと関係ない話を一般論として語られても、
底辺は可哀想だなって感想しか持ち様が無いぞ
361:デフォルトの名無しさん
14/07/31 01:09:10.48 OYcKACC5.net
>>358
お前はリファクタリングのつもりかもしれんが
完璧なテストが存在しない以上、挙動が変わる危険は常につきまとうんだよ。
362:デフォルトの名無しさん
14/07/31 01:15:43.10 jvFYVzT/.net
完璧なテストとか言う以前に、
ろくに自動テストとか書いてないでしょ？
ていうか、レビューもまともに機能してない
（じゃなかったら>>357のケースなんてコードがマージされるはずない）
テストもマトモに書いてないじゃ、そりゃトラブルよ
363:デフォルトの名無しさん
14/07/31 01:21:33.19 1DTVAKx3.net
Excelで書かれたチェックリスト片手に手動でテストして
「散々テストしたのに」って言ってそう
364:デフォルトの名無しさん
14/07/31 07:53:29.99 RHNsF96S.net
>>335
挙動を変えるのはリファクタリングじゃなくて仕様変更だろ
365:デフォルトの名無しさん
14/07/31 21:56:38.46 w9LroIYe.net
仕様変更でもバグ修正でもいいが、
コードを書き換えたら挙動が変わることがある。
つまり、機能追加もバグ修正もするなってことだ。
366:デフォルトの名無しさん
14/07/31 22:08:52.98 t7+Ucdvo.net
ネストが揃ってないとか空行が多いとか
変数がはるか上で宣言されてるけど使ってるのは遥か下に固まってるとか
理解力以前に目が疲れるコードをどうにかしろって言ってるんだよ
367:デフォルトの名無しさん
14/08/01 18:46:58.63 xnEk5c3C.net
変数定義の位置を移動したりスペースを除去したり
するのもリファクタリングなわけだが
368:デフォルトの名無しさん
14/08/01 19:22:03.81 +GTzrZhA.net
失敗例をあげてリファクタリングは糞って言ってるの最高に滑稽。
井戸の王様を気取ってる蛙か
369:デフォルトの名無しさん
14/08/01 20:37:16.99 zWTZP0nt.net
OO批判と同じ流れだな
370:デフォルトの名無しさん
14/08/01 20:43:59.51 fzo9r37p.net
リファクタリングが糞なんじゃないよ
リファクタリングしたがる人が糞なんだよ
371:デフォルトの名無しさん
14/08/01 21:19:55.74 7+EywXB6.net
>>370
ゴミみたいなコードばっか書いてっから
他人にリファクタリングされまくっちゃうんだろ
372:デフォルトの名無しさん
14/08/01 22:07:17.79 2Z4Uf/Xj.net
新人はリファクタしたがっていかん
関数の共通化とかGenericsとかTemplateとか覚えたてのこと使いたがる
ちょっとしたクソが一晩したらそびえたつ巨大なクソに
373:デフォルトの名無しさん
14/08/02 01:12:27.41 tvZxKsuR.net
技術レベルの低い人ってのは初心者に近くて
リファクタリングという技術用語を理解できないんだよ。
だからわかり易い言葉に置き換えるといい
リファクタリング＝整理整頓・改善
こう言い換えれば、改善する必要があるんです。
整理整頓すると普段の仕事が捗るんです。ということになる
こう言い換えれば、反対する人はいなくなるよ。
374:デフォルトの名無しさん
14/08/02 01:27:17.11 nhTOdUsW.net
生理整頓した状態を維持しながら仕事しろよｗ
個人レベルの話ならクソコードをフィックス前にに最低限他人が読めるようにするのなんて責務のうちだ
リファクタはどっちかというと組織再編といったほうがいい
課題と今後の見通しがあってはじめてやることで
375:デフォルトの名無しさん
14/08/02 02:10:54.57 tvZxKsuR.net
>>374
その責務を果たさない奴が、
行き当たりばったりのコード書くんだよな。
そいつに限ってリファクタリングの意味を理解してないという。
もう技術者として終わってるとしか言いようが無いね。
376:デフォルトの名無しさん
14/08/02 08:46:20.40 Mu2XuA5N.net
リファクタリング本を一回読んだとき何を感じるかだよな。
ああそうそう、こういう点で苦しくなってたんだ、って気付くか、
何一つピンとこずに何やってんのこの本？と思うか。
377:デフォルトの名無しさん
14/08/02 11:09:34.62 nhTOdUsW.net
クソコードを普通のコードに直す作業をあんまりリファクタと呼びたくないｗ
378:デフォルトの名無しさん
14/08/02 11:27:29.15 h5SZ209F.net
結合テストとかまで進んじゃったら無理だよね
379:デフォルトの名無しさん
14/08/02 11:55:25.68 nhTOdUsW.net
リリースした後でバージョンアップのついでにやるもんだろ
380:デフォルトの名無しさん
14/08/02 11:59:50.68 tvZxKsuR.net
ボーイスカウトの法則といって、
コードを修正するときは、修正する前よりも
綺麗にするもんです。
これが出来るのと出来ないのが、
初心者と中級者の境目。
もちろん、出来ないほうが初心者ね。
これが許されるのは新卒1年ぐらいなもん。
381:デフォルトの名無しさん
14/08/02 12:22:30.70 DmU4GxTK.net
規模が小さいうちは手抜きで簡単なコードを書くだろ？
最初から拡張性とかそういうものを考えて作りこまない。
で、規模が大きくなってきた時に、将来性のことを
考慮して作り変えればいいんだが、
最初の手抜きのコードをそのままに、手抜きを真似して
同じようなコードを追加するやつどうにかならんかね。
規模に応じたコードの書き換えをしない。できない。
発想がない。そういうい奴がクソコードを量産するんだよ。
382:デフォルトの名無しさん
14/08/02 12:37:41.39 Ydx1jnyI.net
権限のない末端PGが現場の手続き無視してユニットテストのないコードを
勝手に修正する、自称リファクタリングは非常に迷惑。
日本の受託開発の仕事ではリファクタリングなんてするべきではない。
383:デフォルトの名無しさん
14/08/02 12:42:59.05 DmU4GxTK.net
>>382
ユニットテストが無いことが前提になってる時点で、
やっぱり、その程度の所が、リファクタリングを嫌ってるんだなとしか
思えないよ。残念だったね。君のところの技術不足を露呈しただけ。
えと、技術力不足であることを自覚してね？落ち込むところだよ。
384:デフォルトの名無しさん
14/08/02 13:29:01.01 a3/R4SSz.net
最初から厳密に書けばいいんだよ
手抜きコピーが多いのは、そういうものかと思ってしまうからだ
自称上級者がスタートアップ書くことが多いが、手抜き繰り返して
しまいには自分自身が変な癖背負い込んでいくだろう
初期段階でよい方向に導くには、最初のやつががんばるしかない
385:デフォルトの名無しさん
14/08/02 13:37:36.15 DmU4GxTK.net
人間誰しも、最初は初心者で
一年後には今よりも成長しているという
前提にたつと最初から完璧なコードを書くのは不可能
どんなに優れたコードを書いたとしても
一年後の自分はもっと優れたコードを書ける。
386:デフォルトの名無しさん
14/08/02 14:03:04.41 nhTOdUsW.net
>>385
この程度の奴がリファクタしたがるんだよなあ…
リファクタってのはある設計から別の設計に軸足を移すことだ。
書き散らしたクソコードを書き直すのは、リリース前にやっておくべきそれ以前の問題なんだよ。
お前の末端の画面とか帳票とかは、誰も共通機能として使ってないから汚かろうがクソだろうが問題ないよ。
お前の自己満足のためにプロジェクトとめられてたまるか。
どんなクソでも、客の前にひりだしたクソはてめえのクソだ。受け入れて前に進め。
387:デフォルトの名無しさん
14/08/02 14:06:28.03 nhTOdUsW.net
大体最初からある程度ちゃんとしたプログラムも書けないやつに
まともなユニットテスト作れるわけないだろうが。
388:デフォルトの名無しさん
14/08/02 14:26:29.65 1FEiY+vP.net
理想だけど
組織には逆らえない
389:デフォルトの名無しさん
14/08/02 14:42:12.73 wGpqnjMj.net
関数の中身やprivateな関数のインターフェースを修正するようなリファクタリングと、
ライブラリのpublicなインターフェースを変更するような
影響範囲の大きいリファクタリングの話が混じってる気がする
後者はそう簡単じゃないよ
影響範囲に入る全ての開発者と調整が付かない限り変更できない
（勝手に変更したら、ライブラリ使用者側から見たら仕様変更だからリファクタリングにならない）
390:デフォルトの名無しさん
14/08/02 14:44:44.99 atIEditt.net
初心者にオススメなのは、派生開発でコードを読むときに、動作確認をテストで書くことかな。これはとっつきやすい。
『レガシーコード改善ガイド』では「仕様化テスト」のところ。
391:デフォルトの名無しさん
14/08/02 14:54:07.48 1BrdY1ES.net
>>379
そんな意識の奴と仕事したくないわ
392:デフォルトの名無しさん
14/08/02 15:20:52.89 DmU4GxTK.net
リファクタリングするなっていってる奴がいるけどさ、
時間が十分にあるという前提にたつと
とたんに何も言えなくなってしまう
それってリファクタリングがダメなのではなくて
時間がないという問題だから。
じゃあ、なんで時間が足りないんですか？
今までと同じやり方してるんじゃないですか？って
追い詰めると、泣き出しちゃうｗ
393:デフォルトの名無しさん
14/08/02 15:21:48.08 DmU4GxTK.net
>>389
そういう場合は、旧関数の互換性を保ちながら
新しい関数を作ればいいんだよ。
394:デフォルトの名無しさん
14/08/02 15:32:36.71 WtoScNjl.net
>>389
そういうことのないように依存性を無くすようにプログラミングする
プログラマの規律が無いだけ
395:デフォルトの名無しさん
14/08/02 17:35:26.06 w2qydRR0.net
当たり前のことを当たり前に理解してそれを前提としている人と、
当たり前のことなのに全く理解しないでそれを前提とできない人とが会話しているようだ。
396:デフォルトの名無しさん
14/08/02 19:06:34.85 jgRhK7n4.net
ウォーターフォールだったり、詳細設計書で日本語プログラミングしたりしてるとこと
リファクタリングは相性悪いよ
開発の全体を見直さないと、一部だけ優れた手法を取り入れようとしても
歪みが出て上手く行かないんだよね
397:デフォルトの名無しさん
14/08/02 19:30:03.16 DmU4GxTK.net
うまくいかないんじゃなくて
難しいだけだろ？
それを実行する力が技術力なわけで。
398:デフォルトの名無しさん
14/08/02 19:41:02.16 q1w4boEu.net
どうしても自分が書いたコードを書きなおしたい人がいるようだけど
そんなコードはいずれバグで書きなおされるんだから、あまり気にしない方が良い。
その情熱は悪くないけど、もっと前向きに使うべきだよ。
399:デフォルトの名無しさん
14/08/02 19:57:31.28 DmU4GxTK.net
前向きって新しいコードを書くってこと？
残念だけど、開発ってのは既存のコードの修正がほとんどだよ。
新しい機能を追加するといっても
前よりも効率よく開発するために既存の部分を、
使いまわす（コピペじゃないからね！）するために
既存の部分を修正して使えるようにするんだから。
400:デフォルトの名無しさん
14/08/02 19:57:37.46 FIwNTFpf.net
>>396みたいな事言ってると、拡張を繰り返すうちにコードが保守不能なカオスになって
もう無理だから全部捨てて作り直しだー、ってなるんだよ
でもSIerとしては、それが飯の種だから良いんだけどね
401:デフォルトの名無しさん
14/08/02 20:03:28.32 DmU4GxTK.net
全部捨てて作り直しだーまで追い詰めるって馬鹿だと思う。
少しずつ変化させていくことができないからそうなるんだよね。
全部いっぺんに変えるなんて現実的じゃないんだから。
全部いっぺんに変えることは不可能。じゃあどうするか？
それに答えられないから、どんどん壊れていくんだよ。
まあ、少しづつ良くしていくことが出来るのも技術力なわけで。
それを頭でわかっているのと実行するのとは全然違うわけで、
その実行できる力ってのが技術力そのものなわけで。
402:デフォルトの名無しさん
14/08/02 20:19:36.36 q1w4boEu.net
>>399
前向きってのは、コード書きの脳からデザイナーの脳に変われるように努力しろって事。
403:デフォルトの名無しさん
14/08/02 20:23:43.06 DmU4GxTK.net
>>402
何に逃げてるのさ？
両方できるようになるというのなら正しい意見だが、
別のものに逃げたらだめだろ。
まるでペンもイラレもろくに使えない奴が
発想力とかいうのに逃げているのと同じ。
コードをまともに書けるようになった上でデザイナーになることはできる。
だけど、コードから逃げてもデザイナーにはなれない。
404:デフォルトの名無しさん
14/08/02 20:23:58.64 J1UwFk0L.net
よくある設計とコーディングっていう役割分担からしてくるっとる。
プログラミングなんて、設計九割五分なのに。
実装なんざオマケのオマケ。
SEとプログラマ、とわけてプログラマがキーボード叩く役とか、きがくるっとる。
まぁ聡明なお前らの会社は違うだろうけどね。
405:デフォルトの名無しさん
14/08/02 20:28:21.78 DmU4GxTK.net
「前向き」って言ってる奴が、
コードとデザインの両方を手に入れるじゃなくて、
コードから逃げてデザインを求めていて笑えるよ。
そういう奴は両方できない。
406:デフォルトの名無しさん
14/08/02 20:33:33.15 a3/R4SSz.net
やっぱり自分でコード書かなきゃやってる気がしない
407:デフォルトの名無しさん
14/08/03 00:40:07.16 ppjITjjs.net
もう最近ガチガチの詳細設計やるとこって殆ど無いだろ
コメント的仮想コードとかで詳細は終わらせちゃうところが多い
その方が柔軟だしな
408:デフォルトの名無しさん
14/08/03 00:45:38.31 CSranqfK.net
一応UMLでシーケンス図とクラスとPublicメソッドだけはきっちり作ってるな
DBアクセスとかあたりまで
そっから先はprivateで実装して
アプリのフレームワークに依存しないメソッドとかクラスとかはプCommonフォルダに各自放り込んでもらう
で上手くいくと思ったけど
Commonがかなりカオスなことに
409:デフォルトの名無しさん
14/08/03 07:51:54.04 KHwMExMo.net
>>407
あー、主に非技術者がやる作業だね。
410:デフォルトの名無しさん
14/08/03 07:57:18.76 mU4IZymt.net
>>408
＞Commonがかなりカオスなことに
kwsk
411:デフォルトの名無しさん
14/08/03 10:20:01.47 1nxvzFtA.net
まるで業務系しか仕事がないかの勢いw
412:デフォルトの名無しさん
14/08/03 10:36:51.70 CSranqfK.net
>>410
コードが酷いのは予想のうちだけど
あれだけ言ったのに、規約が守られずにアプリのフレームワークに依存が作られてる
最初あたりに誰かがやったせいで後続が真似して、手続きなんとなくまとめただけみたいな処理がいっぱい
関数の共通化もうまくいってなくて
例えば分かりやすいところでは文字列をバイト列に変換してパディングするって処理があるんだけど
SJisStringUtil.ToByte
DBCodeChanger.LeftPaddingByteArray
StringModel.BytesWithSpace
こんな感じでいっぱいできてる
挙句にsTanakaとかフォルダできてるしｗ
413:デフォルトの名無しさん
14/08/03 10:42:19.36 KHwMExMo.net
まあありがちやねｗ
だから規約を作った人は
必ずコードレビューをしなくてはいけない。
414:デフォルトの名無しさん
14/08/03 20:06:25.42 lk1xFWmM.net
>>953
糞設計、糞コード書くような人たちが
集まってコードレビューしてもなんの意味もない
しかもそういう人って声が大きいだけが取り柄みたいな人だろうし
415:デフォルトの名無しさん
14/08/03 21:25:01.28 LWW935BO.net
ロングパスきっちり通せよｗ
416:デフォルトの名無しさん
14/08/03 23:57:33.38 tNPEJw6R.net
Ａ社に発注して作らせた大規模なソフトを、
Ｂ社に一時的にメンテナンスさせて、
今はＣ社に機能拡張させているとか言う例が実際にあるからなー
それぞれがそレなりにちゃんとした会社であっても、
開発者の継続性が０の場合、
中のソースがかなり混乱するのは仕方ないかもしれん。
417:デフォルトの名無しさん
14/08/04 22:06:42.37 w1xJJUBp.net
リファクタリングはアートですよ。
アートは人間が生み出すものではありません。
ある日、天から降りてくるんです。
この感覚がわからない人は、アートしたことが無いんです。
つまり、リファクタリングもわからないってことです。
418:デフォルトの名無しさん
14/08/04 22:17:15.14 p5AMhKr8.net
わかる、わかるぜ～
ソースコードがある書き方になりたがってねだってくるんだぜ～
俺はそのとおりに書き写してるだけなんだぜ～
419:デフォルトの名無しさん
14/08/04 22:19:31.15 w1xJJUBp.net
やべえ。
適当ぶっこいてたらマジキチ召喚しちまった。
ちょっと反省。
420:デフォルトの名無しさん
14/08/04 22:54:50.48 O7gnQe0p.net
自作自演乙
421:デフォルトの名無しさん
14/08/27 12:13:22.10 RluTUsi0.net
他人のコードだと思って、何の前情報もない状態でコードを読み
そこから読み取れる情報だけで、「なんで？」って思う実装を減らしていくのがリファクタリング
もちろん、処理の効率とかをよくする場合もあるけど、
どっちかというと、そういうのよりも第三者が見て読みやすいコードである状態を保つ事のほうが重要
(リファクタリングで大幅に処理コストが改善できるような糞実装が最初にされてることは稀)
ただ、リファクタリングをできるレベルに達していない職場も少なくない
とくに業務系や人売りで奴隷を集めた職場とかは、大抵メンバーのスキルが足りてなさすぎて無理
っていうか設計(という名のゴミファイル作成)段階からそびえ立つうんこを作っていってるから、実装時は既に手遅れ
422:デフォルトの名無しさん
14/09/04 15:14:28.47 NCM4vLJB.net
リファクタリングの誤用
URLﾘﾝｸ(capsctrl.que.jp)
リファクタリングの境界線
URLﾘﾝｸ(capsctrl.que.jp)
423:デフォルトの名無しさん
14/09/13 02:08:52.13 Bjr83Kqx.net
ボキもリファクタリングして欲しいです
URLﾘﾝｸ(twitter.com)
424:デフォルトの名無しさん
14/09/13 02:46:33.71 99VHFg4q.net
ちんこの振る舞いを保持したまま変化させる、もちろん性的な意味で。
425:デフォルトの名無しさん
14/09/13 03:35:58.05 WOkelzJA.net
インタフェースの変更はリファクタリングか
URLﾘﾝｸ(capsctrl.que.jp)
> 答えは簡単―インタフェースの変更はリファクタリングだ。
未知のバグフィックスはリファクタリングか？
URLﾘﾝｸ(capsctrl.que.jp)
> 私はリファクタリングと呼べると思う。 バグを含んだ振る舞いを知らなかった（あるいは気にしなかった）わけだから、
> これは「外部から見たときの振る舞い」ではないのだ。 たとえバグに気付いていたとしても、
> それが気にするようなバグでなければ、 リファクタリングと呼んでもよいと思う。
最適化はリファクタリングか？
URLﾘﾝｸ(capsctrl.que.jp)
> 最適化とリファクタリングはどちらも変化を伴うものだが（なかには最適化かつリファクタリングとなる変化もあるが）、
> 両者は別物だと私は考えている。なぜなら、両者の目的が異なるからである。リファクタリングは、
> コードを理解しやすくするためである。最適化は、プログラムを速くするためである。
> つまり、リファクタリングと最適化は似ており、共通する変更がありはするものの、目的が異なるため、両者は別物であると私は考えている。
宣言の順序変更はリファクタリングか？
URLﾘﾝｸ(capsctrl.que.jp)
> 宣言（Javaで言うメソッドやフィールド）の順序を変更することは、リファクタリングと呼べるのか？
> リファクタリングの定義で、 「理解や修正が簡単になるように」というフレーズを使った。
> 宣言部分を変更すると、理解や修正が簡単になるのだろうか？ 私は、そういう場合もあると思う。
> ソフトウェアの内部構造を変更しないという点が紛らわしいかもしれない。 リネームしても実行内容は変化しない。
> だがリネームは、プログラムの理解度を向上させる 非常に重要なリファクタリングの一種である。
426:デフォルトの名無しさん
14/09/13 13:49:13.80 9aicrkfD.net
あれもこれも取り入れた「オブジェクト指向」とまるっきり同じパターンだな
どんどん曖昧な意味になりそう
427:デフォルトの名無しさん
14/09/13 14:14:43.12 Fgrmdz5F.net
すべてリファクタリングの結果発生する作業だろ。
まったく理解できていないな。まさに本末転倒
428:デフォルトの名無しさん
14/09/13 16:14:30.25 WJGPx/6o.net
要件を仕様にまとめるのもリファクタリングですか？
429:デフォルトの名無しさん
14/09/13 20:28:39.39 Y1nBtaE7.net
>>428
リファクタリングの一部ではあるな
430:デフォルトの名無しさん
14/09/13 20:33:35.66 zttb1Mfl.net
OpenSSLがリファクタリングされまくっているな
431:デフォルトの名無しさん
14/09/14 00:35:49.32 a/rqPd2y.net
>>428
違う
> リファクタリング中に2,3日システムが動かなくなっちゃってーなどと言ってる奴がいたら、
> んなもんリファクタリングじゃあなーいと言ってやれ。 ドキュメントをリファクタリングしちゃるとか言ってる奴、
> それもリファクタリングじゃねーぞコラ。 そういうのは、リストラクチャリング（再構築）というのだッ
432:デフォルトの名無しさん
14/09/14 02:43:07.06 XHTMIvTT.net
客の要件はそのままプログラムにできるけど、
それじゃあ最適化できてないから
外面の挙動は変わらない範囲で最適化を行う。
コードの実体だけがリファクタリングの対象じゃないだろ。
433:デフォルトの名無しさん
14/09/14 03:54:19.00 a/rqPd2y.net
>>432
それこそがリファクタリングの誤用で
リファクタリングではないと述べられていること。
434:デフォルトの名無しさん
14/09/14 10:24:07.39 NZ+I8Nx6.net
最適化じゃないんだよ
最適化なんかできるわけねーだろってのが大前提なんだよ
435:デフォルトの名無しさん
14/09/14 13:02:21.11 bjSSfYoR.net
バグも含めて機能そのままで、構造だけ変える（良くするつもり）ができるっていうのが結構単純な
還元主義的な思い込みで、実際の構造物は両者は一体というか、都合良くできないと思うんだよね。
テスト駆動とかもそうだけど、この種のスローガンが胡散臭いのは、物作りの本質的な困難を直視
しないで、小手先の技法を当てはめれば解決みたいに喧伝しすぎるところにあるんじゃないかと思う。
436:デフォルトの名無しさん
14/09/14 14:21:12.62 TJC+Xrrg.net
別に胡散臭いとは思わないが、真に受けちゃったバカが「リファクタリング最強！」とか言い出すのはかなりうざい。
437:デフォルトの名無しさん
14/09/14 15:42:46.67 a/rqPd2y.net
>>435
> バグも含めて機能そのままで、構造だけ変える（良くするつもり）ができるっていうのが結構単純な
> 還元主義的な思い込みで、
できるよ。
というか、リファクタリングは構造を良くしましょう（終わり）じゃなくて、
構造を良くするのは当然の話しとして、機能をそのままにするためにはどうすればいいか？
って所が出発点で、
機能をそのままにするために、編み出された様々なテクニックが
リファクタリング手法なんだよ。
できないというのなら、リファクタリング手法（それには名前が付いている）
一つ一つに対して出来ない根拠を述べてみてよ。
君は単に、リファクタリングに手法があることを知らないで、
闇雲に自己流でなおそうとしてみて失敗しただけでしょう？
438:デフォルトの名無しさん
14/09/14 15:44:54.17 a/rqPd2y.net
なんだ、自分で自白してるじゃんかｗ
> この種のスローガン
スローガンとしか認識していないｗ
リファクタリングは、数学的な証明と
なんらかわらないんだが。
439:デフォルトの名無しさん
14/09/14 18:12:37.41 d9eejC+C.net
ダメなコードは直すことでよくできる
という公理が大前提
1000行もあるようなおバカ関数を数学的に定式化して改善するのは無意味なこと
見れば何をすべきかわかる
440:デフォルトの名無しさん
14/09/14 18:52:51.74 a/rqPd2y.net
>>439
つまりどういうこと？
リファクタリングすればいいって話を
言葉を変えていってるだけだよね？
441:デフォルトの名無しさん
14/09/14 19:25:36.36 3Rt2m2d6.net
リファクタリングを知らない人は、
リファクタリングを一気に直してしまおうと
思っているに違いない。
リファクタリングが問題が起きることがありえない
小さな修正の繰り返しであることをしらない。
442:デフォルトの名無しさん
14/09/14 19:30:47.61 NZ+I8Nx6.net
デザパタ信者みたいなのが暴走して悪評を広めてるんだろう
443:デフォルトの名無しさん
14/09/14 19:32:04.00 3Rt2m2d6.net
その悪評を鵜呑みにしているのが
頭悪いと言われる所以なわけで。
自分の頭で考えろよとｗ
444:デフォルトの名無しさん
14/09/14 21:08:34.07 oiv3svus.net
リファクタリング
445:デフォルトの名無しさん
14/09/15 00:27:34.64 irRiVyM3.net
流石に数学の定理と同等か言い過ぎだろ。
パターンと同じでさ、セオリーやメソッドじゃない、ちょっとしたコツの集積だろ
オブジェクト指向、CMMI、PMBOKとかと同じでさ、アメリカ人の教授とかはそういうのまとめて
自分が言い出しっぺになって、学会ごっこしたり、資格試験の元締めやろうとしたりするのが好きなんだよ。
そういう商売に乗せられているだけなのに、さも学術的な根拠があるものとして「勉強」したりするのが
偉いと思っている奴はどっかオツムが弱いとしか言いようがないw
446:デフォルトの名無しさん
14/09/15 00:37:25.87 9UWhhSIJ.net
>>445
数学の定理じゃなくて、数学の証明だろ？
a + b = c を b = c - a
に置き換えるようなもの。
式の変形だよ。
リファクタリングのテクニックっていうのはどれも
この式の変形と同じようなもの。
一部の人が勘違いしているように、ぶっ壊して同じように作りなおすことじゃなくて、
項の移動のように、全く同じ結果になる変形をしているにすぎないんだよ。
447:デフォルトの名無しさん
14/09/15 00:39:47.71 9UWhhSIJ.net
>>445
あと警告として、自分が知らないことを
勉強している奴は生意気だっていうのやめたほうがいいよ。
中学生かよ。あいつ勉強なんかしてるんだぜーってｗ
448:デフォルトの名無しさん
14/09/15 00:43:11.40 irRiVyM3.net
何が「警告」だよ
笑わせるな
449:デフォルトの名無しさん
14/09/15 00:44:52.76 9UWhhSIJ.net
いや、普通に恥ずかしいでしょ？
ガリ勉ガリ勉いって勉強しない悪ガキ。
自分が後で困るというのに。
警告してあげないといつまでたっても
気づかないよ。
450:デフォルトの名無しさん
14/09/15 01:15:03.90 WaQuX0Y8.net
ぶっ壊して同じ結果が得られるように作り直すこととの違いを教えてください。
451:デフォルトの名無しさん
14/09/15 01:41:27.21 j8xvklWY.net
イチから作り直したい病と
現実の範囲で出来る事だけやる工夫の違い
452:デフォルトの名無しさん
14/09/15 02:07:53.50 WaQuX0Y8.net
機能やクラスを抽出するのだって破壊を伴うんじゃないの。
リスクが少ない範囲での変更もあれば、
時には大胆なリファクタリングもあると思うけど。
453:デフォルトの名無しさん
14/09/15 04:21:21.27 9UWhhSIJ.net
>>450
> ぶっ壊して同じ結果が得られるように作り直すこととの違いを教えてください。
たとえば数学で、3x - 11 = 4 のxを求めるという問題があった時
1. 移項とい手法を使って、3x = 4 + 11 にして、
2. 足し算という手法を使って、3x = 15 にして
3. 両辺を同じ数で割るという手法を使って、x = 5
という風に、変形をしても等しいと証明されている
安全な手法を使ってシンプルな形に変形していくのがリファクタリング
>>452
大胆なリファクタリングって何よ？
まずさ、数学の式の変形のやり方と一緒で、
リファクタリング手法には名前があるって知ってる？
一覧見つけてきたから、これのどれが大胆で破壊を伴うのかちゃんと説明してくれ。
URLﾘﾝｸ(d.hatena.ne.jp)
454:デフォルトの名無しさん
14/09/15 04:22:40.33 9UWhhSIJ.net
>>452が言ってる、
大胆なリファクタリングというのは、
これらの手法を使わずに
いきなり最終的な答えを
だそうとしていることでしょ？
それはリファクタリングじゃない。
455:デフォルトの名無しさん
14/09/15 04:24:53.24 9UWhhSIJ.net
>>451も少し勘違いしているね。
リファクタリングを「ソースコードを綺麗にしましょう」ということを
英語で言ったものとしか認識していないようだ。
リファクタリングというのは、安全に変形できるという
手法を使って、いっぽずつ書き換えていくもの。
手法を使わない書き換えはリファクタリングじゃない。
456:デフォルトの名無しさん
14/09/15 10:57:57.36 z+pQ6G77.net
>>455
それな
その手法の確立というか
その手法の念押しというか
そういう面も大きい
457:デフォルトの名無しさん
14/09/15 11:09:38.77 pNNQiIbO.net
これがリファクタ信者の暴走か
458:デフォルトの名無しさん
14/09/15 11:28:39.31 kUSteVkT.net
リファクタリングの「関数の抽出」をやったら
増えた関数呼び出し分の実行コストが無視出来なくて
仕様を満たさなくなってしまいました
459:デフォルトの名無しさん
14/09/15 11:46:22.25 9UWhhSIJ.net
>>458
そしたら「関数のインライン化」という
リファクタリングをすれば
動作を変えることなく、仕様を満たせるようになるよ。
やっぱり問題が起きた時にやるのは
リファクタリングだね（笑）
460:デフォルトの名無しさん
14/09/15 11:49:22.77 kUSteVkT.net
つまり途中で一回ぶっ壊して同じ結果が得られるように作り直すわけね
良いと思うよ
461:デフォルトの名無しさん
14/09/15 12:21:05.22 NXR59SQz.net
リファクタリングがゲシュタルト崩壊しそうなスレだ。
462:デフォルトの名無しさん
14/09/15 12:43:17.41 zrs0o34A.net
安全を過信しすぎだな
463:デフォルトの名無しさん
14/09/15 12:46:23.34 9UWhhSIJ.net
>>460
一回ぶっ壊したらだめだろｗ
それではリファクタリングになっていない。
リファクタリングは壊さずに直すことであり
壊さないで直すための手法がまとめられている。
URLﾘﾝｸ(d.hatena.ne.jp)
464:デフォルトの名無しさん
14/09/15 13:45:51.89 kUSteVkT.net
>>463
>>458の操作で一回ぶっ壊れてるじゃん
少なくとも「関数の抽出」はリファクタリングの操作としてアトミックじゃない
465:デフォルトの名無しさん
14/09/15 15:20:24.10 4lL49qVx.net
慌てずリファクタリングの公式に沿って変更すれば副作用は一切ない。
466:デフォルトの名無しさん
14/09/15 15:20:49.07 9UWhhSIJ.net
>>464
> 少なくとも「関数の抽出」はリファクタリングの操作としてアトミックじゃない
アトミックだけど？
リファクタリング本を見ればしっかり書いてあるよ。
アトミックに作業する方法。
どうせあんたは関数を消して書きなおす（書き直してる間
元の関数がなくなってる状態）が起きるって思ってるんだろうけど。
ほんと、やり方をしらんのね。しらんから壊れるって言ってる。
わかりやすい。
467:デフォルトの名無しさん
14/09/15 15:21:50.80 9UWhhSIJ.net
ちなみに、リファクタリングブラウザを使えばもっと簡単に行える。
もちろん、リファクタリング本にはそういうツールを使わないやり方も書いてある。
468:デフォルトの名無しさん
14/09/15 15:45:17.66 wmpEGwKw.net
>>458と>>459の間に一回壊れてるよね
469:デフォルトの名無しさん
14/09/15 15:51:22.11 wmpEGwKw.net
>>466
手で書き直したとかじゃなくて、メソッドの抽出することで
仕様を満たさなくなるケースもあるって話だろう
その直後にインライン化したとしても、一旦仕様を満たさない状態になったのは事実