2ちゃんねる スマホ用 ■掲示板に戻る■ 全部 1- 最新50    

■ このスレッドは過去ログ倉庫に格納されています

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

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

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

2 :仕様書無しさん:2018/05/19(土) 18:35:02.73 .net
アンチは論破された。泣き崩れている。
ウソと詭弁で自分を守ることしかできていない。
様々な証拠がリファクタリングの有用性を示している。

マイクロソフトもリファクタリングをしていた。
Googleもリファクタリングをしていた
Appleもリファクタリングをしていた。

もう誰にも止められない。
アンチはウソと詭弁を繰り返すだけ

3 :仕様書無しさん:2018/05/19(土) 18:38:38.63 .net
嘘つき嘘つき嘘つき嘘つき嘘つき嘘つき嘘つき嘘つき嘘つき嘘つき嘘つき嘘つき
嘘つき嘘つき嘘つき嘘つき嘘つき嘘つき嘘つき嘘つき嘘つき嘘つき嘘つき嘘つき
嘘つき嘘つき嘘つき嘘つき嘘つき嘘つき嘘つき嘘つき嘘つき嘘つき嘘つき嘘つき
嘘つき嘘つき嘘つき嘘つき嘘つき嘘つき嘘つき嘘つき嘘つき嘘つき嘘つき嘘つき
嘘つき嘘つき嘘つき嘘つき嘘つき嘘つき嘘つき嘘つき嘘つき嘘つき嘘つき嘘つき
嘘つき嘘つき嘘つき嘘つき嘘つき嘘つき嘘つき嘘つき嘘つき嘘つき嘘つき嘘つき
嘘つき嘘つき嘘つき嘘つき嘘つき嘘つき嘘つき嘘つき嘘つき嘘つき嘘つき嘘つき
嘘つき嘘つき嘘つき嘘つき嘘つき嘘つき嘘つき嘘つき嘘つき嘘つき嘘つき嘘つき
嘘つき嘘つき嘘つき嘘つき嘘つき嘘つき嘘つき嘘つき嘘つき嘘つき嘘つき嘘つき
嘘つき嘘つき嘘つき嘘つき嘘つき嘘つき嘘つき嘘つき嘘つき嘘つき嘘つき嘘つき

4 :仕様書無しさん:2018/05/19(土) 18:40:54.65 .net
リファクタリングは金にならない虚業

5 :仕様書無しさん:2018/05/19(土) 18:42:49.96 .net
>>4
もう論破されてる。いくらやっても負け犬の遠吠えにしかならない。
金を稼いでいる所は全てリファクタリングしてる

6 :仕様書無しさん:2018/05/19(土) 18:44:55.59 .net
そろそろリファクタリングよりもそれをする頭の悪い>>2自身が全ての元凶だって気がついた?

7 :仕様書無しさん:2018/05/19(土) 18:47:56.31 .net
>>5
犯罪者はパンを食べている理論に通じるものがあるな

8 :仕様書無しさん:2018/05/19(土) 18:49:10.87 .net
リファクタリングを定義することから始めないと
それぞれの話が噛み合わないかもわからんね

9 :仕様書無しさん:2018/05/19(土) 18:52:41.61 .net
リファクタリングなど全ての人間が持っているやり直したい欲求の大義名分にすぎんのだから定義など無理なのだよ

10 :仕様書無しさん:2018/05/19(土) 19:09:33.77 .net
マーチンファウラーは悔しかったら使えるアプリ作ってみろよ
ハゲなんか信用できないんだよ

11 :仕様書無しさん:2018/05/19(土) 19:10:33.10 .net
トイレのウンコが流れるのもリファクタリング

12 :仕様書無しさん:2018/05/19(土) 20:47:42.17 .net
マーチンファウラーは所詮有名な技術書を出しているだけのやつ
仕事している俺(>>10)の方がすごいに決まってる

13 :仕様書無しさん:2018/05/19(土) 20:51:24.39 .net
2000年3月から、ThoughtWorks社に主席技術者として勤務している[1]。同社は、システムインテグレーションとコンサルティングを業務とする会社である。

SIかあ

14 :仕様書無しさん:2018/05/19(土) 20:57:08.26 .net
アメリカのシステムインテグレーションなんて
ろくなもんないだろ
SIなら日本が最高だよ

15 :仕様書無しさん:2018/05/19(土) 20:58:13.71 .net
SIよりも俺のほうがすごい

16 :仕様書無しさん:2018/05/19(土) 21:36:07.81 .net
>>12
いや、アレ詐欺師だろ
なんの実績もないじゃん
有名だと言うことにして売り込んでいる何かだ

17 :仕様書無しさん:2018/05/19(土) 21:40:24.54 .net
言っとくけど有名な技術書書いたって実績とは認めないからな
うちの新人の初めのコードコミットのほうが何倍も価値がある

18 :仕様書無しさん:2018/05/19(土) 21:43:16.16 .net
>>17
すまんがおまえんとこのコードには何の価値もない

19 :仕様書無しさん:2018/05/19(土) 21:48:04.63 .net
雑誌社かソフトウェア会社か
そーゆーのの広告塔なんだろうな
なんの実績もねーのにあの祭り上げ方はおかしい

20 :仕様書無しさん:2018/05/19(土) 21:48:07.34 .net
驚愕の事実拡散

創価の魔(仏罰、現証、非科学的な原始的発想)の正体は、米国が仕掛けてるAI

パトカーの付きまとい、咳払い、くしゃみ、芝刈機音、ドアバン、ヘリの飛行音、子供の奇声、ドアバンも全て、米国が仕掛けてるAIが、人を操ってやってる。救急車のノイズキャンペーンに至っては、サイレンで嫌がらせにする為だけに、重篤な病人を作り出す冷徹さ

集スト(ギャングストーカー、ガスライティング、コインテルプロ、自殺強要ストーキング)以外にも、病気、痛み、かゆみ、湿疹かぶれ、臭い、自殺、殺人、事故、火災、台風、地震等、この世の災い全て、クソダニ米国の腐れAIが、波動(周波数)を悪用して作り出したもの

真実は下に

http://bbs1.aimix-z.com/mtpt.cgi?room=pr02&mode=view&no=46

https://shinkamigo.wordpress.com

21 :19:2018/05/19(土) 21:50:58.75 .net
言っとくが、有名な技術書執筆は実績とは認めねーからな

22 :仕様書無しさん:2018/05/19(土) 21:53:10.80 .net
世界中にどれだけ影響を与えようが本が売れようが
客から金をもらえる1行の方が価値がある

23 :仕様書無しさん:2018/05/19(土) 21:53:41.92 .net
だから給料を上げろ
マーチンファウラーよりも俺のほうが給料が高くあるべきだ

24 :仕様書無しさん:2018/05/19(土) 21:59:37.34 .net
これが典型的な日本のおっさんである

25 :仕様書無しさん:2018/05/19(土) 22:05:07.06 .net
俺らは技術者なんだから技術についてちゃんと精査しないと駄目だってことだな

26 :仕様書無しさん:2018/05/19(土) 22:06:38.55 .net
技術とはコードを書くことである
本を書くことは技術ではない

27 :仕様書無しさん:2018/05/19(土) 23:28:20.40 .net
潟}ーチンファウラーだったんだろうね

28 :仕様書無しさん:2018/05/19(土) 23:30:03.76 .net
マーチンファウラーを貶めると
自分の価値が上がるはず

29 :仕様書無しさん:2018/05/19(土) 23:35:47.97 .net
>>28
ただ、怪しいとは思っておいた方がいいよ
なんもやってねーのに名前だけがひとり歩きしてる

30 :仕様書無しさん:2018/05/19(土) 23:37:56.25 .net
俺の会社じゃ有名な技術書書いても、
なにもやってないの同じだからなー

31 :仕様書無しさん:2018/05/19(土) 23:44:35.06 .net
>>30
売れるのはいいけど
それが役に立つかどうかは別の話じゃん

ホーキンス博士やでんじろう先生が役に立たないってわけじゃないけど
そればっかりでも駄目なんだよ

32 :仕様書無しさん:2018/05/19(土) 23:45:56.02 .net
ホーキング博士だった

33 :仕様書無しさん:2018/05/19(土) 23:47:02.57 .net
そのとおりだ。世界中で有効活用されている本でも
俺のにとっては別だからな。
俺が理解できないとどんな本も役立たずだ

34 :仕様書無しさん:2018/05/19(土) 23:53:34.25 .net
>>33
有効活用されているのか?
そこを精査しなければならない

35 :仕様書無しさん:2018/05/19(土) 23:57:51.61 .net
>>34
じゃあ言い出しっぺが
精査の方法を出してくれ
技術書一般に当てはまるやつ

36 :仕様書無しさん:2018/05/19(土) 23:58:46.61 .net
Amazonの評価とかでいいんやないか?
他にもっといい案があればよろしく
なければこれで

37 :仕様書無しさん:2018/05/19(土) 23:59:44.46 .net
企業が発表する技術を精査するのは雑音が多くて大変だ

敵はマーチンファウラーなんて実績の無いおっさんを有名人に仕立て上げることができる強敵だ
ネームバリューに負けて中身を見れないような雑魚は
そもそも技術書なんか手に取るべきでは無かった

38 :仕様書無しさん:2018/05/20(日) 00:00:31.31 .net
>>36
俺もそれでOK

39 :仕様書無しさん:2018/05/20(日) 00:01:24.46 .net
日本のAmazonだと翻訳が悪くて〜っていうのがあるので
アメリカのAmazonでの評価にしよう
そっちの方がレビュー多そうだし

40 :仕様書無しさん:2018/05/20(日) 00:02:17.95 .net
他にいい案はないかな?
ないならamazon.comの評価で判断するけど

41 :仕様書無しさん:2018/05/20(日) 00:03:16.17 .net
反対する人もないようだし
いいんじゃないですかね

42 :仕様書無しさん:2018/05/20(日) 00:03:49.29 .net
リファクタはプログラマ自身のためのもの
街並みがきれいなところに住むと幸福度が上がるように
自分の作ったコードがきれいに整頓されていると居心地が良い

効率?物の価値のわからんやっちゃな
プログラマになったら人生の3分の1をコードと共に過ごすんだぞ

43 :仕様書無しさん:2018/05/20(日) 00:06:40.82 .net
そもそもお前らはどうなの?

世間一般的に役に立つとされる技術を身に着けて、まわりから役に立つとされる評価が欲しいのか?
本当に開発の役に立つ技術が欲しいのか?

前者であればハゲに同調するのも正しい選択なんだ

44 :仕様書無しさん:2018/05/20(日) 00:07:47.31 .net
>>42
それって君の感想じゃん
なんかどういう仕組みでお金になるのか説明できる資料はないの?

45 :仕様書無しさん:2018/05/20(日) 00:09:24.00 .net
このままだと本が有用かどうかがamazon.comでの
評価になっちゃうよ?それでいいの?

46 :仕様書無しさん:2018/05/20(日) 00:09:44.15 .net
>>45
だからそれでいいって言ってるじゃんw

47 :仕様書無しさん:2018/05/20(日) 00:10:03.30 .net
>>45
もうそいつはNGにしてるからいい

48 :仕様書無しさん:2018/05/20(日) 00:11:40.71 .net
5ちゃんねるには見えないIDでNGにする方法があるのだ
その方法は教えられないがな

49 :仕様書無しさん:2018/05/20(日) 00:11:58.47 .net
ふーん、NGねぇ(笑)

50 :仕様書無しさん:2018/05/20(日) 00:13:24.49 .net
うそじゃないぞ

51 :仕様書無しさん:2018/05/20(日) 00:14:17.23 .net
>>44
最終的には金が入ると嬉しいのだって人間の感想じゃないか

52 :仕様書無しさん:2018/05/20(日) 00:15:23.07 .net
仕事は遊びじゃない。楽しいと思った時点で
それは仕事じゃないんだよ。金を稼ぐことだけ考えてろ

53 :仕様書無しさん:2018/05/20(日) 00:15:43.11 .net
長時間労働すれば金は稼げるぞ?w

54 :仕様書無しさん:2018/05/20(日) 00:18:35.05 .net
満場一致ってことでAmazonでの評価が高ければ、
世界中で有効活用されているとみなします。

55 :仕様書無しさん:2018/05/20(日) 00:19:00.94 .net
マーチンファウラーの本すごいな。
世界中で有効活用されてるじゃん

56 :仕様書無しさん:2018/05/20(日) 00:34:54.29 .net
は?Amazonの評価なんて認めるわけねーじゃん。ばーかーばーか

57 :仕様書無しさん:2018/05/20(日) 00:35:12.65 .net
>>51
そう、そこまで肯定してしまうと
彼らの虚業にも正当性ができてしまう

彼らははじめからかあるいはいつの時点からか
全く役に立たない技術をさも役に立つかのように
無料で公開し関連の商品で儲けるようになった

それの何が悪いのかと?
言われると何も悪くはない

58 :仕様書無しさん:2018/05/20(日) 00:36:42.51 .net
>>56
遅すぎw 他に代替案出せなかったお前の負け
負け犬は負け犬らしく遠吠え吐いて逃げなさい

59 :仕様書無しさん:2018/05/20(日) 00:37:46.74 .net
>>57
> 彼らははじめからかあるいはいつの時点からか
> 全く役に立たない技術をさも役に立つかのように

あー、君。悪いんだけどマーチンファウラーの書籍は
Amazonの評価で役に立つって証明されたばかりなんだわ
その結果を無視せんといてな

60 :仕様書無しさん:2018/05/20(日) 00:40:27.24 .net
無視してるのはわざとだろw
わざとであることを指摘したら
可愛そうじゃないかw

61 :仕様書無しさん:2018/05/20(日) 00:55:46.34 .net
お前らと話しても得られることは無さそうだな

62 :仕様書無しさん:2018/05/20(日) 06:57:35.34 .net
「動いているなら弄るなよ」

さあ反論しろ

63 :仕様書無しさん:2018/05/20(日) 07:20:00.68 .net
反論のなにも、そうやって仕事失った人がいますよ。
改良してください→「動いているからいじりません」
バグ修正してください→「動いているからいじりません」

64 :仕様書無しさん:2018/05/20(日) 09:31:34.08 .net
>>59
証明はされてないんじゃないかな
どっかの誰かが賛同したかもしれないけど
それが正しいかは別の話でしょ
もっと論理的に考えなよ
君プログラマーなの?

65 :仕様書無しさん:2018/05/20(日) 09:52:32.81 .net
タダより高いものは無かったって話だな

66 :仕様書無しさん:2018/05/20(日) 13:15:34.69 .net
>>64
もっといい案を出せなかった時点で
お前の言葉には説得力がない

67 :仕様書無しさん:2018/05/20(日) 15:45:57.31 .net
62
動いてるように見えてるだけだな。

