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

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

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

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

それなｗ

あと、リファクタリングするとお前責任取れるのかとか言ってくるが
機能修正でバグった時の責任はリファクタリングじゃないんだから
全部あんたがとれよって言うと顔真っ赤になるｗ

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

半角カナを使う奴まだいたのか

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

スレタイ長くて入らないからね

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

簡潔にまとめられない奴はプログラミング向いてない

**仕様書無しさん** · 2018/04/15(日) 14:07:43.60

そんなことない
なんでもかんでも一緒にするな

**KAC** · 2018/04/15(日) 14:29:02.33

>>1
テスト粒度とかリスクとか理解できないの？

**仕様書無しさん** · 2018/04/15(日) 14:43:15.84

リファクタリングはテスト必須で
論理的におかしくならないと判明している
決められたやり方でやるので
リスクは低いしテストは自動化されています。
その前提ぐらい知らないんですか？

**仕様書無しさん** · 2018/04/15(日) 14:45:55.12

>>8
だからテストやらなくていいって？
そもそもクラスまで作り変えてるならテスト免除どころか設計書のレビューからだよね

**仕様書無しさん** · 2018/04/15(日) 14:46:35.64

>>9
リファクタリングは「テストをやってる」ことが
前提なので、
あんたが言ってるのは別のものでは？

**仕様書無しさん** · 2018/04/15(日) 14:47:26.22

> そもそもクラスまで作り変えてるならテスト免除どころか設計書のレビューからだよね

そうですね？　なんでレビューせずに
リファクタリングするなんて思い込んでんの？

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

> リファクタリングはテスト必須で

って書いてあるのに

↓

9 返信：仕様書無しさん[sage] 投稿日：2018/04/15(日) 14:45:55.12
>>8
だからテストやらなくていいって？

これもう頭が悪いレベルだろｗ

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

リファクタリングの存在を否定できないと
困る人がいるんですよｗ

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

設計書から書き直すならただの改修作業なんだよね？

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

>>14

改修作業の中身の違い

　1. 無計画に適当に修正して手動でテストしてそれでもバグでて苦労するのと
　2. リファクタリングの手法を使ってテストコード書いて低リスクで修正するかの違い

**仕様書無しさん** · 2018/04/15(日) 16:11:52.19

>>15
具体的にどう違うの？

**仕様書無しさん** · 2018/04/15(日) 19:48:05.09

>>15
TDDでリファクタリングした場合、
1、初歩的なミスにすぐ気付ける
2、作業者が精神的に安心できる

なお、開発者目線の開発体制の優先順位は
バージョン管理 > コードレビュー > 自動テスト > リファクタリング
なので、必ずリファクタリングとTDDはセットになる

**仕様書無しさん** · 2018/04/15(日) 19:48:54.60

>>16
リファクタリングの手法では先に自動化されたテストコードを書く
もしくはすでに存在していなければならない
だから、リファクタリングしたらテストしろよっていうのは意味不明。

リファクタリングの中にテストすることが条件として含まれており
修正前と修正後の両方、それどころか修正のたびにテストすると言ってるのに
なんでそんな当たり前ことを、それも最後だけテストするような質問をするんだ？と
疑問になる

おそらく修正とテストが分離した考え方しか持って無くて
修正後に手動でテストを行うというやり方しか知らないのだろう
そんな再現性がなくてテスト回数もすくないんじゃ、
バグがなかなか取れずにデスマになるのは必死だろう

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

>>17
工数も削減できないし
品質も上がらないんだ？ｗ

**仕様書無しさん** · 2018/04/15(日) 21:17:10.48

なにをゆうちょるんじゃあ主は

**仕様書無しさん** · 2018/04/15(日) 21:37:54.42

リファクタリング厨って受け売りでしか語らないから面白くない

**仕様書無しさん** · 2018/04/15(日) 23:16:16.00

ゴミスレ

**仕様書無しさん** · 2018/04/16(月) 05:06:44.38

