ﾘﾌｧｸﾀﾘﾝｸﾞすると全部ﾃｽﾄしろと言ってくるやつの矛盾

**仕様書無しさん** · 2018/04/15(日) 13:13:44.63

機能追加や変更した時に、全部テストしてるでしょ？
いつもやってることじゃん

**仕様書無しさん** · 2018/04/18(水) 23:07:43.72

>>119
> 修正内容に応じてテスト観点増やさないの？

少ししか修正してないから、テスト減らしていいとでも？

変更したコードの量は少しでも、その影響範囲は
修正の量とは無関係です。

どれくらい影響があるか、それはコードが複雑であれば
有るほど不明です。

**KAC** · 2018/04/18(水) 23:17:24.91

>>122
テスト計画建てたこと無いの？
「全ての条件を網羅したらバグは無くなる」
は真だけど、それができないからみんな工夫してるんだよ。

バグのないものは存在しない

なんてのは、この業界の常識。

**仕様書無しさん** · 2018/04/18(水) 23:22:51.13

>>120
リファクタだけの問題じゃないが、リファクタも修正のうち
修正する以上人間がやらかすリスクはある

だったら修正は極力限定されているほうがいいだろ

>次修正する時、また改修時間（読む時間）がかかりますよね？
そしてリファクタ最大の問題
コードの読みやすさや理解しやすさは人の主観に大きく依存する

else取っ払ってタプル戻り値の関数に変えようとするやつもいるんだぞ

リファクタ後に修正したほうがテスト工数が削減できるとか、規約が新たにできたから合わせるとか
なにかしら明白な理由がないと

**仕様書無しさん** · 2018/04/18(水) 23:23:52.53

あとどうもやっぱりリファクタリングを
単なるコードの修正の意味で使ってるように見えるんだよねｗ

リファクタリングは、コードの修正、コードを綺麗にするを
英語にした言葉じゃないよ？

リファクタリングっていうのはやり方が決まってる。
スタート（修正前）とゴール（修正後）は自分で決めるけど
スタートからゴールへ至る道へは、決まったやり方を使って修正する
その決まったやり方っていうのは、動きを変えないための方法

数学の等式の変形みたいなもんだ
x - 2 = 8 を「移行」して
x = 8 + 2 に変形しても意味は変わらない

こういう「移行」みたいに変形しても意味が変わらないやり方に
ご丁寧に名前までつけてカタログ化されてる。

テスト書いて決められたやり方で式を変形するんだから
無計画なコードの修正なんかよりもずっと安全に変形できる

**仕様書無しさん** · 2018/04/18(水) 23:24:38.02

>>123
いや、だから、一行の変更なら
テスト減らせるってわけじゃないよって言ってるんだが？

**仕様書無しさん** · 2018/04/18(水) 23:25:40.46

>>124
> コードの読みやすさや理解しやすさは人の主観に大きく依存する

じゃあ主観に依存しないものを採用すればいいだけでは？

コードメトリクスを計測せよ

**仕様書無しさん** · 2018/04/18(水) 23:27:30.62

>>125
そうだね
リスクはひくいよ
Eclipseのリファクタ機能使うならなおさらだ

それでもたまにやらかすだろ！

**仕様書無しさん** · 2018/04/18(水) 23:29:05.35

>>127
メトリクスのどれ見んの？

**仕様書無しさん** · 2018/04/18(水) 23:33:22.64

>>128
> それでもたまにやらかすだろ！

複雑なコードをそのまま修正するほうが
やらかします。

その場合、いくら修正してもバグはなおらないし
直したそばから別のバグが発生するし、
時間もかかるしで、良いことはまったくありません。

重要なのは改修量ではなく改修時間な

**仕様書無しさん** · 2018/04/18(水) 23:34:59.93

マーチン本に書いてある手続きいちいち守ってたら日が暮れる
現実的には既存のユニットテストのコードを信用して
手続きを頭に置きつつ直観でつくり変えていくことになる
そんで流して結果変わってなきゃＯＫと

理想が定義されているからといって現実に耐えうるかというと

**仕様書無しさん** · 2018/04/18(水) 23:36:04.44

