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

■ このスレッドは過去ログ倉庫に格納されています
2018/04/15(日) 13:13:44.63
機能追加や変更した時に、全部テストしてるでしょ？
いつもやってることじゃん
2018/04/18(水) 02:00:52.61
>>101
あと仕様変更がないってことだろうね。

仕様変更があれば、少なからず設計を変更することになるから
2018/04/18(水) 03:09:17.61
>>102
OCPができてないから仕様の変更がいろんなところに波及するんだよ
あとから直せばいいやじゃなくて、もう少し基本を身に付けよう
2018/04/18(水) 03:41:28.10
>>103
最初から何でも考慮した過剰な設計は止めましょう
こっちが基本ですよ？ｗ
2018/04/18(水) 07:33:52.26
言語からスクリプト言語が呼べるようにしておけば汎用性は無限
バグも無限
2018/04/18(水) 07:50:27.25
>>98
リファクタの状況的にはありだけど

それって関数全体に手が入ってるわけだから改修量同じじゃないじゃん
テストで検出できない非機能要件を踏んじゃうリスクは明らかに増えてるよね？
2018/04/18(水) 10:52:23.05
数年経ってもリファクタバカは相変わらずだなｗ
未だに賛同者が現れないｗｗｗｗ
しかも、リファクタリングそのものではなく、リファクタバカに対する非賛同が増殖ｗ

かたやリファクタすら許してもらえない信用と立場のリファクタバカが相変わらずの状態
かたや５年以上で完全に新規で作り直しの許可を与えられるようになった俺

技術書に溺れなくてよかった・・・。
108KAC
垢版 |
2018/04/18(水) 12:55:46.41
>>98
あぁ、そういう事か。
「リファクタリング」という範囲のイメージが合ってなかったんだな。

関数単位のリファクタリングならそのイメージでだいたい合ってる。

「外部インタフェース変えずに内部の設計から見直す」事を前提に話してたよ。


それはそうとして、
関数の処理削減などで処理速度が変わったのなら、同期など含めてその観点での試験はちゃんとやれよ？
2018/04/18(水) 18:26:19.09
>>107
意味がわからない
お前、どっち派？
2018/04/18(水) 19:52:23.21
関数レベルのリファクタリングしか語れないレベルだということはお察し
2018/04/18(水) 21:09:41.94
おれは何も察することができんのだが
2018/04/18(水) 22:40:51.02
>>106
> それって関数全体に手が入ってるわけだから改修量同じじゃないじゃん
> テストで検出できない非機能要件を踏んじゃうリスクは明らかに増えてるよね？

関数の中の1行を変えたとして、
その1行だけをテストして関数全体OKってできるんですか？

そもそも関数の中の1行だけをテストすることは不可能だと思います。

結局関数全体をテストするわけでしょう？
2018/04/18(水) 22:42:05.86
>>108
> 関数の処理削減などで処理速度が変わったのなら、同期など含めてその観点での試験はちゃんとやれよ？

もともと修正すべき関数なんだから、リファクタリングしなくても
テスト必須でしょう？ なにを言ってるんでしょうか
2018/04/18(水) 22:50:36.63
>>112
でもさ
ソースで見たとき処理の下の方をちょっと修正すればいいところで
上の方の関係なさ気な箇所がバグったら言い訳できねぇよ
差分見て

何でここ弄ったの？今回の修正と関係ないじゃん

って言われたらちょっと嫌な空気流れるよ
2018/04/18(水) 22:52:17.90
>>106
> それって関数全体に手が入ってるわけだから改修量同じじゃないじゃん
「可読性」って言葉ご存知ですか？

「可読性」の二番目の文字は「読」です。
「書」ではないのです。

改修は「書く」ことですが、改修前には「読む」こと必須です。
では書く時間と読む時間、どちらが多くかかりますか？

もちろん読む方ですよね？
タイピングなんて1分間に200〜300なんて軽く行く

改修の書く量だけを見ても正解にはたどり着けませんよ。
改修量ではなく作業始めてからの改修時間を見るのが筋じゃないですかね？

