機能追加や変更した時に、全部テストしてるでしょ?
いつもやってることじゃん
探検
リファクタリングすると全部テストしろと言ってくるやつの矛盾
■ このスレッドは過去ログ倉庫に格納されています
2018/04/15(日) 13:13:44.63
13仕様書無しさん
2018/04/15(日) 15:06:06.29 リファクタリングの存在を否定できないと
困る人がいるんですよw
困る人がいるんですよw
14仕様書無しさん
2018/04/15(日) 15:30:21.76 設計書から書き直すならただの改修作業なんだよね?
15仕様書無しさん
2018/04/15(日) 15:32:49.9017仕様書無しさん
2018/04/15(日) 19:48:05.09 >>15
TDDでリファクタリングした場合、
1、初歩的なミスにすぐ気付ける
2、作業者が精神的に安心できる
なお、開発者目線の開発体制の優先順位は
バージョン管理 > コードレビュー > 自動テスト > リファクタリング
なので、必ずリファクタリングとTDDはセットになる
TDDでリファクタリングした場合、
1、初歩的なミスにすぐ気付ける
2、作業者が精神的に安心できる
なお、開発者目線の開発体制の優先順位は
バージョン管理 > コードレビュー > 自動テスト > リファクタリング
なので、必ずリファクタリングとTDDはセットになる
18仕様書無しさん
2018/04/15(日) 19:48:54.60 >>16
リファクタリングの手法では先に自動化されたテストコードを書く
もしくはすでに存在していなければならない
だから、リファクタリングしたらテストしろよっていうのは意味不明。
リファクタリングの中にテストすることが条件として含まれており
修正前と修正後の両方、それどころか修正のたびにテストすると言ってるのに
なんでそんな当たり前ことを、それも最後だけテストするような質問をするんだ?と
疑問になる
おそらく修正とテストが分離した考え方しか持って無くて
修正後に手動でテストを行うというやり方しか知らないのだろう
そんな再現性がなくてテスト回数もすくないんじゃ、
バグがなかなか取れずにデスマになるのは必死だろう
リファクタリングの手法では先に自動化されたテストコードを書く
もしくはすでに存在していなければならない
だから、リファクタリングしたらテストしろよっていうのは意味不明。
リファクタリングの中にテストすることが条件として含まれており
修正前と修正後の両方、それどころか修正のたびにテストすると言ってるのに
なんでそんな当たり前ことを、それも最後だけテストするような質問をするんだ?と
疑問になる
おそらく修正とテストが分離した考え方しか持って無くて
修正後に手動でテストを行うというやり方しか知らないのだろう
そんな再現性がなくてテスト回数もすくないんじゃ、
バグがなかなか取れずにデスマになるのは必死だろう
20仕様書無しさん
2018/04/15(日) 21:17:10.48 なにをゆうちょるんじゃあ主は
21仕様書無しさん
2018/04/15(日) 21:37:54.42 リファクタリング厨って受け売りでしか語らないから面白くない
22仕様書無しさん
2018/04/15(日) 23:16:16.00 ゴミスレ
23仕様書無しさん
2018/04/16(月) 05:06:44.38 オープニングから自演w
24仕様書無しさん
2018/04/16(月) 05:08:34.0026仕様書無しさん
2018/04/16(月) 12:37:10.95 >>19
そこらへんの話でいうと、
売上や品質が上がった客観的なデータが示せりゃ、どの会社でも自動テストやリファクタリングは採用されるんよ
そこまでしてないなら、その議論は語るに値しない
んで、殆どの会社はそこを検証していない
そこらへんの話でいうと、
売上や品質が上がった客観的なデータが示せりゃ、どの会社でも自動テストやリファクタリングは採用されるんよ
そこまでしてないなら、その議論は語るに値しない
んで、殆どの会社はそこを検証していない
27仕様書無しさん
2018/04/16(月) 12:45:59.3529仕様書無しさん
2018/04/16(月) 13:36:47.19 >>27
仕事を規定の時間内に許容できる品質のものを上げるのが実装者に求める要求で、それに付随する手段は手段でしかない。
で、手段は自由にやればいいし、基本介入しないし、結果しか見る気は無い。
だからやりたければやれば?としか自分は言わない
工数増えるのは論外
仕事を規定の時間内に許容できる品質のものを上げるのが実装者に求める要求で、それに付随する手段は手段でしかない。
で、手段は自由にやればいいし、基本介入しないし、結果しか見る気は無い。
だからやりたければやれば?としか自分は言わない
工数増えるのは論外
30仕様書無しさん
2018/04/16(月) 14:37:58.22 >>26
> そこまでしてないなら、その議論は語るに値しない
> んで、殆どの会社はそこを検証していない
検証しろっていうのはわかるが、それは世間一般には
すでに検証されていてすでに品質が上がったというデータは出てるんだよな
それも検証するコストも出せないような会社がやるような中途半端な
方法じゃなくて、もっと大規模で信頼できる方法で検証した結果がすでにある。
で、それを参考にすりゃいいのに、参考にしないんだろう。
つまり他人を信用してない。だから他人がなにやってもどんなデータを出しても
そういう会社は信用しないんだろう。
> そこまでしてないなら、その議論は語るに値しない
> んで、殆どの会社はそこを検証していない
検証しろっていうのはわかるが、それは世間一般には
すでに検証されていてすでに品質が上がったというデータは出てるんだよな
それも検証するコストも出せないような会社がやるような中途半端な
方法じゃなくて、もっと大規模で信頼できる方法で検証した結果がすでにある。
で、それを参考にすりゃいいのに、参考にしないんだろう。
つまり他人を信用してない。だから他人がなにやってもどんなデータを出しても
そういう会社は信用しないんだろう。
31仕様書無しさん
2018/04/16(月) 14:41:43.64 リファクタリングが有効かどうか?
検証してやるよ。コスト?そりゃ当然かかるよ
ここで嫌がる会社が多い
重要なのは、失敗するかもしれないがやってみよう
という考えが通じる会社かどうかなんだろうな
検証してやるよ。コスト?そりゃ当然かかるよ
ここで嫌がる会社が多い
重要なのは、失敗するかもしれないがやってみよう
という考えが通じる会社かどうかなんだろうな
32仕様書無しさん
2018/04/16(月) 14:52:53.46 体力がなくて単純工すらできないごみクズがIT技術者(笑)になる日本では
コストメリットどころかリスクしかない。
コストメリットどころかリスクしかない。
33KAC
2018/04/16(月) 17:54:10.17 「リファクタリングしたら工数減ります」
「リファクタリングの為の工数ください」
うん。意味不明だね。
「リファクタリングの為の工数ください」
うん。意味不明だね。
34仕様書無しさん
2018/04/16(月) 18:19:38.72 > 「リファクタリングの為の工数ください」
誰もそんなこと言ってないけど?
>>31が言ってること勘違いした?
リファクタリングが有効かどうかの検証の話だよ。
検証するには、同じことをリファクタリグをするのと
しないので2回やらないといけない。
検証にはコストがかかる。
誰もそんなこと言ってないけど?
>>31が言ってること勘違いした?
リファクタリングが有効かどうかの検証の話だよ。
検証するには、同じことをリファクタリグをするのと
しないので2回やらないといけない。
検証にはコストがかかる。
36仕様書無しさん
2018/04/16(月) 19:33:16.6737仕様書無しさん
2018/04/16(月) 19:50:39.52 リファクタリングで増減する工数って、内部設計クラスレベル〜クラステストまででしょ
詳細設計省かずやる巨大案件でも無い限り、実装者に委ねられる部分やん。
ともすれば、やりたきゃやれって回答にしかならん。
詳細設計省かずやる巨大案件でも無い限り、実装者に委ねられる部分やん。
ともすれば、やりたきゃやれって回答にしかならん。
38仕様書無しさん
2018/04/16(月) 20:03:20.01 >>36
> いや、リファクタリングで総工数が減るなら勝手にやればいいだけじゃね?
俺はやってるよ。リファクタリングで工数減るから
そもそも修正作業の中に自動的に組み込まれるものだから
あえて "リファクタリング単体で" 工数を取るなんてことはしない
だからリファクタリングのために工数くださいっていう発想が
そもそも間違ってるわけ。修正に伴う追加作業じゃない。
修正作業そのものなんだから
> いや、リファクタリングで総工数が減るなら勝手にやればいいだけじゃね?
俺はやってるよ。リファクタリングで工数減るから
そもそも修正作業の中に自動的に組み込まれるものだから
あえて "リファクタリング単体で" 工数を取るなんてことはしない
だからリファクタリングのために工数くださいっていう発想が
そもそも間違ってるわけ。修正に伴う追加作業じゃない。
修正作業そのものなんだから
39仕様書無しさん
2018/04/16(月) 20:08:32.88 仕組みが悪いからって正常に動いてる箇所まで手を入れるってねーな
40仕様書無しさん
2018/04/16(月) 20:37:02.97 リファクタ自体は否定しないが、>>1は確実に技術に溺れて盲信してるアホだから許可出さない
41仕様書無しさん
2018/04/16(月) 21:02:09.3044仕様書無しさん
2018/04/16(月) 21:24:48.73 修正ってなんだよ、バグってんのか
機能追加だろうがなんでも修正って言う奴は素人でしょ
機能追加だろうがなんでも修正って言う奴は素人でしょ
45仕様書無しさん
2018/04/16(月) 21:26:39.53 ただのレッテル張りじゃねえかw
46仕様書無しさん
2018/04/16(月) 21:27:14.47 素人というやつは童貞だ
イカ臭いプログラム書いてろ
と言ってるようなもの
イカ臭いプログラム書いてろ
と言ってるようなもの
47仕様書無しさん
2018/04/16(月) 21:30:14.08 >>43
なんどもリファクタリングは修正の一部だって言ってるじゃん
一部ってことはそれ以外も有るってことだよ
複雑なコードを読み解いて、リファクタリングしないで複雑なまま修正するのと
複雑なコードを読み解いて、リファクタリングしてから修正するのと
どっちがリスクが少ないかって話だ
前者だと、複雑なコードを読み解いた人(修正担当者)がいるにもかかわらず
別の人が、また大変な思いをして読み解いてレビューしなければいけない
そして、次同じところを修正する時、また複雑なコード読み解かなければいけない
なんどもリファクタリングは修正の一部だって言ってるじゃん
一部ってことはそれ以外も有るってことだよ
複雑なコードを読み解いて、リファクタリングしないで複雑なまま修正するのと
複雑なコードを読み解いて、リファクタリングしてから修正するのと
どっちがリスクが少ないかって話だ
前者だと、複雑なコードを読み解いた人(修正担当者)がいるにもかかわらず
別の人が、また大変な思いをして読み解いてレビューしなければいけない
そして、次同じところを修正する時、また複雑なコード読み解かなければいけない
48仕様書無しさん
2018/04/16(月) 21:32:16.33 みんな実装するだけで精一杯なんよ
49仕様書無しさん
2018/04/16(月) 21:33:31.81 リファクタリングは神の領域に達するものにのみ許される技。
素人はおとなしくExcel方眼紙でセル結合の練習でもしておけ。
素人はおとなしくExcel方眼紙でセル結合の練習でもしておけ。
52仕様書無しさん
2018/04/16(月) 21:48:55.54 入門レベルの奴でも上から目線になれるから張り切ってんのか
56仕様書無しさん
2018/04/16(月) 22:21:54.62 リファクタリングしてるのでNG
58仕様書無しさん
2018/04/16(月) 23:48:14.82 テストしづらいとか、クラスが肥大化しすぎて開発に支障があるとかならまだしも
見通しが悪いなんて理由でうごいてるもんをほいほい変えていいもんじゃろか
見通しが悪いなんて理由でうごいてるもんをほいほい変えていいもんじゃろか
59仕様書無しさん
2018/04/17(火) 01:28:22.88 リファクタリングは超プロの領域
このスレには本当のリファクタリングが出来る奴はいない
elseなしに書き換えるのが精一杯のFラン説教野郎みたいなのがいるだけ
このスレには本当のリファクタリングが出来る奴はいない
elseなしに書き換えるのが精一杯のFラン説教野郎みたいなのがいるだけ
60仕様書無しさん
2018/04/17(火) 01:37:33.43 大規模リファクタリングの秘孔をついた
お前のプロジェクトはもう死んでいる
お前のプロジェクトはもう死んでいる
61仕様書無しさん
2018/04/17(火) 02:47:02.14 >>55
> リファクタリングするときのレビューとかどうしてる?
リファクタリングではないときはどうしてる?
それと同じなんだが。
まあそういう質問するってことはリファクタリングに限らず
そもそも設計もコードもレビューしてないってことなんだろうけど
まずはそこからやねw
> リファクタリングするときのレビューとかどうしてる?
リファクタリングではないときはどうしてる?
それと同じなんだが。
まあそういう質問するってことはリファクタリングに限らず
そもそも設計もコードもレビューしてないってことなんだろうけど
まずはそこからやねw
62仕様書無しさん
2018/04/17(火) 02:49:20.05 >>57
> 自動試験だけで完璧なものができるとか信じてる?
だからレビューするんでしょ?
自動試験はバグがないことを証明する手段
その手段が正しいかどうかはレビューでみる。
人手でレビューして、テストした内容も記録されて
後なにがあれば完璧なものができると思います?
> 自動試験だけで完璧なものができるとか信じてる?
だからレビューするんでしょ?
自動試験はバグがないことを証明する手段
その手段が正しいかどうかはレビューでみる。
人手でレビューして、テストした内容も記録されて
後なにがあれば完璧なものができると思います?
63仕様書無しさん
2018/04/17(火) 02:51:40.76 >>58
> テストしづらいとか、クラスが肥大化しすぎて開発に支障があるとかならまだしも
> 見通しが悪いなんて理由でうごいてるもんをほいほい変えていいもんじゃろか
機能追加とか修正するという前提なんだから、どちらにしろ変更するしかないでしょw
> テストしづらいとか、クラスが肥大化しすぎて開発に支障があるとかならまだしも
> 見通しが悪いなんて理由でうごいてるもんをほいほい変えていいもんじゃろか
機能追加とか修正するという前提なんだから、どちらにしろ変更するしかないでしょw
65仕様書無しさん
2018/04/17(火) 08:35:24.00 入門書第1章に書いてあることの受け売りなら長文で語るけど、具体的な話からは煽りで逃げるし、
体験から語ってると思えるような発言もないし、こいつ多分そんなにノウハウないよ
体験から語ってると思えるような発言もないし、こいつ多分そんなにノウハウないよ
66仕様書無しさん
2018/04/17(火) 10:12:11.71 >>64
レビューもするし自動以外のテストもする
そこは普通の機能変更のときとなにも変わらない
ただその時のやり方が、複雑なコードを頑張って解析して
無理やりパッチを当てるような、あとから見た時に
なんでこんな面倒なことしてんの?と思われるような変更をするやり方から、
次回は複雑なコードを読まなくて良いように、複雑なコードを
シンプルに修正しつつ、まるで0からコードを書いた時のように
こういう機能を実現するなら、普通こう書くよねという
当たり前の形にするやり方に変わるだけ
変更するたびに複雑になっていくやり方をやめて
変更しても複雑にならない、むしろシンプルになるような
やり方をしましょうってこと
その後にやるテストうんぬんは、もともと機能変更でやる予定だったんだろ?
なら最初からやるって決まってることじゃないか
レビューもするし自動以外のテストもする
そこは普通の機能変更のときとなにも変わらない
ただその時のやり方が、複雑なコードを頑張って解析して
無理やりパッチを当てるような、あとから見た時に
なんでこんな面倒なことしてんの?と思われるような変更をするやり方から、
次回は複雑なコードを読まなくて良いように、複雑なコードを
シンプルに修正しつつ、まるで0からコードを書いた時のように
こういう機能を実現するなら、普通こう書くよねという
当たり前の形にするやり方に変わるだけ
変更するたびに複雑になっていくやり方をやめて
変更しても複雑にならない、むしろシンプルになるような
やり方をしましょうってこと
その後にやるテストうんぬんは、もともと機能変更でやる予定だったんだろ?
なら最初からやるって決まってることじゃないか
68仕様書無しさん
2018/04/17(火) 10:13:52.53 レビューってさ
もう儀式になってない?
もう儀式になってない?
69仕様書無しさん
2018/04/17(火) 10:16:36.37 TDDってさ
組織的にガチガチにやるもんじゃなくて
設計者の間で守るべき密やかな秘密程度で
やったほうが良い気がすんのね。
組織的にガチガチにやるもんじゃなくて
設計者の間で守るべき密やかな秘密程度で
やったほうが良い気がすんのね。
71仕様書無しさん
2018/04/17(火) 11:05:57.21 >>69
ようは、リファクタリング前に存在するテストコードが
リファクタリング後でも通ることで動きを変えてないことが
証明できれば良いのでTDDである必要はないよ。
具体的にはgit使えば歴史変えられるんで、
コード変更しつつテストコード書いて、
コード変更とテストコードでコミット分けて
あとでrebaseしてテストコードのコミットをコード変更の
コミットより前に持ってくれば良い
ようは、リファクタリング前に存在するテストコードが
リファクタリング後でも通ることで動きを変えてないことが
証明できれば良いのでTDDである必要はないよ。
具体的にはgit使えば歴史変えられるんで、
コード変更しつつテストコード書いて、
コード変更とテストコードでコミット分けて
あとでrebaseしてテストコードのコミットをコード変更の
コミットより前に持ってくれば良い
74仕様書無しさん
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はコードをきれいにし、テストを実行して機能が正しく
> 実装されたままであることを確認します(コードのリファクタリング)。
> 重複することなく、コードと自動テストは他の人も簡単に保守できます。
> TDDは保護するためのテストじゃないから
TDDはテストではなく開発手法ですよ?
TDDという開発手法ではリファクタリングの前にテストを書き
書いたテストが、その後に行うリファクタリングが問題ないことを証明するんですよ
つまり
× TDD = 保護するためのテスト
○ TDD =「保護するためのテスト」を用いた開発手法
(あんたの言った「保護」がリファクタリングで壊さないように守るという意味である前提)
俺が>>71で言ったことは、TDDでやらなくてもテストで保護できると言ったんです。
https://postd.cc/test-driven-development/
> 簡単に言うと、TDDは機能を記述する前に自動テストを書く行為です。
> 例えば、Bobが素晴らしい新たなソーシャルネットワークのアイデアの
> ために新しい機能を開発する必要があるとしましょう。
>
> Bobは自動テストを書くことから始めますが、機能を正しく実装せずに、
> テストを失敗(赤色表示)させます。次に、Bobはテストを成功(緑色表示)
> させるための最小限のコードを記述します。緑色表示になったら、
> Bobはコードをきれいにし、テストを実行して機能が正しく
> 実装されたままであることを確認します(コードのリファクタリング)。
> 重複することなく、コードと自動テストは他の人も簡単に保守できます。
75KAC
2018/04/17(火) 13:27:11.8276仕様書無しさん
2018/04/17(火) 13:49:22.47 >>75
before(リファクタリングしない場合)
1. 機能追加やバグ修正などの変更依頼が来る
2. 変更する
3. 変更したので全部テストをする
after(リファクタリングする場合)
1. 機能追加やバグ修正などの変更依頼が来る
2. 変更する(リファクタリングもする)
3. 変更したので全部テストをする
afterに対して、余計なことするな!
リファクタリングしたなら全部テストしろ!
と言われましても、beforeでも全部テストしてますよね?という話です。
before(リファクタリングしない場合)
1. 機能追加やバグ修正などの変更依頼が来る
2. 変更する
3. 変更したので全部テストをする
after(リファクタリングする場合)
1. 機能追加やバグ修正などの変更依頼が来る
2. 変更する(リファクタリングもする)
3. 変更したので全部テストをする
afterに対して、余計なことするな!
リファクタリングしたなら全部テストしろ!
と言われましても、beforeでも全部テストしてますよね?という話です。
77仕様書無しさん
2018/04/17(火) 15:18:23.57 リファクタリングしたら(その時点で、機能改修する前に)(単体)テストしろって要求なんじゃね?
まあ普通やるけど。
まあ普通やるけど。
78仕様書無しさん
2018/04/17(火) 15:55:33.65 >>77
いやぁ、違うなぁ
リファクタリングさせないための方便として使ってるので
お前がリファクタリングするとテストする人が迷惑するんだぞ
だから余計なことするなという意味だろう。
だがもともとテストするわけで矛盾になるんだよな
いやぁ、違うなぁ
リファクタリングさせないための方便として使ってるので
お前がリファクタリングするとテストする人が迷惑するんだぞ
だから余計なことするなという意味だろう。
だがもともとテストするわけで矛盾になるんだよな
81仕様書無しさん
2018/04/17(火) 16:59:00.9782仕様書無しさん
2018/04/17(火) 17:34:58.09 リリースしたらあとはそのシステムのことは知らん
だからリファクタリングする気もない
だからリファクタリングする気もない
84仕様書無しさん
2018/04/17(火) 18:52:07.2185仕様書無しさん
2018/04/17(火) 18:54:58.0487KAC
2018/04/17(火) 19:26:39.52 >>76
イメージはあってそう(スレ建てた奴とは違う意見)に読めたので、
具体的な内容を書いてみる。
大規模で難解なプロジェクトの一部機能で、
一カ所の編集バッファの数が足りず、
長い氏名の編集に失敗する仕様となっていた。
メモリの使用率なども調査済みで、編集文字数を増やすという仕様変更案件の場合。
バッファサイズを増やして関連箇所の試験して完了。
リファクタリングしたら、統べての試験をやり直し。
リファクタリングの有無でどちらが安いのか、
時と場合によるって認識はあってる?
イメージはあってそう(スレ建てた奴とは違う意見)に読めたので、
具体的な内容を書いてみる。
大規模で難解なプロジェクトの一部機能で、
一カ所の編集バッファの数が足りず、
長い氏名の編集に失敗する仕様となっていた。
メモリの使用率なども調査済みで、編集文字数を増やすという仕様変更案件の場合。
バッファサイズを増やして関連箇所の試験して完了。
リファクタリングしたら、統べての試験をやり直し。
リファクタリングの有無でどちらが安いのか、
時と場合によるって認識はあってる?
88仕様書無しさん
2018/04/17(火) 20:51:10.01 WFとアジャイルとでも違うし
リファクタリングできる設計になってるの?
も大きな要素だが
動いているなら弄るなよは永遠の真理
リファクタリングできる設計になってるの?
も大きな要素だが
動いているなら弄るなよは永遠の真理
90仕様書無しさん
2018/04/17(火) 22:21:50.39 バッファサイズの変更でなにをリファクタするというんだ
文字編集がややこしいから途中量の計算が難しいから処理変更とか?
文字編集がややこしいから途中量の計算が難しいから処理変更とか?
91仕様書無しさん
2018/04/17(火) 23:28:38.99 >>85
リファクタリングの話は一旦おいておきましょう。
> そうはいかねぇだろ
> 文章化されてないけど
> クリアしてるいろんな仕様があんだからよ
それでどうやってコードを正しく変更できるんですか?
コードを変更する時に文書化されてない仕様を
間違って変えてしまうことがありますよね?
文書化されてない仕様をテストでどうやって
見つけるんですか?
リファクタリングの話は一旦おいておきましょう。
> そうはいかねぇだろ
> 文章化されてないけど
> クリアしてるいろんな仕様があんだからよ
それでどうやってコードを正しく変更できるんですか?
コードを変更する時に文書化されてない仕様を
間違って変えてしまうことがありますよね?
文書化されてない仕様をテストでどうやって
見つけるんですか?
92仕様書無しさん
2018/04/17(火) 23:36:25.31 >>87
> バッファサイズを増やして関連箇所の試験して完了。
>
> リファクタリングしたら、統べての試験をやり直し。
え?なんで?先に修正して試験するのがいけないんじゃん
1. リファクタリングをする
2. バッファサイズを増やす
3. 関連箇所の試験して完了
基本はこうですよ?
実際にはこんな大雑把作業じゃなくもう少し細かく
(ユニットテストと)リファクタリングと修正を何回か繰り返しますが
コードの変更とリファクタリングは切り離せません
コードの変更とリファクタリングの間に「関連箇所の試験して完了」
なんてものは入らないし入れたらダメです。
> バッファサイズを増やして関連箇所の試験して完了。
>
> リファクタリングしたら、統べての試験をやり直し。
え?なんで?先に修正して試験するのがいけないんじゃん
1. リファクタリングをする
2. バッファサイズを増やす
3. 関連箇所の試験して完了
基本はこうですよ?
実際にはこんな大雑把作業じゃなくもう少し細かく
(ユニットテストと)リファクタリングと修正を何回か繰り返しますが
コードの変更とリファクタリングは切り離せません
コードの変更とリファクタリングの間に「関連箇所の試験して完了」
なんてものは入らないし入れたらダメです。
93仕様書無しさん
2018/04/17(火) 23:41:10.11 ちゃんと設計できてないから改修する度にいちいち事前のリファクタリングが必要になるんだろうな
94仕様書無しさん
2018/04/17(火) 23:41:50.05 >>91
まさにそのスレでその話してるんだからおいとくなよ…
現に存在するものに文句言ったってしょうがないだろ
あるんだから
非機能要件のないソフトなんてない
改修部分が少なければ少ないほど踏んじゃうリスクは減るだろう
まさにそのスレでその話してるんだからおいとくなよ…
現に存在するものに文句言ったってしょうがないだろ
あるんだから
非機能要件のないソフトなんてない
改修部分が少なければ少ないほど踏んじゃうリスクは減るだろう
95仕様書無しさん
2018/04/17(火) 23:48:58.45 > ちゃんと設計できてないから改修する度にいちいち事前のリファクタリングが必要になるんだろうな
そりゃリファクタリングの必要がない場合にはリファクタリングしませんよw
前提として、リファクタリングの必要があるコードだって
ちゃんと書きましょうか? そうすればもっとわかりやすくなりますね。
・リファクタリングをしない場合
1. ちゃんとした設計になっていない
2. そのままで無理やりバッファサイズを増やす
3. やってることが意味不明。変更に自信が持てない。コードレビューも大変。
4. 変更で問題が出やすい。そのたびに意味不明なコードと格闘する。
5. 関連箇所の試験して完了。
・リファクタリングをする場合
1. ちゃんとした設計になっていない
2. 設計を修正する(リファクタリング)
3. ちゃんとした設計に自然な形でバッファサイズを増やす
4. やってることが明確。変更に自信が持てる。コードレビューも簡単。
5. 変更に問題が出にくい。仮に出たとしてもちゃんとした設計になってるのですぐに修正できる
6. 関連箇所の試験して完了。
リファクタリングしたことで1工程増えたように見えますが、
ちゃんとした設計になってないものを無理やり修正した複雑なコードは
バグが出やすく、修正も大変になって時間がかかります。
それはわかるでしょう?
そりゃリファクタリングの必要がない場合にはリファクタリングしませんよw
前提として、リファクタリングの必要があるコードだって
ちゃんと書きましょうか? そうすればもっとわかりやすくなりますね。
・リファクタリングをしない場合
1. ちゃんとした設計になっていない
2. そのままで無理やりバッファサイズを増やす
3. やってることが意味不明。変更に自信が持てない。コードレビューも大変。
4. 変更で問題が出やすい。そのたびに意味不明なコードと格闘する。
5. 関連箇所の試験して完了。
・リファクタリングをする場合
1. ちゃんとした設計になっていない
2. 設計を修正する(リファクタリング)
3. ちゃんとした設計に自然な形でバッファサイズを増やす
4. やってることが明確。変更に自信が持てる。コードレビューも簡単。
5. 変更に問題が出にくい。仮に出たとしてもちゃんとした設計になってるのですぐに修正できる
6. 関連箇所の試験して完了。
リファクタリングしたことで1工程増えたように見えますが、
ちゃんとした設計になってないものを無理やり修正した複雑なコードは
バグが出やすく、修正も大変になって時間がかかります。
それはわかるでしょう?
96仕様書無しさん
2018/04/17(火) 23:50:34.7898仕様書無しさん
2018/04/18(水) 00:26:44.21 >>97
ちょっとなにかいいサンプルないか探したんだが
見つからなかったので、軽く例を書くわ
ある関数を改修部分することになった。これが100行を超える複雑なコード。
これをリファクタリングすると10行にできるとする
(ライブラリ使用の有無とかで、これぐらいざらにあるからw)
リファクタリングしない場合は無駄なコードで処理が入り組んでおり
入り組んだコードを時間をかけて頑張って解析し
そのまま修正するとなると数箇所を変更しなければいけなくなることが判明した
だが本当にその数箇所の変更で問題ないのか? コードが複雑なのでよくわからない
レビュー依頼した所で時間をかけて解析したものを他の人がすぐに分かるはずもない
多くの時間を費やすることになった。
リファクタリングして10行にまで減らすと、コードはシンプルになりなにやってるのか一目瞭然になった。
テストコードがあるのでリファクタリングの前後でコードが壊れてないことはわかる。
リファクタリングしたため修正箇所もたったの一行になった。
他の人も何の修正をしたのかすぐに分かる
ちょっとなにかいいサンプルないか探したんだが
見つからなかったので、軽く例を書くわ
ある関数を改修部分することになった。これが100行を超える複雑なコード。
これをリファクタリングすると10行にできるとする
(ライブラリ使用の有無とかで、これぐらいざらにあるからw)
リファクタリングしない場合は無駄なコードで処理が入り組んでおり
入り組んだコードを時間をかけて頑張って解析し
そのまま修正するとなると数箇所を変更しなければいけなくなることが判明した
だが本当にその数箇所の変更で問題ないのか? コードが複雑なのでよくわからない
レビュー依頼した所で時間をかけて解析したものを他の人がすぐに分かるはずもない
多くの時間を費やすることになった。
リファクタリングして10行にまで減らすと、コードはシンプルになりなにやってるのか一目瞭然になった。
テストコードがあるのでリファクタリングの前後でコードが壊れてないことはわかる。
リファクタリングしたため修正箇所もたったの一行になった。
他の人も何の修正をしたのかすぐに分かる
99仕様書無しさん
2018/04/18(水) 01:15:38.23 >>98
おまいのレスが長すぎてリファクタリングしないと読めない
おまいのレスが長すぎてリファクタリングしないと読めない
103仕様書無しさん
2018/04/18(水) 03:09:17.61105仕様書無しさん
2018/04/18(水) 07:33:52.26 言語からスクリプト言語が呼べるようにしておけば汎用性は無限
バグも無限
バグも無限
106仕様書無しさん
2018/04/18(水) 07:50:27.25107仕様書無しさん
2018/04/18(水) 10:52:23.05 数年経ってもリファクタバカは相変わらずだなw
未だに賛同者が現れないwwww
しかも、リファクタリングそのものではなく、リファクタバカに対する非賛同が増殖w
かたやリファクタすら許してもらえない信用と立場のリファクタバカが相変わらずの状態
かたや5年以上で完全に新規で作り直しの許可を与えられるようになった俺
技術書に溺れなくてよかった・・・。
未だに賛同者が現れないwwww
しかも、リファクタリングそのものではなく、リファクタバカに対する非賛同が増殖w
かたやリファクタすら許してもらえない信用と立場のリファクタバカが相変わらずの状態
かたや5年以上で完全に新規で作り直しの許可を与えられるようになった俺
技術書に溺れなくてよかった・・・。
108KAC
2018/04/18(水) 12:55:46.41 >>98
あぁ、そういう事か。
「リファクタリング」という範囲のイメージが合ってなかったんだな。
関数単位のリファクタリングならそのイメージでだいたい合ってる。
「外部インタフェース変えずに内部の設計から見直す」事を前提に話してたよ。
それはそうとして、
関数の処理削減などで処理速度が変わったのなら、同期など含めてその観点での試験はちゃんとやれよ?
あぁ、そういう事か。
「リファクタリング」という範囲のイメージが合ってなかったんだな。
関数単位のリファクタリングならそのイメージでだいたい合ってる。
「外部インタフェース変えずに内部の設計から見直す」事を前提に話してたよ。
それはそうとして、
関数の処理削減などで処理速度が変わったのなら、同期など含めてその観点での試験はちゃんとやれよ?
110仕様書無しさん
2018/04/18(水) 19:52:23.21 関数レベルのリファクタリングしか語れないレベルだということはお察し
111仕様書無しさん
2018/04/18(水) 21:09:41.94 おれは何も察することができんのだが
112仕様書無しさん
2018/04/18(水) 22:40:51.02 >>106
> それって関数全体に手が入ってるわけだから改修量同じじゃないじゃん
> テストで検出できない非機能要件を踏んじゃうリスクは明らかに増えてるよね?
関数の中の1行を変えたとして、
その1行だけをテストして関数全体OKってできるんですか?
そもそも関数の中の1行だけをテストすることは不可能だと思います。
結局関数全体をテストするわけでしょう?
> それって関数全体に手が入ってるわけだから改修量同じじゃないじゃん
> テストで検出できない非機能要件を踏んじゃうリスクは明らかに増えてるよね?
関数の中の1行を変えたとして、
その1行だけをテストして関数全体OKってできるんですか?
そもそも関数の中の1行だけをテストすることは不可能だと思います。
結局関数全体をテストするわけでしょう?
113仕様書無しさん
2018/04/18(水) 22:42:05.86 >>108
> 関数の処理削減などで処理速度が変わったのなら、同期など含めてその観点での試験はちゃんとやれよ?
もともと修正すべき関数なんだから、リファクタリングしなくても
テスト必須でしょう? なにを言ってるんでしょうか
> 関数の処理削減などで処理速度が変わったのなら、同期など含めてその観点での試験はちゃんとやれよ?
もともと修正すべき関数なんだから、リファクタリングしなくても
テスト必須でしょう? なにを言ってるんでしょうか
■ このスレッドは過去ログ倉庫に格納されています
ニュース
- 【おこめ券】物価高対策の“おこめ券”全米販は1枚477円で販売へ 鈴木農水大臣「国民の皆様に活用いただきやすいよう工夫いただいた」★2 [ぐれ★]
- 高市首相の答弁書に「台湾有事答えない」と明記 存立危機発言当時 ★5 [蚤の市★]
- 神田沙也加さん元恋人で元俳優の前山剛久 六本木のメンズラウンジ勤務を報告「真叶(まなと)です。よろしく」 [muffin★]
- ハリウッド実写版『ストリートファイター』初映像解禁 リュウ&春麗らのビジュアルも公開 [muffin★]
- 「偽サッチャー」「自滅的」「時代遅れ」 高市首相の経済政策を海外メディアが酷評 ★5 [蚤の市★]
- 【麻雀】プロ雀士の岡田紗佳さんが勝訴、点数計算めぐる発言は「違法とは言えず」 大宮簡裁 [征夷大将軍★]
- 【高市悲報】片山さつき「かじ取り間違えてデフレになったらどうすんの!😡」😲 [359965264]
- 【乞食速報】43インチ4Kモニターが19800円。テレビも見れるぞ [419111196]
- VTuber叩きが大流行してる理由、1枚の画像で解説される…!! [858219337]
- 居酒屋で働いてる女w
- AIで画像出力しても普通のしかできないんだが
- トランプ、ベネズエラの石油タンカーを拿捕して石油を強奪。これもう海賊だろどこがノーベル平和賞なんだよ高市 [931948549]