>>129
基本的にメトリクス測定ツールは、基準値超えたら
アラート出してくれるはずだからそれに従えばいいと思うけど、
俺はCyclomatic複雑度を重視するね。

**仕様書無しさん** · 2018/04/18(水) 23:51:21.89

>>130
改修による単体工数の削減はあるかもしらんが

時間重視ならなおのことリファクタやってるひまなんかないだろ
あれほどの時間泥棒もない

よく考えたら書くほうが早いっつったって
結局その前に理解しないと書き直せないんだから一緒じゃねーか！
だまされるとこだった

**仕様書無しさん** · 2018/04/18(水) 23:59:21.26

> よく考えたら書くほうが早いっつったって
> 結局その前に理解しないと書き直せないんだから一緒じゃねーか！

だから、たった一行の修正とか言っても、
その修正にかかる時間は、理解する時間が大半を占めるんだから
リファクタリングしても大差ないって話だよ。

大差ないどころか、複雑なものを複雑なまま、頭の中で理解するほうが
時間かかると思うがね

そして理解した結果をコードに反映させないで、レビューにかかる時間
次に修正する時間、バグ出た時に読み返す時間を費やするか
コードに反映させて、その後にある時間を減らすかどうか

**仕様書無しさん** · 2018/04/19(木) 00:04:04.23

>>134
で？結局リファクタやると具体的に何がいいんだっけ？
色々話してるとメリットが全く見えなくなっちゃう

**仕様書無しさん** · 2018/04/19(木) 00:04:52.59

>>134
思うのは勝手だが最初にしてた変更リスクの話を忘れてないか

**仕様書無しさん** · 2018/04/19(木) 00:22:17.21

>>135
> で？結局リファクタやると具体的に何がいいんだっけ？

まず改修時間はさほど変わらない。
変更リスクもどちらにしろテストする場所なので変わらないし
行数が少ないほうが影響範囲が小さいってこともない

リファクタリングでバグ入れそうなコードは
リファクタリングしなかったらもっとバグを入れやすい

そして、レビューやバグがあったときの読み返し時間の削減
修正内容に自信が持てる。今後の修正の時の改修時間の減少

**仕様書無しさん** · 2018/04/19(木) 00:24:02.42

>>137
いや全然わからない
普通に改修する場合と比べて何がいいの？

**仕様書無しさん** · 2018/04/19(木) 00:25:04.88

1行の修正でこんなにお金がかかるんですか！
っていう顧客の声がまんまリファクタリングしない場合にあてはまるな

1行の修正だからリスクが少ないとお考えか！？

1行の修正でもお金がかかるってことは、1行だからって
なにかを減らせるわけじゃないんですよ。

**仕様書無しさん** · 2018/04/19(木) 00:28:14.81

>>138
そこで普通に改修っていうのは
リファクタリングをしないってこと

リファクタリングが「理解や修正が簡単になるように、内部構造を改善すること」
なのだからリファクタリングしないってこうのは
理解や修正が簡単になるように改善をしないってこと

元からすでに改善済みのものをリファクタリングしろとは言ってない
理解や修正が難しいコードであることは大前提

で「普通に改修」というのは改善なしに複雑なまま修正ということになるのだから
>>137で言ったようなメリットが有る

複雑なものをそのままにして手を入れたら
もっと複雑になるよ。

**仕様書無しさん** · 2018/04/19(木) 00:34:51.32

複雑なコードは壊すのがこわいからリファクタできない
簡単なコードは意味がないからリファクタできない

**仕様書無しさん** · 2018/04/19(木) 00:37:19.05

>>141
重要なのは手遅れになる前にこまめにやることだよね

大規模リファクタリングなんてのはあってはだめ
リファクタリングだけのための作業なんて持っての他

そうやって手遅れにするから、リファクタリングのための
工数なんて取れるかーみたいな話になる

リファクタリングは、機能追加や変更に伴う作業に
含まれているべきものですよ

**仕様書無しさん** · 2018/04/19(木) 02:08:38.73

>>142
今どきリファクタリングするのは機能追加や変更のタイミングに限らないよ
DDDやってる？機能の変更がなくても、業務にモデルを合わせるために日々リファクタリングするのが常識

**仕様書無しさん** · 2018/04/19(木) 02:28:05.80

こんな事が書いてあるのかｗ

