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

[1 仕様書無しさん 2018/04/15(日) 13:13:44.63]

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

[2 仕様書無しさん 2018/04/15(日) 13:16:31.37]

それなｗ

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

[3 仕様書無しさん 2018/04/15(日) 13:23:46.40]

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

[4 仕様書無しさん 2018/04/15(日) 13:29:25.23]

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

[5 仕様書無しさん 2018/04/15(日) 13:53:39.75]

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

[6 仕様書無しさん 2018/04/15(日) 14:07:43.60]

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

[7 KAC 2018/04/15(日) 14:29:02.33]

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

[8 仕様書無しさん 2018/04/15(日) 14:43:15.84]

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

[9 仕様書無しさん 2018/04/15(日) 14:45:55.12]

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

[10 仕様書無しさん 2018/04/15(日) 14:46:35.64]

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

[11 仕様書無しさん 2018/04/15(日) 14:47:26.22]

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

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

[12 仕様書無しさん 2018/04/15(日) 15:05:33.14]

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

って書いてあるのに

↓

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


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

[13 仕様書無しさん 2018/04/15(日) 15:06:06.29]

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

[14 仕様書無しさん 2018/04/15(日) 15:30:21.76]

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

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

>>14

改修作業の中身の違い

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

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

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

[17 仕様書無しさん 2018/04/15(日) 19:48:05.09]

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

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

[18 仕様書無しさん 2018/04/15(日) 19:48:54.60]

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

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

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

[19 仕様書無しさん 2018/04/15(日) 21:04:44.02]

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

[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]

オープニングから自演ｗ

[24 仕様書無しさん 2018/04/16(月) 05:08:34.00]

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

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

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

[26 仕様書無しさん 2018/04/16(月) 12:37:10.95]

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

[27 仕様書無しさん 2018/04/16(月) 12:45:59.35]

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

[28 仕様書無しさん 2018/04/16(月) 13:26:59.58]

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

[29 仕様書無しさん 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技術者(笑)になる日本では
コストメリットどころかリスクしかない。

[33 KAC 2018/04/16(月) 17:54:10.17]

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

うん。意味不明だね。

[34 仕様書無しさん 2018/04/16(月) 18:19:38.72]

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

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

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

[35 仕様書無しさん 2018/04/16(月) 19:00:22.44]

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

[36 仕様書無しさん 2018/04/16(月) 19:33:16.67]

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

[37 仕様書無しさん 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]

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

[41 仕様書無しさん 2018/04/16(月) 21:02:09.30]

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

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

[42 仕様書無しさん 2018/04/16(月) 21:03:03.43]

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

[43 仕様書無しさん 2018/04/16(月) 21:22:15.99]

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

[44 仕様書無しさん 2018/04/16(月) 21:24:48.73]

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

[45 仕様書無しさん 2018/04/16(月) 21:26:39.53]

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

[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方眼紙でセル結合の練習でもしておけ。

[50 仕様書無しさん 2018/04/16(月) 21:36:56.37]

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

[51 仕様書無しさん 2018/04/16(月) 21:45:07.82]

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

[52 仕様書無しさん 2018/04/16(月) 21:48:55.54]

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

[53 仕様書無しさん 2018/04/16(月) 21:54:14.63]

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

[54 仕様書無しさん 2018/04/16(月) 21:58:29.27]

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

[55 仕様書無しさん 2018/04/16(月) 22:14:39.29]

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

[56 仕様書無しさん 2018/04/16(月) 22:21:54.62]

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

[57 KAC 2018/04/16(月) 22:42:11.58]

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

[58 仕様書無しさん 2018/04/16(月) 23:48:14.82]

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

[59 仕様書無しさん 2018/04/17(火) 01:28:22.88]

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

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

[60 仕様書無しさん 2018/04/17(火) 01:37:33.43]

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

[61 仕様書無しさん 2018/04/17(火) 02:47:02.14]

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

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

[62 仕様書無しさん 2018/04/17(火) 02:49:20.05]

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

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

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

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

[63 仕様書無しさん 2018/04/17(火) 02:51:40.76]

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

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

[64 KAC 2018/04/17(火) 08:07:55.30]

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

[65 仕様書無しさん 2018/04/17(火) 08:35:24.00]

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

[66 仕様書無しさん 2018/04/17(火) 10:12:11.71]

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

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

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

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

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

[67 仕様書無しさん 2018/04/17(火) 10:12:38.07]

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

[68 仕様書無しさん 2018/04/17(火) 10:13:52.53]

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

[69 仕様書無しさん 2018/04/17(火) 10:16:36.37]

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

[70 仕様書無しさん 2018/04/17(火) 11:00:00.11]

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

[71 仕様書無しさん 2018/04/17(火) 11:05:57.21]

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

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

[72 仕様書無しさん 2018/04/17(火) 12:12:26.72]

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

[73 仕様書無しさん 2018/04/17(火) 12:23:08.56]

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

[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はコードをきれいにし、テストを実行して機能が正しく
> 実装されたままであることを確認します（コードのリファクタリング）。
> 重複することなく、コードと自動テストは他の人も簡単に保守できます。

[75 KAC 2018/04/17(火) 13:27:11.82]

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

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

[76 仕様書無しさん 2018/04/17(火) 13:49:22.47]

>>75

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

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


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