オープニングから自演ｗ

**仕様書無しさん** · 2018/04/16(月) 05:08:34.00

>>21
というか、責任あるポジションの経験がないやつが語ってるだけだからな
ちゃんと決定権を持つやつを納得させるだけの説明ができればいいだけだが、
それすらできていないっつーね

**仕様書無しさん** · 2018/04/16(月) 06:25:24.08

>>2
責任とって辞めます。

**仕様書無しさん** · 2018/04/16(月) 12:37:10.95

>>19
そこらへんの話でいうと、
売上や品質が上がった客観的なデータが示せりゃ、どの会社でも自動テストやリファクタリングは採用されるんよ
そこまでしてないなら、その議論は語るに値しない
んで、殆どの会社はそこを検証していない

**仕様書無しさん** · 2018/04/16(月) 12:45:59.35

>>26
そんなもん、やってみりゃ肌で感じ取れること
数値にしなきゃ理解できないよぉとかバカみたいなこと言ってると腕のいい職人にはなれませんよ？？

**仕様書無しさん** · 2018/04/16(月) 13:26:59.58

>>27
数値にできる学がねぇんだろｗ
数値化しろよ

**仕様書無しさん** · 2018/04/16(月) 13:36:47.19

>>27
仕事を規定の時間内に許容できる品質のものを上げるのが実装者に求める要求で、それに付随する手段は手段でしかない。
で、手段は自由にやればいいし、基本介入しないし、結果しか見る気は無い。
だからやりたければやれば？としか自分は言わない
工数増えるのは論外

**仕様書無しさん** · 2018/04/16(月) 14:37:58.22

>>26
> そこまでしてないなら、その議論は語るに値しない
> んで、殆どの会社はそこを検証していない

検証しろっていうのはわかるが、それは世間一般には
すでに検証されていてすでに品質が上がったというデータは出てるんだよな

それも検証するコストも出せないような会社がやるような中途半端な
方法じゃなくて、もっと大規模で信頼できる方法で検証した結果がすでにある。

で、それを参考にすりゃいいのに、参考にしないんだろう。
つまり他人を信用してない。だから他人がなにやってもどんなデータを出しても
そういう会社は信用しないんだろう。

**仕様書無しさん** · 2018/04/16(月) 14:41:43.64

リファクタリングが有効かどうか？
検証してやるよ。コスト？そりゃ当然かかるよ

ここで嫌がる会社が多い

重要なのは、失敗するかもしれないがやってみよう
という考えが通じる会社かどうかなんだろうな

**仕様書無しさん** · 2018/04/16(月) 14:52:53.46

体力がなくて単純工すらできないごみクズがIT技術者(笑)になる日本では
コストメリットどころかリスクしかない。

**KAC** · 2018/04/16(月) 17:54:10.17

「リファクタリングしたら工数減ります」
「リファクタリングの為の工数ください」

うん。意味不明だね。

**仕様書無しさん** · 2018/04/16(月) 18:19:38.72

> 「リファクタリングの為の工数ください」

誰もそんなこと言ってないけど？

>>31が言ってること勘違いした？
リファクタリングが有効かどうかの検証の話だよ。
検証するには、同じことをリファクタリグをするのと
しないので2回やらないといけない。
検証にはコストがかかる。

**仕様書無しさん** · 2018/04/16(月) 19:00:22.44

>>28
俺の筋肉量でリファクタリングの効果を説明できる

**仕様書無しさん** · 2018/04/16(月) 19:33:16.67

>>34
いや、リファクタリングで総工数が減るなら勝手にやればいいだけじゃね？
リファクタリングで品質下がるなんて聞いた事無いわけだし。それとも単体テストレベルまでがっちり管理されてんの？

**仕様書無しさん** · 2018/04/16(月) 19:50:39.52

リファクタリングで増減する工数って、内部設計クラスレベル～クラステストまででしょ
詳細設計省かずやる巨大案件でも無い限り、実装者に委ねられる部分やん。
ともすれば、やりたきゃやれって回答にしかならん。