http://hideoku.hatenablog.jp/entry/2013/03/07/223727

変更を完全に正当化できるまで待つのは、待ちすぎというものである。
プロジェクトはすでに重いコストを負っていて、先延ばしにすると変更するのがより
困難になる。対象となるコードには今より手が入り、さらに多くの他のコードに組み込まれることになるからだ。

継続的なリファクタリングは「ベストプラクティス」と考えられるようになってきたが、
ほとんどのプロジェクトチームは依然として慎重すぎる。コードを変更するリスクと、変更にかかる開発者の時間のコストを見込んでいるためだ。

しかし、それほど簡単に見抜けないのが、設計をぎこちないままにしておくリスクと、
その設計を何とかするためのコストである。

リファクタリングを行いたい開発者は、その決定が正統なものであると証明するよう求められることが多い。
こうした要求は理にかなっているように見えるが、もともと難しいものを不可能なほど難しくして、
リファクタリングを抑制する（または見えない所で行わせる）傾向がある。

ソフトウェア開発は、変更することで得られる利益や変更しないことで生じるコストを
正確に割り出せるような、予測可能なプロセスではない。

**仕様書無しさん** · 2018/04/19(木) 07:16:17.90

リファクタリングがだめなのではなく
おまえらがやるからだめなのだ

**仕様書無しさん** · 2018/04/19(木) 07:34:45.44

>>144
駄目コード（ウィルスみたいなもん）をばら撒いてから治療なんて無理だからねえ。

**仕様書無しさん** · 2018/04/19(木) 08:13:02.34

結局は客がデグレを笑って許してくれるかどうかな気がしてきた

**仕様書無しさん** · 2018/04/19(木) 09:20:08.21

でかくてモノリシックなシステムを複数のマイクロサービスにリファクタリングしたけど、
デグレなんて起きなかったな

**仕様書無しさん** · 2018/04/19(木) 09:40:04.23

>>147
だからデグレは複雑なコードのまま変更するほうが
リスク高いんですってばw

**仕様書無しさん** · 2018/04/19(木) 09:44:31.35

>>149
リファクタリングは処理の内容を変えないで
コードをわかりやすく再配置するだけだから
デグレのリクスはすごく低いんだよね

>>145
リファクタリングがだめなのではなく
闇雲に修正するのがだめなのだ

**仕様書無しさん** · 2018/04/19(木) 10:41:14.32

>>150
> リファクタリングは処理の内容を変えないで
> コードをわかりやすく再配置するだけだから

外側は変えないけど内容は変えますよ
なに言ってるんですか

**KAC** · 2018/04/19(木) 15:09:42.31

>>149
難解なコードを読み解いて修正前に正しく把握するのは難しいという主張？

**仕様書無しさん** · 2018/04/19(木) 16:40:47.18

リファクタ厨はその時々でリファクタリングの定義を変えるので話にならない
正反対のことを平気でメリットとして主張してくる

**仕様書無しさん** · 2018/04/19(木) 20:32:34.99

>>144
わからないことや見えないことを逆に肯定理由にする
宗教家と同じ手口だな！

**仕様書無しさん** · 2018/04/19(木) 21:36:48.00

ある程度経過したコードは捨てろ。
リファクタなんぞせず。

さらにある程度経過したシステムは捨てろ。
リファクタなんぞせず。

**仕様書無しさん** · 2018/04/19(木) 21:39:51.72

>>151
実装は変えるけど、処理の内容は変えませんよｗ
処理の内容っていうのは、1から1000までの数を足すとかいうことです。

forループを使うとか、計算式を使うっていうのは
実装であって処理の内容じゃありません

**仕様書無しさん** · 2018/04/19(木) 21:40:23.43

>>152
> 難解なコードを読み解いて修正前に正しく把握するのは難しいという主張？

違う。時間がかかるという主張

**仕様書無しさん** · 2018/04/19(木) 21:45:12.79

コーダーの時間が現実のリスクとのトレードオフに値するだろうか？

**KAC** · 2018/04/19(木) 21:49:39.33

>>157
解読せずにリファクタリングすると酷いことになるだけだぞ？

**仕様書無しさん** · 2018/04/19(木) 21:52:17.10

