リファクタリングすると全部テストしろと言ってくる奴の矛盾2

1仕様書無しさん2018/05/19(土) 18:05:57.63
機能追加や変更した時に、全部テストしてるでしょ?
いつもやってることじゃん

前スレ
リファクタリングすると全部テストしろと言ってくるやつの矛盾
https://medaka.5ch.net/test/read.cgi/prog/1523765624/

349仕様書無しさん2018/06/09(土) 21:10:24.63
インターフェースを使わずにあちこちに条件分岐を撒き散らすほうが
バグ修正しにくいわ

350仕様書無しさん2018/06/09(土) 21:12:07.65
>>297
IDEのない時代の人かなwww

351仕様書無しさん2018/06/09(土) 22:45:58.47
まぁ実際のところ、interfaceまでガッツリ作る業務は今まであったことないんだけどね。
大体abstractクラスが限界

352仕様書無しさん2018/06/09(土) 22:51:40.60
後はienumerableと受け取ったり返したりするヘルパー関数群とかは作るか。他はもはや趣味の領域な気がする

353仕様書無しさん2018/06/09(土) 23:07:02.97
IT業界は企業間で10年、20年分ぐらい技術格差がある
当たり前のようにinterfaceを使うモダンな企業もある
JavaやC#を採用しているのにCやCOBOLみたいなプログラムを書いてる老舗企業もまだある

354仕様書無しさん2018/06/09(土) 23:22:41.12
>>347
じゃあ、型情報潰しちゃってるのにどうやって該当の処理まで飛ぶの?
っていうか君はインターフェースの先は知る必要がないって主張だから
不具合も直せないよね?w

355仕様書無しさん2018/06/09(土) 23:24:11.27
インターフェース君はどうやってインターフェースの先を知らずに不具合を直すのだろう?

356仕様書無しさん2018/06/09(土) 23:59:51.23
作業対象の依存するインターフェースの先を知る必要はない
作業対象==バグってるクラスを治すだけ

357仕様書無しさん2018/06/10(日) 00:33:37.26
>じゃあ、型情報潰しちゃってるのにどうやって該当の処理まで飛ぶの?
作業対象の型も設定や命名規約からすぐわかるし全体からすれば極一部の動的なインスタンスだったとしてもログやファクトリーを見ればすぐにわかる

>インターフェース君はどうやってインターフェースの先を知らずに不具合を直すのだろう?
作業対象が依存してるのはインターフェースの契約でしかないのでインターフェースの先はもちろん知らなくていい

作業対象==バグってるクラス

358仕様書無しさん2018/06/10(日) 00:41:27.33
>>356
IF「フフフ、我らを見抜けるかな?」
IF「3万のインスタンスをもち、150種のクラスをもつ我らを見抜くことは不可能」
IF「さらにメモリ、フォーム、コントロール、スレッド、ファイル、プロトコル、etc」
IF「すべての共通項を見出した万能クラス」

359仕様書無しさん2018/06/10(日) 00:44:12.74
実際には責務:クラス=1:1だから症状聞いた瞬間にあぁあのクラスだなってわかるんだけどね
クラス分けしないでif文書きまくるとそれができなくなってコード追いかけたり実際に動かさないとわからなくなる

360仕様書無しさん2018/06/10(日) 00:46:05.56
>>357
いや、お前の主張はインターフェースの先は知らなくていいんだから
不具合直せないだろ
そこでチンコでもいじってろよ

361仕様書無しさん2018/06/10(日) 01:05:06.67
バグがあるクラスを直す時にそのクラスが依存しているインターフェースの先を知る必要がない
インターフェースを守っていればいい

362仕様書無しさん2018/06/10(日) 01:07:08.85
これも成り立つよな?

バグがあるクラスを直す時にそのクラスが依存しているクラスの先を知る必要がない

363仕様書無しさん2018/06/10(日) 01:14:58.26
インターフェースの先は知る必要はない

364仕様書無しさん2018/06/10(日) 01:23:43.45
クラスを使ってるだけなら、クラスの実装を知る必要はないのと同じことか
そういやライブラリのソースコードって見ないもんな

365仕様書無しさん2018/06/10(日) 01:31:56.78
クラスを使ってるだけならクラスの実装にも注意が必要

366仕様書無しさん2018/06/10(日) 01:42:08.23
あー、勝負ついたなw

クラス(第三者が作ったライブラリ)のソースコード
普通見ねぇわ

367仕様書無しさん2018/06/10(日) 07:15:47.13
しかし、まだ、インターフェースの先がバグってる

368仕様書無しさん2018/06/10(日) 09:54:12.51
バグってるクラスを直さないと誰が言ったのだろうか

369仕様書無しさん2018/06/10(日) 12:35:52.36
インターフェースを使うとバグが無いことが証明される

なんでかな?

370仕様書無しさん2018/06/10(日) 12:48:41.54
インターフェースを使ってもバグはある

終わり

371仕様書無しさん2018/06/10(日) 12:59:16.23
インターフェースの先は知らなくていい

↑これが間違ってる

372仕様書無しさん2018/06/10(日) 13:05:49.06
なんでそこだけ切り取ってるの?馬鹿なの?

373仕様書無しさん2018/06/10(日) 23:53:21.53
>>372
厳密に表現するとどうなるん?

374仕様書無しさん2018/06/14(木) 20:41:53.41
これが流行ってるからっで、レガシーコードにぶち込まれた数々のソリューション。
やるなら同等の箇所を完全に書き換えろ。
未来に責任が持てないならおとなしくしとけよ、糞が