**仕様書無しさん** · 2018/04/16(月) 20:03:20.01

>>36
> いや、リファクタリングで総工数が減るなら勝手にやればいいだけじゃね？

俺はやってるよ。リファクタリングで工数減るから
そもそも修正作業の中に自動的に組み込まれるものだから
あえて "リファクタリング単体で" 工数を取るなんてことはしない

だからリファクタリングのために工数くださいっていう発想が
そもそも間違ってるわけ。修正に伴う追加作業じゃない。
修正作業そのものなんだから

**仕様書無しさん** · 2018/04/16(月) 20:08:32.88

仕組みが悪いからって正常に動いてる箇所まで手を入れるってねーな

**仕様書無しさん** · 2018/04/16(月) 20:37:02.97

リファクタ自体は否定しないが、>>１は確実に技術に溺れて盲信してるアホだから許可出さない

**仕様書無しさん** · 2018/04/16(月) 21:02:09.30

>>39
正常に動いていると証明するテストをしてないってこと？

正常に動いていることを証明するテストを修正後にもやれば、
正常に動くと証明できるでしょう？

**仕様書無しさん** · 2018/04/16(月) 21:03:03.43

>>40
修正許可与えてるなら、どんな修正をしたとしても
許されるはずだけど？

**仕様書無しさん** · 2018/04/16(月) 21:22:15.99

>>38
修正が発生したときにしかリファクタしないの？

**仕様書無しさん** · 2018/04/16(月) 21:24:48.73

修正ってなんだよ、バグってんのか
機能追加だろうがなんでも修正って言う奴は素人でしょ

**仕様書無しさん** · 2018/04/16(月) 21:26:39.53

ただのレッテル張りじゃねえかｗ

**仕様書無しさん** · 2018/04/16(月) 21:27:14.47

素人というやつは童貞だ
イカ臭いプログラム書いてろ
と言ってるようなもの

**仕様書無しさん** · 2018/04/16(月) 21:30:14.08

>>43
なんどもリファクタリングは修正の一部だって言ってるじゃん
一部ってことはそれ以外も有るってことだよ

複雑なコードを読み解いて、リファクタリングしないで複雑なまま修正するのと
複雑なコードを読み解いて、リファクタリングしてから修正するのと
どっちがリスクが少ないかって話だ

前者だと、複雑なコードを読み解いた人（修正担当者）がいるにもかかわらず
別の人が、また大変な思いをして読み解いてレビューしなければいけない
そして、次同じところを修正する時、また複雑なコード読み解かなければいけない

**仕様書無しさん** · 2018/04/16(月) 21:32:16.33

みんな実装するだけで精一杯なんよ

**仕様書無しさん** · 2018/04/16(月) 21:33:31.81

リファクタリングは神の領域に達するものにのみ許される技。
素人はおとなしくExcel方眼紙でセル結合の練習でもしておけ。

**仕様書無しさん** · 2018/04/16(月) 21:36:56.37

>>47
そんな入門書の1章に書いてあるような話はいいよ、面白くないから

**仕様書無しさん** · 2018/04/16(月) 21:45:07.82

>>50
入門未満の人がいるんでね

**仕様書無しさん** · 2018/04/16(月) 21:48:55.54

入門レベルの奴でも上から目線になれるから張り切ってんのか

**仕様書無しさん** · 2018/04/16(月) 21:54:14.63

だから>>1にはやらせない

**仕様書無しさん** · 2018/04/16(月) 21:58:29.27

>>37
テストの品質が後工程に無関係ならな。
まあそんな現場が多いのは事実だが。

**仕様書無しさん** · 2018/04/16(月) 22:14:39.29

>>51
リファクタリングするときのレビューとかどうしてる？
設計レビューもだし、コードレビューもだけど

**仕様書無しさん** · 2018/04/16(月) 22:21:54.62