リファクタリングは改修時間を短くします。
2018/04/18(水) 22:53:03.68
>>114
関係ない所を修正するのがいけないのでは？ｗ
2018/04/18(水) 22:58:24.94
>>112
具体的なシナリオをいうとだ

日付をこりこり自前でデコードして値つくってる１００行近いまぬけコードを
Ｊａｖａのライブラリつかって数行にしてホルホルしてたら
ついうっかり見たことないようなフォーマットも受け入れちゃうようになってて
そんなん存在もわかんないからテストしてるわけなくて
でもユーザーは何の気なしに入れちゃうと入るからそのまま入れて、想定と異なるへんなデータが蓄積していって
集計バッチの演算とかにちょっとづつ毒虫のように影響を与え続けて
気が付いたらえらいことになってたりとか
2018/04/18(水) 23:00:32.39
>>115
理解できたらもとに戻してもいいのよ？
119KAC
垢版 |
2018/04/18(水) 23:03:03.55
>>113
修正内容に応じてテスト観点増やさないの？
費用対効果考えながらテスト計画立てないと破綻するぞ？
2018/04/18(水) 23:04:52.45
>>117
それはリファクタリングしなくても起こる話ですね。

何度も言うように、そこが修正箇所です。
リファクタリングしなかったとしても修正する場所です。

修正して、ついうっかり見たことないようなフォーマットも受け入れちゃうようになってて
そんなん存在もわかんないからテストしてるわけなくて
でもユーザーは何の気なしに入れちゃうと入るからそのまま入れて、想定と異なるへんなデータが蓄積していって
リファクタリングと何の関係もない話ですよね

>>118
> 理解できたらもとに戻してもいいのよ？
次修正する時、また改修時間（読む時間）がかかりますよね？
2018/04/18(水) 23:06:20.06
>>118
もとに戻すと改修時間（読む時間）が無駄になるだけですね。
次回修正するときも、また改修時間がかかります。

バグが見つかったら、また改修時間がかかります。
2018/04/18(水) 23:07:43.72
>>119
> 修正内容に応じてテスト観点増やさないの？

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

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

どれくらい影響があるか、それはコードが複雑であれば
有るほど不明です。
123KAC
垢版 |
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

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

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

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

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

ソフトウェア開発は、変更することで得られる利益や変更しないことで生じるコストを
正確に割り出せるような、予測可能なプロセスではない。
145仕様書無しさん
垢版 |
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
> リファクタリングは処理の内容を変えないで
> コードをわかりやすく再配置するだけだから

外側は変えないけど内容は変えますよ
なに言ってるんですか
152KAC
垢版 |
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
コーダーの時間が現実のリスクとのトレードオフに値するだろうか？
159KAC
垢版 |
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
人の問題なのか、技術の問題なのか
その区別ぐらいはできるだろうけどな

俺が運転すると事故るから
車はだめだみたいな。
182KAC
垢版 |
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
冗長な文章だな
186KAC
垢版 |
2018/04/20(金) 07:25:56.11
>>184
リファクタリングに時間がかかるって主張だよな？
2018/04/20(金) 14:41:02.18
数字を入力するのにテンキー使う奴の地雷率は100%
2018/04/20(金) 19:02:31.75
ソフトウエアの問題は
どんなに技術的に見えようとも
人間の問題である

って偉い人が言ってた
189仕様書無しさん
垢版 |
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
正確に言えばコードの修正を始めるまでの
コードを解析している時間だな

たった一行の修正なのにこんなにするんですか！？って
言われるぐらいの費用になるのは、"コードのタイピング"には
含まれない部分がたくさんある
193KAC
垢版 |
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
あぁ、問題は全て、人間の主観的な問題！というのが間違いだよ、
客観的な問題も有るよっていったのが通じてないのか
話が分からんやつは困るな
198KAC
垢版 |
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%納得がいくまで
リファクタリングしろなんていってないんだよ。
修正する所、どちらにしろテストが必要な所
関係がある所を、少しづつやればいい。

時間がかかるっていうのは、それはいつも手遅れの
コードばかりだって自覚有るからじゃねーの？
■ このスレッドは過去ログ倉庫に格納されています
5ちゃんねるの広告が気に入らない場合は、こちらをクリックしてください。
ニューススポーツなんでも実況