>>156
どのように実装するかというのが処理の内容だから
リファクタリングで変更しないのは外部仕様な
内側は変えていいんですよ

**仕様書無しさん** · 2018/04/19(木) 21:56:06.09

改修のためのリファクタリングって15年前ぐらいの考え方
今さら熱く語るようなトピックでもない

**仕様書無しさん** · 2018/04/19(木) 21:57:46.81

>>159
> 解読せずにリファクタリングすると酷いことになるだけだぞ？

リファクタリングする時に解読しないなんて誰が言ったの？

そもそも解読が必要になってるのはリファクタリングしてなかったからなんだが、
まあそんなこと言ってもしょうがない。過去の話だ。

今手元にあるのは解読が必要なほど複雑なコード
リファクタリングをしないということは、複雑なコードをそのままに
さらに複雑にする行為。それをレビューしてもらったって、できるわけがない。
なにせ解読が必要なほど複雑なコードなんだから、

そして、せっかく時間を書けて解読しても、その解読をコードに反映させないなら
次回修正する時にまた時間がかかる。そして次回修正はそんなに先のことじゃないかもしれない
なぜなら複雑なコードをさらに複雑にしたのだから、デグレのリスクも高い

せっかく時間かけて解読したのだから、それをコードに反映（リファクタリング）させましょう。
読むのは時間かかるが、書くのは大して時間はかからない。
そうすれば、リファクタリングしなかった場合の時間がかかるという問題が解決できる。

何回も同じこと言ってるんだけどなｗ

**仕様書無しさん** · 2018/04/19(木) 22:01:18.70

あと解読するときも、最初から最後まで想像して解読するよりも
簡単なところから一歩ずつやったほうがいいよ

**仕様書無しさん** · 2018/04/19(木) 22:06:50.19

>>161
リファクタ病患者の闘病のために必要

**仕様書無しさん** · 2018/04/19(木) 22:07:26.56

>>164
君みたいに突っかかってるやつのためだよｗ

**仕様書無しさん** · 2018/04/19(木) 22:11:04.54

まったり普通にまともなこと言っても誰も相手してくんないし

**仕様書無しさん** · 2018/04/19(木) 22:23:27.27

本質的に複雑なものはどうやったって複雑なので、考えるべきは複雑さをどこに押し込めるかだ
複雑な処理もリファクタリングすればシンプルになると信じてる奴は、まあ本質的には簡単なことしかやってないんだろう
例えば、SQLがわからないユーザーのために、DBにUIを提供するだけのCRUDアプリとか

**仕様書無しさん** · 2018/04/19(木) 22:25:12.05

関数レベルのリファクタリングじゃ抜本的な設計改善にはならないからなぁ
やらないよりはやった方がいいけど、まぁ趣味の話だな

**仕様書無しさん** · 2018/04/19(木) 22:29:02.98

>>167

> 例えば、SQLがわからないユーザーのために、DBにUIを提供するだけのCRUDアプリとか

あんたは複雑なことをしたいのかもしれないけど
仕事なんだから客が求めるものを作るべきでは？

客は本質的に複雑なものばかり、求めてるんですか？
客が求めてるものは簡単なものばかりですよ。

**仕様書無しさん** · 2018/04/19(木) 22:34:00.95

>>168
設計ってどこまで含んでいってる？
クラス設計は？どういうメソッドが有るとか
どういう階層をしているかとか

**仕様書無しさん** · 2018/04/19(木) 22:36:08.75

データベース設計なら、まんまデータベースリファクタリングって
本があるけどもう売ってないな

**仕様書無しさん** · 2018/04/19(木) 22:48:51.20

>>169
本質的に簡単なことって、頑張れば誰にでもできるじゃん？
実際、キャリアの少ない若手プログラマだって、先輩やらの手助けを受けつつもちゃんと動くコードを書いて納品してるわけで

たかだか数年の経験しかないプログラマにでもやれなくはない程度の仕事を、ああだこうだいって多少整理された状態に
持っていくのがお前の言うリファクタリングでしょ？
まぁ誰かがやらなきゃいけない仕事なんだろうけど、それって汚いコードを書く奴の尻拭い以上のものではないし、
ドヤって語るほどのもんでもないように思うけどなー