リファクタリングしてるのでNG

**KAC** · 2018/04/16(月) 22:42:11.58

>>47
お前さん、理想通りに開発が進めば
自動試験だけで完璧なものができるとか信じてる？

**仕様書無しさん** · 2018/04/16(月) 23:48:14.82

テストしづらいとか、クラスが肥大化しすぎて開発に支障があるとかならまだしも
見通しが悪いなんて理由でうごいてるもんをほいほい変えていいもんじゃろか

**仕様書無しさん** · 2018/04/17(火) 01:28:22.88

リファクタリングは超プロの領域
このスレには本当のリファクタリングが出来る奴はいない

elseなしに書き換えるのが精一杯のFラン説教野郎みたいなのがいるだけ

**仕様書無しさん** · 2018/04/17(火) 01:37:33.43

大規模リファクタリングの秘孔をついた
お前のプロジェクトはもう死んでいる

**仕様書無しさん** · 2018/04/17(火) 02:47:02.14

>>55
> リファクタリングするときのレビューとかどうしてる？
リファクタリングではないときはどうしてる？
それと同じなんだが。

まあそういう質問するってことはリファクタリングに限らず
そもそも設計もコードもレビューしてないってことなんだろうけど
まずはそこからやねｗ

**仕様書無しさん** · 2018/04/17(火) 02:49:20.05

>>57
> 自動試験だけで完璧なものができるとか信じてる？

だからレビューするんでしょ？

自動試験はバグがないことを証明する手段
その手段が正しいかどうかはレビューでみる。

人手でレビューして、テストした内容も記録されて
後なにがあれば完璧なものができると思います？

**仕様書無しさん** · 2018/04/17(火) 02:51:40.76

>>58
> テストしづらいとか、クラスが肥大化しすぎて開発に支障があるとかならまだしも
> 見通しが悪いなんて理由でうごいてるもんをほいほい変えていいもんじゃろか

機能追加とか修正するという前提なんだから、どちらにしろ変更するしかないでしょｗ

**KAC** · 2018/04/17(火) 08:07:55.30

>>62
自動試験してレビュー通ったらシステムインしてサービス開始すんの？

**仕様書無しさん** · 2018/04/17(火) 08:35:24.00

入門書第1章に書いてあることの受け売りなら長文で語るけど、具体的な話からは煽りで逃げるし、
体験から語ってると思えるような発言もないし、こいつ多分そんなにノウハウないよ

**仕様書無しさん** · 2018/04/17(火) 10:12:11.71

>>64
レビューもするし自動以外のテストもする
そこは普通の機能変更のときとなにも変わらない

ただその時のやり方が、複雑なコードを頑張って解析して
無理やりパッチを当てるような、あとから見た時に
なんでこんな面倒なことしてんの？と思われるような変更をするやり方から、

次回は複雑なコードを読まなくて良いように、複雑なコードを
シンプルに修正しつつ、まるで0からコードを書いた時のように
こういう機能を実現するなら、普通こう書くよねという
当たり前の形にするやり方に変わるだけ

変更するたびに複雑になっていくやり方をやめて
変更しても複雑にならない、むしろシンプルになるような
やり方をしましょうってこと

その後にやるテストうんぬんは、もともと機能変更でやる予定だったんだろ？
なら最初からやるって決まってることじゃないか

**仕様書無しさん** · 2018/04/17(火) 10:12:38.07

>>65
> 具体的な話からは煽りで逃げるし、
ん？どのレス？

**仕様書無しさん** · 2018/04/17(火) 10:13:52.53

レビューってさ
もう儀式になってない？

**仕様書無しさん** · 2018/04/17(火) 10:16:36.37

TDDってさ
組織的にガチガチにやるもんじゃなくて
設計者の間で守るべき密やかな秘密程度で
やったほうが良い気がすんのね。

**仕様書無しさん** · 2018/04/17(火) 11:00:00.11