375仕様書無しさん2018/06/14(木) 20:58:04.16
なんで同等の箇所が何個もあるの?

376仕様書無しさん2018/06/14(木) 20:58:25.98
あ、未来のことなんか考えなかったからだね
未来の責任は放棄か

377仕様書無しさん2018/06/14(木) 21:55:10.14
残業、休出してリファクタリングってなんかおかしくねーか?
いま、足が出てるわけで、いま、なんとかしろよ
アリもしないお前が想定する未来はきっとこないんだ

378仕様書無しさん2018/06/15(金) 02:08:31.09
>>377
うーん? ただ単に遅れてるだけだよね、それ

379仕様書無しさん2018/06/15(金) 07:11:43.08
>>378
え?ちょっと頭使ってね
リファクタリングっていまの工数を使って明日の工数につなげましょうって作戦じゃん?
なのにいま足が出てるのにそんなことしたって一体いつのプロジェクトを成功させたいのかわけがわからないじゃん

380仕様書無しさん2018/06/15(金) 07:46:54.71
> リファクタリングっていまの工数を使って明日の工数につなげましょうって作戦じゃん?

え?違うよ

まず今日の仕事の準備としてリファクタリングする。
そして今日の仕事の仕上げとしてリファクタリングする
それで今日の仕事が終わったと言える

準備と仕上げを入れずに仕事を見積もってはいけない
足が出てるのは、その準備と仕上げを勤務時間中にやらないで
1時間早く出社して、残業もするような状態になってるから

381仕様書無しさん2018/06/15(金) 08:03:25.86
>>380
は?
それなんのためにやってるの?
設計書通りに組んだんだよね?

382仕様書無しさん2018/06/15(金) 08:04:01.47
気分に任せて組んでるから必要になってんじゃない?
お前の場合

383仕様書無しさん2018/06/15(金) 09:52:47.39
まあリファクタして工数増えてんなら本末転倒だわな

384仕様書無しさん2018/06/15(金) 13:22:21.84
>>381
設計書にコードの中身まで書いてあるっていうのかい?

385仕様書無しさん2018/06/15(金) 13:31:19.97
>>381
キチガイ

386仕様書無しさん2018/06/15(金) 14:53:06.17
野球で例えるならバッターが足場を慣らすのがリファクタリング

387仕様書無しさん2018/06/15(金) 17:39:59.41
>>386
ストライク入らない奴に限って長いよね

388仕様書無しさん2018/06/15(金) 17:41:40.64
打てない奴に限ってだった

389仕様書無しさん2018/06/15(金) 18:13:39.98
>>388
それ統計データでもあるの?
それともあなたの思い込み?
嘘つかないでくれませんか?

390仕様書無しさん2018/06/15(金) 18:19:30.60
設計書通りだとバグ出るしバグの修正めちゃくちゃ大変
しかも当たり前のように仕様変更入るじゃん
だから設計書は参考までに止めてリファクタリングするしかない
文句言うなら最初から整理とテストまで実行した設計書をよこせや

391仕様書無しさん2018/06/15(金) 18:34:11.91
>>390
だからって設計書書かないって
それノーガード戦法じゃね

392仕様書無しさん2018/06/15(金) 19:05:31.85
>>391
設計書はゴミだけど設計というプロセスは必要
設計した結果をコードとテストとしてアウトプットする
それらでカバーできない部分があれば別途図表や文章を用意するが設計書という体裁にはならない
後発の開発者やユーザーに対する解説書となる

393仕様書無しさん2018/06/15(金) 19:07:11.25
>>392
君の書いた設計書がゴミなだけで他の略

394仕様書無しさん2018/06/15(金) 19:29:07.71
んで、設計書を通りのコードと言っても
わかりやすいコードと、わかりにくいコードがある
正しく動いていたとしても、わかりにくいコードだと
今後の作業に支障をきたす。

今後の作業を改善するためにリファクタリングするのではなく
今後の作業に支障をきたさないためにリファクタリングをする。
これは今やらなければいけない作業

工事終わりました。でも片付けはしてないです。じゃだめだろう?
片付けまでやるのが今日の仕事

395仕様書無しさん2018/06/15(金) 19:46:24.48
@良い設計を簡潔に記したもの
→必要です。これを設計書と言います。

A悪い設計を膨大な文書で誤魔化そうとしたもの
→不要です。むしろ害悪になります。
これは設計書とは言いません。ゴミです。

残念なことに日本のIT業界ではAの事を設計書と呼び、盲信しています。
今すぐAをリファクタリングして@に書き換えましょう。
そうすればコードのリファクタリングは最小限で済みます。

396仕様書無しさん2018/06/15(金) 20:00:38.76
>>394
わかりにくい文章やな

397仕様書無しさん2018/06/15(金) 20:13:33.02
>>395
> @良い設計を簡潔に記したもの
> →必要です。これを設計書と言います。

簡潔に書くのと、詳細なコードを書くことは
矛盾するからね。簡潔に書けば、書いてない部分が
増えるため汚いコードになってしまう可能性が増える

398仕様書無しさん2018/06/15(金) 20:14:01.00
>>396
読解力をつけよう!

399KAC2018/06/15(金) 21:10:13.88
>>397
お前さんが設計できない事だけは判った

新着レスの表示
レスを投稿する