**仕様書無しさん** · 2018/04/19(木) 23:02:09.88

改修後に予定されているテストでカバーできる範囲でリファクタするというのは
ひとつの答えのようにおもえる

あとはリファクタしたほうが本当にましになってるのかという問題

**仕様書無しさん** · 2018/04/19(木) 23:05:48.73

>>172
> 本質的に簡単なことって、頑張れば誰にでもできるじゃん？

本質的に簡単なことって、頑張れば（＝コストと時間をかければ）誰にでもできるよ？

でもそれじゃだめだよね
コストと時間がかかってるんだから

**仕様書無しさん** · 2018/04/19(木) 23:05:50.09

リファクタじゃなくてリジェクト

**仕様書無しさん** · 2018/04/19(木) 23:07:11.05

関係ないけど安定した共通化部分から
関数抽出して使いまわしたいんだけど
やっていいもんじゃろか？

**仕様書無しさん** · 2018/04/19(木) 23:13:04.60

>>173
将棋でも自分の指した手がいい手かどうかわからない人いるよね。
初心者？上級者？

マシになってるかどうかわからない？
将棋で言えばどっちかな？

自分の指した手が良いかどうかわからないってことは
恥ずかしいことだと思ったほうが良い。

まあ、初心者なら仕方ないけど、そういう人は
コードメトリクスを計測したら良いよ。
客観的に良いか悪いかを判断してくれる。

**仕様書無しさん** · 2018/04/19(木) 23:16:49.13

>>177
>自分の指した手が良いかどうかわからないってことは
>恥ずかしいことだと思ったほうが良い。

やっぱりやらないに越したことはないな！

**仕様書無しさん** · 2018/04/19(木) 23:28:59.50

>>178
なんで？
そういう人はコード書いたらダメだって言ってるんだけど？

**仕様書無しさん** · 2018/04/19(木) 23:30:15.83

料理が下手な人は料理をしないほうが良い

**仕様書無しさん** · 2018/04/19(木) 23:33:30.35

人の問題なのか、技術の問題なのか
その区別ぐらいはできるだろうけどな

俺が運転すると事故るから
車はだめだみたいな。

**KAC** · 2018/04/19(木) 23:44:08.24

>>162
改造するのは解読に時間がかかる
リファクタリングすると解読に時間がかかる

で、何がメリットだって主張？

**仕様書無しさん** · 2018/04/19(木) 23:53:59.72

>>182
二行目が繋がってない、つまらんからやり直して。

**仕様書無しさん** · 2018/04/20(金) 00:03:23.46

>>182
コピペしろって言ってる？

162 自分：仕様書無しさん[sage] 投稿日：2018/04/19(木) 21:57:46.81
>>159
> 解読せずにリファクタリングすると酷いことになるだけだぞ？

リファクタリングする時に解読しないなんて誰が言ったの？

そもそも解読が必要になってるのはリファクタリングしてなかったからなんだが、
まあそんなこと言ってもしょうがない。過去の話だ。

今手元にあるのは解読が必要なほど複雑なコード
リファクタリングをしないということは、複雑なコードをそのままに
さらに複雑にする行為。それをレビューしてもらったって、できるわけがない。
なにせ解読が必要なほど複雑なコードなんだから、

そして、せっかく時間を書けて解読しても、その解読をコードに反映させないなら
次回修正する時にまた時間がかかる。そして次回修正はそんなに先のことじゃないかもしれない
なぜなら複雑なコードをさらに複雑にしたのだから、デグレのリスクも高い

せっかく時間かけて解読したのだから、それをコードに反映（リファクタリング）させましょう。
読むのは時間かかるが、書くのは大して時間はかからない。
そうすれば、リファクタリングしなかった場合の時間がかかるという問題が解決できる。

何回も同じこと言ってるんだけどなｗ

**仕様書無しさん** · 2018/04/20(金) 02:23:37.72

>>184
冗長な文章だな

**KAC** · 2018/04/20(金) 07:25:56.11

>>184
リファクタリングに時間がかかるって主張だよな？

**仕様書無しさん** · 2018/04/20(金) 14:41:02.18

数字を入力するのにテンキー使う奴の地雷率は100%

**仕様書無しさん** · 2018/04/20(金) 19:02:31.75