>>68
それはどんなコード変更のときでもやるべきことだから
リファクタリングの話とは関係ないという注意だけしておくね

**仕様書無しさん** · 2018/04/17(火) 11:05:57.21

>>69
ようは、リファクタリング前に存在するテストコードが
リファクタリング後でも通ることで動きを変えてないことが
証明できれば良いのでTDDである必要はないよ。

具体的にはgit使えば歴史変えられるんで、
コード変更しつつテストコード書いて、
コード変更とテストコードでコミット分けて
あとでrebaseしてテストコードのコミットをコード変更の
コミットより前に持ってくれば良い

**仕様書無しさん** · 2018/04/17(火) 12:12:26.72

>>71
TDDは保護するためのテストじゃないから

**仕様書無しさん** · 2018/04/17(火) 12:23:08.56

>>68
レビューのつもりで儀式やってるだけのところが多いね。

**仕様書無しさん** · 2018/04/17(火) 12:26:04.15

>>72
> TDDは保護するためのテストじゃないから

TDDはテストではなく開発手法ですよ？

TDDという開発手法ではリファクタリングの前にテストを書き
書いたテストが、その後に行うリファクタリングが問題ないことを証明するんですよ

つまり
× TDD = 保護するためのテスト
○ TDD =「保護するためのテスト」を用いた開発手法

（あんたの言った「保護」がリファクタリングで壊さないように守るという意味である前提）

俺が>>71で言ったことは、TDDでやらなくてもテストで保護できると言ったんです。

https://postd.cc/test-driven-development/

> 簡単に言うと、TDDは機能を記述する前に自動テストを書く行為です。
> 例えば、Bobが素晴らしい新たなソーシャルネットワークのアイデアの
> ために新しい機能を開発する必要があるとしましょう。
>
> Bobは自動テストを書くことから始めますが、機能を正しく実装せずに、
> テストを失敗（赤色表示）させます。次に、Bobはテストを成功（緑色表示）
> させるための最小限のコードを記述します。緑色表示になったら、
> Bobはコードをきれいにし、テストを実行して機能が正しく
> 実装されたままであることを確認します（コードのリファクタリング）。
> 重複することなく、コードと自動テストは他の人も簡単に保守できます。

**KAC** · 2018/04/17(火) 13:27:11.82

>>66
えーと、まずはスレタイの
「リファクタリングすると全部テスト」については、
「全部テストするのは当たり前」という理解でOK？

それなら、大筋では意見に違いは無い。

**仕様書無しさん** · 2018/04/17(火) 13:49:22.47

>>75

before（リファクタリングしない場合）
　1. 機能追加やバグ修正などの変更依頼が来る
　2. 変更する
　3. 変更したので全部テストをする

after（リファクタリングする場合）
　1. 機能追加やバグ修正などの変更依頼が来る
　2. 変更する（リファクタリングもする）
　3. 変更したので全部テストをする

afterに対して、余計なことするな！
リファクタリングしたなら全部テストしろ！
と言われましても、beforeでも全部テストしてますよね？という話です。

**仕様書無しさん** · 2018/04/17(火) 15:18:23.57

リファクタリングしたら(その時点で、機能改修する前に)(単体)テストしろって要求なんじゃね？

まあ普通やるけど。

**仕様書無しさん** · 2018/04/17(火) 15:55:33.65

>>77
いやぁ、違うなぁ
リファクタリングさせないための方便として使ってるので
お前がリファクタリングするとテストする人が迷惑するんだぞ
だから余計なことするなという意味だろう。

だがもともとテストするわけで矛盾になるんだよな

**仕様書無しさん** · 2018/04/17(火) 16:16:34.63

>>74
そういうことじゃないんだよなぁ

**仕様書無しさん** · 2018/04/17(火) 16:19:52.69

>>78
違うよ
デグレしたときの徹底的なイジメがヤバイ

**仕様書無しさん** · 2018/04/17(火) 16:59:00.97

>>79
じゃあどういうことか書けよｗ