68 :仕様書無しさん:2018/05/20(日) 15:50:28.92 .net
>>66
(´;ω;`)

69 :仕様書無しさん:2018/05/20(日) 16:36:20.66 .net
>>64
おまえらのような有象無象の馬鹿に多くの賛同が得られたという事は
すなわちその評価を得た対象は正しくないという事を意味する
これが論理的な考え方というものだ

70 :仕様書無しさん:2018/05/20(日) 17:02:30.35 .net
俺らみんな地球が丸いと思ってたがうそだったのか

71 :仕様書無しさん:2018/05/20(日) 17:12:26.04 .net
バカでも安全にコードを変更できるんだし良いよ

72 :仕様書無しさん:2018/05/20(日) 17:23:57.92 .net
賢いのが世間と違うこというのって自分の知識や経験で判断してるからじゃん

世間が世間のいうこと鵜呑みにするのは、だいたいはそれなりに世間が正しくてなんとかなってるからで
それだけを根拠にその逆に判断するのって最悪じゃね?

73 :仕様書無しさん:2018/05/20(日) 17:48:25.34 .net
>>72
じゃあ、日本は財政破綻するの?

74 :仕様書無しさん:2018/05/20(日) 17:49:46.08 .net
馬鹿の直感と真実が一致してるかどうかが重要
1+1は馬鹿の直感も真実も2になるので馬鹿の逆張りをしてはいけない
量子力学のような直感と真実が一致しない問題や、巧妙に思考を誘導する引っ掛け問題に対しては馬鹿の逆張りをした方が有利となる
そもそも馬鹿の答えは白紙になるってツッコミはなしな

75 :仕様書無しさん:2018/05/20(日) 18:25:02.66 .net
>>74
そもそもおまえは馬鹿

76 :仕様書無しさん:2018/05/20(日) 22:58:26.39 .net
マーチンファウラーが直近でなんかソフトの一つでも作ってりゃなぁ
でも実績を見ると典型的な詐欺師だね

テメ、ソフトウェア作ったことあんのかよハゲ



77 :仕様書無しさん:2018/05/21(月) 03:27:20.04 .net
嫉妬かな

78 :仕様書無しさん:2018/05/21(月) 06:15:56.93 .net
>>76
はい、どうぞ、あっちに逝きなさい

技術書の著者がアプリを公開してないと信用できない件
https://medaka.5ch.net/test/read.cgi/prog/1526850800/

79 :仕様書無しさん:2018/05/22(火) 00:24:18.28 .net
ジャップの財政破綻、早く来い。
俺を笑った奴らが真でいくのを笑い返して復習してやる。

80 :仕様書無しさん:2018/05/22(火) 01:50:13.48 .net
隔離スレを用意したとたん静かになったなw

81 :仕様書無しさん:2018/05/22(火) 02:15:27.86 .net
>>79
わざとやってるだろ

82 :仕様書無しさん:2018/05/22(火) 07:12:59.30 .net
あんなハゲ信仰してるやつは終わってるってことだ

83 :仕様書無しさん:2018/05/22(火) 07:43:05.81 .net
staticおじさん VS マーチンファウラー

84 :仕様書無しさん:2018/05/22(火) 07:44:35.35 .net
直接対決してほしい

85 :仕様書無しさん:2018/05/22(火) 08:02:19.26 .net
>>1
テスト出来ない作りにしちゃったの?

86 :仕様書無しさん:2018/05/22(火) 08:04:05.58 .net
>>85
テストはできる。ただ時間がかかるから
コストも掛かるだけだ

87 :仕様書無しさん:2018/05/22(火) 11:16:01.54 .net
とても簡単な自宅で稼げる方法
参考までに書いておきます
グーグルで検索するといいかも『ネットで稼ぐ方法 モニアレフヌノ』

4TTGQ

88 :仕様書無しさん:2018/05/22(火) 12:29:10.75 .net
>>86
手間かけるのをテストとは呼ばない。

89 :仕様書無しさん:2018/05/22(火) 13:59:31.57 .net
age

90 :仕様書無しさん:2018/05/22(火) 19:40:20.09 .net
>>88
いくらなんでもその言いがかりは無茶だ

91 :仕様書無しさん:2018/05/22(火) 19:54:46.87 .net
コストがかかるとテスト回数を減らすだろ
テストってのは何回もやらなきゃダメなんだよ
1回だけじゃたまたまテスト通っただけかもしれんぞ
これは数学的にも正しいことが証明されてるから国外の大手機械メーカーなどは凄まじい回数のテストを繰り返す

92 :仕様書無しさん:2018/05/23(水) 00:20:00.32 .net
アプリケーションのリファクタリングは実はそんなに重要じゃない
データベースのリファクタリングしろマジで

93 :仕様書無しさん:2018/05/23(水) 02:28:17.27 .net
リファクタリングを読みやすくするものだとすると
データベースよりもアプリケーションの方が
よく読む

94 :仕様書無しさん:2018/05/23(水) 06:49:30.06 .net
>>91
不確定要因をソフトにてんこ盛りにする奴が無能なだけ。

95 :仕様書無しさん:2018/05/23(水) 07:46:08.29 .net
不確定要素が無いことを証明できない限り不確定要素が無いからテストは1回でいいとは言えない
そんなことは物理的に不可能なのでテスト回数を増やしてこの程度の確率でなら正常動作を保証しますとしか言えんのだよ
科学的な実験をしたことのある理系ならわかってることだけどね

96 :仕様書無しさん:2018/05/23(水) 16:42:40.82 .net
モンキーテストでもやらんよりマシ

97 :仕様書無しさん:2018/05/23(水) 21:57:34.51 .net
バグが無いことを証明できないからテストするしかないっていう

98 :仕様書無しさん:2018/05/24(木) 06:18:17.54 .net
テストしなくちゃいけない

日本凄い

俺凄い

99 :仕様書無しさん:2018/05/24(木) 06:20:07.14 .net
>>98
いいからきりきり働けよ

100 :仕様書無しさん:2018/05/24(木) 07:44:11.48 .net
>>95
お前さんにはコスト意識がないのは分かった。

101 :仕様書無しさん:2018/05/24(木) 18:21:34.59 .net
リファクタリングって・・・
聞いてるこっちが恥ずかしくなるぜ
マー○ンファ○ラーってのは詐欺師のヘビー級チャンピオンの事
お前ら信者がやっているのは過労によるハゲの量産化
技術者は世の中を便利にするために行動しようとするものだが
信者どもはありもしない仕様変更を想定してリファクタリングとか言ってるわけだろ?
リファクタリングとか聞くたびに思ってたのよ
「今回の○○は△△に対応してるのでいくつでも追加可能にしておきました」
これって訳すと「設計書通りに実装しませんでした」
って事だろ
プログラマとか関係なく
世界中の生物を賢い順に並べたら
お前は先頭どころか下から数えた方が早いんじゃねーか?

102 :仕様書無しさん:2018/05/24(木) 18:29:34.52 .net
またマーチンファウラーに嫉妬してるのかw

103 :仕様書無しさん:2018/05/24(木) 18:50:41.09 .net
>>101
ん?違うよ
ファウラーのリファクタリングを読み返して理解してからまた来なよ

104 :仕様書無しさん:2018/05/24(木) 18:58:55.64 .net
>>103

1. 俺の理解によるとマーチンファウラーは詐欺師である
2. 詐欺師は信用してはいけない
3. 詐欺師であることを見抜いた俺はすごい

105 :仕様書無しさん:2018/05/24(木) 19:03:36.84 .net
いや、石橋コピペを貼ってみたかっただけ

106 :仕様書無しさん:2018/05/24(木) 19:18:23.48 .net
ハゲに有能はいない
これが全て

107 :仕様書無しさん:2018/05/24(木) 22:09:06.89 .net
大規模リファクタリングって普通それを作った・大きく関わってきたメンバーが入るもんだよね

108 :仕様書無しさん:2018/05/24(木) 22:15:25.51 .net
退職してたらどうしようもない

109 :仕様書無しさん:2018/05/25(金) 07:52:06.62 .net
ノルマこなした上でちゃんとテスト書くならリファクタリングしていいよって言われたから取り組んでるんだが
DB層が腐りきってるからどうにもならんという事に気が付いた
DB層を無視してDB層より上を綺麗にしようたってそうはいかないんだ

ビジネスロジックやプレゼンテーションロジックを大量に含む
テーブルやビューが複雑怪奇に絡まりあって何がどこにあるかさっぱりわからない
理解不能で長大なプロシージャが大量にある
どのアプリケーションがそのDBを参照してるかの資料すら無い

そんな腐りきった巨大な企業データベースをリファクタリングする体系的なテクニックって無いものか

110 :仕様書無しさん:2018/05/25(金) 15:46:30.70 .net
難しい構造なのに無理矢理
簡単(?)な構造に押し込めるから
余計におかしくなってしまうんよ

111 :仕様書無しさん:2018/05/25(金) 19:58:20.08 .net
>>109
設計やプログラミングを体系的に学ぶ方法はなんぼでもあるんやで
これを機会に1から学びなおしてみたらどうや無能くん

112 :仕様書無しさん:2018/05/25(金) 20:08:33.77 .net
リファクタの許可がでたら
企業の既存大規模DBの刷新を考えだす新人w

古いのはもういろいろプログラムが紐づいてるから個人で変更は難しい
お前の脳をDBに合わせてリファクタしたほうが
将来にわたって絶対楽
https://qiita.com/opengl-8080/items/37beac5e210f5363af4b

113 :仕様書無しさん:2018/05/25(金) 20:32:07.11 .net
お前らは何もわかってねえよ
ドメインロジックはおろかプレゼンテーションロジックまでデータベースを侵食しているシステムのヤバさをな
ホストアプリケーションのちょっとした変更がデータベースを破壊する
そんな地獄をたっぷりと味わってから出直してこい

114 :仕様書無しさん:2018/05/25(金) 20:37:34.69 .net
>>112
ただのバージョン管理じゃん
機械的な等価変換もできないしテスト支援でもない
ストアドにもホストアプリケーションにも非対応
リファクタリングとは名ばかり

115 :仕様書無しさん:2018/05/25(金) 20:40:21.58 .net
>>113
なんやそれw
「大人は何もわかってくれない」的なwwww
おまえリアル中二やな無能www

116 :仕様書無しさん:2018/05/25(金) 20:48:31.82 .net
あ、さわっちゃいかんあいつだったか

117 :仕様書無しさん:2018/05/26(土) 08:42:29.02 .net
マーチン・ファウラー : 数十年にわたってビジネスへのオブジェクト指向の適用に尽力する独立コンサルタント。
ヘルスケア、金融取引、企業財務などの分野におけるシステムのコンサル経験を持つ。
顧客にはクライスラー、シティバンク、英国民保健サービス、アンダーセン・コンサルティング、
ネットスケープ・コミュニケーションズなどが名を連ねる

118 :仕様書無しさん:2018/05/26(土) 08:56:33.31 .net
すごい実績だな
そんなファウラーが言うなら間違いない
JavaScriptのリファクタリング本楽しみ

119 :仕様書無しさん:2018/05/26(土) 10:14:39.33 .net
その人のリファクタリング本持ってるけど
そんなに目から鱗なこと書いてあるか?って思ったけどな

120 :仕様書無しさん:2018/05/26(土) 10:16:13.77 .net
今や常識だからな
地球が太陽の周りを回っているのだって現代人に行ってもなにを今更ってなるじゃん?
それと同じ
でも常識を定着させるのって大変なんだぜ

121 :仕様書無しさん:2018/05/26(土) 11:46:44.27 .net
で?何作った人なの?

122 :仕様書無しさん:2018/05/26(土) 13:14:13.69 .net
アルゴリズムを考える人より
アルゴリズムを特定の言語で実装するほうが
偉いに決まってるだろ

123 :仕様書無しさん:2018/05/26(土) 14:06:22.69 .net
だから給料上げろ

124 :仕様書無しさん:2018/05/26(土) 14:15:06.90 .net
給料あげたいなら転職ですよ

125 :仕様書無しさん:2018/05/26(土) 14:50:11.14 .net
マーチンファウラーはRailsのActiveRecordの基本を考えただけ
それを実装したRailsの開発者のほうがすごい
そのActiveRecordを使いこなしている俺のほうがもっとすごい
やつはリファクタリングを考え出しただけ
使いこなしている俺のほうがもっとすごい

126 :仕様書無しさん:2018/05/26(土) 15:01:45.54 .net
使うだけの人は他にも大勢いるので

127 :仕様書無しさん:2018/05/26(土) 15:17:50.89 .net
で?何作った人なの?

128 :仕様書無しさん:2018/05/26(土) 16:14:47.09 .net
マーチンファウラーはRailsのActiveRecordの基本を考えただけ
それを実装したRailsの開発者のほうがすごい
そのActiveRecordを使いこなしている俺のほうがもっとすごい
やつはリファクタリングを考え出しただけ
使いこなしている俺のほうがもっとすごい

129 :仕様書無しさん:2018/05/27(日) 09:23:12.38 .net
バカでも使えるようにしてくれているだけ

130 :仕様書無しさん:2018/05/29(火) 13:38:17.98 .net
>>128
サービス使うだけのオレの方がもっとすごい

131 :仕様書無しさん:2018/05/29(火) 20:26:06.70 .net
丸投げしているオレの方がもっとすごい

132 :仕様書無しさん:2018/05/29(火) 21:31:16.12 .net
普通に考えて丸投げされてる方がすごいやんコーダーさん

133 :仕様書無しさん:2018/05/29(火) 23:23:16.14 .net
>>131
確かにな。
すごい無能だ。

134 :仕様書無しさん:2018/05/30(水) 20:16:04.78 .net
>>132
コーダーに丸投げしてる自覚ないのかお前

135 :仕様書無しさん:2018/05/31(木) 06:56:15.54 .net
本当に頑張っても問題が解決できないなら
その頑張りが問題を解決できない原因です。

136 :仕様書無しさん:2018/05/31(木) 07:09:12.81 .net
>>134
は?コーダーさんすごいね言うとるやん
何を言うとるんやおのれは?w

137 :仕様書無しさん:2018/06/01(金) 21:41:56.20 .net
リファクタ厨はマーチンファウラーのハゲがバレて逃げちゃったんだろ?

138 :仕様書無しさん:2018/06/01(金) 22:43:08.05 .net
>>137
ハゲにコンプレックス持ってる奴は、そういう発想がナチュラルに出て来るんだな。

139 :仕様書無しさん:2018/06/02(土) 03:08:10.24 .net
まさか、あのマー○ンファ○ラーがハゲとか誰も予想だにしなかったよね

140 :仕様書無しさん:2018/06/02(土) 06:24:28.62 .net
ハゲのジョブズは早死したしな

141 :仕様書無しさん:2018/06/02(土) 09:26:01.58 .net
ハゲに嫉妬

142 :仕様書無しさん:2018/06/02(土) 19:00:26.84 .net
ハゲに人権なし

143 :仕様書無しさん:2018/06/05(火) 10:16:30.55 .net
リファクタリング出来る環境なら、テストも自動化されてるはずだよな?
まさか手作業でリファクタリングしてるとか?

144 :仕様書無しさん:2018/06/05(火) 11:27:38.12 .net
訂正 まさか手作業でテストしてるとか?

145 :仕様書無しさん:2018/06/05(火) 11:28:09.65 .net
手作業でテストしている所が
リファクタリングに文句つけてるんだろうね

146 :仕様書無しさん:2018/06/05(火) 13:35:11.08 .net
テストがないとリファクタリングできない
リファクタリングしないとテストが整備できない


はい終わり
リファクタリングは机上の空論

147 :仕様書無しさん:2018/06/05(火) 13:46:40.92 .net
最近のビジュアルスタジオって、そここっちのコードの方が良いよって言って来るよな?

148 :仕様書無しさん:2018/06/05(火) 13:59:43.66 .net
>>146
え?テストができないコードをどうやって今修正してるの?
修正できるならいくらでもテストできるように修正できるはずだよね?

149 :仕様書無しさん:2018/06/05(火) 14:08:09.27 .net
>>148
手作業で必要なテストをするだけ
悪いけどこっちはリファクタリング厨みたいに無計画じゃないから安定的でバグはそんなに出ないんだわ
なので手作業のテストで変更を十分カバーできるのな

150 :仕様書無しさん:2018/06/05(火) 14:41:13.07 .net
>>149
じゃあ手作業でテストすればリファクタリングできるね(大爆笑)
おら?どうした?墓穴踏んだ気分はwwww

151 :仕様書無しさん:2018/06/05(火) 15:57:32.17 .net
>>150
無駄な作業はしない

152 :仕様書無しさん:2018/06/05(火) 16:58:42.21 .net
>>151
じゃあするってことだね(大爆笑)

153 :KAC:2018/06/05(火) 17:58:50.19 .net
>>143
お前は自動テストだけやって製品出荷するつもりか?

154 :仕様書無しさん:2018/06/05(火) 18:34:36.43 .net
動けばいいんやで、あとのことは知らん

155 :仕様書無しさん:2018/06/05(火) 20:48:21.55 .net
リファクタリング(筋肉)

156 :仕様書無しさん:2018/06/05(火) 21:18:58.78 .net
テスト(手動)

157 :仕様書無しさん:2018/06/05(火) 22:18:12.30 .net
コードレビューとかうざすぎる
うごきゃいんだよ動きゃ
汎用性なんか知るか
全部コードベタ書きにしてやるわ

158 :仕様書無しさん:2018/06/05(火) 22:20:21.02 .net
そしてそれを全部>>157がメンテしてやるよ!

159 :仕様書無しさん:2018/06/05(火) 22:32:45.94 .net
と自分で言えない所がだめだよねw

160 :仕様書無しさん:2018/06/05(火) 23:05:18.43 .net
綺麗なコードを書いてリファクタリングを繰り返したほうが楽に動くコードを維持できると思うんだが

161 :仕様書無しさん:2018/06/05(火) 23:06:29.62 .net
動かすだけなら汚くてもいい
綺麗に書いたら時間がかかるって前提がまず狂ってる

162 :仕様書無しさん:2018/06/05(火) 23:08:28.75 .net
汚いコードを書いてリファクタリングしたら時間かかったが?

163 :仕様書無しさん:2018/06/05(火) 23:11:55.06 .net
それは汚いままだともっと時間がかかってたんだよ
リファクタリングしたことによって被害が最小化した

164 :仕様書無しさん:2018/06/05(火) 23:22:14.30 .net
btnSearch_Click(object sender, EventArgs e) {
string sql = "select * from ... where ...";
DataTable t = new DataTable();
g_Database.CommandText = sql;
g_Database.Parameters.Add("unko", txtUnko.Text);
g_Database.Fill(t);
grid1.DataSource = t;
}

こうやって汚くても別にええねん
そんなんより爆速でコーディングしたほうがええで
リポジトリとかドメインサービスとかアホくさwww

165 :仕様書無しさん:2018/06/05(火) 23:27:42.79 .net
上のコードなら3分で書ける
コードもシンプルで誰が見てもわかりやすい
リポジトリやらドメインサービスやらおバカなことをやりだすとクラスが一気に増えて意味不明になる
コーディング時間も10倍じゃ足らんくなる
世間一般で言う綺麗なコードを書くのは実は非合理的なんやな
コンサルさんはそれでお金貰っとるから綺麗に書かなアカンって洗脳しようと企んどるようやけど騙されへんで

166 :仕様書無しさん:2018/06/05(火) 23:29:33.18 .net
おもちゃ屋さんはそれでいと思うよ

167 :仕様書無しさん:2018/06/05(火) 23:29:45.86 .net
このように、たったこれだけのコードが
自分が作っているものの全てだと
言ってるような人の浅い考えなのです

168 :仕様書無しさん:2018/06/05(火) 23:32:10.27 .net
なんや論理的反論できひんなら素直にそう言いや
負け惜しみはみっともないで

169 :仕様書無しさん:2018/06/05(火) 23:38:18.13 .net
悔しかったら、自分が普段どれだけのコードを書いてるのか言ってみいや
100行か? 1000行か?

170 :仕様書無しさん:2018/06/05(火) 23:40:00.55 .net
普段1万行とか普通に書いてる人間に
たった10行のコード持ってきて
ほら、この場合はいらないでしょ?と言われてもな(苦笑)

171 :仕様書無しさん:2018/06/05(火) 23:45:13.51 .net
上のコードなら3分で書けるといっただろ?
10行で3分なら、100行で30分、1000行で300分
1万行でも3000分だ。50時間、2日あればできる量だ
いちいちリファクタリングする意味はない

172 :仕様書無しさん:2018/06/05(火) 23:45:54.47 .net
リポジトリやらドメインサービスやらくだらない余計なクラスを書くから何万行も無駄なステップ数が生じるんやで

173 :仕様書無しさん:2018/06/06(水) 01:34:19.28 .net
c#のインターフェース機能が百害あって一利無しだ

174 :仕様書無しさん:2018/06/06(水) 01:49:03.63 .net
>>173
なぜ?

175 :仕様書無しさん:2018/06/06(水) 01:53:52.81 .net
俺様に理解できないから邪魔

176 :仕様書無しさん:2018/06/06(水) 08:14:52.01 .net
>>174
ソースが追えない
インターフェース読んでる箇所全部見ないといけない
動かさないと挙動がわからない
動かせないときの開発のヤバさは異常

177 :仕様書無しさん:2018/06/06(水) 09:31:12.99 .net
>>176
ああ単なる能力不足ね

178 :仕様書無しさん:2018/06/06(水) 12:12:46.41 .net
>>177
物理的な問題だと思うが?

179 :仕様書無しさん:2018/06/06(水) 12:21:34.08 .net
設計者が何のためにインターフェース切って疎結合にしたのかわかってないのでは?
インターフェースの先まで見に行かないとクライアントを保守できないとしたら
それは設計が間違ってるからインターフェースを超えて結合しちゃってるんだよ

180 :仕様書無しさん:2018/06/06(水) 12:23:37.73 .net
動かせないってのも何言ってんだかって感じだね
モックを書くって発想がないのかな?
ユニットテストしてないの?
ユニットテストは個別に動かすこともできるよ

181 :仕様書無しさん:2018/06/06(水) 12:41:30.48 .net
>>179
同じインターフェースでほとんど似てる機能なんだから機能重複しまくりだと思うけど見たら負けなの?

182 :仕様書無しさん:2018/06/06(水) 12:42:42.54 .net
>>180
モックを書かないとどうしようもないんだよね?

183 :仕様書無しさん:2018/06/06(水) 12:45:56.12 .net
>>178
ソースが追えないってのは能力不足かメモ帳使ってるかだろ

184 :仕様書無しさん:2018/06/06(水) 13:00:12.33 .net
>>183
え?自分で呼び出し口で違いがわからないようにしたんだよね?
知る必要がないってことで
忘れちゃったの?
だからそこは追えないのが正解でしょ?

185 :仕様書無しさん:2018/06/06(水) 13:30:39.28 .net
>>179
リリースした後のバグっていうのは通常アプリケーションを
使っているときに見つかるんだわ
○○という設定でボタンをクリックしたときとか

で、実際のバグはそのクリックを行って実行する処理の
どこかのモジュールに存在する。

その時、インターフェースの先を見ないでバグのある箇所を
見つけることはできないよ。だってインターフェースの先に
バグがあるんだから

186 :仕様書無しさん:2018/06/06(水) 13:33:57.19 .net
>>182
モックはなるべく書かないほうが良い。
なぜならモックはOKだけど、実際のアプリでは
バグになることがあるから

なお、インターフェースはモックにすり替えるためにあるのではなく
同じインターフェースを持つ複数のモジュールを使うためにある
テストを用意にするためでも疎結合にするためでもない

187 :仕様書無しさん:2018/06/06(水) 13:38:25.16 .net
c#のinterfaceでソースが追えないってのは、そもそも追い方からして間違ってる気がする
追加や保守なら何も考えずに呼び出し履歴追って修正に対する影響範囲調べりゃいいだけだし、それでクラス設計やデザインパターン機構の根っこを弄らんといけないなら、大改修だろ。
そもそも別の手がないか考えろよってのもある

188 :仕様書無しさん:2018/06/06(水) 13:57:01.37 .net
修正に対する影響範囲調べて
それでどうやって最初から存在するバグを見つけられるの?

189 :仕様書無しさん:2018/06/06(水) 15:30:27.75 .net
どんなクソコードも解読して作り直すみたいな
特殊能力持った奴も中にはいるのかな

190 :仕様書無しさん:2018/06/06(水) 15:50:11.46 .net
>>184
何こいつ

191 :仕様書無しさん:2018/06/06(水) 19:46:21.82 .net
最低限ユニットテストしておけよってことじゃないのか

192 :仕様書無しさん:2018/06/06(水) 21:42:22.41 .net
え、実装に飛べないやつとかいるのかよ…

193 :仕様書無しさん:2018/06/06(水) 21:47:01.50 .net
                    ハ_ハ _
                   ∩゚∀゚)ノ  飛べるよ!
                    )  /
                   (_ノ_ノ

               彡
      .
 _,,..-―'"⌒"~ ̄"~⌒゙゙"'''ョ
゙~,,,....-=-‐√"゙゙T"~ ̄Y"゙=ミ
T  |   l,_,,/\ ,,/l  |
,.-r '"l\,,j  /  |/  L,,,/
,,/|,/\,/ _,|\_,i_,,,/ /
_V\ ,,/\,|  ,,∧,,|_/

194 :仕様書無しさん:2018/06/06(水) 22:01:51.95 .net
>>192
やれるもんならやってみろよ

195 :仕様書無しさん:2018/06/06(水) 22:33:07.03 .net
ポケモン
デジモン
やれるもん

ヤダモン
ドラえもん
やれるもん

196 :仕様書無しさん:2018/06/06(水) 23:01:14.34 .net
設計書の段階でリプレースしてえ
日本のSEさん設計能力低すぎてアーキテクチャすら定まってない

197 :仕様書無しさん:2018/06/06(水) 23:37:14.88 .net
>>187
うまくいってる間はいいけど
発生率の低いバグが出たときに
インターフェースは死ぬ
動かしてみないと何が生成されてるのかわからないうえに
影響範囲はインターフェースをもつクラス全部になる
一つ一つ可能性を排除していく作業を行わなければならない

198 :仕様書無しさん:2018/06/07(木) 04:42:46.23 .net
>>194
右クリックもできないの?それとも本当にメモ帳使ってんの?

199 :仕様書無しさん:2018/06/07(木) 07:11:25.09 .net
>>198
え?具体的に右クリックからどうやって追ってくの?
そもそも知らなくていいってのが君の主張だったよね?
何、一生懸命できるみたいなこと言ってるの?
必要ないんでしょ?

200 :仕様書無しさん:2018/06/07(木) 07:24:06.27 .net
>>199
こいつwww

201 :仕様書無しさん:2018/06/07(木) 07:25:37.92 .net
どうせまだVS2005とか使ってんだろ

202 :仕様書無しさん:2018/06/07(木) 07:37:35.21 .net
キチガイに触るな

203 :仕様書無しさん:2018/06/07(木) 08:02:26.43 .net
反論が無いなら俺の勝ちだぞ

204 :仕様書無しさん:2018/06/07(木) 08:03:21.80 .net
右クリックに過剰な夢を見すぎてる

205 :仕様書無しさん:2018/06/07(木) 08:21:56.25 .net
本当にインターフェイスから実装に飛べないやつなんているのかよ…

206 :仕様書無しさん:2018/06/07(木) 08:50:14.99 .net
visualstudio使ったことないんじゃね?

207 :KAC:2018/06/07(木) 10:42:30.32 .net
コード読む力が無いだけかと

208 :仕様書無しさん:2018/06/07(木) 19:23:34.75 .net
>>205
具体的にどうやるの?
全部見るしかないでしょ?

209 :仕様書無しさん:2018/06/07(木) 19:28:56.75 .net
>>208
全部とは?

210 :仕様書無しさん:2018/06/07(木) 19:45:28.92 .net
インターフェースの契約をテストするコードを書いて実装クラス全部についてテスト実行するだけだろ
それでオールグリーンならインターフェースの先がなんだろうと関係ない
バグはクライアントクラスにあるとわかる
もちろんレッドが出たらインターフェースのどの実装クラスが犯人か即座にわかる

211 :仕様書無しさん:2018/06/07(木) 19:54:58.72 .net
>>210
テストでバグがないことが証明できるなら
そうだろうな。

実際はテストはバグを見つけることはできても
バグがないことの証明にはならない。

いくらインターフェースの契約をテストするコードを書いても
そこにバグがないことにはならないんだよ

結局バグを見つけるために、インターフェースの呼び出し側が悪いのか
呼び出し先が悪いのか、特定の実装クラスだけで起こる問題なのか
探し回る必要がある

212 :仕様書無しさん:2018/06/07(木) 20:09:57.82 .net
>>194
こいつwww

213 :仕様書無しさん:2018/06/07(木) 20:33:15.96 .net
>>211
なるよ
それが契約というものなんだよ
契約はそうあれと定められたものだからね

どんなにおかしい動きをしていても契約どおりならインターフェース実装クラスはバグではない
そのおかしな動きに対応していないクライアントクラスがバグってこと
逆に対応してるのにおかしいならインターフェース実装クラスが契約に違反したバグクラスってこと

契約そのものが矛盾してるってこともあるけどそれは契約が間違っているわけではなく
すべてのインターフェース実装クラスが間違っているということになる
それはそれで赤信号が出まくるからすぐにわかる
バグではないが役に立たない矛盾した契約を解消しようってことになるね

214 :仕様書無しさん:2018/06/07(木) 20:36:53.10 .net
ちなみにその矛盾した契約ってのはバグよりも遥かに発生しにくい
契約は実装よりもずっとシンプルだからね
なのでほぼすべてのケースで契約をテストするだけでクライアント側かインターフェース実装側のどちらかが悪いか決着がつく

215 :仕様書無しさん:2018/06/07(木) 20:38:41.72 .net
>>213
> なるよ
> それが契約というものなんだよ
> 契約はそうあれと定められたものだからね

根拠なしにそう言われてもなー

まずそう定められたものとか
嘘言わないで理由を言おうか

216 :仕様書無しさん:2018/06/07(木) 20:47:13.17 .net
人間はミスする
故に人間が作ったものに完璧はない。

「契約」が人間が作ったものであれば
完璧なものは存在しないのでバグない証明にはならない

217 :仕様書無しさん:2018/06/07(木) 22:30:29.01 .net
>>194
いつの時代の話でしょうか

218 :仕様書無しさん:2018/06/07(木) 22:52:43.06 .net
>>213
長文の割に全く中身が無いなw

219 :仕様書無しさん:2018/06/07(木) 23:01:28.40 .net
インターフェースに間違いって言われてもなぁ?

本当は200Vが欲しいんだけど
家庭用に普及してるのは100Vなんだよね

これがインターフェースの本質だろ
みんなで使うためにとりあえず1つの型にハメる

そこにベストは存在しねーんだよ
それでも型を作ることにメリットがあるとしたときに初めて威力を発揮する仕組みがインターフェースだろ

ぶっちゃけオーダーメイドのビジネスアプリにこんなもん適用してる奴
頭が悪いだろ

220 :仕様書無しさん:2018/06/07(木) 23:54:14.02 .net
バグってるインターフェースは存在しない
嘘だと思うなら何か例を挙げてみな
絶対の不可能だから

221 :仕様書無しさん:2018/06/07(木) 23:58:52.34 .net
>>219
ちがう
「200Vでなければならない」
が本質

「100Vしかないから変圧して200Vにしよう」
これは実装

222 :仕様書無しさん:2018/06/08(金) 00:31:57.52 .net
>>220
論点がおかしい。
いくらテストしても、バグがないことは証明できず
いざバグが発生したとなったときに、
インターフェースの呼び出し側に問題があるか
呼び出し先にあるのかわからないから
インターフェースの先まで調べないといけないって話だろ

223 :仕様書無しさん:2018/06/08(金) 00:37:50.29 .net
>>222
インターフェースにはバグは無い
実装にバグがあるか
クライアントにバグがある

224 :仕様書無しさん:2018/06/08(金) 00:38:28.31 .net
そしてそれは規約をテストすればすぐにわかる

225 :仕様書無しさん:2018/06/08(金) 01:42:03.55 .net
>>224
頭悪いのかな?

バグっていうのは特定の場合のテストを
してない(正しく行われてない)から発生するんだよ

バグが後から発覚することからもわかるように
そりゃテストすればわかるが、
テストしてないって状況が存在する

テストしてない場合にどうやってわかるの?

226 :仕様書無しさん:2018/06/08(金) 06:07:35.14 .net
>>225
テスト実施してない場合はテスト実施してください
大丈夫ですかあなた?

227 :仕様書無しさん:2018/06/08(金) 06:25:46.17 .net
プロフェッショナルならログを取ろう
スタックトレースを見れば実行時型はすぐわかる
インターフェースへのIOをログして仕様通りか確認すれば即座に具象クラスのバグかどうかわかる
具象クラスのバグじゃなければモックでIOを再現すれば新しいテストケースになる
どんなバグも定数時間で解ける

228 :仕様書無しさん:2018/06/08(金) 07:24:46.93 .net
無理だな
ゲームでよくあるごった煮リストだろ?
上履きとか黒板消しも鍋に入ってるし

229 :仕様書無しさん:2018/06/08(金) 07:51:42.26 .net
>>226
テストしてもバグが出るんですよ。
知らないんですか?

230 :仕様書無しさん:2018/06/08(金) 08:20:12.44 .net
テストすればバグを無くせると
いう、壮大な勘違い。

231 :仕様書無しさん:2018/06/08(金) 12:49:02.36 .net
>>227
だからそれ実行しないとわかんないって言ってるんでしょ?
インターフェースなんてゴミ機能使うからこのザマなわけ

232 :仕様書無しさん:2018/06/08(金) 13:27:08.92 .net
実行しなければバグもクソもないので問題なし

233 :仕様書無しさん:2018/06/08(金) 13:41:45.35 .net
額に入れて飾っておくのか?

234 :仕様書無しさん:2018/06/08(金) 19:08:52.90 .net
ソース見てもわからないソースにしたわけだ
実行しないとわからないクソソースって理解できた?

235 :仕様書無しさん:2018/06/08(金) 19:27:53.99 .net
ソース見れば分かるよ

236 :仕様書無しさん:2018/06/08(金) 23:00:48.32 .net
>>235
全部見ればなw
インターフェースは呪いだ
こいつを通すと問答無用で全部読まなければならなくなる
普通は不具合がでてもいいように影響範囲を絞るように組むものだが
こいつは同じインターフェースを使う奴全員を問答無用で容疑者にする
プロジェクトを破綻させたいならオススメの手法

237 :仕様書無しさん:2018/06/08(金) 23:02:35.01 .net
ソース見ればわかるよ
インターフェースが使われていると大変だけど

238 :仕様書無しさん:2018/06/09(土) 00:33:43.99 .net
>>236
影響範囲を極限まで絞るためのインターフェース
もし直接参照したら連鎖的に影響が広がりコードベース全体が影響範囲になってしまう
インターフェースできっとけばあらゆる影響が局所化する

239 :仕様書無しさん:2018/06/09(土) 08:59:12.38 .net
>>238
じゃ、どのクラスがバグってるのか言ってご覧よ

240 :仕様書無しさん:2018/06/09(土) 09:01:03.39 .net
そもそも違いを知らなくていいように自分でしたのに特定なんかできるわけないじゃん
自分が何をやってるのかわかってる?
君が作ってるのはごった煮リストって言われる闇鍋

241 :仕様書無しさん:2018/06/09(土) 10:32:37.55 .net
例えばインターフェースが以下のようなものだったとしよう

interface Foo {
 void method1();
 void method2(int i);
}


この時、インターフェースを守っていなければ、
呼び出し側にバグがあるし

インターフェースを守っていれば、
呼び出し先にバグがある


プログラムでバグが発生したら、Fooのインターフェース
具体的には、method1を引数無しで呼び出しているか?
method2をint引数一つで呼び出しているか?
を確認すれば良い。

このインターフェースを守っていれば、呼び出し側にはバグはなく
呼び出し先にバグが有るということだ

242 :仕様書無しさん:2018/06/09(土) 10:33:15.97 .net
インターフェースの先がどうなってるかは気にしなくていい
気にしなければならないなら設計ミス

243 :仕様書無しさん:2018/06/09(土) 10:41:45.13 .net
呼び出し先にバグがあるなら、呼び出し先を見ないといけない

どうやって呼び出し先を特定するの?

が疑問らしいよ。騒いでいる人は。

244 :仕様書無しさん:2018/06/09(土) 10:50:52.51 .net
>>243
テスト書いて実行
赤くなったやつが犯人

245 :仕様書無しさん:2018/06/09(土) 11:11:20.05 .net
>>244
実行しないとわかんないクソソースなんだろ?
どうしてそこを認めないの?

246 :仕様書無しさん:2018/06/09(土) 11:14:32.39 .net
>>242
じゃ、一個でもバグったら終わりじゃん

247 :仕様書無しさん:2018/06/09(土) 11:17:20.69 .net
>>246
インターフェースの先は絶対にバグらない
そういう世界に書き換えておいた

248 :仕様書無しさん:2018/06/09(土) 11:18:16.03 .net
DIコンテナにインターフェースの実装クラスは
これを使いますって書くじゃんすぐ分かるじゃん

249 :仕様書無しさん:2018/06/09(土) 11:30:27.78 .net
>>248
知る必要は無いんじゃないの?
なんでそんなことしたの?

250 :仕様書無しさん:2018/06/09(土) 11:35:07.25 .net
>>245
実行すりゃいいじゃん
ソースを目視チェックするより簡単だよ

251 :仕様書無しさん:2018/06/09(土) 11:36:59.79 .net
>>249
インターフェースの利用側は知らなくていいだけ。
インターフェースの提供側(DIコンテナ)でクラスを切り替えることにより、
利用側はコードを変えずに実装を変えられるのがメリット。

252 :仕様書無しさん:2018/06/09(土) 11:41:27.66 .net
>>248
だからみんな99%のインターフェースは問題なしって認識で納得してるよ
実行時にダイナミックに型が変わる場合に限ってバグを出した型の特定が難しいからインターフェースはダメなんじゃないかと議論してるところ

253 :仕様書無しさん:2018/06/09(土) 11:42:34.82 .net
>>250
実行しないとわかんないクソソースだよね

254 :仕様書無しさん:2018/06/09(土) 11:51:44.90 .net
switch (kubun) {
case Kubum.Hoge:
// super long code
break;
case Kubun.Fuga:
// super long code
break;
case ...
}

インターフェース(あるいは抽象クラス)を使わないとなると
代わりにこういう異常なボリュームの分岐がアッチコッチに大量発生する
実行するまで分岐条件が決まらないからどの分岐を追いかければいいかわからない
実行しないでソーストレースするなら全ての分岐を見なければならない
それってインターフェース否定派の言ってることと同じだよね

しかも分岐バージョンの方はインターフェースや抽象クラスと違って各バリエーションがバラバラに引きちぎられてプログラム全体に散らばってるからトレースが死ぬほど大変

255 :仕様書無しさん:2018/06/09(土) 11:55:23.51 .net
>>252
お前はifやswitchを使わずにコードを書くのか?
インターフェースの提供側にifやswitch文が出来たらコードを追えないの?

256 :仕様書無しさん:2018/06/09(土) 12:09:55.53 .net
>>255
インターフェースや抽象クラスに分離するほどのものでない小さく局所的な条件分岐ならコードを見ればいい
でも今はインターフェースや抽象との対比としての条件分岐を話題にしてる
その場合の条件分岐はとてもじゃないけどコードを追いかける気にはならないね

257 :仕様書無しさん:2018/06/09(土) 12:10:22.15 .net
>>254
だからさ
それは必要なコードじゃねーの?
バグったときにバグった箇所もわからないようなコードのどこがいいの?

極論を言うとプログラムなんて代入と四則演算と条件分岐を繰り返してるだけなので
それ以外は無駄な手間って言うならクラスも関数もいらねーよ

258 :仕様書無しさん:2018/06/09(土) 12:10:35.07 .net
例えばインターフェースが以下のようなものだったとしよう

interface Foo {
 void method1();
 void method2(int i);
}


この時、インターフェースを守っていなければ、
呼び出し側にバグがあるし

インターフェースを守っていれば、
呼び出し先にバグがある


プログラムでバグが発生したら、Fooのインターフェース
具体的には、method1を引数無しで呼び出しているか?
method2をint引数一つで呼び出しているか?
を確認すれば良い。

このインターフェースを守っていれば、呼び出し側にはバグはなく
呼び出し先にバグが有るということだ

259 :仕様書無しさん:2018/06/09(土) 12:11:38.98 .net
>>251
> 利用側はコードを変えずに実装を変えられるのがメリット。

コードは変えませんが設定ファイルは変えます
って言いたいの?

260 :仕様書無しさん:2018/06/09(土) 12:15:38.43 .net
>>259
変える箇所が小さい

261 :仕様書無しさん:2018/06/09(土) 12:17:20.00 .net
>>260
じゃあそもそも変える必要性がない場合は?

262 :仕様書無しさん:2018/06/09(土) 12:18:30.49 .net
>>256
>>252は実行時にダイナミックに型が変わる場合の話をしている

263 :仕様書無しさん:2018/06/09(土) 12:20:04.98 .net
>>261
変える必要性があるところの話だから

264 :仕様書無しさん:2018/06/09(土) 12:26:30.23 .net
>>263
変える必要性がある = インターフェースを使う
変える必要性がない = インターフェースは使わない

ってことでいいでしょうか?

265 :仕様書無しさん:2018/06/09(土) 12:31:38.30 .net
>>257
だからインターフェースや抽象クラスに対応する条件分岐はバグった時にバグった箇所もわからないクソコードなんだよ

インターフェースや抽象クラスを使えば原因の切り分け、再現コード(テストケース)の作成、詳細の分析、修正の妥当性確認(テスト)まで高速で実行できる
対応する条件分岐では不可能

266 :仕様書無しさん:2018/06/09(土) 12:34:52.93 .net
>>265
え?何いってん?
そもそも型情報は必要ないって
潰しちゃってるのがインターフェースだよね?
知る必要もないってのが君の主張だったよね?

267 :仕様書無しさん:2018/06/09(土) 12:36:29.57 .net
>>264
インターフェースを使うのは一つの手段

268 :仕様書無しさん:2018/06/09(土) 12:40:51.75 .net
やっぱりパソコンのたとえがわかりやすい

インターフェース使わない派は
メモリが壊れたらパソコンが壊れたものとしてパソコン全体を修理に出すしかない
パソコンとして結合してないとテストできないからどこが壊れたかもわからないのでぼったくられる
ひどい時は修理代が馬鹿にならんならいっそパソコン買い替えちゃうかともったいないことを言い出す
そそてメモリだけを高性能なものに替えたい場合でもパソコンを買い換えるしかない

インターフェース使う派は
メモリが壊れたらパソコンの部品を個別にテストしてメモリが壊れてると判断できる
メモリだけ買い替えればいいので最小限のコストでパソコンが復活する
メモリだけを高性能なものに替えたい場合は文字通りメモリだけを取り替えればいい

269 :仕様書無しさん:2018/06/09(土) 12:42:01.12 .net
>>266
そう
必要ないよ
わかってきたか?

270 :仕様書無しさん:2018/06/09(土) 12:43:20.53 .net
>>269
不具合修正できないじゃんw

271 :仕様書無しさん:2018/06/09(土) 12:43:53.01 .net
インターフェースの先はバグらない世界に書き換えておいた

272 :仕様書無しさん:2018/06/09(土) 12:51:03.93 .net
>>270
テストエラーを潰すだけ

273 :仕様書無しさん:2018/06/09(土) 12:53:38.99 .net
>>268
> インターフェース使わない派は
> メモリが壊れたらパソコンが壊れたものとしてパソコン全体を修理に出すしかない

その方がいい場合もあるよね?

例えばパソコンが動かない!どこが壊れたんだ?ってなった時
パソコンに詳しくない人はメモリかどうかを切り分けられない

どうせ切り分けないんだから、丸ごとメーカーに出したほうが良いし
メーカーも丸ごと交換したほうが安くて早い
それほど人件費は高い

274 :仕様書無しさん:2018/06/09(土) 12:57:27.66 .net
>>273
ということは君はバグが発生する度にシステムリプレース案件立ち上げればいいんじゃないかな

275 :仕様書無しさん:2018/06/09(土) 12:58:24.48 .net
普通ダイナミックライブラリにして複数のアプリ間で共通に使うものを定義するのに使うよな?

276 :仕様書無しさん:2018/06/09(土) 12:59:27.73 .net
>>274
バグをなおすこととインターフェースになんの関係があんの?
インターフェースを使っていようがいまいが、
バグの原因は一緒だろ

インターフェースを使わないからって
システムリプレースになるわけじゃない

277 :仕様書無しさん:2018/06/09(土) 13:04:30.80 .net
>>276
インターフェースを使わないと原因のスコープが広くなりすぎて全体に影響するんだよ

278 :仕様書無しさん:2018/06/09(土) 13:34:30.55 .net
>>277
インターフェース使わなくても、小さなモジュール(クラス)に分ければ十分では?
そもそもクラスですらなくても十分なC言語w

279 :仕様書無しさん:2018/06/09(土) 13:36:44.91 .net
>>274
ハハハ(*゚∀゚)b

280 :仕様書無しさん:2018/06/09(土) 13:59:19.10 .net
実行しないと原因わからんから糞って意見があるが、どんなソースでもログ仕込んだりしつつ実行するのが手っ取り早いだろとか思う。
んで、実行できないんだよボケとか言ってる奴らは、正にテスト出来ないソースを量産してる奴らってことだよな

281 :仕様書無しさん:2018/06/09(土) 14:11:48.87 .net
>>278
依存先を直に参照、インスタンス化すると親に埋め込まれてしまう
これは依存先にバグがあると親もバグがあるということな
再起的にあらゆるクラスが異常となる
インターフェースで依存を切っておけばそうならない

282 :仕様書無しさん:2018/06/09(土) 14:14:54.36 .net
>>280
その通り
クラスの実体に直接依存してしまうとインフラストラクチャにも依存することになる
すると全てのインフラストラクチャが整備されていないとテストもデバッグもできくなってしまう

283 :仕様書無しさん:2018/06/09(土) 14:19:17.39 .net
だからdllにして切り離せってのは、インターフェース介した作りかどうかと直接関係無いよな?

284 :仕様書無しさん:2018/06/09(土) 14:22:57.91 .net
>>281
> 依存先を直に参照、インスタンス化すると親に埋め込まれてしまう
> これは依存先にバグがあると親もバグがあるということな

意味が全くわからん
依存先にバグが有って、親にはバグがない
依存ざきにバグはなくて、親にはバグが有る
両方にバグが有る

どれの可能性も存在するが、
インターフェースに洗脳されているお前は
その可能性が思いつかないって話?

銀の弾丸はないんだよ?
インターフェースを使ったらバグがないとか
はは、ありえないww

285 :仕様書無しさん:2018/06/09(土) 14:23:39.62 .net
>>282
> すると全てのインフラストラクチャが整備されていないとテストもデバッグもできくなってしまう

そんなことはないが? テスト用のモックを使えば良いだけだよ

286 :仕様書無しさん:2018/06/09(土) 14:43:48.21 .net
>>284
まだわからないかー
子供用の説明ならどうだ?

依存先を直接参照インスタンス化するのは一体型パソコンと同じ
メモリが壊れてたらパソコン全体が壊れてることになるんだ
パソコン全体を修理に出すか買い替えてね

依存先をインターフェースで切るのは組み立て型のパソコンと同じ
メモリが壊れててもパソコンが壊れたことにはならないんだ
メモリだけを交換してね

287 :仕様書無しさん:2018/06/09(土) 14:59:56.95 .net
インターフェース定義しただけなら切り離されてないからなぁ。
きちんとリンクライブラリにして初めて切り離される。

288 :仕様書無しさん:2018/06/09(土) 15:14:09.76 .net
>>284
いいや
インターフェースは最強だよ
バグるはずはないよ

289 :仕様書無しさん:2018/06/09(土) 15:15:08.99 .net
>>286
だからそれインターフェースと関係ないじゃん
モジュール(クラス)が壊れていたら
それを交換するだけだろ?

あとは、お前、はなっからメモリが壊れてるってことに
しているようだが、マザーボードのほうが壊れている場合だってあるんだぞ

インターフェースを使っていれば、絶対にメモリが壊れる
マザーボードが壊れることはないって言うつもりか?

290 :仕様書無しさん:2018/06/09(土) 15:23:48.56 .net
>>289
やれやれ
メモリが壊れてるのも何が壊れてるのも話の要点は同じだろ
例え話に変なツッコミ入れる人ってホント要点から目をそらしたがるよね

291 :仕様書無しさん:2018/06/09(土) 15:26:19.26 .net
>>290
あれ?インターフェースは関係ないというツッコミへの
レスはしないの?

これがたとえ話ではなく一番重要な点なんだが
反論できない所からは目をそらすんだねw

292 :仕様書無しさん:2018/06/09(土) 15:38:52.62 .net
>>291
は?
頓珍漢すぎてスルーしてたわ
パソコン部品はインターフェースの考え方を応用して成功した代表例だぞ?
インターフェース関係ないとかまじ大丈夫か?

293 :仕様書無しさん:2018/06/09(土) 15:44:07.05 .net
インターフェースさん
開発の邪魔だから早く死んで

294 :仕様書無しさん:2018/06/09(土) 15:45:18.81 .net
| echo

295 :仕様書無しさん:2018/06/09(土) 15:54:54.09 .net
C#なのにインターフェイスから実装に飛べないなんて言ってるアホの妄言だから気にするな

296 :仕様書無しさん:2018/06/09(土) 15:55:42.85 .net
モノリスおじさん「インターフェースさん邪魔(うわあああ論理じゃ勝てない。そんだ!むかつくから悪口いったろwww)」


悲しいなぁ

297 :仕様書無しさん:2018/06/09(土) 16:01:27.94 .net
>>295
無理だろ
型情報を削っちまったんだから
それに知る必要がないんだろ?
主張に責任持てよw

298 :仕様書無しさん:2018/06/09(土) 16:15:42.81 .net
でもお前、ifがあるコードは追えるんでしょ?

299 :仕様書無しさん:2018/06/09(土) 16:23:59.60 .net
ものによるね
インターフェースや抽象クラスでやるべきものを無理やり条件分岐にしたようなものは追う気しないね
実装クラス全部見るより大変だよ

300 :仕様書無しさん:2018/06/09(土) 16:51:18.63 .net
>>299
でもそれごった煮リストじゃん

301 :仕様書無しさん:2018/06/09(土) 18:06:39.52 .net
>>300
ごった煮のクソッタレ条件分岐をインターフェースで綺麗に分離、パッケージングしたわけさ
インターフェース使わないとごった煮っていうのは同意

302 :仕様書無しさん:2018/06/09(土) 18:37:42.37 .net
>>292
パソコンの話をしたいのなら
別の板に言ってください。

インターフェースは関係ありません

303 :仕様書無しさん:2018/06/09(土) 18:40:50.00 .net
そもそもさ、壊れたメモリを交換するのと
モジュールを修理するのは意味がぜんぜん違う。

パソコンにインターフェースがあってよかったというのは、
インターフェースさえ一緒なら、他のメーカーであっても
正常なメモリに交換できるからだ

だけどソフトウェアは違う。インターフェースが同じで
機能が全く一緒のものなんて、殆ど無い。
バグがあったら交換するのではなく、そのモジュール修正するのだから
インターフェースがあることと、バグの修正には全く関係がない

304 :仕様書無しさん:2018/06/09(土) 18:43:41.64 .net
>>301
ごった煮になるのはインターフェース使うからだろ?
フツーに組めよフツーにw

305 :仕様書無しさん:2018/06/09(土) 18:47:29.04 .net
>>303
メーカーの気持ちがわかってないね
君は開発者じゃなくてユーザーということなんだろう

306 :仕様書無しさん:2018/06/09(土) 18:48:02.70 .net
>>305
だからパソコンの話をしたいなら
他の板に逝けって言ったよね?

307 :仕様書無しさん:2018/06/09(土) 18:49:28.42 .net
>>304
フツーに組んだらインターフェースになんだって
オブジェクト指向でなんで手続き型丸出しの条件分岐地獄をワザワザ使わないといけないのか
マゾなのかな

308 :仕様書無しさん:2018/06/09(土) 18:50:54.84 .net
>>306
人間は異なる話題から共通性を認識して教訓とする能力がある

309 :仕様書無しさん:2018/06/09(土) 18:52:26.32 .net
>>306
その論法だとインターフェース使いたくないならプログラム板とプロフラマ板には入れないね
どちらもインターフェースと密接に関わる板だから

310 :仕様書無しさん:2018/06/09(土) 18:56:32.58 .net
>>308

>>303を読むと、パソコンのインターフェースと
ソフトウェアのインターフェースは共通してないことがわかる

311 :仕様書無しさん:2018/06/09(土) 18:57:25.28 .net
インターフェースは交換しやすいだけで
バグが修正しやすくなるわけじゃないんだな

312 :仕様書無しさん:2018/06/09(土) 19:03:50.67 .net
バグが修正しやすくなるぞ

お気に入りのバイクが壊れたけど壊れてるパーツを修理すれば動くとする

インターフェースを使わない派は
バイクが組みあがった状態で修理作業をしないといけないので修正が最悪にしにくい
修理した後もぶっつけ本番でテストしなきゃならんから最悪の場合それで他の部分が壊れる

インターフェースを使う派は
部品を外して壊れた部品だけを作業机に置いて修理できるので超やりやすい
直したら部品の単機能テストをして本体に組みこんでテストできるから安心

313 :仕様書無しさん:2018/06/09(土) 19:05:03.74 .net
>>312
だからそれ、インターフェースがあるからじゃなくて
単にモジュールとして別れていればいいだけだよねw

314 :仕様書無しさん:2018/06/09(土) 19:07:31.20 .net
どうやってクラスAの中に埋め込まれているクラスBをテストするのか?

そりゃクラスBだけ取り出して、
テストすればいいだけでは?

315 :仕様書無しさん:2018/06/09(土) 19:09:33.66 .net
>>313
モジュールとして分けるためのインターフェースな
インターフェースなかったらモジュール化してもハンダで癒着させるしかない

316 :仕様書無しさん:2018/06/09(土) 19:10:53.19 .net
>>315
普通にインターフェース無くても分離できるけど?

あんた、クラスの仕様、かけない人?

317 :仕様書無しさん:2018/06/09(土) 19:17:32.31 .net
>>316
それは君が分離できてると思い込んでるだけ

318 :仕様書無しさん:2018/06/09(土) 19:20:15.50 .net
ソフトウェアだと全く同じものを複数作れるからな
半田で癒着したモジュールをテストする必要はない。

そのモジュール=クラスがあるのだから、
そのクラス単体でテストすれば良いだけ

319 :仕様書無しさん:2018/06/09(土) 19:21:42.93 .net
>>317
だからクラスAの中にあるクラスBを分離するんでしょ?
クラスBだけをテストすれば終わりじゃん
なにか難しいことでもあんの
クラスBはクラスAがなければテストできないわけじゃないんだしさぁ

320 :仕様書無しさん:2018/06/09(土) 19:22:46.93 .net
自分で例え話をして自滅するスタイルかな?

321 :仕様書無しさん:2018/06/09(土) 19:25:43.51 .net
>>319
そもそもBは依存先がないのだからその例は無意味だな
ABが癒着していたらAを分離してテストする方法がないだろ

322 :仕様書無しさん:2018/06/09(土) 19:40:59.46 .net
ABが癒着していたら Aを分離してテストする方法がないだろ

であれば、

ABが癒着していなければ Aを分離してテストする方法がある

という意味になる


で、インターフェースを使うことは必須ではない
インターフェースを使わず、かつ癒着しないようにすれば良い

323 :仕様書無しさん:2018/06/09(土) 19:42:18.06 .net
インターフェースを使わなければ、
絶対癒着してしまうんだー、ブンブン(手足を振り回す音)


ガキじゃないんだから、理由ぐらい言えよw

324 :仕様書無しさん:2018/06/09(土) 19:47:13.82 .net
>>322
無理

325 :仕様書無しさん:2018/06/09(土) 19:49:38.37 .net
はい、ガキいっちょいただきましたーw

やっぱり理由言えませんでしたね。
想定どおりです。

ほんとガキ

326 :仕様書無しさん:2018/06/09(土) 19:50:23.18 .net
ABが癒着していなければな
しかしAがBに依存するなら癒着は不可避
インターフェースを使うしかない

327 :仕様書無しさん:2018/06/09(土) 19:52:20.60 .net
で、癒着してない例は?
それで任意のシステムを組める保証は?
できるったらできるんだーブンブン、ってかwww

328 :仕様書無しさん:2018/06/09(土) 19:59:15.61 .net
>>327
くだらね。そんなこともわからんのか。
じゃあ、ぐうの音も出ない例だしてやるよ。


Aという会社にClassAの作成を依頼しました。
ClassAは完成しテストはしっかり行われています。
ClassAはどこにも癒着していません


数年後、Bという会社に、ClassAを使ってClassBを作るように仕事を依頼しました。
仕事を依頼する前は、ClassAは癒着していません。
ClassAのコードはなにも変えてないのだから
仕事完了後も、ClassAはどこにも癒着していません

329 :仕様書無しさん:2018/06/09(土) 20:01:35.18 .net
つーかこんな茶番劇のような例を出さなくても
MSが作ったライブラリをラップしたオレオレライブラリが
癒着するわけ無いだろと

MSはそのライブラリ単体で開発・テストしてんだからさ

330 :仕様書無しさん:2018/06/09(土) 20:10:35.17 .net
>>328
意味不明
ClassBはClassAに依存しているから開発にもテストにもClassAが必要
もう少しまともな意見を期待してたんだがこりゃ話にならんかな

331 :仕様書無しさん:2018/06/09(土) 20:14:50.16 .net
>>329
オレオレラッパーはMSのライブラリと癒着してんだよ
そしてそのオレオレラッパーを使うクラスはオレオレラッパーに癒着する
癒着が連鎖してMSのライブラリに癒着することになる

オレオレラッパーをインターフェースを実装するように作れば
オレオレラッパーインターフェースを使うクラスは癒着から逃れられる

332 :仕様書無しさん:2018/06/09(土) 20:15:29.58 .net
> ClassBはClassAに依存しているから開発にもテストにもClassAが必要

ClassAならすでにあるじゃん?アホなの?

333 :仕様書無しさん:2018/06/09(土) 20:15:54.02 .net
アホなんだろw

334 :仕様書無しさん:2018/06/09(土) 20:20:55.14 .net
>>332
それを癒着というんだよ
ClassAがあるからいいじゃんじゃなくてなかったらダメじゃんってのが正解な
ClassAがデータベースに依存してたらデータベースも整備しなきゃならん
ClassAが外部サービス依存してたら外部サービスと契約しなきゃいけない
そうやって癒着の連鎖が広がっていく

335 :仕様書無しさん:2018/06/09(土) 20:21:21.75 .net
仮にClassBを動かすのにClassAがまだできていなかったとしても
モックを使えばいいだけなのでインターフェースは必要ない

まあClassAの偽物を使ってテストしても
それは本当に動くことの証明にはならないから、
最終的にはClassAを組み込んだ状態でテストしなければいけないんだがな

336 :仕様書無しさん:2018/06/09(土) 20:22:07.65 .net
>>334
> それを癒着というんだよ

言わない。ソフトウェア業界のどの文献を探しても
癒着なんて書いてあるものはない
勉強し直したほうが良いよ?
あんた自分の妄想の世界で生きてる

337 :仕様書無しさん:2018/06/09(土) 20:23:32.48 .net
>>334
> ClassAがデータベースに依存してたらデータベースも整備しなきゃならん
整備すればいい

> ClassAが外部サービス依存してたら外部サービスと契約しなきゃいけない
外部サービスのモックを使えばいい

接続先の切り替えは単に設定ファイルの接続先を変更するだけ

338 :仕様書無しさん:2018/06/09(土) 20:23:42.80 .net
>>335
それは言語機能的な意味でインターフェースを使っていないだけで
考え方としてはインターフェースを使って実装を切り替えるのと変わらんよ
インターフェースを使った場合との違いは手順が増えて面倒くさくなる

339 :仕様書無しさん:2018/06/09(土) 20:25:00.97 .net
>>336
文献ベースで話進めるなら世界中で言及されてるインターフェースを使うのが正義ってことになるぞ

340 :仕様書無しさん:2018/06/09(土) 20:26:41.02 .net
>>338
> それは言語機能的な意味でインターフェースを使っていないだけで
> 考え方としてはインターフェースを使って実装を切り替えるのと変わらんよ

はぁ? じゃあお前のその主張だと

すべてのクラスは、言語的な意味でのインターフェースを使ってないだけで
インターフェースを持っているので、別になにかを作る必要はないってことで終わりだな

はい、ClassAとClassBだけで十分ですーw
だって、インターフェースがあるのですからーw

341 :仕様書無しさん:2018/06/09(土) 20:26:46.54 .net
>>337
整備のコストがもったいない
モック使うって発想はインターフェース肯定だぞ

342 :仕様書無しさん:2018/06/09(土) 20:27:49.66 .net
>>341
テストなんだから完璧なものを作る必要はない

343 :仕様書無しさん:2018/06/09(土) 20:33:41.77 .net
>>340
インターフェースを使わない代わりに無駄なコストを呼び込んでるんだよ

古の時代では確かにビルド時のリンク設定を変えたりマクロ定数による分岐を使って実装の切り替えを行っていた
これは非常に原始的だけど依存性注入の原型と言っていい

だけどあまりに不安定で管理の手間がかかるから人類は新しい方法を考えた
それは抽象基底クラスや仮装メソッドだったりするがまだまだ実用には難があった
最終的に依存性を丸ごとインターフェースに切り出して外からインスタンス渡すのがいいねって進化した

君が言うようにインターフェースを使わなくても実装のの切り替えはできないことはないが
それはIT原始時代の非効率的で野蛮な方法なんだよ
そういうのは猿がやることだ

344 :仕様書無しさん:2018/06/09(土) 20:34:22.80 .net
>>342
完璧でなくても手間はかかるからな

345 :仕様書無しさん:2018/06/09(土) 20:54:19.46 .net
>>312
いや、型情報が潰されてるしバグ修正なんてしにくいと思うけど
しかも、インターフェースの先は知る必要がないんでしょ?

346 :仕様書無しさん:2018/06/09(土) 20:54:53.19 .net
インターフェース君、もう死んだ方がいいな
バカだし

347 :仕様書無しさん:2018/06/09(土) 21:02:30.42 .net
>>345
しやすいよ
余計な依存関係がクリアされるから作業対象に集中できる
作業対象の型も設定や命名規約からすぐわかるし全体からすれば極一部の動的なインスタンスだったとしてもログやファクトリーを見ればすぐにわかる
作業対象が依存してるのはインターフェースの契約でしかないのでインターフェースの先はもちろん知らなくていい

348 :仕様書無しさん:2018/06/09(土) 21:03:01.94 .net
>>346
素直に参りましたと言ったら?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

なんでかな?

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

終わり

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

↑これが間違ってる

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

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

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

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

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

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

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

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

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

え?違うよ

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

400 :仕様書無しさん:2018/06/18(月) 20:23:08.40 .net
リファクタリングしながらやると美しいコードになるけどやっぱり時間かかるな

複雑なSQLで一気にデータ持ってきて表示、編集させて、ボタン押したらこれまた複雑な更新SQLで一気にデータを更新
コードめちゃくちゃになるけど、これが一番生速度が速い

401 :KAC:2018/06/18(月) 21:53:41.21 .net
いや、ちゃんと設計しろよ

402 :仕様書無しさん:2018/06/18(月) 22:53:05.35 .net
設計は遠回り
最初から最短距離見えてるんだからそうすればいい

403 :仕様書無しさん:2018/06/18(月) 22:58:25.68 .net
どうせ引き継ぎ用の説明書作らなきゃならないだろうに…。

404 :仕様書無しさん:2018/06/18(月) 23:00:21.08 .net
逃げ切るんでね

405 :仕様書無しさん:2018/06/18(月) 23:12:11.32 .net
家にケータイに電話来まくる未来しか見えないw

406 :KAC:2018/06/18(月) 23:35:19.24 .net
>>402
じゃあリファクタリングいらんだろ

407 :仕様書無しさん:2018/06/19(火) 06:02:26.20 .net
>>406
そう。要らない

408 :仕様書無しさん:2018/06/19(火) 07:39:04.26 .net
>>402
設計は必須。
お前さんは書き込みする時に、カキコの影響とか考えるだろ?
それは広い意味での設計。
「設計書」と称する、実は設計書になってないゴミは要らんけどね。

409 :仕様書無しさん:2018/06/30(土) 20:48:21.44 .net
設計・設計書要らない派が挙げてる仕事って、
1時間で終わるレベルのタスクなんだろうなって思う。
人と設計を共有したりしないでいいんだろうな。

410 :仕様書無しさん:2018/07/01(日) 00:07:45.44 .net
だからコードで設計を共有すればいいじゃん
設計書を記述するための「プログラム言語」という専用の言語で
設計書を記述すればいいでしょう?

411 :KAC:2018/07/01(日) 02:15:52.13 .net
>>410
プログラム書いて持ちよった結果
イメージが合って無くて全面書き直しになっても
直ぐに書き直せるのならそうかもな

412 :仕様書無しさん:2018/07/01(日) 02:16:11.30 .net
>>410
小規模ならそれもいいけど、大規模になったらそうもいかんのよ

413 :仕様書無しさん:2018/07/01(日) 03:46:41.54 .net
>>411
お前が言う「設計書」を書いて持ち寄った結果
イメージが合って無くて全面書き直しになるのと何が違うの?

全面書き直しが問題なら、単に早めに
レビューすればいいだけ。別の問題だろ

414 :仕様書無しさん:2018/07/01(日) 03:51:24.97 .net
>>413
それはプログラムと設計書の工数によって変わるだろ
プログラムより設計書の工数がえらい小さい場合は、設計書を持ち寄ってレビューするべきだし
工数がほとんど変わらないなら、最初からプログラムでレビューすればいい

415 :仕様書無しさん:2018/07/01(日) 04:01:00.47 .net
設計書は長時間うんうんうなって完成させてから
レビューするもんでしょ

大規模なものなら、1ヶ月とかそれ以上かかって完成させて、
でイメージが合ってなくて全面書き直しwww

416 :仕様書無しさん:2018/07/01(日) 04:03:02.31 .net
設計書は書き直すことなんてないよ
所詮絵に描いた餅なんだから
間違ってもOK。レビューなんてしない
間違いはコードでなおす

417 :仕様書無しさん:2018/07/01(日) 12:16:15.96 .net
>>416
いや、設計書書いたならレビューしろよw
何のために書いてんの?

418 :仕様書無しさん:2018/07/01(日) 17:06:03.85 .net
>>417
作業者に仕事を与えるためだろ

419 :仕様書無しさん:2018/07/15(日) 20:49:16.71 .net
建築業なら企画書→仕様書→設計書→図面→といった工程の中の
一部分であることが設計書の存在意義なんだが
この業界って仕様変更の頻度が高すぎて工程という前提条件が破綻してる
とくに下請けはプロマネのレベルが低くて無知だから何でもハイハイで
再見積もりも無しに平気で工程をまき戻していつものデスマーチ

420 :仕様書無しさん:2018/07/16(月) 23:47:33.28 .net
>>419
建築はしっかりしてるというような隣の芝生は青く見えるんだろうけど、
あっちもやっぱり似たようにgdgdだよ。
特に今は作業員に外国人が増えてるから意思疎通も大変だし。

421 :仕様書無しさん:2018/07/17(火) 20:14:10.53 .net
建築業界に例えたらプログラマは何に相当するんだ?

○○に相当するとして、建築業界では○○に対して
ちゃんとした資料を渡してるんだろ?
だけどプログラマに対して、それと同じぐらいの内容の
資料渡してないだろ

って結論になるのが、この話題の最後になるのが目に見えてる

422 :仕様書無しさん:2018/07/17(火) 22:55:19.02 .net
>>421
土方だろ
だって俺ら鬼の副長じゃなくてIT土方だろ

423 :仕様書無しさん:2018/07/18(水) 03:26:52.12 .net
>>422
おい、先にレスしてるんだからその先を書けよ。

土方に渡す資料に
「4階建でマンションを建てます。
部屋はいくつで、階段、エレベータはここで。
詳細は全部任せます。材料とか適切なのを選んでください」
って書いてあったら、それ建築士が使えないって判断だぞ

424 :仕様書無しさん:2018/07/18(水) 04:54:54.12 .net
>>423
末端の土方はそれくらいの情報しか持ってなさそう
で、現場監督や棟梁には詳細な資料が渡ってると

425 :仕様書無しさん:2018/07/18(水) 11:14:36.88 .net
プログラマは土方に相当すると言ってのに
現場監督や棟梁に相当するって訂正かよw

426 :仕様書無しさん:2018/07/21(土) 18:07:22.82 .net
リファクタしたいけど影響範囲ひろがりすぎる

427 :仕様書無しさん:2018/07/21(土) 18:09:01.09 .net
将来的には絶対いいしそうしないと先がふさがるけど
当面の課題解決の理由として正当化できないせいで採用できない

428 :仕様書無しさん:2018/07/21(土) 19:57:36.56 .net
などと言い訳をしているところは
デスマ状態なんだろうってのがよく分かる

なぜならコード修正の見積もりには
予めリファクタリング分の工数を含めるものだからだ

その余裕も無いほどカツカツなスケジュールなら
デスマになるに決まっている

429 :仕様書無しさん:2018/07/21(土) 20:05:56.17 .net
そのリファクタ見積もりが正当化できないんですけど

430 :仕様書無しさん:2018/07/21(土) 20:10:08.19 .net
将来的に当たるかもしれない課題がある
でもそれは優先度低くてかなり先、一度後回しでいいやってなった

今回の改修は範囲狭くて緊急性たかい
今回のを理由に将来を見越した改修をしてしまうと、緊急性高いテストに関係ないモジュールまで巻き込まれてしまう

先で死ぬのが見えてるのに出口が

431 :仕様書無しさん:2018/07/21(土) 20:55:20.97 .net
コストカット原理主義が無くならない限りはリファクタリングの正当性を見出すのは無理だろうな

空いてる時間に今までのフィードバックをすることでよくしていくことが必要なのに空いた時間
そのものをコストとして敵対視してるのだから受け入れられることはない

空いた時間=余裕=コスト=絶対悪 になっている人が多い

432 :仕様書無しさん:2018/07/21(土) 21:50:17.21 .net
>>429
それならコード修正の見積もりもできないだろうね

433 :仕様書無しさん:2018/07/21(土) 22:17:48.11 .net
なんでだよ

434 :仕様書無しさん:2018/07/21(土) 22:25:55.48 .net
そりゃ正しいコードの姿が見えてないのに
コード書くのにどれくらいかなんて見積もりできないだろw

それか修正前のコードがどんなに汚くて
修正箇所が大きくテスト範囲も広くなろうが
修正前のコードが綺麗でわずかの修正で解決できようが
全く同じ工数で修正できるって考えてるアホかのどちらかだ

435 :仕様書無しさん:2018/07/21(土) 22:33:30.78 .net
正当化できない理由は>>430
コードの正しい姿とかどっからでてきた話だ

436 :仕様書無しさん:2018/07/21(土) 23:01:38.04 .net
言語やOS、ライブラリ、フレームワークなんてのは変わり続けてたり、変わらないことで
使えなくなることがあったり、使用者の習熟度が上がるなんかでも変化するから正しい
コードの姿なんてものは幻想だよ。

極端な話、変更がなければリファクタリングなんてしなくてもいいがOSバージョンアップは
ほぼ確実に数年単位で起きるしそれに対する対応としてはリファクタリングなりなんなりの
事前によくしておくというのは必要なんだよな。

437 :仕様書無しさん:2018/07/21(土) 23:03:41.98 .net
>>435
え? コードを適当に修正してんの?
動けばどんなコードでもOKって人?

438 :仕様書無しさん:2018/07/21(土) 23:04:48.61 .net
>>436
> 使用者の習熟度が上がるなんかでも変化するから正しい
> コードの姿なんてものは幻想だよ。

コードの話をしてくれないかな?
お前が言ってるのは使用者の習熟度の話

お前が言ってるのは、正しいコードはあるが
それを使用者が理解できないって言ってるだけだろう?

439 :仕様書無しさん:2018/07/21(土) 23:13:39.14 .net
>>437
おまえは自分の頭にある筋道以外の話が理解できんのか

440 :KAC:2018/07/22(日) 01:02:58.95 .net
>>428
なんで正しい設計をしようとしない?

441 :仕様書無しさん:2018/07/22(日) 07:42:33.24 .net
>>431
テストやリファクタリングをサボって、コストカットしたと勘違いしてるのが多いけどね。

442 :仕様書無しさん:2018/07/22(日) 11:49:00.45 .net
>>441
そもそもそこまでコストカットする必要はあるのかっていう話だな。

お給料=コストなんだからコストカット自体は自分の給料を減らすものとして考えなきゃ
ならないわけで、なんで自分の首を絞めることに肯定的なのかなあと。

効率化自体はかったるい作業をかったるくない作業にする自分ために必要なことだが
効率化しないと評価下げる、お前は低評価だみたいなのは違うだろうと。

443 :仕様書無しさん:2018/07/22(日) 12:10:14.32 .net
資本主義の世界だと自分の成功とは他人より成果を出すことでつまり他人が失敗すること
つまり望まれてるのはお前がコケて失敗することなんだ
それでまわりが幸せになる

おまえの上司は
お前が失敗しないことを理由に地位と給与を下げ、失敗したことを理由に地位と給与を下げるだろう
成功者の側に立とうと思ったらうわべに隠された別の道を通らねばならない

444 :仕様書無しさん:2018/07/22(日) 14:02:52.60 .net
>>442
費用対効果って概念が抜けてる現場は多い。

445 :仕様書無しさん:2018/07/22(日) 14:20:05.45 .net
>>444
だからそんなバカバカしい定量化しづらい、出来ない概念を信奉してるから
ちょっとした計算違いでどんどんドツボにはまっていくんだよ。
金は貯めたり削ったりするものじゃなくて使うものだという認識が出来てない。

446 :仕様書無しさん:2018/07/22(日) 14:23:00.79 .net
減量が必要なボクサーじゃないんだから無駄なんてあっていいの、あって当たり前なの
そんな当たり前のことが分らなくなってきているから作業量が増え続けて仕事が楽に
ならないんだよ。

過労死するとかそれに近い状態が幸せなのか?

447 :KAC:2018/07/22(日) 17:11:53.36 .net
どうでもいいけど、
少なくとも給料上がった分くらいは効率化しろよ?
新人雇った方がコスパ良いとか笑えないから。

448 :仕様書無しさん:2018/07/22(日) 17:13:26.47 .net
さきにあげてからいえ
ガッデム

449 :仕様書無しさん:2018/08/01(水) 22:38:50.65 .net
われながらクラスとメソッドの名前がひどい
壊滅的な英語センスと気まぐれなルールで
日本語との対応や分類がえらいことになってる

名前かえるぐらいさせろよ

450 :仕様書無しさん:2018/09/03(月) 10:29:43.86 .net
難読化とか何だったんだろう。

451 :仕様書無しさん:2018/10/01(月) 19:25:22.11 .net
小売業者が定期的にやってる棚卸しみたいなもんだけどな

452 :仕様書無しさん:2018/10/02(火) 20:04:13.47 .net
なんやかんや言って全然ちゃうけどね

453 :仕様書無しさん:2018/10/02(火) 20:15:37.69 .net
リファクタリングは日々一人ひとりがやることだから
棚卸しのようにまとめてやる行事とはぜんぜん違う

454 :仕様書無しさん:2018/10/02(火) 20:16:40.24 .net
正確には無能がする日課のオナニーみたいなものやけどね

455 :仕様書無しさん:2018/10/02(火) 20:21:20.38 .net
システム刷新の前にリファクタリング少しでもやると効果的なんだけど余計な手間だろって却下される
古い言語で書かれたゴミを新しい言語で書かれたゴミに刷新しても意味ないと思うんだけどな

456 :仕様書無しさん:2018/10/02(火) 20:24:34.25 .net
定期的な整理をしないと肝心なときにぐちゃぐちゃになる
んで、緊急だっつって慌てて直してカオス化が進む
そーなる前に整理しろってそんだけの話でしょ
なんか難しいところあるか?

457 :仕様書無しさん:2018/10/02(火) 20:26:18.31 .net
整理整頓するつもりで散らかし放題やから無能と呼ばれとんのやぞおまえw

458 :仕様書無しさん:2018/10/02(火) 20:26:51.57 .net
整理整頓するつもりで
整理整頓してればいいだけでしょう?

459 :仕様書無しさん:2018/10/02(火) 20:28:30.77 .net
出来とらんゆうとるやんw

460 :仕様書無しさん:2018/10/02(火) 20:31:19.14 .net
整理整頓した結果が前よりマシになる保証がないことを奴隷主どもはよくわきまえている

まともな整理整頓できるぐらい理解が進んでたら
そもそも整理したいって思わないことも多い

461 :仕様書無しさん:2018/10/02(火) 21:19:29.11 .net
リファクタリング何ぞ不要

その頃には丸ごと作り直せ

462 :仕様書無しさん:2018/10/02(火) 21:23:26.63 .net
自動テスト出来るならもうかなりキレイなコードになってるはず
リファクタリングが本当に必要なのはテスト困難な汚いコード

リファクタリングはテストと必ずセットだって常識は間違っていたのかも知れないな
テストしないでリファクタリングすることも時には必要
これをエクストリーム・リファクタリングと名付けよう

みんなこのワードを流行らしてくれ
流行ってるなら本番でも採用されるから

463 :仕様書無しさん:2018/10/02(火) 22:06:17.68 .net
エクストリームデグレードした記憶しかない

464 :仕様書無しさん:2018/10/02(火) 23:05:28.72 .net
最初は何とかなってたのに
あれがたりないこれがたりないってプライベートメソッドが増えて
にっちもさっちも行かなくなった…

リファクタしたいけどテストできなくなったからリファクタできない

465 :仕様書無しさん:2018/10/03(水) 12:36:31.43 .net
規模にもよるけど、機能の変更や追加依頼があった時にその部分だけリファクタをやってから手をつけてるなぁ
もちろんそれ込みの見積もりを出す

依頼もないのに勝手にリファクタやることはないわ

466 :仕様書無しさん:2018/10/03(水) 19:55:36.77 .net
なんでこんなに変わってるんですか?
工数を増やさないでください
勝手にやった分の料金返してください

467 :仕様書無しさん:2018/10/03(水) 20:03:20.05 .net
客からはその工数で金ふんだくってるくせに…

468 :KAC:2018/10/03(水) 23:24:31.41 .net
本当にリファクタリングを綺麗にできるのなら、
そもそも設計が綺麗だから、リファクタリングなんて不要だろ?

まともに設計できずにぐちゃぐちゃ書いた奴が、
リファクタリングなんてできる訳が無い。

469 :仕様書無しさん:2018/10/04(木) 01:10:25.08 .net
>>468
コードを修正する必要がないなら、
最初からきれいに書けるよ

実際には機能追加、変更、バグ修正などで
コードを変更する必要があるから、リファクタリングが必要なんだよ

470 :KAC:2018/10/04(木) 02:22:27.37 .net
>>469
そうだね。
まともに設計できない奴はそうなるね。

471 :仕様書無しさん:2018/10/04(木) 06:48:48.05 .net
まともに設計できるかどうかじゃなくて、
将来を読めるかどうかだろ?

将来大規模になるなら、大規模な設計をするし、
そうでないなら小規模な設計をする

規模に応じて適切な設計は変わるのに
最初から規模が読めるとでも?

472 :KAC:2018/10/04(木) 07:18:51.36 .net
最近は設計できない奴の言い訳がすごいな。

まともに設計できてればそんなことでリファクタリングは発生しない。

473 :仕様書無しさん:2018/10/04(木) 07:50:59.20 .net
まともの中身をまともに話せよ
具体的に

474 :仕様書無しさん:2018/10/04(木) 10:03:32.69 .net
そりゃ先の先の先まで考えて
必要ないことまで設計することだろw

475 :仕様書無しさん:2018/10/04(木) 21:36:10.68 .net
>>474
クソコテの戯言はおいとくとしても
設計はコーディングとちゃうで?それはコーディングの話や

476 :仕様書無しさん:2018/10/04(木) 21:42:23.71 .net
日本人は年末の大掃除が文化として根付いてる
なので「日々整理整頓してクリーンな状況を維持しよう」って外国人なら当たり前の感覚がどうしてもわからない
民族・文化のレベルでITが向いてないんだよね

477 :仕様書無しさん:2018/10/04(木) 21:46:24.65 .net
設計を受け取ってコードを書くだけの人ほど>>472のような勘違いをする傾向が有るね
ドメインへの理解度は開発をすすめるにつれて深化する
ビジネスルールやニーズは時間経過で変化する
という2つの大前提を理解してないっぽい

478 :仕様書無しさん:2018/10/04(木) 21:58:17.83 .net
>>477
クソコテに反論したからと言っておまえがコーダーである事は隠せんよw

479 :KAC:2018/10/04(木) 22:05:46.37 .net
もうコテも信用できない
俺だってKACのふりぐらいできる

480 :KAC:2018/10/04(木) 22:40:27.98 .net
>>477
設計できない事はよく分かった。
つか、開発プロセスすらまともに理解できてないんだな。

481 :仕様書無しさん:2018/10/05(金) 19:49:17.51 .net
>>480
じいちゃんそれ古いって腐ってる

482 :仕様書無しさん:2018/10/07(日) 17:21:06.95 .net
リファクタリング出来る環境あるならテストも自動化されてるだろうに、何が問題なんだろ?

483 :仕様書無しさん:2018/10/07(日) 17:46:35.29 .net
テストが自動化されてる現場なんてあるわけじゃないか!
だからリファクタリングは禁止!

484 :仕様書無しさん:2018/10/07(日) 18:25:36.50 .net
>>483
あるわけだよ?

485 :仕様書無しさん:2018/10/07(日) 18:48:09.16 .net
まさか、人力でリファクタリングしといて、インターフェースは完全に互換だとかのたまうアホなん?

486 :仕様書無しさん:2018/10/08(月) 21:15:22.90 .net
完全に互換です
動き違うのはもともと定義外の使い方してたからで
既存バグです
正しくなおしたわれわれのせいではない

487 :仕様書無しさん:2018/10/09(火) 09:59:33.83 .net
齟齬があるのに観世互換とか、日本語が使えないのかな?

488 :仕様書無しさん:2018/10/10(水) 20:00:15.54 .net
とりかえがきくから互換

489 :仕様書無しさん:2018/10/11(木) 12:28:59.32 .net
金になるなら、やる
ならないのなら、やらない

490 :仕様書無しさん:2018/10/11(木) 15:00:12.53 .net
リファクタリングして、コードのメンテナンス性が上がって
メンテナンスに時間がかからなくなると、時間を節約で金になるんだよな
これをわかってないやつが多い

491 :仕様書無しさん:2018/10/11(木) 15:03:03.80 .net
ソース付きで売り切りの開発にリファクタリングなんて不要

492 :仕様書無しさん:2018/10/11(木) 15:04:09.91 .net
ソースコードがなにもないところから生まれてくるとでも思ってるのだろうか?

493 :仕様書無しさん:2018/10/11(木) 15:04:41.03 .net
切り売りするにはリファクタリングされきって
綺麗な設計になってないと無理だからなぁ

494 :仕様書無しさん:2018/10/11(木) 15:05:22.26 .net
>>492
ネットを巡回すると出来上がる。

495 :仕様書無しさん:2018/10/11(木) 15:05:26.04 .net
あ、無理っていうのは不可能って意味じゃないよ。
切り売りする時、綺麗な設計になってないと
修正が大量に必要なってコストがかかるという意味

496 :仕様書無しさん:2018/10/11(木) 15:06:59.05 .net
>>494
ネットに落ちてるのはバグばかりだよwww

497 :仕様書無しさん:2018/10/11(木) 15:07:22.98 .net
>>495
売り切りなのに修正なんてあるはず無いだろ。
修正するとすれば、購入した顧客側の仕事だしな。

498 :仕様書無しさん:2018/10/11(木) 15:08:44.74 .net
>>497
じゃあ売ってる使えないコードってことか
詐欺という仕事も、そりゃありますよねぇwwww

499 :仕様書無しさん:2018/10/11(木) 15:09:21.02 .net
じゃあ売ってるのは使えないコードってことか

500 :仕様書無しさん:2018/10/11(木) 15:09:39.68 .net
>>493
コメントを飾り立てれば綺麗なコードになるから無問題w

501 :仕様書無しさん:2018/10/11(木) 15:10:11.27 .net
やっぱりリファクタリングしきった
綺麗なコードじゃないと売れないよね

502 :仕様書無しさん:2018/10/11(木) 15:10:45.43 .net
動くんだから詐欺じゃないけどな。

503 :仕様書無しさん:2018/10/11(木) 15:11:30.29 .net
>>500
ゴミを飾り立ててもゴミでしかありませんよw

あ、ゴミを騙して売る商売でしたね
商売の邪魔してすみませんwww

504 :仕様書無しさん:2018/10/11(木) 15:11:54.56 .net
>>502
動くと、正しく動くの違いぐらい知ってますよwww

505 :仕様書無しさん:2018/10/11(木) 15:12:59.57 .net
切り売りってw
ライブラリとして無修正で提供できない時点で終わってるよね

506 :仕様書無しさん:2018/10/11(木) 15:13:52.83 .net
>>504
あ?
リファクタリングの意味も分からずここに来てんのか?
正しく動くから商売してんだろ?

507 :仕様書無しさん:2018/10/11(木) 15:17:24.49 .net
まずくても食べられれば売れますもんねwww

508 :仕様書無しさん:2018/10/11(木) 15:17:40.13 .net
おまえらはアホだな。
リファクタリングし切ったコードなんか売ったら、
顧客都合の仕様変更の仕事が来ないだろw

509 :仕様書無しさん:2018/10/11(木) 15:20:53.31 .net
あぁ、時給で働いてんのなw
作業が減れば減るほど、稼げる金が減ると・

価値ではなく、作業時間で金額決めてるから
効率化すればするほど、稼げる金が減る。

地獄だね

510 :仕様書無しさん:2018/10/11(木) 15:23:25.75 .net
売り切り商売のどこが時給と関係してるんだろ?

511 :仕様書無しさん:2018/10/11(木) 15:28:20.99 .net
>>510
ライブラリを売る場合、作業が0でもそのライブラリの価値として売るのは明白
何もしなくても金が稼げる

切り売りっていうのは、一つのプロダクトから、必要そうな部分を切り出して渡す。
まず切り出すという作業が必要になる。どこがどう影響してるかわからないから
そして仕様変更が来たら、追加でなにか作るのではなく、切り売りしたソースを修正する
クソ汚いコードだから、顧客には修正するのが無理。というのを利用して作業費用を受け取る
反対に言えば、作業しなければ金が稼げない

同じ金額を稼いでいたとしても、ライブラリは何もしないで稼いでいるが
切り売りにして作業しないと稼げないと思ってる。
作業時間=金額 なのだから時給

512 :仕様書無しさん:2018/10/11(木) 15:59:39.41 .net
あ?
誰が切り売りって言った?
売り切りだ。
売ったらそれでおしまいの商売な。

513 :KAC:2018/10/11(木) 18:05:55.46 .net
>>490
なんで最初からまともなコードを書けないの?

514 :仕様書無しさん:2018/10/11(木) 18:31:48.28 .net
>>513
YAGNIだから

515 :仕様書無しさん:2018/10/11(木) 19:36:16.50 .net
>>513
人間は完璧ではない
システム化の対象が不変ではない
経営判断が不変ではない
情報源となる顧客が非協力的

最初から完璧なコードを書けない理由は沢山あるね
最初から完璧なコードが書けると思ってるうちはまだまだ初心者

516 :仕様書無しさん:2018/10/11(木) 19:56:17.84 .net
リファクタしたいけど
きわめて明白なことに
根本的リファクタしたら2年ぐらい自分がやってた部分全部いらない

どうすればいい

517 :仕様書無しさん:2018/10/11(木) 20:11:38.77 .net
いらないなら消せばいいじゃん

サンクコスト効果とか知らない?
いらないものをメンテするほうがコストがかかる

518 :仕様書無しさん:2018/10/11(木) 20:17:42.96 .net
そのコストが俺の飯の種なんですけど

519 :仕様書無しさん:2018/10/11(木) 20:21:47.28 .net
大きな猫用ドアと小さな猫用ドアがあって小さいほう作ってる
どっちのドアをくぐらせるか猫を誘導するのがまた

機能は実質まったく一緒

520 :仕様書無しさん:2018/10/11(木) 20:33:14.61 .net
>>518
時給ってやつだね
作業時間がそのまま金になる
だから効率化すると逆に金が減る

521 :KAC:2018/10/11(木) 21:03:17.24 .net
>>515
まともに書けない理由がそれなら、
なんでリファクタリングすれば
成功すると思ったの?

522 :仕様書無しさん:2018/10/11(木) 21:07:49.15 .net
リファクタすると工数2、3倍
リファクタしないと指数関数的に複雑さがふえる

523 :仕様書無しさん:2018/10/11(木) 21:15:32.35 .net
まともに書けないんじゃなくて、まともに書かないだけ。
時間をかければまともに書けるが、その時点では
そこまでする必要がなかったという判断

だが「その時点では」の話。時が変わればその判断も変わる
状況が変われば、その目的地も変わる。新しい目的地に向かって
既存のルートを変えることがリファクタリング

その反対の行為は、古い目的地のルートはそのままに古い目的地から
新しい目的地へルートを伸ばす。だから無駄が積み重なって最後には
入り組んだ迷路のようになる

524 :KAC:2018/10/11(木) 21:54:50.87 .net
>>523
で、リファクタリングして作り直してるるあいだに状況が変わるんだよな?
開発プロセスから見直した方がいいぞ。

525 :仕様書無しさん:2018/10/11(木) 22:00:48.50 .net
まあ、リファクタリングするくらいなら新規で作った方が金も取れるからなぁ

526 :仕様書無しさん:2018/10/11(木) 22:13:18.61 .net
>>524
リファクタリングって何かを修正するたびに、該当箇所だけを少しづつやるもんだぞ?
毎日状況が変わっていたら仕事にならんだろうが

お前みたいに、リファクタリングという特別な時間を使って大規模にまとめてやるって
間違った考え持ってるやつはいつ撲滅できるんだろうかね
ほんと害悪でしかないわ

527 :仕様書無しさん:2018/10/11(木) 22:21:42.14 .net
>>525
時給で請求金額を決めてるんですね
大変ですね。開発時間を短くすると金が取れない仕組みなんてw

528 :仕様書無しさん:2018/10/11(木) 22:26:11.34 .net
>>527
だからさw
請け負いでやってても何でも
見積もりは作業工数から算出だろうに。
だからむしろ数時間で終わっちゃうリファクタリング作業なんかではたいした金は取れないんだよ。
電気屋が修理じゃなく新製品勧めて来るのと同じだ。

529 :仕様書無しさん:2018/10/11(木) 22:54:07.97 .net
>>524
そう
ずっと追いかけるんだよ
理想と現実の誤差がある程度の範囲に収まるように調整すんの
リファクタリングしないと誤差が大きくなりすぎて商品価値が暴落する
暴落してから焦って直そうとしても誤差が大きすぎてどっちに進めば理想に近くのかがわからなくなる

530 :仕様書無しさん:2018/10/11(木) 23:05:27.01 .net
>>528
矛盾してるなぁw

リファクタリングの時間を作業工数に含めたら
むしろ金は取れるだろうに

531 :KAC:2018/10/11(木) 23:13:37.93 .net
>>529
その誤差をリファクタリングで埋めようとするのが間違ってるって話なんだけど?

532 :仕様書無しさん:2018/10/11(木) 23:14:59.67 .net
>>531
リファクタリングは修正のたびに小さくやるもので
1日以内で終わるような誤差をなぜリファクタリングで埋めたらダメなんだ?

533 :仕様書無しさん:2018/10/11(木) 23:15:45.02 .net
>>530
リファクタリングってのは、そもそも設計不具合だからな。
新規開発の工数に入れられるはずが無いだろw

534 :仕様書無しさん:2018/10/11(木) 23:19:19.47 .net
>>533
リファクタリングは不具合修正じゃないので
工数に入れていいってことになりますねぇw

2階建ての家を3階建てにする時、土台を補強するのは
不具合じゃないですよ?

ま、あんたは不具合は全部無償で修理するんでしょうがねw

535 :仕様書無しさん:2018/10/11(木) 23:25:18.04 .net
新規開発なら最初から三階建てだろw

536 :仕様書無しさん:2018/10/11(木) 23:33:59.67 .net
新規開発のお金が取れるぐらいなら
リファクタリングのお金も当然取れる

537 :仕様書無しさん:2018/10/11(木) 23:35:41.03 .net
リファクタに金がかかるってことは
リファクタで開発が楽になってないんだから
そのリファクタは間違いだと結論できる

538 :仕様書無しさん:2018/10/11(木) 23:39:30.65 .net
>>536
おまえさ、くたびれたババアだけとわ処女再生手術したのと、ピチピチの女子高生と、どっちと付き合いたい?

539 :仕様書無しさん:2018/10/11(木) 23:40:46.89 .net
>>538
今は女の子の話はしていない

540 :仕様書無しさん:2018/10/11(木) 23:43:14.80 .net
>>537
おいおいw

リファクタリングで金がかかるのは最初で
開発が楽になるのは次回以降に決まってるだろ
そんなこともわからないのか?

しかも次回以降、請求金額はリファクタリングしてない場合の
金額にしておけば楽して稼げるんだぜ?

リスクゼロで金を稼ぐいい方法だ。

541 :仕様書無しさん:2018/10/11(木) 23:43:34.33 .net
新しいハードに新しい技術で作ったアプリと、
ガラケーのアプリに機能追加したアプリでもいいよ。

542 :仕様書無しさん:2018/10/11(木) 23:44:17.16 .net
ハードを変えるという条件を追加するな

543 :仕様書無しさん:2018/10/11(木) 23:44:35.24 .net
これからはリコンストラクトって呼ぼう
リファクタなんて陰謀くさい名前でいうからコストを考える気にならんのだ

544 :仕様書無しさん:2018/10/11(木) 23:45:04.70 .net
名前なんてどうでもいいわw

545 :仕様書無しさん:2018/10/11(木) 23:45:36.50 .net
>>540
じゃあ今回は認めるけど今後の機能追加は恒久的に料金4割引きで

546 :仕様書無しさん:2018/10/11(木) 23:45:42.71 .net
>>540
そんなの夢物語だぞ。
顧客のニーズは思いがけない方向にあって、
だいたいどんなリファクタリングを先回りしてやってても
無意味だったりするのが現実だぞ。

547 :仕様書無しさん:2018/10/11(木) 23:47:06.88 .net
>>542
おまえは商売の話をしてないから無意味な事に金を使いたがるんだろ?

548 :仕様書無しさん:2018/10/11(木) 23:47:13.10 .net
名前が心理に与える影響をばかにしてはいけない
人間は絶望的にいい加減

549 :仕様書無しさん:2018/10/11(木) 23:47:50.37 .net
>>545
時給で請求金額決めてるところは大変だなぁ
開発を楽にしたら儲けが減るんだからw

ビジネスモデルが破綻してることにも気づいていない
自分で自分の首を絞めてることに気づいていない

550 :仕様書無しさん:2018/10/11(木) 23:49:06.68 .net
まず、リファクタリングに金を出す客は居ないからなぁw

551 :仕様書無しさん:2018/10/11(木) 23:49:35.44 .net
>>545
> だいたいどんなリファクタリングを先回りしてやってても

YAGNIって知ってるか? 今必要になっていないならやらない。
必要になったときにやる。ということだ

先回りしないからこそあとでリファクタリングするんだよ。
先回りしてリファクタリングとか矛盾そのものだ

552 :仕様書無しさん:2018/10/11(木) 23:50:08.49 .net
>>550
リファクタリングを作業工数に入れるという発想がないから
自分で自分の首を絞めてるんだろうねw

553 :仕様書無しさん:2018/10/11(木) 23:50:51.93 .net
>>549
え?機能で値段決めてるのに機能増えないリファクタで金とるの?

554 :仕様書無しさん:2018/10/11(木) 23:51:51.88 .net
>>553
機能を実現するコードを作り出すためなんだから
当然入れるに決まってるだろ。

本当に頭がおかしい。馬鹿じゃなくておかしい

555 :仕様書無しさん:2018/10/11(木) 23:52:14.62 .net
>>551
だからリファクタリングは無意味なんだって。
仕様変更があって初めて秘密裏にリファクタリングするくらいが関の山なんだよ。
リファクタリング自体に金なんか誰も出さないから。

556 :仕様書無しさん:2018/10/11(木) 23:53:21.87 .net
>>555
秘密裏っていうか、お前客にやってること全部説明するのか?
ここのi+1というのはですね(略
コードの説明なんてわざわざしねーよ

557 :仕様書無しさん:2018/10/11(木) 23:53:33.49 .net
>>554
そろそろ自分の矛盾に気が付いた?

558 :仕様書無しさん:2018/10/11(木) 23:54:32.36 .net
>>556
おまえは、客先コードレビューもやらない素人相手のマか?

559 :仕様書無しさん:2018/10/11(木) 23:55:51.21 .net
> リファクタリング自体に金なんか誰も出さないから。

作業時間に含めるのが常識だから
当たり前の話だな。

リファクタリングで別に見積もりだせーって言っているやつが
リファクタリングで金だせないだろーって言ってる矛盾

なら作業時間に含めればいいだけなのに
その発想が出ない。おかしい。馬鹿じゃなくておかしい

560 :仕様書無しさん:2018/10/11(木) 23:57:15.08 .net
>>558
> おまえは、客先コードレビューもやらない素人相手のマか?

コードレビューした気になってるだけだろ。
リファクタリングされてない奇怪なコードの解読に
数時間かけても何も生まれないよ

561 :仕様書無しさん:2018/10/11(木) 23:57:53.64 .net
>>559
おまえは、見積もりの内訳も分からない素人を相手にしているマなのか?

562 :仕様書無しさん:2018/10/11(木) 23:58:19.33 .net
>>557
矛盾してる所があったら指摘してみて
できないなら黙るか、関係ない話にすり替えてみてw

563 :仕様書無しさん:2018/10/11(木) 23:59:09.31 .net
>>560
素人相手のレビューなら無駄だろうなw

564 :仕様書無しさん:2018/10/11(木) 23:59:31.06 .net
>>561
お前は見積もりの内訳としてコード一行一行の値段なんか出してんのか?

565 :仕様書無しさん:2018/10/12(金) 00:00:26.94 .net
>>559
人間がバグったww

コード量と時間と機能のどれで金とるの?

566 :仕様書無しさん:2018/10/12(金) 00:00:57.18 .net
>>563
もしかしてプロならバグを入れないと思ってる?
どんなコードでも一瞬で理解できると思ってる?

汚いコードであればあるほど、バグが含まれるし
どこがどう影響しているかなんて、わからなくなるんだが

だからリファクタリングが必要なの

567 :仕様書無しさん:2018/10/12(金) 00:02:00.50 .net
おれは一切バグを出さない方法を知ってる。

さわらなきゃいいんだ

568 :仕様書無しさん:2018/10/12(金) 00:02:05.75 .net
>>565
> コード量と時間と機能のどれで金とるの?

顧客への価値に決まってんだろ
いらない機能を追加しても金なんかもらえない
発想自体が根本からずれてる

569 :仕様書無しさん:2018/10/12(金) 00:02:49.28 .net
>>564
この仕事何十年もやってる人なら処理内容からだいたいの工数は頭ん中にあるんだよ。
その工数に見合わない見積もり出したら、突っ込まれて詳細聞かれるんだよ。

570 :仕様書無しさん:2018/10/12(金) 00:02:55.85 .net
>>567
だからリファクタリングは修正する必要があるときに
作業時間に含めてやることになるわけなんですね。

さわらなきゃいけないときにやるもの

571 :仕様書無しさん:2018/10/12(金) 00:04:29.82 .net
じゃあリファクタで余分な金なんかとれないじゃん

572 :仕様書無しさん:2018/10/12(金) 00:04:34.68 .net
>>570
そう、動いているコードにはさわるなってのは名言。

573 :仕様書無しさん:2018/10/12(金) 00:05:36.00 .net
>>569
> この仕事何十年もやってる人なら処理内容からだいたいの工数は頭ん中にあるんだよ。

はは、何十年もやっていてそれか。

既存のコードの修正の工数は、既存のコードがどうなってるかで変わってくる
メンテナンスがしやすいコードとそうでないコードでは
修正の時間は何十倍も違ってくる

だから他人が作った見たこともないコードの修正の見積もりなんかしない
自分の仕事に責任を持っているからだ

574 :仕様書無しさん:2018/10/12(金) 00:09:07.35 .net
>>573
それも込みでだいたいの工数なんか決まってんだよ。
見た事も無いコードならリファクタリングが必要かすらわからないんだから、そもそも前提が意味がないって事に気づけ。
そして見た事も無いコードの修正作業の見積もりなんか普通はしない。見積もりに際してコードを提供してもらうのが普通だぞ。

575 :仕様書無しさん:2018/10/12(金) 00:11:11.83 .net
たぶん口だけだな

見積まともにできるやつは
改修による影響範囲とかパスとか
画面とかテストケースの数とか具体的に見積もる

コードがぐちゃぐちゃだからリファクタしたいなんていうやつに
稼働コードに指一本触れさせてはいけない

彼は優れたコードが書けるのではない。単に理解力が劣っているんだ。

576 :仕様書無しさん:2018/10/12(金) 00:19:00.10 .net
自分で書いたコードを自分の責任で弄り回すのは勝手にやればいい。
リファクタリングでも何でも好きな名目でやってれ。
でも、会社組織に組み込まれてる身分では、責任なんか取れないんだから、余計な事はするな。
それだけ。

577 :KAC:2018/10/12(金) 00:46:04.92 .net
>>558
話の本質とは違うけど気になったのでツッコんどく。
「それは客の定義によるだろ」

例えばお前さんが客として買ったゲームソフト、開発者とレビューしたか?

578 :KAC:2018/10/12(金) 00:51:10.56 .net
>>575
概ね同意。
コードがグチャグチャになった根本原因すら理解できてない奴が
リファクタリングしたところでまともなコードにはならないのは明白だし。
時間と金の無駄どころが不要なリスクを上げるだけだろう。

579 :仕様書無しさん:2018/10/12(金) 06:53:26.39 .net
>>578
理解して整理するためにリファクタリングするんだよ
素人は知らないだろうけどプロジェクトの最初から全てのコードの歴史を知ってる人材なんてほとんどいないからな

580 :KAC:2018/10/12(金) 07:00:56.22 .net
>>579
理解するためにリファクタリングするとか、
素人丸出しの意見だな。。。

581 :仕様書無しさん:2018/10/12(金) 07:09:11.43 .net
>>580
お前さんがな
最低限マーティン・ファウラーの本は読んでからこい
でなければ議論の場に立つには早すぎる

582 :KAC:2018/10/12(金) 07:54:59.96 .net
>>581
なるほど。
事象に対する理解力すらないのか。

そりゃあ、自分の間違った行動を正当化するために
リファクタリングをしているってことにしたいわけだ。

583 :仕様書無しさん:2018/10/12(金) 10:06:25.50 .net
客先レビューすると、客からリファクタリング求めらる事もあるんだよな。でも工数は据え置きってのが普通だ。

584 :仕様書無しさん:2018/10/12(金) 11:39:54.32 .net
>>583
はい。交渉力がなければ、工数据え置きでやらされるでしょうね
おそらく仕様変更も無償でやらされてますよ。

585 :仕様書無しさん:2018/10/12(金) 11:41:44.63 .net
>>583
そりゃリファクタリングが要求されるような
読みづらいコードは、バグと一緒だからね

だから、最初からリファクタリング込みで工数を出すんだよ。
動けば完成じゃない。客から文句を言われないものを作るまでが仕事だ

586 :仕様書無しさん:2018/10/12(金) 14:19:06.40 .net
読みづらいからって修正要求される事は無いなぁ
関数ヘッダのコメントが無いとかくらいならあるけどさ。
リファクタリング求められる一番多いのは、
同じ事をコピペかってくらい繰り返してたりするコードとかかなぁ

587 :仕様書無しさん:2018/10/12(金) 18:48:47.73 .net
読みづらいコードとバグは違うだろw変なやつだなあw

588 :仕様書無しさん:2018/10/12(金) 20:00:21.60 .net
繰り返しは目に見えてテスト工数にはねるのでリファクタされてしまう
条件分岐も

やっぱりまぎらわしい名前とか処理順序とか
ややこしい変数渡しがいちばんきくな

589 :仕様書無しさん:2018/10/12(金) 20:26:20.02 .net
>>587
品質が低いからバグと一緒だよ

590 :仕様書無しさん:2018/10/12(金) 21:04:58.85 .net
○○と一緒とかいうな
思考がめっちゃ雑になる

みんなは区別がつくから別の名前で呼んでるんだ
つまり
おまえだけ区別がつかないまぬけということになる

591 :仕様書無しさん:2018/10/12(金) 21:36:10.05 .net
読みづらいコードはバグではない・・・そのとおり
読みづらいコードはバグと一緒で無償修正の対象・・・そのとおり

592 :仕様書無しさん:2018/10/12(金) 21:40:43.46 .net
>>591
ソースコードを納品する場合で
相手側のソースコードのレビューがある場合は当然だな
そのためのレビューなんだし

593 :仕様書無しさん:2018/10/12(金) 22:12:19.93 .net
下流が下流に納品する特殊事例をあげられましてもw
ソースコードなんか読みませんからw

594 :仕様書無しさん:2018/10/12(金) 22:24:05.39 .net
>>593

558 返信:仕様書無しさん[sage] 投稿日:2018/10/11(木) 23:54:32.36
>>556
おまえは、客先コードレビューもやらない素人相手のマか?

595 :仕様書無しさん:2018/10/12(金) 23:05:45.10 .net
執拗な下流押しw

596 :仕様書無しさん:2018/10/12(金) 23:36:20.41 .net
ソース持ってなきゃ相手に依存しっぱなしになってしまう
何か仕込まれてもわからない

コードは権力そのものだ

コード読めないコード読まない上流など
金の上流なだけで立場は最下層
どれほど愚かであればそれを誇る気になるのだろう

597 :仕様書無しさん:2018/10/12(金) 23:55:25.51 .net
自社から出す商品の品質がどうでもいいなんてアホ居るんだw

598 :仕様書無しさん:2018/10/12(金) 23:56:38.24 .net
いやごめん
そんな上流いるわけないな
下流だけど適当に煽ってみただけだよね

599 :KAC:2018/10/13(土) 00:15:55.54 .net
>>596
お前さんは買った商品の全部のコードを読んでから使うのか?
Windowsはさぞかし読むの大変だったろうな。

600 :仕様書無しさん:2018/10/13(土) 00:19:37.81 .net
>>599
読まないしテストもろくな検証もしてない
だからむしられるだけの庶民

MSに勝手にメール見てもいいことにされ、いりもしないOSを無理やり入れさせられ
プライベートをくまなく抜き取られ
せっかく買ったパソコンを自分のもののように好き勝手にいじりまわされても
あきらめて黙って使うしかない

601 :仕様書無しさん:2018/10/14(日) 20:02:01.74 .net
コードメトリクスの上限とか指示されないのかな

602 :仕様書無しさん:2018/10/15(月) 21:12:59.20 .net
 私たち日本人の、日本国憲法を改正しましょう。
総ム省の、『憲法改正國民投票法』、でググって
みてください。拡散も含め、お願い致します。

603 :仕様書無しさん:2018/10/17(水) 08:13:37.09 .net
リファクタリングが必要なとき、それは、システムをそもそもリプレイスしないといけないとき。
よって、リファクタリングなんぞ不要。

604 :仕様書無しさん:2018/10/17(水) 08:33:54.64 .net
>>603
リファクタリングの工数とリプレイスの工数が同じならそれも真だが
多くの場合はそうではないからリファクタリングは必要だよ

605 :仕様書無しさん:2018/10/17(水) 09:03:34.82 .net
むしろいつまで古いシステム使うつもりなんだって話
ハードの耐用年数だってあんだろ?

606 :仕様書無しさん:2018/10/17(水) 09:09:26.37 .net
>>604
だから、リプレイスが必要なレベルなのに、リファクタを提案すること自体愚かだって話だ。
宇宙軍だの言ってる時代に、未だに、石器時代の石で作った武器の石を研ぐことを提案するのか?

607 :仕様書無しさん:2018/10/17(水) 20:32:07.89 .net
移行プロジェクトで
既存システムにリプレースされそうな勢い

いろいろシャレにならない

608 :仕様書無しさん:2018/10/18(木) 19:51:59.30 .net
>>606
リファクタバカを黙らせる例えだなw

609 :仕様書無しさん:2018/10/18(木) 20:43:13.31 .net
>>608
下手くそすぎる例えだろ
自画自賛なんだろうなw

610 :仕様書無しさん:2018/10/18(木) 21:58:06.14 .net
>>606
リプレイスが必要なレベルならリプレイスするのが最適だろ
そうでもないレベルでリファクタが必要なケースもある

「不要」と断言する方が俺には信じられないよ

611 :仕様書無しさん:2018/10/18(木) 22:00:52.92 .net
ちゃんと動いてるもんになんでわざわざ手を加えて金取ろうとするの?

612 :仕様書無しさん:2018/10/18(木) 22:09:10.01 .net
>>611
リファクタだけで金取るビジネスなんて聞いたことないよ

機能追加や仕様変更時に、手を入れやすいようにリファクタするくらいだろ
もちろんリファクタの工数もスケジュールに入れる
当然だが、もしリファクタやらない方が工数が減るならリファクタはやらん

613 :仕様書無しさん:2018/10/18(木) 23:18:45.15 .net
>>612
ちゃんと動いてるもんになんでわざわざ機能追加や仕様変更しようとするの?

614 :仕様書無しさん:2018/10/18(木) 23:36:15.00 .net
べつのことがしたいからじゃないの

615 :仕様書無しさん:2018/10/19(金) 07:25:16.80 .net
>>614
それは改修依頼が入ったってこと?

616 :仕様書無しさん:2018/10/19(金) 08:27:28.18 .net
>>615
そう、改修依頼があってはじめてリファクタを検討する
リファクタした方が工数が少なそうならリファクしてから改修に着手するし
しない方が工数が少なそうならそのまま着手する

あと当然、リプレイスした方が工数が少なそうならリプレイスする

617 :仕様書無しさん:2018/10/19(金) 09:55:32.55 .net
工数で考えるのはまだアマチュア。
プロなら金額で考えれ

618 :仕様書無しさん:2018/10/19(金) 11:03:58.34 .net
>>617
工数で考えるべきか金額で考えるべきかは立場によるだろ
それに、馬鹿正直に工数と金額を比例させる必要はない

619 :仕様書無しさん:2018/10/19(金) 11:06:03.34 .net
立場?
金が全てに優先するだろw

620 :仕様書無しさん:2018/10/19(金) 12:09:00.13 .net
社内では工数、社外では金だろ

621 :仕様書無しさん:2018/10/19(金) 12:20:49.04 .net
客に対しては金、従業員に対しても金。
ただし、ベクトルはそれぞれ真逆だがなw

622 :仕様書無しさん:2018/10/19(金) 12:43:13.76 .net
>>621
まあ経営側からのみの話ならそれでもいいんじゎね?

623 :仕様書無しさん:2018/10/20(土) 00:38:17.81 .net
かしむら最低だな

624 :仕様書無しさん:2018/10/20(土) 10:16:15.04 .net
客や従業員から見ても、経営者の思いとは逆ベクトルだけどな。

625 :仕様書無しさん:2018/10/20(土) 10:43:39.59 .net

 んなことより、要望の品作って

626 :仕様書無しさん:2018/10/20(土) 18:28:30.36 .net
リファクタがリプレイスまでにちょくちょく必要なほど、毎回いきあたりばったりの汚いソースコードの開発会社か
発注したくねー

627 :仕様書無しさん:2018/10/20(土) 18:44:51.16 .net
>>626
何度言っても理解しなよな。

リファクタリングは、別途時間をとってやるってものじゃないの
ちょくちょく必要なんじゃなくて、
コード書くときにほぼ毎回必要なものなの

汚いからリファクタリングするんじゃないんだよ
テストコード書いてそれに通るコード書いて
リファクタリングしながら作り上げるの

プログラマが「できました」と言うまでに
何度もリファクタリングが行われる。

628 :仕様書無しさん:2018/10/20(土) 19:24:53.05 .net
>>627
前に動いたところが触る必要もないのに動かなくなってるお前を信じるビジネスパートナーはこの世にいねーんだよ

629 :仕様書無しさん:2018/10/20(土) 19:38:54.60 .net
リファクタはテスト工数を減らすために改修前にやるもの

630 :仕様書無しさん:2018/10/20(土) 20:11:23.63 .net
>>628
それってさぁ、リファクタリング関係ない話だよね。

共通関数修正したら、前に動いたところが触る必要もないのに動かなくなるじゃん

631 :仕様書無しさん:2018/10/20(土) 20:34:46.03 .net
>>630
だから普通は避ける
円周率が3.14じゃ精度が足りない計算が必要になっても
既存の円周率とは別に用意して
既存には一切手を付けない
そういう管理が必要なんだよ

632 :仕様書無しさん:2018/10/20(土) 20:49:41.21 .net
>>631
ようするにコピペするってことでしょ?
テストの工数が倍増する問題はどう解決するの?

633 :仕様書無しさん:2018/10/20(土) 20:58:54.14 .net
リファクタリングを理解しない人はコスト意識がないんだよね
金を出すのは客だから知ったこっちゃないんだろうけど
コストだけじゃなくて開発時間も伸びるから結局いつも
時間足りなくなってクレームの元になってる

634 :仕様書無しさん:2018/10/20(土) 21:06:00.07 .net
コードを共有するなって話だからリファクタリングとは全く関係ないな。

コードをコピペしてるからバグが出たら、体中に転移した
がん細胞探すように、全体を調べないといけない
一箇所直しただけでは、他の部分には影響しない(=バグがあるまま)

635 :仕様書無しさん:2018/10/20(土) 23:00:14.60 .net
>>632
リグレッションテストどうすんだよ
ちょっと機能追加するたびに共通化して毎回テストするんか
倍増どころじゃないな

636 :仕様書無しさん:2018/10/20(土) 23:04:48.94 .net
リファクタの欠点はどれだけやっても終わりがないことだ
コスト意識がないと
自己満足と脅迫概念にかられて延々非生産的な作業を続けることになる

637 :仕様書無しさん:2018/10/21(日) 01:19:18.08 .net
>>632
は?
お前のやり方じゃ、円周率使ってるとこ全部見直すって言ってるんだぞ
追加分だけじゃ済まないぞ

638 :仕様書無しさん:2018/10/21(日) 01:41:05.39 .net
>>635
リファクタリングとは全く関係ない話だが
テストは自動化しないとリグレッションテストなんてやってられないだろ?

>>637
> お前のやり方じゃ、円周率使ってるとこ全部見直すって言ってるんだぞ

円周率使ってるところが100箇所あるとして、1箇所に変更があったら、
100箇所同様の変更をして100箇所テスト(自動化されたテストの変更も100箇所ある)を
行わないといけないんだぞ。そんな事やってられないだろ

639 :仕様書無しさん:2018/10/21(日) 02:10:11.45 .net
リファクタリングって一旦壊して再構築するんだから
テストし直すのは当たり前だよ

640 :仕様書無しさん:2018/10/21(日) 02:32:19.64 .net
> リファクタリングって一旦壊して再構築するんだから

壊すってどういう事?

641 :仕様書無しさん:2018/10/21(日) 06:05:26.58 .net
>>627
毎回、リファクタwwww
どんだけ、きたねーソースコードなんだよwwww

642 :仕様書無しさん:2018/10/21(日) 06:11:25.20 .net
リファクタで、最適化しているつもりになって、毎回、ソースコードを破壊していくやつ

643 :仕様書無しさん:2018/10/21(日) 06:15:32.12 .net
リファクタリングが一旦壊すってどういう意味だろうか?

644 :仕様書無しさん:2018/10/21(日) 06:16:43.21 .net
>>642
最適化はリファクタリングか?
http://bliki-ja.github.io/IsOptimizationRefactoring/

> 最適化とリファクタリングはどちらも変化を伴うものだが
> (なかには最適化かつリファクタリングとなる変化もあるが)、両者は別物だと私は考えている。
>
> なぜなら、両者の目的が異なるからである。リファクタリングは、
> コードを理解しやすくするためである。最適化は、プログラムを速くするためである。

645 :仕様書無しさん:2018/10/21(日) 06:47:47.64 .net
>>644
最適化=速度に対する

という完全な視野の狭いアホの落書きw

辞書
 最適化とは、速度を改善することである。
って書いてある辞書あるの?www

646 :仕様書無しさん:2018/10/21(日) 06:51:04.63 .net
よくもまぁ、マーチン・ファウラーにアホとか言えるもんだわ
お前はこの業界で世界に誇れるレベルの実績があるのか?

647 :仕様書無しさん:2018/10/21(日) 07:09:30.10 .net
>>646
マーチン・ファウラーさんは、アホですわあww
ねえ。
辞書に最適化とは、速度を改善することである。
って書いてある辞書あるの?wwwねえ?ねえ?ねえ?

648 :仕様書無しさん:2018/10/21(日) 07:12:41.82 .net
マーチン・ファウラーってあれだろ?
開発手法を開発しようとしているのやらwww
それだけいろんな手法を開発してもなお改善しない。
これが何を示すのかわからん馬鹿ってことだ。

649 :仕様書無しさん:2018/10/21(日) 07:13:33.89 .net
ガキが重箱の隅をつついてなんか叫んでるなぁw
この記事に最適化は速くする以外の目的もあるといった所で
「あぁ、そうだな」って言われて終わりだろうに
論点は「リファクタリングと最適化は違う」なんだから

650 :仕様書無しさん:2018/10/21(日) 07:20:42.62 .net
辞書に最適化とは、速度を改善することである。
って書いてある辞書あるの?wwwねえ?ねえ?ねえ?

勝手に、言葉を変更しないでくださいな。大混乱ですわ。wwww

651 :仕様書無しさん:2018/10/21(日) 07:21:13.50 .net
キチガイ認定していい?

652 :仕様書無しさん:2018/10/21(日) 07:21:26.71 .net
>>651
はい論破w

653 :仕様書無しさん:2018/10/21(日) 07:22:33.83 .net
「リファクタリングと最適化は違う」

この場合、「リファクタリング」「最適化」という2単語は極めて重い意味を持つ。
それを「重箱の隅」と片付ける馬鹿w

654 :仕様書無しさん:2018/10/21(日) 07:24:02.39 .net
重箱の隅と言ってるのは「リファクタリング」と「最適化」の比較の話で
「最適化とは速度以外のものもある」ということだよ。

お前は速度以外の最適化に何があると思ってるのか?
それがリファクタリングの比較と同影響が出るのかを答えなさい

655 :仕様書無しさん:2018/10/21(日) 07:24:40.84 .net
コードを読みやすくすることは最適化って言いませんぇね(大爆笑)

656 :仕様書無しさん:2018/10/21(日) 07:27:03.30 .net
>>655
 最適化は、プログラムを速くするためである。
だなんて、断言しているアホwww

辞書に書いてあるの?www

657 :仕様書無しさん:2018/10/21(日) 07:29:14.81 .net
コードを理解しやすくするための最適化

という日本語は存在できないんでしょうか?????wwww

658 :仕様書無しさん:2018/10/21(日) 07:30:11.97 .net
ちなみに、
俺は、著者を馬鹿にしてません。
読者のお前を馬鹿にしています。

659 :仕様書無しさん:2018/10/21(日) 07:43:54.08 .net
>>654
同影響?

660 :仕様書無しさん:2018/10/21(日) 07:44:20.78 .net
>>654
スケールって知ってる?

661 :仕様書無しさん:2018/10/21(日) 07:47:33.05 .net
馬鹿「りふぁくたー!」
周囲「新人さん、あの「りふぁくたー!」って言ってる馬鹿のコード使えないから、同じとこAさんが担当してるから。そっちと調整してね。」

662 :仕様書無しさん:2018/10/21(日) 07:47:33.55 .net
>>638
何を言ってるのかわからない
円周率の精度のテストを新たに作った上でのテストだろ

663 :仕様書無しさん:2018/10/21(日) 07:48:46.51 .net
stringクラスを変更するって平気で言い出すキチガイ

664 :仕様書無しさん:2018/10/21(日) 08:11:56.75 .net
リファクタリングと最適化は違うものですよ

665 :仕様書無しさん:2018/10/21(日) 08:14:14.94 .net
>>663
テストしてないの?
テストしていて、変更しても動きが変わらなければ問題ないでしょ

(前提:リファクタリングは、変更しても動きが変わらない。
動きが変わるものはリファクタリングにはあたらない)

666 :仕様書無しさん:2018/10/21(日) 08:19:00.64 .net
>>631
> 円周率が3.14じゃ精度が足りない計算が必要になっても
> 既存の円周率とは別に用意して

あの、リファクタリングは変えないものなので
精度を増やすことは、リファクタリングではなくて単なる仕様変更なんですけど?

なんてことはないリファクタリングの意味をわかってないだけかw

667 :仕様書無しさん:2018/10/21(日) 08:22:12.52 .net
>>631
> 円周率が3.14じゃ精度が足りない計算が必要になっても
> 既存の円周率とは別に用意して
> 既存には一切手を付けない

別に用意する必要はないな。
(リファクタリングではなく)仕様変更の前後で互換性があればいいだけ
俺なら精度を上げるための省略可能なオプションを追加する

668 :仕様書無しさん:2018/10/21(日) 08:28:49.48 .net
リファクタリング・・・動きは変えない。だから既存の自動テストがそのまま通る

仕様変更・・・動きが変わる。だから全部テストしないといけない


結論。リファクタリングはしてもよいが、仕様変更はするな。

669 :仕様書無しさん:2018/10/21(日) 08:48:52.56 .net
>>668
全部?

670 :仕様書無しさん:2018/10/21(日) 08:51:49.32 .net
>>666
いいや、仕様には円周率の精度なんて書いてないよ
精度がたまたま必要になっちゃったのは今回の追加処理だけ
それだって明記されてるわけじゃない

671 :仕様書無しさん:2018/10/21(日) 08:53:02.17 .net
>>670
それがどうかしたの?

672 :仕様書無しさん:2018/10/21(日) 08:54:12.89 .net
>>671
仕様変更ではないよね?

673 :仕様書無しさん:2018/10/21(日) 08:55:22.67 .net
>>672
仕様変更です

674 :仕様書無しさん:2018/10/21(日) 08:55:46.35 .net
>>673
へぇ、どこが?

675 :仕様書無しさん:2018/10/21(日) 08:56:16.37 .net
>>670
精度が"たまたま"必要になる"なんてことはありません

676 :仕様書無しさん:2018/10/21(日) 08:56:21.55 .net
リファクタリング(動きが変わらないもの)の話で
仕様変更を持ってくるやつは、何も理解してないとしか言えないな

677 :仕様書無しさん:2018/10/21(日) 08:56:43.67 .net
>>674
キチガイ

678 :仕様書無しさん:2018/10/21(日) 08:57:26.32 .net
>>675
あるよ
円周率を割と入力しないと違いが出てほしいとこで出ない計算式とかあるぜ

679 :仕様書無しさん:2018/10/21(日) 08:58:11.51 .net
>>673
いいか?仕事とはこうやるんだ

仕様書がないということは、いかなる動作変更も仕様変更ではないということなんだ

だから客にはこう言うんだ。

「動作は変わりましたが仕様変更ではありません」

680 :仕様書無しさん:2018/10/21(日) 08:58:37.58 .net
>>678
それはたまたまじゃねーだろ

681 :仕様書無しさん:2018/10/21(日) 08:59:18.83 .net
>>679
素晴らしい仕事だ

682 :仕様書無しさん:2018/10/21(日) 08:59:50.61 .net
>>678
だから今まで低い精度で行っていた仕様を
精度を上げるというふうに仕様変更したんでしょう?

まさか、そもそも変更すべき仕様がない = 仕様変更ではない とでも?

683 :仕様書無しさん:2018/10/21(日) 09:00:03.73 .net
リファクタリングもエンハンスも元あるものから手を加えるなら
それは一度壊す事を意味する
言葉上の意味だがこれが理解出来ないからテストを軽視する

684 :仕様書無しさん:2018/10/21(日) 09:00:09.32 .net
>>680
だから必要なのは今回の追加分だけだっつの
客からしたらな
円周率をソース内で使いまわしたいのはテメーのおかしい頭だけなんだよ

685 :仕様書無しさん:2018/10/21(日) 09:00:18.01 .net
>>678
割と入力しないと?

686 :仕様書無しさん:2018/10/21(日) 09:00:34.32 .net
>>683
> リファクタリングもエンハンスも元あるものから手を加えるなら
> それは一度壊す事を意味する

だからリファクタリングで壊すってなに?

687 :仕様書無しさん:2018/10/21(日) 09:00:59.96 .net
>>684
はいキチガイ

688 :仕様書無しさん:2018/10/21(日) 09:01:24.46 .net
>>687
まだわからないの?
バーカ

689 :仕様書無しさん:2018/10/21(日) 09:01:46.71 .net
>>688
キチガイ

690 :仕様書無しさん:2018/10/21(日) 09:02:01.47 .net
>>684
だから今回追加分は、今までと同じ精度では足りなかったから
それに対応する精度に仕様変更するんでしょう?

691 :仕様書無しさん:2018/10/21(日) 09:02:43.75 .net
>>682
え?誰も既存処理を変えろなんて言ってないよね?
円周率を何で使いまわしたいの?
精度が必要なのは今回の追加分だけだよ

692 :仕様書無しさん:2018/10/21(日) 09:02:44.73 .net
>>684
それ仕様変更やん

693 :仕様書無しさん:2018/10/21(日) 09:03:42.47 .net
そもそも円周率の精度変更ってなんなんだ?

円周率取得関数の話してんの?
円周率は固定値なんだから、変更すべきコードなんて無いじゃん

でだしからおかしいのかよw

694 :仕様書無しさん:2018/10/21(日) 09:04:03.53 .net
>>686
端的に言えば元あるものに手を加えて変更する事
変更してる最中は機能してないんだから壊している
作り上げてテストして元あるものと同等であることが確認出来て
初めてリファクタリングしたと言っていい

695 :仕様書無しさん:2018/10/21(日) 09:04:30.44 .net
× 円周率は固定値なんだから、変更すべきコードなんて無いじゃん
○ 円周率は固定値なんだから、リファクタリングすべきコードなんて無いじゃん

696 :仕様書無しさん:2018/10/21(日) 09:05:46.67 .net
>>694
> 端的に言えば元あるものに手を加えて変更する事
> 変更してる最中は機能してないんだから壊している

え? 変更ってコミット単位じゃないの?
コミット単位では壊さないよ

まさか、ファイル保存した単位で壊してるって言ってる?

697 :仕様書無しさん:2018/10/21(日) 09:06:33.50 .net
>>684
あるシステムにはA機能しかありません。ここにB機能を追加します。
はいこれ仕様変更ね。

698 :仕様書無しさん:2018/10/21(日) 09:07:18.95 .net
>>697
仕様書はないのだから、仕様変更ではない

699 :仕様書無しさん:2018/10/21(日) 09:07:48.02 .net
>>683
壊すって何?

700 :仕様書無しさん:2018/10/21(日) 09:09:47.07 .net
>>698
こいつプログラムと一対一の設計者書いてそうwww

701 :仕様書無しさん:2018/10/21(日) 09:10:55.30 .net
>>696
編集してる最中が壊している状態
編集完了してもテストしてない状態が壊れている状態
テストまで完了して完全に機能している事が保証できたらリファクタリング完了

702 :仕様書無しさん:2018/10/21(日) 09:12:59.55 .net
>>701
いや、だから「編集」とはコミット単位で考えてないんですか?
YES か NO でお応えください

703 :仕様書無しさん:2018/10/21(日) 09:13:46.77 .net
>>702
それならNO

704 :仕様書無しさん:2018/10/21(日) 09:24:12.38 .net
今回の追加分の処理の円周率は3.1415までは必要
既存の処理は3.14で十分

このとき既存処理と追加分の処理とで同じ円周率3.1415を共通で使うかどうかって話だな

ビジネスならNo
既存の処理を変更することになる

705 :仕様書無しさん:2018/10/21(日) 09:28:18.38 .net
今回の追加分の処理の円周率は3.1415までは必要
既存の処理は3.14で十分

このとき既存処理と追加分の処理とで同じ円周率3.1415を共通で使うかどうかって話だな

ビジネスならNo
既存の処理を変更することになる

706 :仕様書無しさん:2018/10/21(日) 09:37:24.73 .net
>>703
つまりサーバーにアップロードする前
個人のコンピューターの中でだけ
一時的に壊れてるってことですか?

707 :仕様書無しさん:2018/10/21(日) 09:51:52.30 .net
>>704
ビジネスならNoとか意味わからんし、こっちが恥ずかしくなるレベルw
仕様による。それだけ。仕様書がないのは論外

> このとき既存処理と追加分の処理とで同じ円周率3.1415を
共通で使うならば、それは仕様変更。なぜなら既存の処理の動きが変わってるから。
なお、動きが変わるのでこれはリファクタリングではない(リファクタリングと関係ない話)

仕様変更なのでいままでのテストは通らない可能性があるだろう
まあリファクタリングではないので、それはしかたない

> このとき既存処理と追加分の処理とで同じ円周率3.1415を
共通で使わないならば、既存の処理は変わらない
既存の処理は変わらないのであれば、追加分の処理を除いた既存の処理はリファクタリング可能(必須ではない)
既存の処理に関しては仕様変更しないので、いままでのテストはそのまま通る

追加分の処理は、そもそも存在しなかったものなのだから、この文は当然リファクタリングではない

708 :仕様書無しさん:2018/10/21(日) 09:52:00.90 .net
>>706
コミット単位と言ってる意味が
「毎回機能が保たれた状態に編集してテストまでして問題なくコミットすること」を意味しているなら壊れてない状態
それ以外は壊れてる状態

709 :仕様書無しさん:2018/10/21(日) 09:52:59.68 .net
>>703
質問に答えてくれないので、追加で追い打ちw

つまりサーバーにアップロードする前
個人のコンピューターの中でだけ
一時的に壊れてるってことですか?

他の人は壊れたことに気づかない=壊れてないってことですか?

710 :仕様書無しさん:2018/10/21(日) 09:53:56.25 .net
>>708
でも他の人は誰も、一時的に壊れたことに気づかないんですよね?

711 :仕様書無しさん:2018/10/21(日) 09:54:02.20 .net
コミット単位ってなに?

712 :仕様書無しさん:2018/10/21(日) 09:58:56.26 .net
>>711
バージョン管理ソフト用語で、変更の1単位を表す

ソースコードの修正は複数のファイルにまたがることがあるが
その複数のファイルの変更をまとめて一つにしたものがコミット

通常はコミットごとにテストを実行し壊れていないことを確認する

713 :仕様書無しさん:2018/10/21(日) 10:01:27.12 .net
>>710
他人は関係なく自分で今プログラムをどういう状態にしようとしているか
編集を始めた時点で壊し始めている
当然他人にそんな事認識できるわけない
ローカルで勝手にやってる事が壊してるというのはおかしいというなら
俺とは考えが違う

714 :仕様書無しさん:2018/10/21(日) 10:03:58.62 .net
>>713
え?だってあなたの定義だと既存の機能に全く手を付けなくても
機能追加中も壊れますよね?
ソースコードコンパイルできなくなるんだから

715 :仕様書無しさん:2018/10/21(日) 10:06:39.57 .net
>>714
機能追加中はエンハンスだから壊してる状態
文法エラーでコンパイルできないならそれ以前の問題

716 :仕様書無しさん:2018/10/21(日) 10:07:16.67 .net
ソースコードの修正途中に一時的に動かなくなることを壊すと言ってるのなら、
それをリリースするわけでもないので大したことじゃないから
心配する必要はなにもないってことになるのでいいんですよ。

717 :仕様書無しさん:2018/10/21(日) 10:08:54.02 .net
(自動化された)テストが重要なのは、壊れてないことを保証するためですからね
一時的に壊れてもコミット時に壊れてなければ問題ないので
リファクタリング(動きを変えない)の場合はテストを変える必要もないので、
機能追加と違って、安心して変更ができるわけなんですね。

718 :仕様書無しさん:2018/10/21(日) 10:52:10.73 .net
細井隼人最低だな

719 :仕様書無しさん:2018/10/21(日) 11:33:37.79 .net
揚げ足取りしかできなくて自分の意見が表明できないなんて悲しいな

720 :仕様書無しさん:2018/10/21(日) 12:00:43.16 .net
リファクタに耐えるようなうまいユニットテストつくれん
設定項目が膨大すぎてIF変更やDBの取得先変更で
あっさりで投げ捨てられる

F痛でDBの更新項目とか結果全部テストしてたからそういうふうにしてたが
世間の常識とちがうらしい

721 :仕様書無しさん:2018/10/21(日) 14:09:44.77 .net
ゼネコン案件だったらほとんどがコーディングスキルゼロの素人が設計したスマートUI乱用システムだろ
そのようなシステムではそもそもユニットテストは作れないのが普通なんだ
無理してユニットテストを作るんじゃなくて設計か要件定義までロールバックしたほうがいい

722 :仕様書無しさん:2018/10/21(日) 14:40:04.94 .net
>>668
動きは変えない。

変わっていないことを証明せよ。

723 :仕様書無しさん:2018/10/21(日) 14:54:49.81 .net
このリファクタ馬鹿って、結婚障害だとか書いてる馬鹿と同一人物なんだろ
ほっとけよ

724 :KAC:2018/10/21(日) 15:52:55.50 .net
>>627
毎回リファクタリングが必要とか、
無能すぎてもう何やってるか理解できてないんだな。

725 :仕様書無しさん:2018/10/21(日) 16:04:17.15 .net
業務システムだと簡単すぎて時間が余る
暇を弄ぶのも苦痛なのでテストを整備してリファクタリングする
これぐらいでいいんだよ
無理してやるもんでもないし頑なに拒否するもんでもない

726 :仕様書無しさん:2018/10/21(日) 16:05:15.11 .net
うちのメンツだとリファクタはまずないわ
なにせ綺麗だもん常に

727 :仕様書無しさん:2018/10/21(日) 16:06:37.75 .net
>>726
ならビジネスが進歩してないんだね

728 :仕様書無しさん:2018/10/21(日) 16:16:15.70 .net
うちは正規職員しかいないから
正規職員も全員偏差値70は最低でもある
だからソースも無駄がないのさ
馬鹿な派遣だらけの職場は大変ですね

729 :仕様書無しさん:2018/10/21(日) 16:21:32.14 .net
その割に無駄話が多いですね

730 :仕様書無しさん:2018/10/21(日) 17:52:59.47 .net
ビジネスが進歩してないw

731 :KAC:2018/10/21(日) 18:17:09.31 .net
>>727
ビジネスが進歩とか、
お前の辞書()には面白い単語が載ってるんだな。


つか、表面に見えてるビジネスに依存したソース書くのは素人丸出し。
まともに設計できる技術者なら、リファクタリングなんて無駄な事は発生させない。

732 :仕様書無しさん:2018/10/21(日) 18:18:26.55 .net
>>731
言語やフレームワークの進化も無視ですかそうですか

733 :仕様書無しさん:2018/10/21(日) 18:51:26.49 .net
>>1って、自分以外誰も支持してくれない現実どう受け止めてんの?w
ああキチガイだから受け止めないかw

734 :仕様書無しさん:2018/10/21(日) 18:52:19.63 .net
>>732
そうそう
お気づきの変化が起きた頃にはリプレイスです
リファクタ不要だろ?w

735 :仕様書無しさん:2018/10/21(日) 18:53:26.21 .net
>>734
ものすごい頻度でリプレイスwww

736 :仕様書無しさん:2018/10/21(日) 19:25:07.19 .net
客「仕様変更をお願いしたいですが」
お前「リプレイスですね」

客「ちょっと仕様変更だけなんですが」
お前「無理です。変えられません。リプレイスしたほうが安いです」

客「来月さらに同じところの仕様変更を考えてるのですが」
お前「またリプレイスでしょうねーwww」

737 :仕様書無しさん:2018/10/21(日) 19:38:13.47 .net
>>731
まあそこが君んとこの限界なんだろうね
業務ルールや要望が変化するたびに秘伝のタレを付け足していけばいいさ

738 :仕様書無しさん:2018/10/21(日) 19:55:13.11 .net
リファクタせずに機能追加しまくって
限界が来たらリプレース
理にかなっている

739 :仕様書無しさん:2018/10/21(日) 19:58:39.09 .net
・客先にて

客「広島から大阪を経由して東京へ行く仕様を、京都経由に変更してくれ」
上司「了解しました」

・社内にて

上司「大阪と京都は近くだから簡単だろう?すぐに修正してくれ」

お前「現状、広島から北海道を経由して福岡を経由して新潟を経由して京都を経由して東京に行くようになってますから
京都からさらに大阪を経由して東京に行くんですね」

上司「は? 広島から京都を経由して東京にいくだけだろ。なんでそんなに遠回りしてるんだ?」
お前「動いているコードに手はださない。既存のルートに付け足すだけだ。今までずっとそうしてきた」

上司「それだとムダでわかりづいらいだろ。リファクタリングしろ」
お前「コードぐっちゃぐちゃやねん。手遅れだ。リプレイスしたほうが早い」

上司「なぜこまめにリファクタリングしなかったんだ?」
お前「リプレイスしたほうが早いからだ」

上司「手遅れにならないうちに! こ・ま・めに!」
お前「知るか、リファクタリングなんか不要!」

740 :仕様書無しさん:2018/10/21(日) 20:03:24.02 .net
・客先にて

上司「この間の仕様変更の作業中に、遅かった理由が判明しました。
広島から大阪を経由して東京に行く仕様ですが、
広島から北海道を経由して福岡を経由して新潟を経由して大阪を経由して東京に行っていました」

客(絶句)

上司「担当者は今回の仕様で、上記に追加して大阪からさらに京都を経由しようとしていましたので、
ご安心ください。クビにしました」

741 :仕様書無しさん:2018/10/21(日) 20:06:14.48 .net
コードを書くのは下流だけど下流に行くほどリファクタリングに無頓着
派遣さんはコードを書かせたらサヨナラバイバイだから
彼らには後の事を考えてコーディングする機会がないのだろうね
そうなるとリファクタリングという発想自体が出てこなくなるのも仕方がない

742 :仕様書無しさん:2018/10/21(日) 20:08:30.12 .net
>>738
正解
その頃にはシステム担当者が変わってるから、引き継ぎを兼ねて新しく作るのが吉

743 :KAC:2018/10/21(日) 20:13:07.98 .net
>>732
フレームワークに振り回されるのは素人

744 :仕様書無しさん:2018/10/21(日) 20:15:20.27 .net
新人「大阪経由を京都経由に変更するんですね!(簡単そうだ)任せてください!」

上司「ちなみに納期はこれこれだから」

新人「まあ、変更少なそうだし、大丈夫でしょう」

新人(コード見て絶句)

新人「え!!その期間でその修正を!?」

新人(無理や・・・大阪からさらに京都へ経由する処理を追加するしかない)

上司「おい、なんで。広島から北海道を経由して福岡を経由して新潟を経由して京都を経由して大阪を経由して東京に行ってるんだ?」

新人「知らねーよ。既存のコードがそうなってたんだから真似しただけだ」(暗黒面落ち)

745 :仕様書無しさん:2018/10/21(日) 20:15:54.98 .net
>>742
新しく作るには、ぐっちゃぐちゃのコードを解析しないといけないんやで?

746 :仕様書無しさん:2018/10/21(日) 20:21:29.53 .net
リプレースって既存システムの仕様解析を諦めてベタ移植するフラグが最初からたってる
汚いレガシーシステムを違う基盤上の汚いレガシーシステムに置き換えるだけに終わる
莫大なコストがかかるくせにビジネス上のメリットは殆どゼロ

747 :仕様書無しさん:2018/10/21(日) 20:25:08.48 .net
>>738
> リファクタせずに機能追加しまくって
> 限界が来たらリプレース
> 理にかなっている

限界が来る前の修正でリファクタリングしない理由がわからん

748 :仕様書無しさん:2018/10/21(日) 20:30:22.65 .net
既存システムがめちゃくちゃで仕様解析は無理だ

解析は諦める
行単位で移せば機能を維持したまま移植できるはず

言語やライブラリの仕様の違いのせいでバグが多発
残業しまくって火消しするしかない

なんとか移植完了
バグ数が多いので客は品質に強い懸念を抱いているがテストは通した
たとえスカスカでもテストは通したんだから大丈夫なはずだ

経営陣に土下座させて客への説得もなんとかクリアして受け入れも済んだ
さあ本来の目的だった機能を追加するぞ

コードがめちゃくちゃでどうやったら機能を追加できるかわからないよ

リプレースって毎回こんななるんだけど
リプレースがうまくいくことなんてあるの?

749 :仕様書無しさん:2018/10/21(日) 20:38:22.90 .net
リプレースついでに新しくしましょうとかやるからだろ

リプレースは古いものを使うのが鉄則
そんで限界が来るまで使って
限界が来たら、リプレースをする

750 :仕様書無しさん:2018/10/21(日) 20:46:37.35 .net
リファクタリングしてリプレースに耐えうるコードに書き換えてからリプレースするとうまくいくのだけど
コストをケチってリファクタリングが省略されて失敗する

751 :仕様書無しさん:2018/10/21(日) 20:54:45.22 .net
リプレースって仕様書みて一から全部再実装するんだぞ
そのために仕様書があるわけで、
完璧な仕様書が求められてる

752 :仕様書無しさん:2018/10/21(日) 21:00:04.09 .net
>>751
そんなもんねーよ
夢でも見てんのか

753 :仕様書無しさん:2018/10/21(日) 21:05:52.63 .net
>>743
フレームワークが少し変わるとリプレイスとか頭おかしいよね

754 :仕様書無しさん:2018/10/21(日) 21:37:04.24 .net
>>739
まさにお前のいうようにするわ

いままで北海道で下車できてたのにできなくなったら大デグレードじゃん
それリファクタじゃない
クビになるのは間違いなくお前のほう

多少遅いぐらいなんだってんだ
通常の現実世界とプログラムの世界の違いを知れよ
どうせ1秒2秒だろ?またせとけよ

755 :仕様書無しさん:2018/10/21(日) 21:52:52.70 .net
>>754
> いままで北海道で下車できてたのにできなくなったら大デグレードじゃん
勝手に仕様を追加するな

756 :仕様書無しさん:2018/10/21(日) 22:04:52.76 .net
> 通常の現実世界とプログラムの世界の違いを知れよ
> どうせ1秒2秒だろ?またせとけよ

実行時間の問題じゃないのよ。解析にかかる時間が問題なの

別の担当者が作業した時、なんでこんなことをしているのかわからないコードを
自信を持って完成しましたと言えないことが問題なの

何をやってるか知りませんが、動くからバグはないんじゃない?
テストに漏れがないと良いですね。

こんな無責任なこと言えないの

757 :仕様書無しさん:2018/10/21(日) 22:07:42.69 .net
仕様変更で既存のコードに付け足してつじつま合わせのようなことをしてるなら
テストも同じように付け足してつじつまを合わせをすることになる

必要のないテストをするだけじゃなくテスト自体の自信もなくなる。
こんなテストしてますが、このテストは正しいのですか?
必要なさそうなテストですが、前の人がやっていたので繰り返しやります
時間かかりますね。

758 :仕様書無しさん:2018/10/21(日) 22:10:41.82 .net
>>734
お気づきの変化が起きた時??

759 :KAC:2018/10/21(日) 22:13:40.43 .net
>>748
リプレースの目的と、今後必要な機能を整理して、
現状よりも効率の良い新システムとして提案するのが正解。

760 :仕様書無しさん:2018/10/21(日) 22:14:23.38 .net
>>758
例えばCOBOLのバージョンを毎日確認したりしないよね
いつの間にか「あれ?バージョンが上がってる?」ってなる
数年スパンで起きる現象なんだから
お気づきの変化が起きた頃には(数年たっていて)リプレイスです。

761 :仕様書無しさん:2018/10/21(日) 22:15:14.60 .net
>>755
理由もなくそんなことになるもんか
変えたら何がおこるかわからん

762 :仕様書無しさん:2018/10/21(日) 22:15:37.28 .net
>>759
> リプレースの目的

リファクタリングしてなかったので
想定よりずっと早くコードの寿命が来てしまった
仕方がないのでリプレースで対応します

763 :仕様書無しさん:2018/10/21(日) 22:16:25.32 .net
>>761
意味がわからん。

> 客「広島から大阪を経由して東京へ行く仕様を、京都経由に変更してくれ」

どこにも北海道で下車したいなんて書いてない

764 :仕様書無しさん:2018/10/21(日) 22:16:52.84 .net
リファクタをリプレースと呼べば多少動きが変わっても許してもらえるという願望

765 :KAC:2018/10/21(日) 22:17:41.50 .net
>>755
自分が知らない仕様を他人のせいにするなよ。。。

こういう馬鹿が「聞いてない」「勝手に仕様が追加された」とか言い出すんだよな。

利用者にとって当たり前の仕様くらい把握する力を持てよ?

766 :KAC:2018/10/21(日) 22:18:48.13 .net
>>762
コードの寿命。。。?
お前の書いたコードは経年劣化するのか?

767 :仕様書無しさん:2018/10/21(日) 22:18:52.07 .net
>>763
客も開発者もすべての仕様を常に把握してるわけじゃないからな
どっかでだれか急に悲鳴上げて大混乱になる

768 :仕様書無しさん:2018/10/21(日) 22:19:18.50 .net
>>765
だから意味がわからん。

> 客「広島から大阪を経由して東京へ行く仕様を、京都経由に変更してくれ」

どこにも北海道で下車したいなんて書いてない


仕様に書いてない挙動も、動作保証してるのかな?w

769 :仕様書無しさん:2018/10/21(日) 22:19:59.07 .net
>>767
つまり「仕様変更は認められません」ですかな?w

770 :仕様書無しさん:2018/10/21(日) 22:22:20.47 .net
客「仕様を変更し欲しい。どれくらいかかりますか?」

お前「仕様変更は認められん。こういう使い方してるかもしれないだろ」

客「いやそういう使い方してないから」

お前「お前が決めるな。客は神様ではない。」

客「お前の所に開発頼むのやめるわ」

771 :仕様書無しさん:2018/10/21(日) 22:23:42.33 .net
>>769
仕様変更の依頼があったら大手を振って変えられるし
多少デグレしても言い訳は立つ

ちょっと大阪を京都にするだけだろ?そこだけ対応するよ?

772 :仕様書無しさん:2018/10/21(日) 22:24:16.92 .net
>>759
増改築繰り返したシステムではその必要な機能を解析することがほぼ不可能

773 :仕様書無しさん:2018/10/21(日) 22:24:28.92 .net
客が求めてないのに、一旦リリースした以上
混乱を招くかもしれないからって仕様変更を拒否するとかイミフ

774 :KAC:2018/10/21(日) 22:24:39.11 .net
>>768
そんなことすら理解できないから、
お前は素人だと言ってるんだよ。

現状それで運用されてるんだろ?
なんでわざわざ北海道経由してるのを
「お前の判断でやめてもいい」んだ?

それは最早リファクタリングでもなんでも無い。
ただのバグ追加だ。

775 :仕様書無しさん:2018/10/21(日) 22:25:27.78 .net
>>771
> ちょっと大阪を京都にするだけだろ?そこだけ対応するよ?
大阪で下車するかもしれないだろ?

というような(意味不明な)話だったはずですが?

776 :仕様書無しさん:2018/10/21(日) 22:26:05.81 .net
>>774
> 現状それで運用されてるんだろ?
> なんでわざわざ北海道経由してるのを
> 「お前の判断でやめてもいい」んだ?

↓どうみても客の判断なんだが? 何を言ってるんだこいつ。

> 客「広島から大阪を経由して東京へ行く仕様を、京都経由に変更してくれ」

777 :仕様書無しさん:2018/10/21(日) 22:27:35.48 .net
>>775
なんか気づけば指摘してやるが
そこは客が言い出したんだから間違いがあったら客のせいにできる

778 :仕様書無しさん:2018/10/21(日) 22:29:20.71 .net
>>777
つまり
> いままで北海道で下車できてたのにできなくなったら大デグレードじゃん
っていうのは間違いってことね

779 :仕様書無しさん:2018/10/21(日) 22:29:30.47 .net
???

780 :仕様書無しさん:2018/10/21(日) 22:30:13.47 .net
>>778
そりゃ客が北海道で下車したいって今まで言ってないなら
そんなことに対応する必要はありませんね

781 :仕様書無しさん:2018/10/21(日) 22:31:58.51 .net
・客先にて

客「広島から大阪を経由して東京へ行く仕様を、京都経由に変更してくれ」
上司「了解しました」

・社内にて

上司「大阪と京都は近くだから簡単だろう?すぐに修正してくれ」

お前「現状、広島から北海道を経由して福岡を経由して新潟を経由して京都を経由して東京に行くようになってますから
京都からさらに大阪を経由して東京に行くんですね」

上司「は? 広島から京都を経由して東京にいくだけだろ。なんでそんなに遠回りしてるんだ?」
お前「動いているコードに手はださない。既存のルートに付け足すだけだ。今までずっとそうしてきた」

上司「それだとムダでわかりづいらいだろ。リファクタリングしろ」
お前「コードぐっちゃぐちゃやねん。手遅れだ。リプレイスしたほうが早い」

上司「なぜこまめにリファクタリングしなかったんだ?」
お前「リプレイスしたほうが早いからだ」

上司「手遅れにならないうちに! こ・ま・めに!」
お前「知るか、リファクタリングなんか不要!」

782 :仕様書無しさん:2018/10/21(日) 22:33:07.72 .net
続き

・客先にて

上司「この間の仕様変更の作業中に、遅かった理由が判明しました。
広島から大阪を経由して東京に行く仕様ですが、
広島から北海道を経由して福岡を経由して新潟を経由して大阪を経由して東京に行っていました」

客「今までの経由の変更はすべてそんなことをしていたと?頼んでないんだけど?」(絶句)

上司「担当者は今回の仕様で、上記に追加して大阪からさらに京都を経由しようとしていましたので、
ご安心ください。クビにしました」

783 :仕様書無しさん:2018/10/21(日) 22:33:56.94 .net
おまえぐらい同じこと何回もコピペするのが好きなら
リファクタしたくなるのもわからんでもない

784 :仕様書無しさん:2018/10/21(日) 22:35:05.48 .net
>>783
読まないで途中参加するやつがいるから
これ結構効果あるんだよ。

785 :仕様書無しさん:2018/10/21(日) 22:35:21.24 .net
一見仕様にないように見えても
イクラ弁当がたべたいとか言い出すやつがいたりして
そこで仕様がねじくれてる可能性もある

ぜんぜん関係ないはずなのに勝手に機能削除してそこでデグレたらだいぶやばい

786 :仕様書無しさん:2018/10/21(日) 22:35:47.76 .net
まず経路をデータとして扱うように改修して
既存の経路と同じ結果になるデータを投入してテスト
新しい経路のデータを投入

リファクタリングしてよかったな
しなければ経路を増やすたびにバカバカしい議論、コード分析、コード改修、ビルド、テスト、納品、客先説明をしなければならないところだった
とんでもないコストだよ

787 :KAC:2018/10/21(日) 22:36:23.70 .net
>>785
何度も言わせるな

なんか気づけば指摘してやるが
そこは客が言い出したんだから間違いがあったら客のせいにできる

788 :仕様書無しさん:2018/10/21(日) 22:42:37.01 .net
客の仕様自体が間違ってた時な

べつにそこだけ変えりゃ今まで通り達成できるのに
全然関係ないとこでデグレてあんたが言ったからだって通んないでしょ

789 :仕様書無しさん:2018/10/21(日) 22:44:30.53 .net
>>760
日本語がおかしいって指摘だろ

そしてCOBOLかよwww

790 :仕様書無しさん:2018/10/21(日) 22:45:52.81 .net
>>788
そこは客が言い出したんだから間違いがあったら客のせいにできる

791 :仕様書無しさん:2018/10/21(日) 22:49:03.97 .net
支持者が一人も居ねえw

792 :仕様書無しさん:2018/10/21(日) 22:49:45.59 .net
言い出した部分自体の仕様バグだったらね
これは関係ないとこの機能削除しようってんだからだめだろ

どっちにせよ現実に対しては何の解決にもならんが

793 :仕様書無しさん:2018/10/21(日) 22:49:47.18 .net
そりゃリファクタリングしないほうが良いとか誰も支持せんわw

794 :仕様書無しさん:2018/10/21(日) 22:50:58.75 .net
>>792
やっぱり現実的に解決できるのは
リファクタリングしかないのかな
仕様変更で無駄になったコードは削除しないといけないね

795 :仕様書無しさん:2018/10/21(日) 22:58:53.14 .net
今回の例↓みたいに
> 客「広島から大阪を経由して東京へ行く仕様を、京都経由に変更してくれ」

広島 → 大阪 → 東京 を
広島 → 京都 → 東京 に変更する場合

既存の処理(大阪に行く)を残して
広島 → 大阪 → 京都 → 東京 に変更する方法もある

だがそれは客は望んでいない

で、忘れてはいけないのはコレは ”リファクタリングではない" ということ
仕様変更なんだから当然リファクタリングではない


じゃあこの話のどこにリファクタリングが絡んでくるのかと言うと
(手っ取り早いという理由で)広島 → 大阪 → 京都 → 東京 と書いた後
(客の要望通り無駄な)大阪 を経由する処理を省くこと

広島 → 大阪 → 京都 → 東京 を
広島 → 京都 → 東京 にすることがリファクタリング

ここまでやって、完成と言えるのだが
こまったちゃんは動いたからOKでしょで、完成にしてしまうから
それが積み重なって、(客が要求してない)こんなクソコードになる
広島 → 北海道 → 福岡 → 新潟 → 大阪 → 京都 → 東京

796 :仕様書無しさん:2018/10/21(日) 23:00:03.96 .net
>>795
わかりやすい

797 :仕様書無しさん:2018/10/21(日) 23:00:41.50 .net
仕様変更のたびに、こうやって無駄になってしまったコードを
削除することもリファクタリングの一つなんだよ

798 :仕様書無しさん:2018/10/21(日) 23:02:14.98 .net
消したらもったいないじゃないか!

799 :仕様書無しさん:2018/10/21(日) 23:04:16.62 .net
これからの修正で、時間がかかるほうがもったいない

800 :仕様書無しさん:2018/10/21(日) 23:06:41.33 .net
>>795
その要望で、その直し方する且つそんな直しになるプログラムを組むバカがいるとこで働いてないので

801 :仕様書無しさん:2018/10/21(日) 23:07:55.25 .net
ただの要望通りの仕様変更w

802 :仕様書無しさん:2018/10/21(日) 23:08:48.44 .net
俺はそんなところで目隠しされた状態で働いてる
へたに動いて事故れない

803 :KAC:2018/10/21(日) 23:17:19.02 .net
>>776
だからお前はど素人なんだよ。

「現状のルートは京都を経由していない」
という可能性に気付け。

勝手に仕様を自分の中だけで完結するな。
相手の意図を正しく判断して、今のシステムと比較して確認しろ。

お前のいうとおりなら、そもそも京都を経由してるんだから
要望じたいが発生しない。

804 :仕様書無しさん:2018/10/21(日) 23:58:51.08 .net
>>803
お前一人でずれたこと言ってるぞ
もう少し落ちつて書いてある要望を見ろ
それが全てなんだから

805 :仕様書無しさん:2018/10/22(月) 00:30:11.82 .net
>>786
いちばんヤバいやつ
データ化すると仕様変更にいちじるしく弱くなる
それこそ最初から設計されてなきゃ
なりゆきで変えちゃったらどつぼにはまるパターン

そしてどのみち駅ごとに別のことやるからテスト工数削減できないという

そのうえプログラムだとIF文ですんだところがデシジョンテーブルなんか使ったら
ちょっとしたきっかけで組み合わせ爆発、そのすべてをテストせざるを得なくなる

806 :仕様書無しさん:2018/10/22(月) 00:32:27.85 .net
客や上司が意地悪だとこっちの様子やプログラム見てわざと困るような要求してきたりするしな!
世界が敵に見えてる人間のやることではない

807 :仕様書無しさん:2018/10/22(月) 00:33:12.72 .net
システムと自分とどっちが大事か考えろ

808 :仕様書無しさん:2018/10/22(月) 01:01:17.87 .net
リファクタリング禁止とか言ってるやつが書いた(クソ)コード見てみたいよなー
でもクソコード書くようなやつは公開しないだろうなー
ってことでなんかないか探すスレ立ててみた

【反面教師】 オプソで汚いソースコードを見てみる
https://mevius.5ch.net/test/read.cgi/tech/1540137601/

809 :仕様書無しさん:2018/10/22(月) 01:03:06.50 .net
>>805
> そしてどのみち駅ごとに別のことやるからテスト工数削減できないという

駅の話なんて一言も言ってないよ

810 :仕様書無しさん:2018/10/22(月) 01:23:59.03 .net
じゃあ経路

811 :仕様書無しさん:2018/10/22(月) 01:36:43.04 .net
木村はくそ

812 :仕様書無しさん:2018/10/22(月) 05:42:58.87 .net
>>805
何言ってんだ?
ハードコードされてる方が変更に弱い
経路という明らかにデータで表現すべきものを手続きで実装するなんておかしいよ
そうやっておかしなことをやるから「既存の経路をコピペして付け足しましたー」などと無茶をする奴が現れる
データだったら「新規経路登録しました」で済む話だ
プログラムの変更がないからテストも最小限で済む
客への説明もこれ以上ないほど簡単だ

813 :仕様書無しさん:2018/10/22(月) 06:42:57.75 .net
だから例えが例えになってないから

814 :名無しさん@そうだ選挙に行こう! Go to vote!:2018/10/22(月) 07:56:09.75 .net
誰が何の例えをしたって?

815 :仕様書無しさん:2018/10/22(月) 18:29:43.39 .net
けぇろ(経路、帰ろう)

816 :仕様書無しさん:2018/10/22(月) 19:08:28.04 .net
この事例でパスをデータ化しない奴は即刻クビでもおかしくない

817 :仕様書無しさん:2018/10/22(月) 19:17:08.48 .net
任意のデータを扱えることという要件がない以上やらんほうがいい
客の要望が都合よく同じ枠組みからずっと外れずにいる保証なんてないぞ

やっていいのはこっちが開発のアドバンテージを握ってるときだけだ
思い付きで下っ端がリファクタでやるとか自殺行為

818 :仕様書無しさん:2018/10/22(月) 19:29:08.01 .net
仕様が変わる可能性があるから「具体的な経路」と「枠組み」を分離してメンテナンス性を上げるんだろが
これらがハードコードされて絡み合ってたら直すに直せんぞ

819 :仕様書無しさん:2018/10/22(月) 19:54:07.93 .net
誰からも共感を得られない可愛そうな人

820 :仕様書無しさん:2018/10/22(月) 21:47:00.60 .net
経路が本当は何を意味しているか気づいてないやつばかりだなw
これ、コードの修正方法の話よ?

例えば、既存の処理が
A という処理を行って
B という処理を行って
C という処理を行っているとき、

仕様変更で、BをB'に変えてください(もうBは不要です)と、客から注文が来た時
A という処理を行って
B' という処理を行って
C という処理をすればいいのに

もしかしてBを使ってるかもしれないだろ!(実際には使ってない)と
使うかもしれないだろ(そんな予定はない)と
動いているコードに手を出すな!とかいって言って
客が残せなんて言ってないものを自分の判断で勝手に残して

A という処理を行って
B という処理を行って
B* という処理を追加して Bの結果からB'の結果を作り出して
C という処理を行うという修正をする

素直にBをB'に変更すれば、コードもシンプルになり内容を明確になるのに
修正するたびに既存のものをなるべく残して処理をねじり込ませてコードを複雑にしていく
こういうことするやつがシステムを腐らせていく


なお修正作業の流れだが、BをB'に変更するのが簡単であればそのまま変更すればいいが
複雑な場合は、直接 BをB'にするのではなく、一旦 B+B* にしてテストコードを書いてから
リファクタリングすることで B+B* を B` に変更するという方法もある

821 :KAC:2018/10/22(月) 22:08:32.62 .net
>>820
内容が理解できないなら無理して話に加わらなくてもいいんだよ?

822 :仕様書無しさん:2018/10/22(月) 22:27:50.23 .net
状態遷移の話だとおもえばみんなハッピー

823 :KAC:2018/10/22(月) 22:56:41.52 .net
>>812
既存システムで扱われている「経路」というものを
「データで扱った方が良い」と判断した根拠が示されていないんだから、
賛同者が居ないのは当たり前。

データに分離しない方が楽なときはまたリファクタリング()するのか?

824 :仕様書無しさん:2018/10/23(火) 00:37:50.15 .net
>>821
書いた俺が内容わからないわけ無いだろw

825 :KAC:2018/10/23(火) 02:50:52.88 .net
>>824
お前は、自分の書いたことすら理解できてないだろ。
1つのレス内ですら筋が通ってない。

真ん中頃と最後の発言比べてみ?

826 :仕様書無しさん:2018/10/23(火) 03:11:06.15 .net
>>825
比べたけど矛盾はなかった

827 :仕様書無しさん:2018/10/23(火) 08:20:45.42 .net
誰も同調してくれないwwww

828 :仕様書無しさん:2018/10/23(火) 08:47:50.77 .net
こんなに必死になっても、誰も同意してくれないってことは
自分に間違いがあるってことだってことに気が付かないんだろうな

人の意見に耳をかさず、自分の意見は主張し続ける
パヨク病だな完全に

829 :仕様書無しさん:2018/10/23(火) 14:55:09.75 .net
>>828
こんなところで自己紹介しなくていいから

830 :仕様書無しさん:2018/10/23(火) 17:14:02.28 .net
>>820の言いたいことがわからん
方針決めずにダラダラ書いていくのがリファクタリングってこと?

831 :仕様書無しさん:2018/10/23(火) 18:38:15.96 .net
不毛なスレだな

832 :KAC:2018/10/23(火) 18:38:36.36 .net
設計もせずにいつもグダグダになるから
リファクタリングが必要とか言い出すんだろう

833 :仕様書無しさん:2018/10/23(火) 19:56:21.86 .net
>>830
> 方針決めずにダラダラ書いていくのがリファクタリングってこと?

リファクタリングの利用の場面はいくつかあって、
その一つが、テストファーストであるという話

先にテストを書いて、そのテストに通る最低限のコードを書く
(ここまではリファクタリングじゃないぞ)

そしてテストに通る状態を維持したまま、質の高いコードに変える
これがリファクタリングの利用例の一つ

834 :仕様書無しさん:2018/10/23(火) 20:24:42.81 .net
>>833
なんではじめから質の高いコードを書かないの?

835 :仕様書無しさん:2018/10/23(火) 20:42:01.45 .net
時間効率悪くても
最初は動くの確かめて安心したいから

836 :仕様書無しさん:2018/10/23(火) 20:55:40.64 .net
>>834
既存のコードがあって、そこに付け足すから。

ちょうど今やってるんだが1関数50行のコードがある。
少々長めだが、switchである値はこれ、この値はこれ、みたいな処理の連続で
単純な処理なのでこのままで質には十分だった。

だけどその値のパターン数が5つだったが、新たに3個追加になる。
似たようなコードなので今のコードに単純に追加するのは簡単だが
これをやると単純計算で1関数80行にもなってしまう。1関数80行はさすがにヤバい。長過ぎる
許容範囲の品質が、悪い品質に変わる瞬間

だから今リファクタリングを行ってる段階。(3個追加はまだする段階ではない)テストはあるので安心。
関数の中にある似たようなコードを共通化して別の関数に追い出すことで15行減らした。
もう一箇所減らせそうなので15行、50行のコードが20行程度になる予定

これに3個追加しても+12行で32行なので十分な品質だろう
もしもっとパターン数が追加になれば、パターンごとに別関数にするだろうけど
まだそこまでやる段階じゃないな。今の段階でこれをやると逆に関数に分けすぎで見通しが悪くなる

837 :KAC:2018/10/24(水) 00:57:51.29 .net
>>836
設計しろよ。。。
スケーラビリティーの考慮なんて基本中の基本。

838 :仕様書無しさん:2018/10/24(水) 01:16:44.88 .net
俺なら3つ書き足して帰って寝る

ねるぞ

839 :仕様書無しさん:2018/10/24(水) 02:24:02.86 .net
>>837
コストを考えろ。
必要かどうかもわからないことをやるな

840 :仕様書無しさん:2018/10/24(水) 04:04:07.52 .net
ソースコードが仮に1万行だとすると、
1関数あたり平均20行として500関数ぐらいかな?

今作ってるのを見てみたら2000行程度で
120関数だから大体計算あってる

何が言いたいかって言うと、1万行で500関数ぐらいは
設計時点で関数名出してくださいよっていったら
不可能と言うだろうってこと。俺もそう思うw

841 :KAC:2018/10/24(水) 05:50:45.06 .net
>>839
設計もせずに書き始めるから書き直す羽目になるんだろ。
コスト意識ないバカはこれだから・・・

842 :仕様書無しさん:2018/10/24(水) 06:07:24.09 .net
>>841
設計っていうのは規模で変わるんだよ
一階建ての家と二階建ての家の設計が違うように
設計は変えないといけないの

お前MS-DOSの時代にWindowsの設計をする馬鹿じゃないだろうな?w

843 :仕様書無しさん:2018/10/24(水) 06:14:01.22 .net
ガチガチに設計してしまったら、変更に弱くなるからな
作り直しが必要になるのは、やりすぎた設計が原因だよ
必要最小限の実装にしておけば、そこだけ修正すればいい

844 :仕様書無しさん:2018/10/24(水) 06:23:03.42 .net
全く設計しないみたいな論調はどこからでてきた?そして何故その前提を受け入れるんだ?
リファクタリングは必須だがだからといって設計をしないわけじゃない
どんなに注意深く設計しても多人数で時間をかけてコードを蓄積したらコードは劣化するからリファクタリングが必要なんだ
はじめから汚く書いてもいい免罪符にはならん

テストドリブンでもすべてを厳密に動く汚いコードから始めるメリットはない
普通はできるだけキレイで動くコードから始める

845 :仕様書無しさん:2018/10/24(水) 06:25:31.23 .net
設計を変更するって言ってる時点で、
最初に設計してるの当たり前ですわw

客からなにを言われても、修正対応は受け付けない!って
突っぱねるなら話は別だけどwww

846 :仕様書無しさん:2018/10/24(水) 06:27:07.27 .net
とりあえず、1万行のソースコードから
500個の関数名を始めに設計(?)できるもんなら
やってみなと

あーだこーだと机上の空論で手を動かさず
設計に何ヶ月もかかったりしてなwww

847 :KAC:2018/10/24(水) 07:04:48.93 .net
>>844
リファクタリング必須とか言ってる時点で設計とは何かを理解していない

848 :仕様書無しさん:2018/10/24(水) 07:05:40.42 .net
詳細設計書く力があったら普通にできるんじゃないか
やることって大体決まってるだろ

849 :仕様書無しさん:2018/10/24(水) 07:06:14.45 .net
>>847
設計と内部構造に何の関係があるの?

設計をしていれば、内部構造も決まるってこと?

850 :仕様書無しさん:2018/10/24(水) 07:07:50.29 .net
あ、KACが言ってることが破綻してきたw

どう答える気だろうwww

851 :仕様書無しさん:2018/10/24(水) 09:18:25.63 .net
きむまさダメだろ荒らしたら

852 :KAC:2018/10/24(水) 11:39:54.06 .net
>>850
なにが破綻してるというのか。

内容が理解できないなら無理して煽らなくていいぞ?

853 :仕様書無しさん:2018/10/24(水) 15:33:30.94 .net
破綻してるな。

リファクタリングは内部構造(実装)の問題点を修正するものなんだから
設計していればリファクタリングが不要になるというのなら、
設計時点で、内部構造(実装)まで決まっていないといけない

854 :仕様書無しさん:2018/10/24(水) 15:36:21.03 .net
しかも、最初の時点で最終的な設計をしなければいけない
バージョンアップしていくという当たり前のことできない

855 :仕様書無しさん:2018/10/24(水) 15:46:02.32 .net
バージョンアップしてもリファクタリング不要にするってことは
初期バージョンの時点で最終バージョン用のコードを書くってことですかねぇw
最終バージョンの機能なんて決まってんの?
そもそも最終バージョンなんてものが存在するのか知りませんが

856 :仕様書無しさん:2018/10/24(水) 15:59:42.63 .net
最初のうちから完璧なものを出せって考え方だと
いつまでたってもリリースできないんやで

857 :KAC:2018/10/24(水) 18:25:15.77 .net
なるほど。
お前が設計がどういうものか全く理解していない事はよく分かった。

858 :仕様書無しさん:2018/10/24(水) 18:38:41.80 .net
昔はこの手の人を小ばかにした韜晦でいいようにつつきまわされたもんだ
今は死ねとしか思わん

859 :仕様書無しさん:2018/10/24(水) 18:57:06.39 .net
>>857
みんなお前がわかってないと思ってるよ
なぜならお前は設計がどんなものかを何一つ言ってないから

860 :KAC:2018/10/24(水) 19:30:24.36 .net
>>859
おまえ、周りの人達も「設計を理解していない」とか思ってる?

理解してて当たり前だって事すら知らないんだな。

861 :仕様書無しさん:2018/10/24(水) 19:50:52.27 .net
IT技術者辞典

理解=個人的解釈
当たり前=根拠のない思い込み

862 :仕様書無しさん:2018/10/24(水) 20:19:07.98 .net
IT技術者辞典には設計すら載ってないってこと?

863 :仕様書無しさん:2018/10/24(水) 20:23:06.43 .net
では設計を理解してるKACに問おう

設計とはなんぞや?

簡潔に述べよ

864 :836:2018/10/24(水) 20:35:43.97 .net
昨日の50行→80行になりそうだった関数。言ってなかったけど
あれからリファクタリングして35行に減らした。

で、そのあともう少し見直して、パターンごとで関数に分けるのではなく
中でやってる処理を複数の処理に分けられることに気づいた(適切な名前をつけられた)
そこで分割したら、メインの関数が25行に減って、そこから呼び出す4つの関数
(それぞれ15行、20行、5行、10行)に分割できた。

テストもそれぞれの関数ごとに行えるようになったので、よりシンプルになった

最初からこうしろと?無理だよ。一番最初は30行程度だったんだぜ。
初期バージョン時点の複雑になってない状態で分割とかしてたら
いつまでたってもリリースできない。

865 :仕様書無しさん:2018/10/24(水) 20:39:05.09 .net
行数で語るって、古いタイプの人かな?

866 :仕様書無しさん:2018/10/24(水) 20:54:53.77 .net
>>865


時間をかけて35行に減らしたものを、さらに、25+15+5+10 = 合計55行に
増やして "改善された" って言ってるんだけど?
行数で "あんたが望んでいるようなこと" は何も語ってないよね?


このようにリファクタリングで時間がかかるのに
将来のバージョンアップでどうなかもわからないのに
最初のうちに将来のバージョンアップを想定してやるのは時間の無駄

だけど1関数80行を放置したら、さらに時間がかかる
このタイミングでリファクタリングするのはいいタイミングよ。

開発コストは行数とは無関係。だけど多くの場合複雑度とは関係ある
複雑だとテストの時間も長くなるし、バグも増える

コストを掛けて1関数の行数を減らす=複雑度を減らすことは
将来のコストを減らすことにつながる
ただし1関数の行数は減っても全体の行数は増えることもある。
もちろんそれで良い。重要なのは複雑度

だから行数と開発コストを関連付けるなんて古いタイプの人間の考えとは全く違う

867 :仕様書無しさん:2018/10/24(水) 21:09:35.62 .net
あと設計で関数の名前を出すといってるのかしらんが、
実装(何行かかるか、どれくらい複雑か)がわからんうちに
どれくらいの数の関数が必要なのか、わかるはずがない

5行以下の関数を大量に作ったら、それはそれで分かりづらいし
そもそも関数に分割するべきかを行数で判断してはいけない
(ただし行数と複雑度に相関関係はある。俺は行数ではなく複雑度で判断して分割している)

868 :仕様書無しさん:2018/10/24(水) 21:22:49.00 .net
?

869 :仕様書無しさん:2018/10/24(水) 21:35:22.43 .net
現実でも誰にも支持されてないんだろうな
これだけ利害関係もない多くの人がいるとこでも支持されない
無様w

誰でも極端なやつは相手にされないんだよ
適材適所
なんでもかんでも自分が読んだ本はすべての人が実践しなければならないって思い込んじゃうんだろう
精神病患者だな完全に

870 :仕様書無しさん:2018/10/24(水) 21:45:50.78 .net
40年ぐらい前なら支持されてたかもしれないなー
当時はリファクタリングなんて用語はなかっただろうし
自動テストってのもなかっただろう

871 :仕様書無しさん:2018/10/24(水) 21:52:28.05 .net
まあ待て支持を得られているかどうかを判断するのは
KACが設計とはなにかを語ってからにしようじゃないか
今は何も言ってないから支持を集められないだけ

872 :仕様書無しさん:2018/10/24(水) 21:58:06.90 .net
IT技術者辞典には設計すら載ってないってこと?

873 :仕様書無しさん:2018/10/24(水) 21:59:48.70 .net
KACが考える設計がそれ(世間一般の常識)とずれてるって話

874 :仕様書無しさん:2018/10/24(水) 22:00:38.93 .net
なるほど

875 :仕様書無しさん:2018/10/24(水) 22:29:48.00 .net
>>870
40年前だと、ほんとに露骨なほど、
腕の良いプログラマとそうでないプログラマの作ったソースコードの差が酷かったからなw

876 :仕様書無しさん:2018/10/24(水) 22:30:25.03 .net
>>873
たとえば?

877 :仕様書無しさん:2018/10/24(水) 22:35:05.33 .net
根本的に海外の人の設計思想って、日本で言うところの内製環境が絶対的前提条件だしなあ
ぶん投げた先の派遣の馬鹿に設計なんてやらせないし

878 :仕様書無しさん:2018/10/24(水) 22:35:55.62 .net
>>876
本人が設計を言わないで、
オラの考える設計と違うだと言ってるから
KACが間違ってるんだろうって話だよ

879 :仕様書無しさん:2018/10/24(水) 22:36:23.29 .net
なるほど

880 :仕様書無しさん:2018/10/24(水) 22:39:09.95 .net
>>877
海外と同じように、派遣がやってる設計を全部
自分の所で引き取って、自分で設計すれば良いのでは?

本当の理由は、派遣が〜じゃなくて
あんたの会社に、開発リソースがないってことでしょう?

881 :仕様書無しさん:2018/10/24(水) 22:43:09.39 .net
>>878
設計なんて皆普通に理解できるけど
貴方には無理って事?

882 :仕様書無しさん:2018/10/24(水) 22:43:35.01 .net
>>880
は?
プログラマの立場。日本と海外とどういうスタンスの差があるか調べたら?
その違いから、根本的に海外の開発設計思想を日本で語ろうというのが間違いなんだよ

883 :仕様書無しさん:2018/10/24(水) 22:46:22.00 .net
日本の場合プログラマは大半が派遣・少し外部、部内プログラマは極小
海外の場合プログラマは大半が部内プログラマ、少し派遣・外部

884 :仕様書無しさん:2018/10/24(水) 22:48:25.40 .net
日本で開発設計手法を語るなら、日本の開発環境を大前提とした開発設計手法を独自に考えないと意味がないね
たとえガラパゴスと言われようとも
それが嫌なら、海外とプログラマの立ち位置を同じようにしないと話しにならん

885 :仕様書無しさん:2018/10/24(水) 23:03:12.36 .net
>>882
いやいや、派遣のせいにするのではなくて、
そういう開発してるのはあんたの会社でしょうって話。

886 :仕様書無しさん:2018/10/24(水) 23:06:16.50 .net
>>884
それ、支持を集められると良いね

887 :仕様書無しさん:2018/10/24(水) 23:15:09.93 .net
> 日本で開発設計手法を語るなら、日本の開発環境を大前提とした開発設計手法を独自に考えないと意味がないね

念の為に言っておくけど、海外の開発設計手法は
全て日本には当てはまらないという話にしたらだめだよ?
海外の開発設計手法は全く使ってないと言うのなら別だけど。

888 :仕様書無しさん:2018/10/25(木) 10:18:39.16 .net
結局リファクタリングって何してるの?
関数を小分けにして作業時間の水増しを図るって事?

889 :仕様書無しさん:2018/10/25(木) 10:33:02.50 .net
ソースコードの複雑性を解消して
メンテナンス性を上げてる

890 :仕様書無しさん:2018/10/25(木) 10:34:13.41 .net
まああれだな。

整理整頓するのには時間がかかる
だから散らかっている方が、時間の節約になる
と短絡的に考えてる人には理解できないw

891 :KAC:2018/10/25(木) 10:36:27.26 .net
そもそも散らかさない
という考えには至らないんだよな

892 :仕様書無しさん:2018/10/25(木) 10:39:06.57 .net
>>891
面白くないよ

バージョンアップすると、
必ず無駄な部分、効率が悪い部分が出てくるんだから

それよりキミ、自分の宿題をなかったコトにしないように

863 名前:仕様書無しさん[sage] 投稿日:2018/10/24(水) 20:23:06.43
では設計を理解してるKACに問おう

設計とはなんぞや?

簡潔に述べよ

893 :仕様書無しさん:2018/10/25(木) 10:59:58.22 .net
>>890
なるほど
整理整頓・ゴミ掃除が下手な人の言い訳なんだね

894 :仕様書無しさん:2018/10/25(木) 11:09:17.07 .net
>>893
そうそう。片付けるのには時間がかかるからと言ってやらない
結果余計に時間がかかる。
それを防ぐのがリファクタリングなわけさ。
こまめにリファクタリングしましょう

895 :仕様書無しさん:2018/10/25(木) 11:26:05.54 .net
>>894
でも整理整頓は一般常識の範囲なんで普通は仕事とは言わないよね?
その作業を仕事といってお金取るのはどうなんだろう
整理整頓をリファクタリングっていう言葉に置き換えて仰々しくみせてるだけな気がする

896 :仕様書無しさん:2018/10/25(木) 11:27:18.07 .net
1剣件あたり10nsでやらないといけないとこを勝手に無学なやつにリファクタされる悪夢

897 :仕様書無しさん:2018/10/25(木) 11:29:37.49 .net
>>895
> でも整理整頓は一般常識の範囲なんで普通は仕事とは言わないよね?

それは「整理整頓」の話ですね。
リファクタリングの話じゃないです。

898 :仕様書無しさん:2018/10/25(木) 11:30:29.77 .net
>>896
リファクタリングしても10nsで実行できていれば問題ないのでは???

899 :仕様書無しさん:2018/10/25(木) 11:37:15.50 .net
>>897
え?リファクタリングってコードを整理する事でしょ
処理の共通化や細分化ってコードの整理じゃないの?
整理整頓と同義だと思うんだけど

900 :仕様書無しさん:2018/10/25(木) 11:39:49.65 .net
1. 作業をしていると散らかるのは避けられない
2. だから整理整頓やリファクタリングをしないといけない
3. 整理整頓もリファクタリングも作業効率が上がるという効果がある
4. 整理整頓は仕事ではないが、リファクタリングは仕事である

901 :仕様書無しさん:2018/10/25(木) 11:40:50.46 .net
>>900
1から3まで

4が一致しないというwwww

902 :仕様書無しさん:2018/10/25(木) 11:41:25.40 .net
>>899
はい? 整理整頓は仕事じゃないですが、
リファクタリングは仕事だって言っただけですよ?

そりゃどちらも効果はあるでしょう?

効果はありますが、整理整頓は仕事とは言わないといわれたから
リファクタリングは仕事かつ効果があるって話をしてるんですよ

903 :仕様書無しさん:2018/10/25(木) 11:42:08.37 .net
>>901
そりゃ、違うものなんだから違う部分ぐらいあるでしょう

頭大丈夫なのか?

効果は一緒。
仕事かどうかは違う

904 :仕様書無しさん:2018/10/25(木) 11:42:20.24 .net
>>900の話で、整理整頓が仕事から除外された理由がわからんわwwwwwwww

やっぱりキチガイだwこいつ

905 :仕様書無しさん:2018/10/25(木) 11:43:31.55 .net
>>904
> でも整理整頓は一般常識の範囲なんで普通は仕事とは言わないよね?

整理整頓は仕事なんですか?仕事じゃないんですか?
仕事なんですよね?

906 :仕様書無しさん:2018/10/25(木) 11:44:14.49 .net
作業をしていると散らかるのは避けられないので、整理整頓やリファクタを「しなければならない」
整理整頓やリファクタは「効果がある」

だけど、整理整頓は仕事では「ない」。リファクタは仕事で「ある」
なにが起こったんだ???wwww

907 :仕様書無しさん:2018/10/25(木) 11:44:47.56 .net
普通に考えれば、会社でやる整理整頓は仕事の一環ですよ
もちろんリファクタリングも仕事の一環

おかしいのは>>895

908 :仕様書無しさん:2018/10/25(木) 11:45:50.09 .net
>>906


よし>>895を問い詰めようぜ。
この馬鹿が、整理整頓は仕事じゃないって言ったんだ

909 :仕様書無しさん:2018/10/25(木) 11:46:18.41 .net
なんだよw 結局、整理整頓もリファクタリングも
仕事なんじゃねーかw

910 :906:2018/10/25(木) 11:47:06.61 .net
>>907-908
おかしいのはおめーだよw

911 :仕様書無しさん:2018/10/25(木) 11:47:26.67 .net
(リファクタリングの)アンチって行き当たりばったりで
しゃべてるから、すぐ矛盾起すよねw

912 :仕様書無しさん:2018/10/25(木) 11:48:29.32 .net
>作業をしていると散らかるのは避けられないので、整理整頓やリファクタを「しなければならない」

この「作業をしていると散らかるのは避けられないので、整理整頓やリファクタを「しなければならない」」から、お前以外誰も同意してないけどな。

913 :仕様書無しさん:2018/10/25(木) 11:48:56.72 .net
>>910
整理整頓は仕事じゃないって言っちゃった本人ですかw
社会人失格ですよ

914 :仕様書無しさん:2018/10/25(木) 11:49:49.76 .net
>>912
そういうが、お前に同意しているやつは一人もいないじゃん

915 :仕様書無しさん:2018/10/25(木) 11:52:58.38 .net
コードのリファクタより重要なことは
 ユーザーのシステム仕様に対する記憶や理解、把握が劣化しないようにすること
これをダメポシステムが教えた。

ユーザーのシステム仕様に対する記憶や理解、把握が劣化しなければ、システムの再開発は容易い。

916 :仕様書無しさん:2018/10/25(木) 11:54:05.43 .net
>>915
それが不可能だからという前提なんですが・・・

917 :仕様書無しさん:2018/10/25(木) 11:56:36.73 .net
十分な時間が与えられ、誰も間違いをおかさず、仕様、設計が変更にならず
バージョンアップ(段階リリース)することもなく
最初から最終バージョンをいきなりリリースして
その後バグ修正以外のことをしないなら
リファクタリングなんか必要ない

918 :仕様書無しさん:2018/10/25(木) 11:57:13.14 .net
>>917
それも不可能という前提なんですが・・・

919 :仕様書無しさん:2018/10/25(木) 11:57:20.48 .net
>>915の対応作として最近出てきてるのが、担当者交代毎のリプレイス法なんだがトップが理解してくれない悲しい現実

920 :仕様書無しさん:2018/10/25(木) 12:00:01.96 .net
895だけど整理整頓を仕事の範囲なんて書いてないけど?
一般常識でいう整理整頓って普通は仕事前とか終わりなんかに自主的にするもので仕事外の作業だと思うんだけど…
そもそもコード書いたときに日常的にコードの整理を最後に加えておけばいいだけなんじゃないの?
なんでリファクタリングっていう整理だけの工程が仕事になってるの?

921 :仕様書無しさん:2018/10/25(木) 12:01:15.37 .net
>>920
社畜って知ってる?w

922 :仕様書無しさん:2018/10/25(木) 12:05:41.16 .net
>>921
あ!なるほど…いいよねフリーダム
束縛されない人生って素敵やん

923 :仕様書無しさん:2018/10/25(木) 12:08:40.67 .net
別名:無職

司法「仕事は?」
リファクタリアン「社畜どもがwww」
司法「無職ね」

924 :仕様書無しさん:2018/10/25(木) 12:29:26.94 .net
>>922
え?なに極端なこと言ってんの?

仕事なんだから仕事時間内にやれって言ってるだけなのに

そんなんだから社畜なんだよw

925 :仕様書無しさん:2018/10/25(木) 12:40:31.55 .net
>>920
そのコードの整理も仕事のひとつだと思うぞ

926 :仕様書無しさん:2018/10/25(木) 23:29:22.79 .net
かしむら役立たず

927 :仕様書無しさん:2018/10/26(金) 20:29:05.48 .net
まだ支持を得られないのか

928 :仕様書無しさん:2018/10/26(金) 22:16:38.49 .net
リファクタリングは不要
誰か支持をくれ!

929 :仕様書無しさん:2018/10/26(金) 22:29:21.15 .net
おまえを支持するくらいだったら無駄にリファクタリングするわ

930 :仕様書無しさん:2018/10/26(金) 22:31:03.30 .net
まあ、その時点で無駄だと認めてるわけだが。

931 :仕様書無しさん:2018/10/27(土) 01:02:38.21 .net
支持しなくていいなら?

932 :仕様書無しさん:2018/10/27(土) 09:00:10.47 .net
無駄なリファクタリングもあれば必要なリファクタリングもあるよ
当たり前だろ

933 :仕様書無しさん:2018/10/27(土) 13:15:05.68 .net
整理整頓って言った方が心理的抵抗感が減ってGoサインが出やすくなることに気付いた

934 :仕様書無しさん:2018/10/27(土) 13:51:57.30 .net
でもまあGoサインとかもらうもんじゃないけどな
修正作業に含まれるものなんだから

935 :仕様書無しさん:2018/10/27(土) 14:51:05.56 .net
コードの複雑さを数値化して
複雑すぎるモジュールは作り直すんだよ
もちろんテストは全部やり直す

936 :仕様書無しさん:2018/10/27(土) 20:22:04.06 .net
>>935
そしてその作り直したものに修正を加える時はどうするの?

937 :仕様書無しさん:2018/10/28(日) 13:47:55.32 .net
>>935
正しいけれど
真の馬鹿は閾値を馬鹿みたいに上昇させて
結局リファクタリングなんてさせない。

938 :仕様書無しさん:2018/10/28(日) 19:36:53.15 .net
複雑かどうかより、追加変更のしやすい形に直すんだぞ。
変更しやすければ、より複雑でも構わないんだ。
仕組みの複雑さより、見た目の複雑さの方が問題なのさ。

939 :仕様書無しさん:2018/10/28(日) 21:01:09.00 .net
部下が勝手にリファクタやってたら懲戒にするわマジで

940 :仕様書無しさん:2018/10/28(日) 21:31:17.25 .net
>>938
「複雑」という言葉の意味を理解してないように見える

コードが複雑という話。重要なのは「コード」
読めない人がいる というのは「人の話」

この2つをごっちゃにしてはいけない

変更しやすいが複雑なコードなんてものはないだろう

>>939
リファクタリングは修正作業の中に含まれるものなんだが?
勝手に修正はしませんよ。客などからの要求があって作業します。
修正しろと言われたら、案に必要ならリファクタリングすることも含まれるってだけです。

941 :仕様書無しさん:2018/10/28(日) 22:00:35.02 .net
>>938
次の仕事来なかったら意味ねーじゃんアホ?

942 :仕様書無しさん:2018/10/28(日) 22:06:04.61 .net
>>940
>変更しやすいが複雑なコードなんてものはないだろう

そんなことないよ

943 :仕様書無しさん:2018/10/28(日) 22:09:02.77 .net
複雑と言うのは、既存機能モジュールに置き換えしたら結果全体的には複雑化になるって話だぞ。
複雑さと読みにくさは比例しない。
複数の分岐処理と論理演算駆使した1分岐処理と、どっちが複雑?
でその論理演算を1つの関数にまとめたら、最初のものと比べてどっちが複雑?

944 :仕様書無しさん:2018/10/29(月) 18:59:02.42 .net
規模の大きい企業システムが混乱する原因はほぼ100%データベースだから
アプリケーションコードだけリファクタリングしてもあまり意味がないと思う

945 :仕様書無しさん:2018/10/29(月) 19:15:39.71 .net
>>944

データベース・リファクタリング
https://www.amazon.co.jp/dp/4894715007
これ知られざる良書なんだけど、絶版なんだよなぁ

946 :仕様書無しさん:2018/10/29(月) 19:20:41.34 .net
>>945
DBリファクタリングはノウハウがあっても業務系では絶対に許可が出ないから需要がない

947 :仕様書無しさん:2018/10/29(月) 19:24:20.10 .net
> 業務系では絶対に許可が出ないから

それはノウハウがないってことでは?
許可が出ないのにノウハウなんて貯まるわけ無いでしょw

ってか、仕様変更があったらどうすんの?
DB変えられないので、仕様変更は受け付けませんって
客の要求を突っぱねるの?

948 :仕様書無しさん:2018/10/29(月) 19:27:14.60 .net
仕様変更は(多大な労力が必要だけど)許可が出る
そこをはき違えちゃいかん

949 :仕様書無しさん:2018/10/29(月) 19:32:27.86 .net
だから仕様変更でリファクタリング(が必要な場合)の許可がでるでしょ

仕様変更などで(客などから要求があって)変更する許可がでたときに
作業工程の一つとしていれるのがリファクタリングだって何度も言われてるじゃん

なんでまたいつものように、勝手にやるのがリファクタリングだって思いこんでるのさ?

950 :仕様書無しさん:2018/10/29(月) 19:35:10.73 .net
余計なことするなって言われて終わり
最小限の変更は許可するがそれ以外は認めない
これ常識ね

951 :仕様書無しさん:2018/10/29(月) 19:40:07.80 .net
リファクタリングは余計なことじゃないですよw

952 :仕様書無しさん:2018/10/29(月) 19:42:14.06 .net
そう思ってるのは末端だけ
決定権持ってる人は揃って無駄な工程と言う

953 :仕様書無しさん:2018/10/29(月) 19:44:29.09 .net
でも、無駄な工程と言ってるあんたは
決定権持ってないじゃんw

954 :仕様書無しさん:2018/10/29(月) 19:44:55.74 .net
リファクタリングは余計なことじゃないのかもしれんが
おまえらがやってるのはゴミを別のゴミに変えとるだけやからな
そもそもリファクタリングちゃうし

955 :仕様書無しさん:2018/10/29(月) 19:46:16.61 .net
どうしておまえらごとき一介のコーダーがリファクタリングできると勘違いしてしまったのか
闇は深いでこれ

956 :仕様書無しさん:2018/10/29(月) 19:46:56.47 .net
つまり、一介のコーダーじゃないからでは?

957 :仕様書無しさん:2018/10/29(月) 19:46:58.68 .net
コーダーはコードしかみてないからな
変えた後の単体から受け入れまでのテスト工数
デグレのリスク

なのに後から参加して詳細知らないPGほど積極的で
最悪前よりさらにぐちゃぐちゃになる

958 :仕様書無しさん:2018/10/29(月) 19:47:43.87 .net
そもそも問題ないとこさわるな
一生経っても終わらんなる

959 :仕様書無しさん:2018/10/29(月) 19:49:02.28 .net
つまり、問題あるならリファクタリングしてよし!

960 :仕様書無しさん:2018/10/29(月) 19:49:27.03 .net
そこの関連のテストがナンボあるかわかってないやつに限って触ろうとする狂気

961 :仕様書無しさん:2018/10/29(月) 19:49:48.89 .net
コードの問題じゃないぞ
動きに問題があるときだけだぞ

962 :仕様書無しさん:2018/10/29(月) 19:49:54.92 .net
>>959
それ不具合修正やろ?

963 :仕様書無しさん:2018/10/29(月) 19:50:13.38 .net
2位じゃダメなんでしょうか?

964 :仕様書無しさん:2018/10/29(月) 19:51:12.89 .net
>>953
俺が言ってる言ってないは関係ないと知れ

965 :仕様書無しさん:2018/10/29(月) 19:51:34.32 .net
>>962
コードを修正するときにより複雑にしていまい
不具合が発生する。大問題ですね

966 :仕様書無しさん:2018/10/29(月) 19:52:22.32 .net
>>964
せやな。上であるお前(笑)が
無駄と言ってるかどうかは関係ないなw

967 :仕様書無しさん:2018/10/29(月) 19:53:21.89 .net
>>960
> そこの関連のテストがナンボあるかわかってないやつに限って触ろうとする狂気

でも、客から修正しろって言われたんですよ?
客にテストがなんぼあるかわからんから、修正は受け付けないって突っぱねるの?

968 :仕様書無しさん:2018/10/29(月) 19:53:39.83 .net
リファクタリングの許可が出ない現実は変わらない
これだけは確かだ

969 :仕様書無しさん:2018/10/29(月) 19:54:23.89 .net
>>968
いや、修正作業の一環として普通に出るんだが?

970 :仕様書無しさん:2018/10/29(月) 19:55:08.86 .net
>>967
客の命令は仕方がないので直して全部テストする
余計な修正はしちゃダメ

971 :仕様書無しさん:2018/10/29(月) 19:56:22.43 .net
>>969
出ないよ
データベースの話だぞ
DB管理者が抱え込んでるからアプリ開発者などには手出しできん

972 :仕様書無しさん:2018/10/29(月) 19:57:22.53 .net
大きいプロジェクトはな、詳細なんて誰もわかんねーんだよ
だから動くと自信を持って開発することなんかできやしない

動くかも?動くと良いな。で開発してあとはひたすらテストして
あ、動いてる?良かったよかったってのを増やすしか無いんだよ

その程度のプロとは思えない仕事をするのが現実なんだから
リファクタリングして動くと自信を持てるコードになんかする必要ないの
動いてるといいなーレベルで十分。

973 :仕様書無しさん:2018/10/29(月) 19:58:04.59 .net
>>971
いや、仕様変更するんだから変更許可出る

974 :仕様書無しさん:2018/10/29(月) 19:59:12.01 .net
> DB管理者が抱え込んでるからアプリ開発者などには手出しできん

DB管理者がリファクタリングするんでしょ?
動きを変えないのがリファクタリングなんだから
アプリ開発者にとっては関係ないこと

975 :仕様書無しさん:2018/10/29(月) 19:59:20.91 .net
新人が結合テスト中にコードリファクタして文字とか定数に変えまくってて
全体がめっちゃ変更履歴ついてて肝が冷えた

でも問題おこってないからわりかし大丈夫なのかもしれない

976 :仕様書無しさん:2018/10/29(月) 20:03:03.59 .net
やっぱ>>945(データベース・リファクタリング)読んだほうが良いぜ

お前(ら?)、どうせ無停止(もしくは短時間の停止)で
(客からの支持に伴う仕様変更で必須な)データベースの構造変更とかできないだろ?

データベースとアプリを同時に変更しなきゃいけないから
どうしても停止時間が必要ですとか思ってそう

(データベースの)リファクタリングは動きを変えないものなんだから
データベースのみ変更できるんだよ。

977 :仕様書無しさん:2018/10/29(月) 20:04:37.93 .net
>>975
リファクタリングは動きを変えないものだからねー

動きを変えるものの変更は大変だけど
理論上動きが変わらないと確立されている
変更を行うだけだから問題は起きにくいんだよ

978 :仕様書無しさん:2018/10/29(月) 20:52:54.85 .net
>>976
んなあほな…
止められるときは止めたほうが安全だろ

変更中にシステムが正常に稼働し続けるテストとか
手続きを間違いなく行うための準備とか
その変更プロセス自体のリスクと重さ考えたら
よっぽどのことじゃなきゃやれん

979 :仕様書無しさん:2018/10/29(月) 20:54:12.47 .net
> 止められるときは止めたほうが安全だろ
止められない時の話をしてる

980 :仕様書無しさん:2018/10/29(月) 20:56:24.73 .net
> 変更中にシステムが正常に稼働し続けるテストとか

そんなんじゃAmazonのように24時間稼働しつづけてかつ
変更もされていくシステムなんか到底できそうもありませんね

981 :仕様書無しさん:2018/10/29(月) 20:58:03.05 .net
Amazon神

982 :仕様書無しさん:2018/10/29(月) 21:51:05.16 .net
>>980
あいつら機械とかビルごと別のにしてんじゃねーの

983 :仕様書無しさん:2018/10/29(月) 21:57:06.02 .net
データベースは共有してるに決まってるだろ

984 :仕様書無しさん:2018/10/29(月) 22:03:49.78 .net
リファクタの手続きとしてはわかる
でもこれってほんとにシステムを停止させないための話なの?

切り替えるのはサブ構成作ってマシンごとごっそりやっちゃうみたいな感じじゃないの

985 :仕様書無しさん:2018/10/29(月) 22:24:01.04 .net
おい急にだまるなし

986 :仕様書無しさん:2018/10/29(月) 22:26:49.17 .net
本気で無停止にするならイベントソースにするんでね

987 :仕様書無しさん:2018/10/30(火) 01:28:43.31 .net
>>984
アプリとは違ってデータベースはサブ構成作ってえいやって
置き換えることはできないんだよ

すでに大量のデータが溜まってるんだから
データの変換作業というものが必要になる

そういうのをどうやるかが「データベースリファクタリング」には
書いてあるんだが絶版

988 :仕様書無しさん:2018/10/30(火) 08:50:35.16 .net
サーバーを分散しているに決まってるだろ。

989 :仕様書無しさん:2018/10/30(火) 09:05:52.95 .net
>>988
意味がわからん。データベースはサーバーを分散したとしても
えいやって置き換えることはできないって話をしてる

990 :仕様書無しさん:2018/10/30(火) 09:41:24.67 .net
えいやって置き換えなくていい様に分散化だろうに。

991 :仕様書無しさん:2018/10/30(火) 09:55:25.28 .net
>>990
データベースを分散化することで、何がどう解決するのか言ってみ
お前、目的を忘れてるみたいだからさ

992 :仕様書無しさん:2018/10/30(火) 11:05:26.41 .net
あ?
まさか、単にバラバラにデータばら撒いてるだけだと思ってる?
主な目的は、相互補完だぞ。

993 :仕様書無しさん:2018/10/30(火) 11:30:09.11 .net
そういうのは良いから、何(どういう問題)がどう解決するのか書いて
どうせわかってないから誤魔化かしてるんだろうけどw

994 :仕様書無しさん:2018/10/30(火) 11:30:38.12 .net
ちなみにデータベースのリファクタリングの話をしてるんだからな

995 :仕様書無しさん:2018/10/30(火) 12:19:25.73 .net
リファクタリングするよりクリアなスキーマ設計のデータベースを立ててデータ転送する方が楽

996 :仕様書無しさん:2018/10/30(火) 13:09:45.94 .net
はいはい。それを無停止でやる方法が上で書いた
「データベースリファクタリング」に書いてあるんですってば
何周も回ってやっと追いついた感じだなw

997 :仕様書無しさん:2018/10/30(火) 18:42:47.80 .net
残念ですが許可されません

998 :仕様書無しさん:2018/10/30(火) 19:14:37.28 .net
技術の問題じゃないんです。
無能の問題なんです。

999 :仕様書無しさん:2018/10/30(火) 19:16:07.13 .net
だめな会社は、優れたこと(リファクタリング)でも
理解できないので、なんでもだめといいます。

ゲーム?よくわからないからだめ
漫画?よくわからないからだめ
インターネット?よくわからないからだめ

これと一緒です。

とりあえず否定からはいって
会社をダメにする奴らです

1000 :仕様書無しさん:2018/10/30(火) 19:16:23.66 .net
リファクタリングすると全部テストしろと言ってくる奴の矛盾3
https://medaka.5ch.net/test/read.cgi/prog/1540809569/

1001 :2ch.net投稿限界:Over 1000 Thread
2ch.netからのレス数が1000に到達しました。

総レス数 1001
244 KB
掲示板に戻る 全部 前100 次100 最新50
read.cgi ver 2014.07.20.01.SC 2014/07/20 D ★