ソフトウエアの問題は
どんなに技術的に見えようとも
人間の問題である

って偉い人が言ってた

**仕様書無しさん** · 2018/04/20(金) 19:05:43.41

>>188
(底辺ではなwww)

が抜けてる

**仕様書無しさん** · 2018/04/20(金) 21:52:25.40

問題というのは人間の主観的認識なのだから
人間の問題でない問題などというものがあろうか？

**仕様書無しさん** · 2018/04/20(金) 23:16:13.44

>>186
> リファクタリングに時間がかかるって主張だよな？

なんでそう何度も曲解するの？
わざとだよね？

時間がかかるのは、コードの修正。
リファクタリングしなくても時間がかかる

**仕様書無しさん** · 2018/04/20(金) 23:20:25.44

正確に言えばコードの修正を始めるまでの
コードを解析している時間だな

たった一行の修正なのにこんなにするんですか！？って
言われるぐらいの費用になるのは、"コードのタイピング"には
含まれない部分がたくさんある

**KAC** · 2018/04/20(金) 23:23:17.89

>>192
で、コードを解析する時間は
　リファクタリング　＞　一部修正
だって理解できないの？

「リファクタリング終わったコードを修正する時間は短い」
という主張に誤りは無いが、
リファクタリングする時間を無視してどうする。

**仕様書無しさん** · 2018/04/20(金) 23:23:47.05

>>190
そういうレベルの人はコードメトリクスを計測するツールを使ったほうが良い
ツールで問題が有るとされたコードはほぼ確実に問題が有る

**仕様書無しさん** · 2018/04/20(金) 23:28:17.97

>>193
> で、コードを解析する時間は
解析する時間って言ったのに、お前

↓
>　リファクタリング　＞　一部修正

修正する時間に話がすり替わってるじゃんｗ

解析する時間、すなわち複雑なコードをよんで
それがなにを意味しているか、どう書換えれば
正しく動くかを、考える時間は

リファクタリングしながら解析する時間　＜　一部修正のために解析する時間

こうだからな。

ぐちゃぐちゃに絡み合った紐の束から、少しづつ結び目をときながら、
適切な一本を抜き出すのと、結び目をとかずに適切な一本だけを抜き出すの
どちらが簡単なのかを考えればわかるだろ
スパゲティコードとはよく言ったものだｗ

**仕様書無しさん** · 2018/04/20(金) 23:42:05.55

>>194
それはそれでわかったが

言ったことの返答にもなってない
話のつながりが見えない
レベルが何を指すのかわからない
問題が何を指すのかわからない

リファクタする奴は思考が支離滅裂だな

**仕様書無しさん** · 2018/04/21(土) 00:05:35.08

あぁ、問題は全て、人間の主観的な問題！というのが間違いだよ、
客観的な問題も有るよっていったのが通じてないのか
話が分からんやつは困るな

**KAC** · 2018/04/21(土) 00:14:22.07

>>195
お前さん、開発したこと無いの？

一部の修正の為に必要な解析情報量と
リファクタリングに必要な解析情報量の
違いすらわからないなら
解析の仕方がおかしいか、
内容を十分理解せずにリファクタリングしてるって事。

**仕様書無しさん** · 2018/04/21(土) 00:17:57.77

>リファクタリングしながら解析する時間　＜　一部修正のために解析する時間

個人的経験から断固として異議を唱えたい

**仕様書無しさん** · 2018/04/21(土) 00:19:59.16

>>199
もしかしてリファクタリング、溜まってるんですか？

**仕様書無しさん** · 2018/04/21(土) 00:21:01.32

>>196
リファクタ厨は毎回そんなもんだよ

**仕様書無しさん** · 2018/04/21(土) 00:23:24.27

つーかさ、誰も100%納得がいくまで
リファクタリングしろなんていってないんだよ。
修正する所、どちらにしろテストが必要な所
関係がある所を、少しづつやればいい。

時間がかかるっていうのは、それはいつも手遅れの
コードばかりだって自覚有るからじゃねーの？

**仕様書無しさん** · 2018/04/21(土) 00:24:30.08

でもメリットが欠片も見えないな

**仕様書無しさん** · 2018/04/21(土) 00:25:43.38