>>80
でもどっちみちコード変更するんでしょ？
リファクタリングしない方がデグレさせる可能性高いし

**仕様書無しさん** · 2018/04/17(火) 17:34:58.09

リリースしたらあとはそのシステムのことは知らん
だからリファクタリングする気もない

**仕様書無しさん** · 2018/04/17(火) 18:30:58.65

>>81
いやリファクタリングすると触らなくていいとこまで変更するじゃん
既存コードを変更するって時点でまずい

**仕様書無しさん** · 2018/04/17(火) 18:52:07.21

>>83
触らなくていいかどうかが重要なんですか？

重要なのはテストする所かどうかでしょう？
触った所でテストするなら、なにも問題ないはずですが？

**仕様書無しさん** · 2018/04/17(火) 18:54:58.04

>>84
そうはいかねぇだろ
文章化されてないけど
クリアしてるいろんな仕様があんだからよ
長い間運用してるとそういうのあるわけよ

**仕様書無しさん** · 2018/04/17(火) 19:09:26.69

>>84
触らなければテストもしなくていい
プロは余計なコードも書かないし、余計なテストもしない

**KAC** · 2018/04/17(火) 19:26:39.52

>>76
イメージはあってそう（スレ建てた奴とは違う意見）に読めたので、
具体的な内容を書いてみる。

大規模で難解なプロジェクトの一部機能で、
一カ所の編集バッファの数が足りず、
長い氏名の編集に失敗する仕様となっていた。
メモリの使用率なども調査済みで、編集文字数を増やすという仕様変更案件の場合。

バッファサイズを増やして関連箇所の試験して完了。

リファクタリングしたら、統べての試験をやり直し。

リファクタリングの有無でどちらが安いのか、
時と場合によるって認識はあってる？

**仕様書無しさん** · 2018/04/17(火) 20:51:10.01

WFとアジャイルとでも違うし
リファクタリングできる設計になってるの？
も大きな要素だが

動いているなら弄るなよは永遠の真理

**仕様書無しさん** · 2018/04/17(火) 21:08:17.92

>>88
そのレベルの現場が多いもんな。

**仕様書無しさん** · 2018/04/17(火) 22:21:50.39

バッファサイズの変更でなにをリファクタするというんだ

文字編集がややこしいから途中量の計算が難しいから処理変更とか？

**仕様書無しさん** · 2018/04/17(火) 23:28:38.99

>>85

リファクタリングの話は一旦おいておきましょう。

> そうはいかねぇだろ
> 文章化されてないけど
> クリアしてるいろんな仕様があんだからよ

それでどうやってコードを正しく変更できるんですか？
コードを変更する時に文書化されてない仕様を
間違って変えてしまうことがありますよね？

文書化されてない仕様をテストでどうやって
見つけるんですか？

**仕様書無しさん** · 2018/04/17(火) 23:36:25.31

>>87

> バッファサイズを増やして関連箇所の試験して完了。
>
> リファクタリングしたら、統べての試験をやり直し。

え？なんで？先に修正して試験するのがいけないんじゃん

1. リファクタリングをする
2. バッファサイズを増やす
3. 関連箇所の試験して完了

基本はこうですよ？
実際にはこんな大雑把作業じゃなくもう少し細かく
（ユニットテストと）リファクタリングと修正を何回か繰り返しますが

コードの変更とリファクタリングは切り離せません

コードの変更とリファクタリングの間に「関連箇所の試験して完了」
なんてものは入らないし入れたらダメです。

**仕様書無しさん** · 2018/04/17(火) 23:41:10.11

ちゃんと設計できてないから改修する度にいちいち事前のリファクタリングが必要になるんだろうな

**仕様書無しさん** · 2018/04/17(火) 23:41:50.05

>>91
まさにそのスレでその話してるんだからおいとくなよ…

現に存在するものに文句言ったってしょうがないだろ
あるんだから
非機能要件のないソフトなんてない

改修部分が少なければ少ないほど踏んじゃうリスクは減るだろう

**仕様書無しさん** · 2018/04/17(火) 23:48:58.45

> ちゃんと設計できてないから改修する度にいちいち事前のリファクタリングが必要になるんだろうな

そりゃリファクタリングの必要がない場合にはリファクタリングしませんよｗ

前提として、リファクタリングの必要があるコードだって
ちゃんと書きましょうか？そうすればもっとわかりやすくなりますね。

・リファクタリングをしない場合
1. ちゃんとした設計になっていない
2. そのままで無理やりバッファサイズを増やす
3. やってることが意味不明。変更に自信が持てない。コードレビューも大変。
4. 変更で問題が出やすい。そのたびに意味不明なコードと格闘する。
5. 関連箇所の試験して完了。

・リファクタリングをする場合
1. ちゃんとした設計になっていない
2. 設計を修正する（リファクタリング）
3. ちゃんとした設計に自然な形でバッファサイズを増やす
4. やってることが明確。変更に自信が持てる。コードレビューも簡単。
5. 変更に問題が出にくい。仮に出たとしてもちゃんとした設計になってるのですぐに修正できる
6. 関連箇所の試験して完了。

リファクタリングしたことで1工程増えたように見えますが、
ちゃんとした設計になってないものを無理やり修正した複雑なコードは
バグが出やすく、修正も大変になって時間がかかります。
それはわかるでしょう？

**仕様書無しさん** · 2018/04/17(火) 23:50:34.78

>>94
> 改修部分が少なければ少ないほど踏んじゃうリスクは減るだろう

改修部分をリファクタリングするんだから、
改修部分の量は同じですが？

**仕様書無しさん** · 2018/04/17(火) 23:55:28.57

>>96
具体的なイメージがわからない

本当に改修部分だけ改修だったらリファクタ部分消えちゃうじゃない
それってただの改修では

**仕様書無しさん** · 2018/04/18(水) 00:26:44.21

>>97
ちょっとなにかいいサンプルないか探したんだが
見つからなかったので、軽く例を書くわ

ある関数を改修部分することになった。これが100行を超える複雑なコード。
これをリファクタリングすると10行にできるとする
（ライブラリ使用の有無とかで、これぐらいざらにあるからｗ）

リファクタリングしない場合は無駄なコードで処理が入り組んでおり
入り組んだコードを時間をかけて頑張って解析し
そのまま修正するとなると数箇所を変更しなければいけなくなることが判明した
だが本当にその数箇所の変更で問題ないのか？コードが複雑なのでよくわからない
レビュー依頼した所で時間をかけて解析したものを他の人がすぐに分かるはずもない
多くの時間を費やすることになった。

リファクタリングして10行にまで減らすと、コードはシンプルになりなにやってるのか一目瞭然になった。
テストコードがあるのでリファクタリングの前後でコードが壊れてないことはわかる。
リファクタリングしたため修正箇所もたったの一行になった。
他の人も何の修正をしたのかすぐに分かる

**仕様書無しさん** · 2018/04/18(水) 01:15:38.23

>>98
おまいのレスが長すぎてリファクタリングしないと読めない

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

>>99
バイバイ

**仕様書無しさん** · 2018/04/18(水) 01:43:53.78

>>95
リファクタリングの必要性をそこまで感じないってことは、俺の設計ってちゃんとしてるんだろうなぁ

**仕様書無しさん** · 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

数年経ってもリファクタバカは相変わらずだなｗ
未だに賛同者が現れないｗｗｗｗ
しかも、リファクタリングそのものではなく、リファクタバカに対する非賛同が増殖ｗ

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

技術書に溺れなくてよかった・・・。

**KAC** · 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
理解できたらもとに戻してもいいのよ？

**KAC** · 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
> 修正内容に応じてテスト観点増やさないの？

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

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

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

**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
もしかしてリファクタリング、溜まってるんですか？