>>142でも書いたが、
リファクタリング＝大規模なものしかイメージできてないって
状態がそもそもやばいよ

142 自分：仕様書無しさん[sage] 投稿日：2018/04/19(木) 00:37:19.05
>>141
重要なのは手遅れになる前にこまめにやることだよね

大規模リファクタリングなんてのはあってはだめ
リファクタリングだけのための作業なんて持っての他

そうやって手遅れにするから、リファクタリングのための
工数なんて取れるかーみたいな話になる

リファクタリングは、機能追加や変更に伴う作業に
含まれているべきものですよ

**仕様書無しさん** · 2018/04/21(土) 00:26:03.25

>>203
何度も書いた。コピペしかしないよ？

**仕様書無しさん** · 2018/04/21(土) 00:26:42.60

リファクタリングをしたから具体的にどういうコードがどうなってそれでどのくらい得になるのかわからない

**仕様書無しさん** · 2018/04/21(土) 00:27:48.92

>>205
え？説明になってないじゃん

**仕様書無しさん** · 2018/04/21(土) 00:28:36.97

>>206
そういう実例が書いてある本を紹介すればいいの？

**仕様書無しさん** · 2018/04/21(土) 00:29:13.26

>>207
ん？すでに過去レスで書いたって言ってるんだけど、
お前はどのレスが「説明」だと思ったの？

**仕様書無しさん** · 2018/04/21(土) 00:29:45.71

肝心のマーチン本からして何が得なのかよくわからん有様

**仕様書無しさん** · 2018/04/21(土) 00:31:35.22

本読んでもコードがどうなるかも分からんの？

**仕様書無しさん** · 2018/04/21(土) 00:33:26.89

理解がちょっとづつ歪んでいくな
リファクタでも同じように処理をちょっとずつゆがめて気が付かずにいるにちがいない

**仕様書無しさん** · 2018/04/21(土) 00:33:29.19

>>209
いや、ここまでそんなレス1つも無いから

**仕様書無しさん** · 2018/04/21(土) 00:35:02.56

https://blogs.yahoo.co.jp/mathweather4067/5819997.html

> 指導のポイント
> ここの指導は、難しい。なかなか理解されないのが、現状です。
>
> まずは、「等式の性質」を思い出させることが必要でしょう。
>
> 次に、「１次方程式の解法」も思い出させます。
>
> その後、１次方程式の解法と対比させながら、進めていきます。
>
> 「等式の変形」は、等式をその目的に応じて変形することの良さが理解できていないと、
> 何のためにするのかがわからないまま、機械的に進めてしまいます。
>
> 導入部分を大事にしたいですね。

まさにコレだな

**仕様書無しさん** · 2018/04/21(土) 00:35:26.46

>>213
でも説明なってないと判断したレスがあるわけでしょう？

**仕様書無しさん** · 2018/04/21(土) 00:35:28.22

>>212
自分の都合のいいように捏造と曲解ばっかりしてるよね
一度もまともな実績がないくせに何で役に立つって言うんだろうね
どうせ数字も捏造してんだろう

**仕様書無しさん** · 2018/04/21(土) 00:38:32.40

>>216
曲解って俺が先に指摘したんだけど、
言われて悔しかったからって自分も使おうとしないでよｗ
どれが曲解かを指摘してない以上意味ないよ

**仕様書無しさん** · 2018/04/21(土) 00:42:39.66

いやリファクタ野郎のことね

**仕様書無しさん** · 2018/04/21(土) 00:43:50.39

お前のことだよｗ

**仕様書無しさん** · 2018/04/21(土) 00:45:19.25

>>214
そいつの説明が悪すぎる、良さってなんやねん

理解してもらえないのではない
自分が理解もせずに良いものだと思い込んでいるだけだ

本当に理解してたら必要性や可能になることを明確に説明できるはず

**仕様書無しさん** · 2018/04/21(土) 00:53:21.22

本当に理解している本の作者が
十分以上に説明してるんだけどなぁ

**仕様書無しさん** · 2018/04/21(土) 00:57:49.37

修正ってほんの数行程度なのに対して
リファクタリングってほぼ全域書き換えでしょ？
そりゃ影響範囲が違いすぎるよ