機能追加や変更した時に、全部テストしてるでしょ？
いつもやってることじゃん
前スレ
ﾘﾌｧｸﾀﾘﾝｸﾞすると全部ﾃｽﾄしろと言ってくるやつの矛盾
https://medaka.5ch.net/test/read.cgi/prog/1523765624/
ﾘﾌｧｸﾀﾘﾝｸﾞすると全部ﾃｽﾄしろと言ってくる奴の矛盾2
レス数が1000を超えています。これ以上書き込みはできません。
2018/05/19(土) 18:05:57.63
2仕様書無しさん
2018/05/19(土) 18:35:02.73 アンチは論破された。泣き崩れている。
ウソと詭弁で自分を守ることしかできていない。
様々な証拠がリファクタリングの有用性を示している。
マイクロソフトもリファクタリングをしていた。
Googleもリファクタリングをしていた
Appleもリファクタリングをしていた。
もう誰にも止められない。
アンチはウソと詭弁を繰り返すだけ
ウソと詭弁で自分を守ることしかできていない。
様々な証拠がリファクタリングの有用性を示している。
マイクロソフトもリファクタリングをしていた。
Googleもリファクタリングをしていた
Appleもリファクタリングをしていた。
もう誰にも止められない。
アンチはウソと詭弁を繰り返すだけ
2018/05/19(土) 18:38:38.63
嘘つき嘘つき嘘つき嘘つき嘘つき嘘つき嘘つき嘘つき嘘つき嘘つき嘘つき嘘つき
嘘つき嘘つき嘘つき嘘つき嘘つき嘘つき嘘つき嘘つき嘘つき嘘つき嘘つき嘘つき
嘘つき嘘つき嘘つき嘘つき嘘つき嘘つき嘘つき嘘つき嘘つき嘘つき嘘つき嘘つき
嘘つき嘘つき嘘つき嘘つき嘘つき嘘つき嘘つき嘘つき嘘つき嘘つき嘘つき嘘つき
嘘つき嘘つき嘘つき嘘つき嘘つき嘘つき嘘つき嘘つき嘘つき嘘つき嘘つき嘘つき
嘘つき嘘つき嘘つき嘘つき嘘つき嘘つき嘘つき嘘つき嘘つき嘘つき嘘つき嘘つき
嘘つき嘘つき嘘つき嘘つき嘘つき嘘つき嘘つき嘘つき嘘つき嘘つき嘘つき嘘つき
嘘つき嘘つき嘘つき嘘つき嘘つき嘘つき嘘つき嘘つき嘘つき嘘つき嘘つき嘘つき
嘘つき嘘つき嘘つき嘘つき嘘つき嘘つき嘘つき嘘つき嘘つき嘘つき嘘つき嘘つき
嘘つき嘘つき嘘つき嘘つき嘘つき嘘つき嘘つき嘘つき嘘つき嘘つき嘘つき嘘つき
嘘つき嘘つき嘘つき嘘つき嘘つき嘘つき嘘つき嘘つき嘘つき嘘つき嘘つき嘘つき
嘘つき嘘つき嘘つき嘘つき嘘つき嘘つき嘘つき嘘つき嘘つき嘘つき嘘つき嘘つき
嘘つき嘘つき嘘つき嘘つき嘘つき嘘つき嘘つき嘘つき嘘つき嘘つき嘘つき嘘つき
嘘つき嘘つき嘘つき嘘つき嘘つき嘘つき嘘つき嘘つき嘘つき嘘つき嘘つき嘘つき
嘘つき嘘つき嘘つき嘘つき嘘つき嘘つき嘘つき嘘つき嘘つき嘘つき嘘つき嘘つき
嘘つき嘘つき嘘つき嘘つき嘘つき嘘つき嘘つき嘘つき嘘つき嘘つき嘘つき嘘つき
嘘つき嘘つき嘘つき嘘つき嘘つき嘘つき嘘つき嘘つき嘘つき嘘つき嘘つき嘘つき
嘘つき嘘つき嘘つき嘘つき嘘つき嘘つき嘘つき嘘つき嘘つき嘘つき嘘つき嘘つき
嘘つき嘘つき嘘つき嘘つき嘘つき嘘つき嘘つき嘘つき嘘つき嘘つき嘘つき嘘つき
2018/05/19(土) 18:40:54.65
リファクタリングは金にならない虚業
6仕様書無しさん
2018/05/19(土) 18:44:55.59 そろそろリファクタリングよりもそれをする頭の悪い>>2自身が全ての元凶だって気がついた？
7仕様書無しさん
2018/05/19(土) 18:47:56.31 >>5
犯罪者はパンを食べている理論に通じるものがあるな
犯罪者はパンを食べている理論に通じるものがあるな
8仕様書無しさん
2018/05/19(土) 18:49:10.87 リファクタリングを定義することから始めないと
それぞれの話が噛み合わないかもわからんね
それぞれの話が噛み合わないかもわからんね
9仕様書無しさん
2018/05/19(土) 18:52:41.61 リファクタリングなど全ての人間が持っているやり直したい欲求の大義名分にすぎんのだから定義など無理なのだよ
10仕様書無しさん
2018/05/19(土) 19:09:33.77 マーチンファウラーは悔しかったら使えるアプリ作ってみろよ
ハゲなんか信用できないんだよ
ハゲなんか信用できないんだよ
11仕様書無しさん
2018/05/19(土) 19:10:33.10 トイレのウンコが流れるのもリファクタリング
13仕様書無しさん
2018/05/19(土) 20:51:24.39 2000年3月から、ThoughtWorks社に主席技術者として勤務している[1]。同社は、システムインテグレーションとコンサルティングを業務とする会社である。
SIかあ
SIかあ
14仕様書無しさん
2018/05/19(土) 20:57:08.26 アメリカのシステムインテグレーションなんて
ろくなもんないだろ
SIなら日本が最高だよ
ろくなもんないだろ
SIなら日本が最高だよ
15仕様書無しさん
2018/05/19(土) 20:58:13.71 SIよりも俺のほうがすごい
17仕様書無しさん
2018/05/19(土) 21:40:24.54 言っとくけど有名な技術書書いたって実績とは認めないからな
うちの新人の初めのコードコミットのほうが何倍も価値がある
うちの新人の初めのコードコミットのほうが何倍も価値がある
18仕様書無しさん
2018/05/19(土) 21:43:16.16 >>17
すまんがおまえんとこのコードには何の価値もない
すまんがおまえんとこのコードには何の価値もない
19仕様書無しさん
2018/05/19(土) 21:48:04.63 雑誌社かソフトウェア会社か
そーゆーのの広告塔なんだろうな
なんの実績もねーのにあの祭り上げ方はおかしい
そーゆーのの広告塔なんだろうな
なんの実績もねーのにあの祭り上げ方はおかしい
20仕様書無しさん
2018/05/19(土) 21:48:07.34 驚愕の事実拡散
創価の魔(仏罰、現証、非科学的な原始的発想)の正体は、米国が仕掛けてるAI
パトカーの付きまとい、咳払い、くしゃみ、芝刈機音、ドアバン、ヘリの飛行音、子供の奇声、ドアバンも全て、米国が仕掛けてるAIが、人を操ってやってる。救急車のノイズキャンペーンに至っては、サイレンで嫌がらせにする為だけに、重篤な病人を作り出す冷徹さ
集スト(ギャングストーカー、ガスライティング、コインテルプロ、自殺強要ストーキング)以外にも、病気、痛み、かゆみ、湿疹かぶれ、臭い、自殺、殺人、事故、火災、台風、地震等、この世の災い全て、クソダニ米国の腐れAIが、波動(周波数)を悪用して作り出したもの
真実は下に
http://bbs1.aimix-z.com/mtpt.cgi?room=pr02&;mode=view&no=46
https://shinkamigo.wordpress.com
創価の魔(仏罰、現証、非科学的な原始的発想)の正体は、米国が仕掛けてるAI
パトカーの付きまとい、咳払い、くしゃみ、芝刈機音、ドアバン、ヘリの飛行音、子供の奇声、ドアバンも全て、米国が仕掛けてるAIが、人を操ってやってる。救急車のノイズキャンペーンに至っては、サイレンで嫌がらせにする為だけに、重篤な病人を作り出す冷徹さ
集スト(ギャングストーカー、ガスライティング、コインテルプロ、自殺強要ストーキング)以外にも、病気、痛み、かゆみ、湿疹かぶれ、臭い、自殺、殺人、事故、火災、台風、地震等、この世の災い全て、クソダニ米国の腐れAIが、波動(周波数)を悪用して作り出したもの
真実は下に
http://bbs1.aimix-z.com/mtpt.cgi?room=pr02&;mode=view&no=46
https://shinkamigo.wordpress.com
2119
2018/05/19(土) 21:50:58.75 言っとくが、有名な技術書執筆は実績とは認めねーからな
22仕様書無しさん
2018/05/19(土) 21:53:10.80 世界中にどれだけ影響を与えようが本が売れようが
客から金をもらえる1行の方が価値がある
客から金をもらえる1行の方が価値がある
23仕様書無しさん
2018/05/19(土) 21:53:41.92 だから給料を上げろ
マーチンファウラーよりも俺のほうが給料が高くあるべきだ
マーチンファウラーよりも俺のほうが給料が高くあるべきだ
24仕様書無しさん
2018/05/19(土) 21:59:37.34 これが典型的な日本のおっさんである
25仕様書無しさん
2018/05/19(土) 22:05:07.06 俺らは技術者なんだから技術についてちゃんと精査しないと駄目だってことだな
26仕様書無しさん
2018/05/19(土) 22:06:38.55 技術とはコードを書くことである
本を書くことは技術ではない
本を書くことは技術ではない
27仕様書無しさん
2018/05/19(土) 23:28:20.40 ㈱マーチンファウラーだったんだろうね
28仕様書無しさん
2018/05/19(土) 23:30:03.76 マーチンファウラーを貶めると
自分の価値が上がるはず
自分の価値が上がるはず
30仕様書無しさん
2018/05/19(土) 23:37:56.25 俺の会社じゃ有名な技術書書いても、
なにもやってないの同じだからなー
なにもやってないの同じだからなー
31仕様書無しさん
2018/05/19(土) 23:44:35.0632仕様書無しさん
2018/05/19(土) 23:45:56.02 ホーキング博士だった
33仕様書無しさん
2018/05/19(土) 23:47:02.57 そのとおりだ。世界中で有効活用されている本でも
俺のにとっては別だからな。
俺が理解できないとどんな本も役立たずだ
俺のにとっては別だからな。
俺が理解できないとどんな本も役立たずだ
36仕様書無しさん
2018/05/19(土) 23:58:46.61 Amazonの評価とかでいいんやないか？
他にもっといい案があればよろしく
なければこれで
他にもっといい案があればよろしく
なければこれで
37仕様書無しさん
2018/05/19(土) 23:59:44.46 企業が発表する技術を精査するのは雑音が多くて大変だ
敵はマーチンファウラーなんて実績の無いおっさんを有名人に仕立て上げることができる強敵だ
ネームバリューに負けて中身を見れないような雑魚は
そもそも技術書なんか手に取るべきでは無かった
敵はマーチンファウラーなんて実績の無いおっさんを有名人に仕立て上げることができる強敵だ
ネームバリューに負けて中身を見れないような雑魚は
そもそも技術書なんか手に取るべきでは無かった
39仕様書無しさん
2018/05/20(日) 00:01:24.46 日本のAmazonだと翻訳が悪くて～っていうのがあるので
アメリカのAmazonでの評価にしよう
そっちの方がレビュー多そうだし
アメリカのAmazonでの評価にしよう
そっちの方がレビュー多そうだし
40仕様書無しさん
2018/05/20(日) 00:02:17.95 他にいい案はないかな？
ないならamazon.comの評価で判断するけど
ないならamazon.comの評価で判断するけど
41仕様書無しさん
2018/05/20(日) 00:03:16.17 反対する人もないようだし
いいんじゃないですかね
いいんじゃないですかね
42仕様書無しさん
2018/05/20(日) 00:03:49.29 リファクタはプログラマ自身のためのもの
街並みがきれいなところに住むと幸福度が上がるように
自分の作ったコードがきれいに整頓されていると居心地が良い
効率？物の価値のわからんやっちゃな
プログラマになったら人生の３分の１をコードと共に過ごすんだぞ
街並みがきれいなところに住むと幸福度が上がるように
自分の作ったコードがきれいに整頓されていると居心地が良い
効率？物の価値のわからんやっちゃな
プログラマになったら人生の３分の１をコードと共に過ごすんだぞ
43仕様書無しさん
2018/05/20(日) 00:06:40.82 そもそもお前らはどうなの？
世間一般的に役に立つとされる技術を身に着けて、まわりから役に立つとされる評価が欲しいのか？
本当に開発の役に立つ技術が欲しいのか？
前者であればハゲに同調するのも正しい選択なんだ
世間一般的に役に立つとされる技術を身に着けて、まわりから役に立つとされる評価が欲しいのか？
本当に開発の役に立つ技術が欲しいのか？
前者であればハゲに同調するのも正しい選択なんだ
45仕様書無しさん
2018/05/20(日) 00:09:24.00 このままだと本が有用かどうかがamazon.comでの
評価になっちゃうよ？それでいいの？
評価になっちゃうよ？それでいいの？
48仕様書無しさん
2018/05/20(日) 00:11:40.71 5ちゃんねるには見えないIDでNGにする方法があるのだ
その方法は教えられないがな
その方法は教えられないがな
49仕様書無しさん
2018/05/20(日) 00:11:58.47 ふーん、NGねぇ（笑）
50仕様書無しさん
2018/05/20(日) 00:13:24.49 うそじゃないぞ
52仕様書無しさん
2018/05/20(日) 00:15:23.07 仕事は遊びじゃない。楽しいと思った時点で
それは仕事じゃないんだよ。金を稼ぐことだけ考えてろ
それは仕事じゃないんだよ。金を稼ぐことだけ考えてろ
53仕様書無しさん
2018/05/20(日) 00:15:43.11 長時間労働すれば金は稼げるぞ？ｗ
54仕様書無しさん
2018/05/20(日) 00:18:35.05 満場一致ってことでAmazonでの評価が高ければ、
世界中で有効活用されているとみなします。
世界中で有効活用されているとみなします。
55仕様書無しさん
2018/05/20(日) 00:19:00.94 マーチンファウラーの本すごいな。
世界中で有効活用されてるじゃん
世界中で有効活用されてるじゃん
56仕様書無しさん
2018/05/20(日) 00:34:54.29 は？Amazonの評価なんて認めるわけねーじゃん。ばーかーばーか
57仕様書無しさん
2018/05/20(日) 00:35:12.65 >>51
そう、そこまで肯定してしまうと
彼らの虚業にも正当性ができてしまう
彼らははじめからかあるいはいつの時点からか
全く役に立たない技術をさも役に立つかのように
無料で公開し関連の商品で儲けるようになった
それの何が悪いのかと？
言われると何も悪くはない
そう、そこまで肯定してしまうと
彼らの虚業にも正当性ができてしまう
彼らははじめからかあるいはいつの時点からか
全く役に立たない技術をさも役に立つかのように
無料で公開し関連の商品で儲けるようになった
それの何が悪いのかと？
言われると何も悪くはない
59仕様書無しさん
2018/05/20(日) 00:37:46.74 >>57
> 彼らははじめからかあるいはいつの時点からか
> 全く役に立たない技術をさも役に立つかのように
あー、君。悪いんだけどマーチンファウラーの書籍は
Amazonの評価で役に立つって証明されたばかりなんだわ
その結果を無視せんといてな
> 彼らははじめからかあるいはいつの時点からか
> 全く役に立たない技術をさも役に立つかのように
あー、君。悪いんだけどマーチンファウラーの書籍は
Amazonの評価で役に立つって証明されたばかりなんだわ
その結果を無視せんといてな
60仕様書無しさん
2018/05/20(日) 00:40:27.24 無視してるのはわざとだろｗ
わざとであることを指摘したら
可愛そうじゃないかｗ
わざとであることを指摘したら
可愛そうじゃないかｗ
61仕様書無しさん
2018/05/20(日) 00:55:46.34 お前らと話しても得られることは無さそうだな
62仕様書無しさん
2018/05/20(日) 06:57:35.34 「動いているなら弄るなよ」
さあ反論しろ
さあ反論しろ
63仕様書無しさん
2018/05/20(日) 07:20:00.68 反論のなにも、そうやって仕事失った人がいますよ。
改良してください→「動いているからいじりません」
バグ修正してください→「動いているからいじりません」
改良してください→「動いているからいじりません」
バグ修正してください→「動いているからいじりません」
64仕様書無しさん
2018/05/20(日) 09:31:34.0865仕様書無しさん
2018/05/20(日) 09:52:32.81 タダより高いものは無かったって話だな
67仕様書無しさん
2018/05/20(日) 15:45:57.31 62
動いてるように見えてるだけだな。
動いてるように見えてるだけだな。
68仕様書無しさん
2018/05/20(日) 15:50:28.92 >>66
(´；ω；｀)
(´；ω；｀)
69仕様書無しさん
2018/05/20(日) 16:36:20.6670仕様書無しさん
2018/05/20(日) 17:02:30.35 俺らみんな地球が丸いと思ってたがうそだったのか
71仕様書無しさん
2018/05/20(日) 17:12:26.04 バカでも安全にコードを変更できるんだし良いよ
72仕様書無しさん
2018/05/20(日) 17:23:57.92 賢いのが世間と違うこというのって自分の知識や経験で判断してるからじゃん
世間が世間のいうこと鵜呑みにするのは、だいたいはそれなりに世間が正しくてなんとかなってるからで
それだけを根拠にその逆に判断するのって最悪じゃね？
世間が世間のいうこと鵜呑みにするのは、だいたいはそれなりに世間が正しくてなんとかなってるからで
それだけを根拠にその逆に判断するのって最悪じゃね？
74仕様書無しさん
2018/05/20(日) 17:49:46.08 馬鹿の直感と真実が一致してるかどうかが重要
1+1は馬鹿の直感も真実も2になるので馬鹿の逆張りをしてはいけない
量子力学のような直感と真実が一致しない問題や、巧妙に思考を誘導する引っ掛け問題に対しては馬鹿の逆張りをした方が有利となる
そもそも馬鹿の答えは白紙になるってツッコミはなしな
1+1は馬鹿の直感も真実も2になるので馬鹿の逆張りをしてはいけない
量子力学のような直感と真実が一致しない問題や、巧妙に思考を誘導する引っ掛け問題に対しては馬鹿の逆張りをした方が有利となる
そもそも馬鹿の答えは白紙になるってツッコミはなしな
75仕様書無しさん
2018/05/20(日) 18:25:02.66 >>74
そもそもおまえは馬鹿
そもそもおまえは馬鹿
76仕様書無しさん
2018/05/20(日) 22:58:26.39 マーチンファウラーが直近でなんかソフトの一つでも作ってりゃなぁ
でも実績を見ると典型的な詐欺師だね
テメ、ソフトウェア作ったことあんのかよハゲ
と
でも実績を見ると典型的な詐欺師だね
テメ、ソフトウェア作ったことあんのかよハゲ
と
77仕様書無しさん
2018/05/21(月) 03:27:20.04 嫉妬かな
78仕様書無しさん
2018/05/21(月) 06:15:56.93 >>76
はい、どうぞ、あっちに逝きなさい
技術書の著者がｱﾌﾟﾘを公開してないと信用できない件
https://medaka.5ch.net/test/read.cgi/prog/1526850800/
はい、どうぞ、あっちに逝きなさい
技術書の著者がｱﾌﾟﾘを公開してないと信用できない件
https://medaka.5ch.net/test/read.cgi/prog/1526850800/
79仕様書無しさん
2018/05/22(火) 00:24:18.28 ジャップの財政破綻、早く来い。
俺を笑った奴らが真でいくのを笑い返して復習してやる。
俺を笑った奴らが真でいくのを笑い返して復習してやる。
80仕様書無しさん
2018/05/22(火) 01:50:13.48 隔離スレを用意したとたん静かになったなｗ
82仕様書無しさん
2018/05/22(火) 07:12:59.30 あんなハゲ信仰してるやつは終わってるってことだ
83仕様書無しさん
2018/05/22(火) 07:43:05.81 staticおじさん VS マーチンファウラー
84仕様書無しさん
2018/05/22(火) 07:44:35.35 直接対決してほしい
87仕様書無しさん
2018/05/22(火) 11:16:01.54 とても簡単な自宅で稼げる方法
参考までに書いておきます
グーグルで検索するといいかも『ネットで稼ぐ方法 モニアレフヌノ』
4TTGQ
参考までに書いておきます
グーグルで検索するといいかも『ネットで稼ぐ方法 モニアレフヌノ』
4TTGQ
89仕様書無しさん
2018/05/22(火) 13:59:31.57 age
91仕様書無しさん
2018/05/22(火) 19:54:46.87 コストがかかるとテスト回数を減らすだろ
テストってのは何回もやらなきゃダメなんだよ
1回だけじゃたまたまテスト通っただけかもしれんぞ
これは数学的にも正しいことが証明されてるから国外の大手機械メーカーなどは凄まじい回数のテストを繰り返す
テストってのは何回もやらなきゃダメなんだよ
1回だけじゃたまたまテスト通っただけかもしれんぞ
これは数学的にも正しいことが証明されてるから国外の大手機械メーカーなどは凄まじい回数のテストを繰り返す
92仕様書無しさん
2018/05/23(水) 00:20:00.32 アプリケーションのリファクタリングは実はそんなに重要じゃない
データベースのリファクタリングしろマジで
データベースのリファクタリングしろマジで
93仕様書無しさん
2018/05/23(水) 02:28:17.27 リファクタリングを読みやすくするものだとすると
データベースよりもアプリケーションの方が
よく読む
データベースよりもアプリケーションの方が
よく読む
95仕様書無しさん
2018/05/23(水) 07:46:08.29 不確定要素が無いことを証明できない限り不確定要素が無いからテストは1回でいいとは言えない
そんなことは物理的に不可能なのでテスト回数を増やしてこの程度の確率でなら正常動作を保証しますとしか言えんのだよ
科学的な実験をしたことのある理系ならわかってることだけどね
そんなことは物理的に不可能なのでテスト回数を増やしてこの程度の確率でなら正常動作を保証しますとしか言えんのだよ
科学的な実験をしたことのある理系ならわかってることだけどね
96仕様書無しさん
2018/05/23(水) 16:42:40.82 モンキーテストでもやらんよりマシ
97仕様書無しさん
2018/05/23(水) 21:57:34.51 バグが無いことを証明できないからテストするしかないっていう
98仕様書無しさん
2018/05/24(木) 06:18:17.54 テストしなくちゃいけない
↓
日本凄い
↓
俺凄い
↓
日本凄い
↓
俺凄い
101仕様書無しさん
2018/05/24(木) 18:21:34.59 リファクタリングって・・・
聞いてるこっちが恥ずかしくなるぜ
マー○ンファ○ラーってのは詐欺師のヘビー級チャンピオンの事
お前ら信者がやっているのは過労によるハゲの量産化
技術者は世の中を便利にするために行動しようとするものだが
信者どもはありもしない仕様変更を想定してリファクタリングとか言ってるわけだろ？
リファクタリングとか聞くたびに思ってたのよ
「今回の○○は△△に対応してるのでいくつでも追加可能にしておきました」
これって訳すと「設計書通りに実装しませんでした」
って事だろ
プログラマとか関係なく
世界中の生物を賢い順に並べたら
お前は先頭どころか下から数えた方が早いんじゃねーか？
聞いてるこっちが恥ずかしくなるぜ
マー○ンファ○ラーってのは詐欺師のヘビー級チャンピオンの事
お前ら信者がやっているのは過労によるハゲの量産化
技術者は世の中を便利にするために行動しようとするものだが
信者どもはありもしない仕様変更を想定してリファクタリングとか言ってるわけだろ？
リファクタリングとか聞くたびに思ってたのよ
「今回の○○は△△に対応してるのでいくつでも追加可能にしておきました」
これって訳すと「設計書通りに実装しませんでした」
って事だろ
プログラマとか関係なく
世界中の生物を賢い順に並べたら
お前は先頭どころか下から数えた方が早いんじゃねーか？
102仕様書無しさん
2018/05/24(木) 18:29:34.52 またマーチンファウラーに嫉妬してるのかｗ
104仕様書無しさん
2018/05/24(木) 18:58:55.64105仕様書無しさん
2018/05/24(木) 19:03:36.84 いや、石橋コピペを貼ってみたかっただけ
106仕様書無しさん
2018/05/24(木) 19:18:23.48 ハゲに有能はいない
これが全て
これが全て
107仕様書無しさん
2018/05/24(木) 22:09:06.89 大規模リファクタリングって普通それを作った・大きく関わってきたメンバーが入るもんだよね
108仕様書無しさん
2018/05/24(木) 22:15:25.51 退職してたらどうしようもない
109仕様書無しさん
2018/05/25(金) 07:52:06.62 ノルマこなした上でちゃんとテスト書くならリファクタリングしていいよって言われたから取り組んでるんだが
DB層が腐りきってるからどうにもならんという事に気が付いた
DB層を無視してDB層より上を綺麗にしようたってそうはいかないんだ
ビジネスロジックやプレゼンテーションロジックを大量に含む
テーブルやビューが複雑怪奇に絡まりあって何がどこにあるかさっぱりわからない
理解不能で長大なプロシージャが大量にある
どのアプリケーションがそのDBを参照してるかの資料すら無い
そんな腐りきった巨大な企業データベースをリファクタリングする体系的なテクニックって無いものか
DB層が腐りきってるからどうにもならんという事に気が付いた
DB層を無視してDB層より上を綺麗にしようたってそうはいかないんだ
ビジネスロジックやプレゼンテーションロジックを大量に含む
テーブルやビューが複雑怪奇に絡まりあって何がどこにあるかさっぱりわからない
理解不能で長大なプロシージャが大量にある
どのアプリケーションがそのDBを参照してるかの資料すら無い
そんな腐りきった巨大な企業データベースをリファクタリングする体系的なテクニックって無いものか
110仕様書無しさん
2018/05/25(金) 15:46:30.70 難しい構造なのに無理矢理
簡単（？）な構造に押し込めるから
余計におかしくなってしまうんよ
簡単（？）な構造に押し込めるから
余計におかしくなってしまうんよ
111仕様書無しさん
2018/05/25(金) 19:58:20.08112仕様書無しさん
2018/05/25(金) 20:08:33.77 リファクタの許可がでたら
企業の既存大規模ＤＢの刷新を考えだす新人ｗ
古いのはもういろいろプログラムが紐づいてるから個人で変更は難しい
お前の脳をＤＢに合わせてリファクタしたほうが
将来にわたって絶対楽
https://qiita.com/opengl-8080/items/37beac5e210f5363af4b
企業の既存大規模ＤＢの刷新を考えだす新人ｗ
古いのはもういろいろプログラムが紐づいてるから個人で変更は難しい
お前の脳をＤＢに合わせてリファクタしたほうが
将来にわたって絶対楽
https://qiita.com/opengl-8080/items/37beac5e210f5363af4b
113仕様書無しさん
2018/05/25(金) 20:32:07.11 お前らは何もわかってねえよ
ドメインロジックはおろかプレゼンテーションロジックまでデータベースを侵食しているシステムのヤバさをな
ホストアプリケーションのちょっとした変更がデータベースを破壊する
そんな地獄をたっぷりと味わってから出直してこい
ドメインロジックはおろかプレゼンテーションロジックまでデータベースを侵食しているシステムのヤバさをな
ホストアプリケーションのちょっとした変更がデータベースを破壊する
そんな地獄をたっぷりと味わってから出直してこい
114仕様書無しさん
2018/05/25(金) 20:37:34.69115仕様書無しさん
2018/05/25(金) 20:40:21.58116仕様書無しさん
2018/05/25(金) 20:48:31.82 あ、さわっちゃいかんあいつだったか
117仕様書無しさん
2018/05/26(土) 08:42:29.02 マーチン・ファウラー : 数十年にわたってビジネスへのオブジェクト指向の適用に尽力する独立コンサルタント。
ヘルスケア、金融取引、企業財務などの分野におけるシステムのコンサル経験を持つ。
顧客にはクライスラー、シティバンク、英国民保健サービス、アンダーセン・コンサルティング、
ネットスケープ・コミュニケーションズなどが名を連ねる
ヘルスケア、金融取引、企業財務などの分野におけるシステムのコンサル経験を持つ。
顧客にはクライスラー、シティバンク、英国民保健サービス、アンダーセン・コンサルティング、
ネットスケープ・コミュニケーションズなどが名を連ねる
118仕様書無しさん
2018/05/26(土) 08:56:33.31 すごい実績だな
そんなファウラーが言うなら間違いない
JavaScriptのリファクタリング本楽しみ
そんなファウラーが言うなら間違いない
JavaScriptのリファクタリング本楽しみ
119仕様書無しさん
2018/05/26(土) 10:14:39.33 その人のリファクタリング本持ってるけど
そんなに目から鱗なこと書いてあるか？って思ったけどな
そんなに目から鱗なこと書いてあるか？って思ったけどな
120仕様書無しさん
2018/05/26(土) 10:16:13.77 今や常識だからな
地球が太陽の周りを回っているのだって現代人に行ってもなにを今更ってなるじゃん？
それと同じ
でも常識を定着させるのって大変なんだぜ
地球が太陽の周りを回っているのだって現代人に行ってもなにを今更ってなるじゃん？
それと同じ
でも常識を定着させるのって大変なんだぜ
121仕様書無しさん
2018/05/26(土) 11:46:44.27 で？何作った人なの？
122仕様書無しさん
2018/05/26(土) 13:14:13.69 アルゴリズムを考える人より
アルゴリズムを特定の言語で実装するほうが
偉いに決まってるだろ
アルゴリズムを特定の言語で実装するほうが
偉いに決まってるだろ
123仕様書無しさん
2018/05/26(土) 14:06:22.69 だから給料上げろ
124仕様書無しさん
2018/05/26(土) 14:15:06.90 給料あげたいなら転職ですよ
125仕様書無しさん
2018/05/26(土) 14:50:11.14 マーチンファウラーはRailsのActiveRecordの基本を考えただけ
それを実装したRailsの開発者のほうがすごい
そのActiveRecordを使いこなしている俺のほうがもっとすごい
やつはリファクタリングを考え出しただけ
使いこなしている俺のほうがもっとすごい
それを実装したRailsの開発者のほうがすごい
そのActiveRecordを使いこなしている俺のほうがもっとすごい
やつはリファクタリングを考え出しただけ
使いこなしている俺のほうがもっとすごい
126仕様書無しさん
2018/05/26(土) 15:01:45.54 使うだけの人は他にも大勢いるので
127仕様書無しさん
2018/05/26(土) 15:17:50.89 で？何作った人なの？
128仕様書無しさん
2018/05/26(土) 16:14:47.09 マーチンファウラーはRailsのActiveRecordの基本を考えただけ
それを実装したRailsの開発者のほうがすごい
そのActiveRecordを使いこなしている俺のほうがもっとすごい
やつはリファクタリングを考え出しただけ
使いこなしている俺のほうがもっとすごい
それを実装したRailsの開発者のほうがすごい
そのActiveRecordを使いこなしている俺のほうがもっとすごい
やつはリファクタリングを考え出しただけ
使いこなしている俺のほうがもっとすごい
129仕様書無しさん
2018/05/27(日) 09:23:12.38 バカでも使えるようにしてくれているだけ
130仕様書無しさん
2018/05/29(火) 13:38:17.98 >>128
サービス使うだけのオレの方がもっとすごい
サービス使うだけのオレの方がもっとすごい
131仕様書無しさん
2018/05/29(火) 20:26:06.70 丸投げしているオレの方がもっとすごい
132仕様書無しさん
2018/05/29(火) 21:31:16.12 普通に考えて丸投げされてる方がすごいやんコーダーさん
135仕様書無しさん
2018/05/31(木) 06:56:15.54 本当に頑張っても問題が解決できないなら
その頑張りが問題を解決できない原因です。
その頑張りが問題を解決できない原因です。
136仕様書無しさん
2018/05/31(木) 07:09:12.81137仕様書無しさん
2018/06/01(金) 21:41:56.20 リファクタ厨はマーチンファウラーのハゲがバレて逃げちゃったんだろ？
139仕様書無しさん
2018/06/02(土) 03:08:10.24 まさか、あのマー○ンファ○ラーがハゲとか誰も予想だにしなかったよね
140仕様書無しさん
2018/06/02(土) 06:24:28.62 ハゲのジョブズは早死したしな
141仕様書無しさん
2018/06/02(土) 09:26:01.58 ハゲに嫉妬
142仕様書無しさん
2018/06/02(土) 19:00:26.84 ハゲに人権なし
143仕様書無しさん
2018/06/05(火) 10:16:30.55 リファクタリング出来る環境なら、テストも自動化されてるはずだよな？
まさか手作業でリファクタリングしてるとか？
まさか手作業でリファクタリングしてるとか？
144仕様書無しさん
2018/06/05(火) 11:27:38.12 訂正 まさか手作業でテストしてるとか？
145仕様書無しさん
2018/06/05(火) 11:28:09.65 手作業でテストしている所が
リファクタリングに文句つけてるんだろうね
リファクタリングに文句つけてるんだろうね
146仕様書無しさん
2018/06/05(火) 13:35:11.08 テストがないとリファクタリングできない
リファクタリングしないとテストが整備できない
はい終わり
リファクタリングは机上の空論
リファクタリングしないとテストが整備できない
はい終わり
リファクタリングは机上の空論
147仕様書無しさん
2018/06/05(火) 13:46:40.92 最近のビジュアルスタジオって、そここっちのコードの方が良いよって言って来るよな？
148仕様書無しさん
2018/06/05(火) 13:59:43.66149仕様書無しさん
2018/06/05(火) 14:08:09.27154仕様書無しさん
2018/06/05(火) 18:34:36.43 動けばいいんやで、あとのことは知らん
155仕様書無しさん
2018/06/05(火) 20:48:21.55 リファクタリング（筋肉）
156仕様書無しさん
2018/06/05(火) 21:18:58.78 テスト（手動）
157仕様書無しさん
2018/06/05(火) 22:18:12.30 コードレビューとかうざすぎる
うごきゃいんだよ動きゃ
汎用性なんか知るか
全部コードベタ書きにしてやるわ
うごきゃいんだよ動きゃ
汎用性なんか知るか
全部コードベタ書きにしてやるわ
159仕様書無しさん
2018/06/05(火) 22:32:45.94 と自分で言えない所がだめだよねｗ
160仕様書無しさん
2018/06/05(火) 23:05:18.43 綺麗なコードを書いてリファクタリングを繰り返したほうが楽に動くコードを維持できると思うんだが
161仕様書無しさん
2018/06/05(火) 23:06:29.62 動かすだけなら汚くてもいい
綺麗に書いたら時間がかかるって前提がまず狂ってる
綺麗に書いたら時間がかかるって前提がまず狂ってる
162仕様書無しさん
2018/06/05(火) 23:08:28.75 汚いコードを書いてリファクタリングしたら時間かかったが？
163仕様書無しさん
2018/06/05(火) 23:11:55.06 それは汚いままだともっと時間がかかってたんだよ
リファクタリングしたことによって被害が最小化した
リファクタリングしたことによって被害が最小化した
164仕様書無しさん
2018/06/05(火) 23:22:14.30 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
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 上のコードなら3分で書ける
コードもシンプルで誰が見てもわかりやすい
リポジトリやらドメインサービスやらおバカなことをやりだすとクラスが一気に増えて意味不明になる
コーディング時間も10倍じゃ足らんくなる
世間一般で言う綺麗なコードを書くのは実は非合理的なんやな
コンサルさんはそれでお金貰っとるから綺麗に書かなアカンって洗脳しようと企んどるようやけど騙されへんで
コードもシンプルで誰が見てもわかりやすい
リポジトリやらドメインサービスやらおバカなことをやりだすとクラスが一気に増えて意味不明になる
コーディング時間も10倍じゃ足らんくなる
世間一般で言う綺麗なコードを書くのは実は非合理的なんやな
コンサルさんはそれでお金貰っとるから綺麗に書かなアカンって洗脳しようと企んどるようやけど騙されへんで
166仕様書無しさん
2018/06/05(火) 23:29:33.18 おもちゃ屋さんはそれでいと思うよ
167仕様書無しさん
2018/06/05(火) 23:29:45.86 このように、たったこれだけのコードが
自分が作っているものの全てだと
言ってるような人の浅い考えなのです
自分が作っているものの全てだと
言ってるような人の浅い考えなのです
168仕様書無しさん
2018/06/05(火) 23:32:10.27 なんや論理的反論できひんなら素直にそう言いや
負け惜しみはみっともないで
負け惜しみはみっともないで
169仕様書無しさん
2018/06/05(火) 23:38:18.13 悔しかったら、自分が普段どれだけのコードを書いてるのか言ってみいや
100行か？ 1000行か？
100行か？ 1000行か？
170仕様書無しさん
2018/06/05(火) 23:40:00.55 普段1万行とか普通に書いてる人間に
たった10行のコード持ってきて
ほら、この場合はいらないでしょ？と言われてもな（苦笑）
たった10行のコード持ってきて
ほら、この場合はいらないでしょ？と言われてもな（苦笑）
171仕様書無しさん
2018/06/05(火) 23:45:13.51 上のコードなら3分で書けるといっただろ？
10行で3分なら、100行で30分、1000行で300分
1万行でも3000分だ。50時間、2日あればできる量だ
いちいちリファクタリングする意味はない
10行で3分なら、100行で30分、1000行で300分
1万行でも3000分だ。50時間、2日あればできる量だ
いちいちリファクタリングする意味はない
172仕様書無しさん
2018/06/05(火) 23:45:54.47 リポジトリやらドメインサービスやらくだらない余計なクラスを書くから何万行も無駄なステップ数が生じるんやで
173仕様書無しさん
2018/06/06(水) 01:34:19.28 c#のインターフェース機能が百害あって一利無しだ
175仕様書無しさん
2018/06/06(水) 01:53:52.81 俺様に理解できないから邪魔
176仕様書無しさん
2018/06/06(水) 08:14:52.01179仕様書無しさん
2018/06/06(水) 12:21:34.08 設計者が何のためにインターフェース切って疎結合にしたのかわかってないのでは？
インターフェースの先まで見に行かないとクライアントを保守できないとしたら
それは設計が間違ってるからインターフェースを超えて結合しちゃってるんだよ
インターフェースの先まで見に行かないとクライアントを保守できないとしたら
それは設計が間違ってるからインターフェースを超えて結合しちゃってるんだよ
180仕様書無しさん
2018/06/06(水) 12:23:37.73 動かせないってのも何言ってんだかって感じだね
モックを書くって発想がないのかな？
ユニットテストしてないの？
ユニットテストは個別に動かすこともできるよ
モックを書くって発想がないのかな？
ユニットテストしてないの？
ユニットテストは個別に動かすこともできるよ
184仕様書無しさん
2018/06/06(水) 13:00:12.33185仕様書無しさん
2018/06/06(水) 13:30:39.28 >>179
リリースした後のバグっていうのは通常アプリケーションを
使っているときに見つかるんだわ
○○という設定でボタンをクリックしたときとか
で、実際のバグはそのクリックを行って実行する処理の
どこかのモジュールに存在する。
その時、インターフェースの先を見ないでバグのある箇所を
見つけることはできないよ。だってインターフェースの先に
バグがあるんだから
リリースした後のバグっていうのは通常アプリケーションを
使っているときに見つかるんだわ
○○という設定でボタンをクリックしたときとか
で、実際のバグはそのクリックを行って実行する処理の
どこかのモジュールに存在する。
その時、インターフェースの先を見ないでバグのある箇所を
見つけることはできないよ。だってインターフェースの先に
バグがあるんだから
186仕様書無しさん
2018/06/06(水) 13:33:57.19 >>182
モックはなるべく書かないほうが良い。
なぜならモックはOKだけど、実際のアプリでは
バグになることがあるから
なお、インターフェースはモックにすり替えるためにあるのではなく
同じインターフェースを持つ複数のモジュールを使うためにある
テストを用意にするためでも疎結合にするためでもない
モックはなるべく書かないほうが良い。
なぜならモックはOKだけど、実際のアプリでは
バグになることがあるから
なお、インターフェースはモックにすり替えるためにあるのではなく
同じインターフェースを持つ複数のモジュールを使うためにある
テストを用意にするためでも疎結合にするためでもない
187仕様書無しさん
2018/06/06(水) 13:38:25.16 c#のinterfaceでソースが追えないってのは、そもそも追い方からして間違ってる気がする
追加や保守なら何も考えずに呼び出し履歴追って修正に対する影響範囲調べりゃいいだけだし、それでクラス設計やデザインパターン機構の根っこを弄らんといけないなら、大改修だろ。
そもそも別の手がないか考えろよってのもある
追加や保守なら何も考えずに呼び出し履歴追って修正に対する影響範囲調べりゃいいだけだし、それでクラス設計やデザインパターン機構の根っこを弄らんといけないなら、大改修だろ。
そもそも別の手がないか考えろよってのもある
188仕様書無しさん
2018/06/06(水) 13:57:01.37 修正に対する影響範囲調べて
それでどうやって最初から存在するバグを見つけられるの？
それでどうやって最初から存在するバグを見つけられるの？
189仕様書無しさん
2018/06/06(水) 15:30:27.75 どんなクソコードも解読して作り直すみたいな
特殊能力持った奴も中にはいるのかな
特殊能力持った奴も中にはいるのかな
191仕様書無しさん
2018/06/06(水) 19:46:21.82 最低限ユニットテストしておけよってことじゃないのか
192仕様書無しさん
2018/06/06(水) 21:42:22.41 え、実装に飛べないやつとかいるのかよ…
193仕様書無しさん
2018/06/06(水) 21:47:01.50 ﾊ_ﾊ _
∩ﾟ∀ﾟ)ﾉ 飛べるよ！
） /
(_ﾉ_ﾉ
彡
.
_,,..-―'"⌒"~￣"~⌒ﾞﾞ"'''ｮ
ﾞ~,,,....-=-‐√"ﾞﾞＴ"~￣Y"ﾞ=ﾐ
Ｔ | l,＿,,/＼ ,,/l |
,.-r '"l＼,,j / |/ L,,,/
,,/|,／＼,/ _,|＼_,i_,,,/ ／
_V＼ ,,/＼,| ,,∧,,|_/
∩ﾟ∀ﾟ)ﾉ 飛べるよ！
） /
(_ﾉ_ﾉ
彡
.
_,,..-―'"⌒"~￣"~⌒ﾞﾞ"'''ｮ
ﾞ~,,,....-=-‐√"ﾞﾞＴ"~￣Y"ﾞ=ﾐ
Ｔ | l,＿,,/＼ ,,/l |
,.-r '"l＼,,j / |/ L,,,/
,,/|,／＼,/ _,|＼_,i_,,,/ ／
_V＼ ,,/＼,| ,,∧,,|_/
195仕様書無しさん
2018/06/06(水) 22:33:07.03 ポケモン
デジモン
やれるもん
ヤダモン
ドラえもん
やれるもん
デジモン
やれるもん
ヤダモン
ドラえもん
やれるもん
196仕様書無しさん
2018/06/06(水) 23:01:14.34 設計書の段階でリプレースしてえ
日本のSEさん設計能力低すぎてアーキテクチャすら定まってない
日本のSEさん設計能力低すぎてアーキテクチャすら定まってない
197仕様書無しさん
2018/06/06(水) 23:37:14.88 >>187
うまくいってる間はいいけど
発生率の低いバグが出たときに
インターフェースは死ぬ
動かしてみないと何が生成されてるのかわからないうえに
影響範囲はインターフェースをもつクラス全部になる
一つ一つ可能性を排除していく作業を行わなければならない
うまくいってる間はいいけど
発生率の低いバグが出たときに
インターフェースは死ぬ
動かしてみないと何が生成されてるのかわからないうえに
影響範囲はインターフェースをもつクラス全部になる
一つ一つ可能性を排除していく作業を行わなければならない
199仕様書無しさん
2018/06/07(木) 07:11:25.09201仕様書無しさん
2018/06/07(木) 07:25:37.92 どうせまだVS2005とか使ってんだろ
202仕様書無しさん
2018/06/07(木) 07:37:35.21 キチガイに触るな
203仕様書無しさん
2018/06/07(木) 08:02:26.43 反論が無いなら俺の勝ちだぞ
204仕様書無しさん
2018/06/07(木) 08:03:21.80 右クリックに過剰な夢を見すぎてる
205仕様書無しさん
2018/06/07(木) 08:21:56.25 本当にインターフェイスから実装に飛べないやつなんているのかよ…
206仕様書無しさん
2018/06/07(木) 08:50:14.99 visualstudio使ったことないんじゃね？
207KAC
2018/06/07(木) 10:42:30.32 コード読む力が無いだけかと
210仕様書無しさん
2018/06/07(木) 19:45:28.92 インターフェースの契約をテストするコードを書いて実装クラス全部についてテスト実行するだけだろ
それでオールグリーンならインターフェースの先がなんだろうと関係ない
バグはクライアントクラスにあるとわかる
もちろんレッドが出たらインターフェースのどの実装クラスが犯人か即座にわかる
それでオールグリーンならインターフェースの先がなんだろうと関係ない
バグはクライアントクラスにあるとわかる
もちろんレッドが出たらインターフェースのどの実装クラスが犯人か即座にわかる
211仕様書無しさん
2018/06/07(木) 19:54:58.72 >>210
テストでバグがないことが証明できるなら
そうだろうな。
実際はテストはバグを見つけることはできても
バグがないことの証明にはならない。
いくらインターフェースの契約をテストするコードを書いても
そこにバグがないことにはならないんだよ
結局バグを見つけるために、インターフェースの呼び出し側が悪いのか
呼び出し先が悪いのか、特定の実装クラスだけで起こる問題なのか
探し回る必要がある
テストでバグがないことが証明できるなら
そうだろうな。
実際はテストはバグを見つけることはできても
バグがないことの証明にはならない。
いくらインターフェースの契約をテストするコードを書いても
そこにバグがないことにはならないんだよ
結局バグを見つけるために、インターフェースの呼び出し側が悪いのか
呼び出し先が悪いのか、特定の実装クラスだけで起こる問題なのか
探し回る必要がある
213仕様書無しさん
2018/06/07(木) 20:33:15.96 >>211
なるよ
それが契約というものなんだよ
契約はそうあれと定められたものだからね
どんなにおかしい動きをしていても契約どおりならインターフェース実装クラスはバグではない
そのおかしな動きに対応していないクライアントクラスがバグってこと
逆に対応してるのにおかしいならインターフェース実装クラスが契約に違反したバグクラスってこと
契約そのものが矛盾してるってこともあるけどそれは契約が間違っているわけではなく
すべてのインターフェース実装クラスが間違っているということになる
それはそれで赤信号が出まくるからすぐにわかる
バグではないが役に立たない矛盾した契約を解消しようってことになるね
なるよ
それが契約というものなんだよ
契約はそうあれと定められたものだからね
どんなにおかしい動きをしていても契約どおりならインターフェース実装クラスはバグではない
そのおかしな動きに対応していないクライアントクラスがバグってこと
逆に対応してるのにおかしいならインターフェース実装クラスが契約に違反したバグクラスってこと
契約そのものが矛盾してるってこともあるけどそれは契約が間違っているわけではなく
すべてのインターフェース実装クラスが間違っているということになる
それはそれで赤信号が出まくるからすぐにわかる
バグではないが役に立たない矛盾した契約を解消しようってことになるね
214仕様書無しさん
2018/06/07(木) 20:36:53.10 ちなみにその矛盾した契約ってのはバグよりも遥かに発生しにくい
契約は実装よりもずっとシンプルだからね
なのでほぼすべてのケースで契約をテストするだけでクライアント側かインターフェース実装側のどちらかが悪いか決着がつく
契約は実装よりもずっとシンプルだからね
なのでほぼすべてのケースで契約をテストするだけでクライアント側かインターフェース実装側のどちらかが悪いか決着がつく
215仕様書無しさん
2018/06/07(木) 20:38:41.72216仕様書無しさん
2018/06/07(木) 20:47:13.17 人間はミスする
故に人間が作ったものに完璧はない。
「契約」が人間が作ったものであれば
完璧なものは存在しないのでバグない証明にはならない
故に人間が作ったものに完璧はない。
「契約」が人間が作ったものであれば
完璧なものは存在しないのでバグない証明にはならない
219仕様書無しさん
2018/06/07(木) 23:01:28.40 インターフェースに間違いって言われてもなぁ？
本当は200Vが欲しいんだけど
家庭用に普及してるのは100Vなんだよね
これがインターフェースの本質だろ
みんなで使うためにとりあえず1つの型にハメる
そこにベストは存在しねーんだよ
それでも型を作ることにメリットがあるとしたときに初めて威力を発揮する仕組みがインターフェースだろ
ぶっちゃけオーダーメイドのビジネスアプリにこんなもん適用してる奴
頭が悪いだろ
本当は200Vが欲しいんだけど
家庭用に普及してるのは100Vなんだよね
これがインターフェースの本質だろ
みんなで使うためにとりあえず1つの型にハメる
そこにベストは存在しねーんだよ
それでも型を作ることにメリットがあるとしたときに初めて威力を発揮する仕組みがインターフェースだろ
ぶっちゃけオーダーメイドのビジネスアプリにこんなもん適用してる奴
頭が悪いだろ
220仕様書無しさん
2018/06/07(木) 23:54:14.02 バグってるインターフェースは存在しない
嘘だと思うなら何か例を挙げてみな
絶対の不可能だから
嘘だと思うなら何か例を挙げてみな
絶対の不可能だから
222仕様書無しさん
2018/06/08(金) 00:31:57.52 >>220
論点がおかしい。
いくらテストしても、バグがないことは証明できず
いざバグが発生したとなったときに、
インターフェースの呼び出し側に問題があるか
呼び出し先にあるのかわからないから
インターフェースの先まで調べないといけないって話だろ
論点がおかしい。
いくらテストしても、バグがないことは証明できず
いざバグが発生したとなったときに、
インターフェースの呼び出し側に問題があるか
呼び出し先にあるのかわからないから
インターフェースの先まで調べないといけないって話だろ
224仕様書無しさん
2018/06/08(金) 00:38:28.31 そしてそれは規約をテストすればすぐにわかる
225仕様書無しさん
2018/06/08(金) 01:42:03.55 >>224
頭悪いのかな？
バグっていうのは特定の場合のテストを
してない（正しく行われてない）から発生するんだよ
バグが後から発覚することからもわかるように
そりゃテストすればわかるが、
テストしてないって状況が存在する
テストしてない場合にどうやってわかるの？
頭悪いのかな？
バグっていうのは特定の場合のテストを
してない（正しく行われてない）から発生するんだよ
バグが後から発覚することからもわかるように
そりゃテストすればわかるが、
テストしてないって状況が存在する
テストしてない場合にどうやってわかるの？
227仕様書無しさん
2018/06/08(金) 06:25:46.17 プロフェッショナルならログを取ろう
スタックトレースを見れば実行時型はすぐわかる
インターフェースへのIOをログして仕様通りか確認すれば即座に具象クラスのバグかどうかわかる
具象クラスのバグじゃなければモックでIOを再現すれば新しいテストケースになる
どんなバグも定数時間で解ける
スタックトレースを見れば実行時型はすぐわかる
インターフェースへのIOをログして仕様通りか確認すれば即座に具象クラスのバグかどうかわかる
具象クラスのバグじゃなければモックでIOを再現すれば新しいテストケースになる
どんなバグも定数時間で解ける
228仕様書無しさん
2018/06/08(金) 07:24:46.93 無理だな
ゲームでよくあるごった煮リストだろ？
上履きとか黒板消しも鍋に入ってるし
ゲームでよくあるごった煮リストだろ？
上履きとか黒板消しも鍋に入ってるし
230仕様書無しさん
2018/06/08(金) 08:20:12.44 テストすればバグを無くせると
いう、壮大な勘違い。
いう、壮大な勘違い。
232仕様書無しさん
2018/06/08(金) 13:27:08.92 実行しなければバグもクソもないので問題なし
233仕様書無しさん
2018/06/08(金) 13:41:45.35 額に入れて飾っておくのか？
234仕様書無しさん
2018/06/08(金) 19:08:52.90 ソース見てもわからないソースにしたわけだ
実行しないとわからないクソソースって理解できた？
実行しないとわからないクソソースって理解できた？
235仕様書無しさん
2018/06/08(金) 19:27:53.99 ソース見れば分かるよ
236仕様書無しさん
2018/06/08(金) 23:00:48.32 >>235
全部見ればなｗ
インターフェースは呪いだ
こいつを通すと問答無用で全部読まなければならなくなる
普通は不具合がでてもいいように影響範囲を絞るように組むものだが
こいつは同じインターフェースを使う奴全員を問答無用で容疑者にする
プロジェクトを破綻させたいならオススメの手法
全部見ればなｗ
インターフェースは呪いだ
こいつを通すと問答無用で全部読まなければならなくなる
普通は不具合がでてもいいように影響範囲を絞るように組むものだが
こいつは同じインターフェースを使う奴全員を問答無用で容疑者にする
プロジェクトを破綻させたいならオススメの手法
237仕様書無しさん
2018/06/08(金) 23:02:35.01 ソース見ればわかるよ
インターフェースが使われていると大変だけど
インターフェースが使われていると大変だけど
238仕様書無しさん
2018/06/09(土) 00:33:43.99240仕様書無しさん
2018/06/09(土) 09:01:03.39 そもそも違いを知らなくていいように自分でしたのに特定なんかできるわけないじゃん
自分が何をやってるのかわかってる？
君が作ってるのはごった煮リストって言われる闇鍋
自分が何をやってるのかわかってる？
君が作ってるのはごった煮リストって言われる闇鍋
241仕様書無しさん
2018/06/09(土) 10:32:37.55 例えばインターフェースが以下のようなものだったとしよう
interface Foo {
void method1();
void method2(int i);
}
この時、インターフェースを守っていなければ、
呼び出し側にバグがあるし
インターフェースを守っていれば、
呼び出し先にバグがある
プログラムでバグが発生したら、Fooのインターフェース
具体的には、method1を引数無しで呼び出しているか？
method2をint引数一つで呼び出しているか？
を確認すれば良い。
このインターフェースを守っていれば、呼び出し側にはバグはなく
呼び出し先にバグが有るということだ
interface Foo {
void method1();
void method2(int i);
}
この時、インターフェースを守っていなければ、
呼び出し側にバグがあるし
インターフェースを守っていれば、
呼び出し先にバグがある
プログラムでバグが発生したら、Fooのインターフェース
具体的には、method1を引数無しで呼び出しているか？
method2をint引数一つで呼び出しているか？
を確認すれば良い。
このインターフェースを守っていれば、呼び出し側にはバグはなく
呼び出し先にバグが有るということだ
242仕様書無しさん
2018/06/09(土) 10:33:15.97 インターフェースの先がどうなってるかは気にしなくていい
気にしなければならないなら設計ミス
気にしなければならないなら設計ミス
243仕様書無しさん
2018/06/09(土) 10:41:45.13 呼び出し先にバグがあるなら、呼び出し先を見ないといけない
↓
どうやって呼び出し先を特定するの？
が疑問らしいよ。騒いでいる人は。
↓
どうやって呼び出し先を特定するの？
が疑問らしいよ。騒いでいる人は。
248仕様書無しさん
2018/06/09(土) 11:18:16.03 DIコンテナにインターフェースの実装クラスは
これを使いますって書くじゃんすぐ分かるじゃん
これを使いますって書くじゃんすぐ分かるじゃん
251仕様書無しさん
2018/06/09(土) 11:36:59.79252仕様書無しさん
2018/06/09(土) 11:41:27.66 >>248
だからみんな99%のインターフェースは問題なしって認識で納得してるよ
実行時にダイナミックに型が変わる場合に限ってバグを出した型の特定が難しいからインターフェースはダメなんじゃないかと議論してるところ
だからみんな99%のインターフェースは問題なしって認識で納得してるよ
実行時にダイナミックに型が変わる場合に限ってバグを出した型の特定が難しいからインターフェースはダメなんじゃないかと議論してるところ
254仕様書無しさん
2018/06/09(土) 11:51:44.90 switch (kubun) {
case Kubum.Hoge:
// super long code
break;
case Kubun.Fuga:
// super long code
break;
case ...
}
インターフェース(あるいは抽象クラス)を使わないとなると
代わりにこういう異常なボリュームの分岐がアッチコッチに大量発生する
実行するまで分岐条件が決まらないからどの分岐を追いかければいいかわからない
実行しないでソーストレースするなら全ての分岐を見なければならない
それってインターフェース否定派の言ってることと同じだよね
しかも分岐バージョンの方はインターフェースや抽象クラスと違って各バリエーションがバラバラに引きちぎられてプログラム全体に散らばってるからトレースが死ぬほど大変
case Kubum.Hoge:
// super long code
break;
case Kubun.Fuga:
// super long code
break;
case ...
}
インターフェース(あるいは抽象クラス)を使わないとなると
代わりにこういう異常なボリュームの分岐がアッチコッチに大量発生する
実行するまで分岐条件が決まらないからどの分岐を追いかければいいかわからない
実行しないでソーストレースするなら全ての分岐を見なければならない
それってインターフェース否定派の言ってることと同じだよね
しかも分岐バージョンの方はインターフェースや抽象クラスと違って各バリエーションがバラバラに引きちぎられてプログラム全体に散らばってるからトレースが死ぬほど大変
255仕様書無しさん
2018/06/09(土) 11:55:23.51256仕様書無しさん
2018/06/09(土) 12:09:55.53 >>255
インターフェースや抽象クラスに分離するほどのものでない小さく局所的な条件分岐ならコードを見ればいい
でも今はインターフェースや抽象との対比としての条件分岐を話題にしてる
その場合の条件分岐はとてもじゃないけどコードを追いかける気にはならないね
インターフェースや抽象クラスに分離するほどのものでない小さく局所的な条件分岐ならコードを見ればいい
でも今はインターフェースや抽象との対比としての条件分岐を話題にしてる
その場合の条件分岐はとてもじゃないけどコードを追いかける気にはならないね
257仕様書無しさん
2018/06/09(土) 12:10:22.15 >>254
だからさ
それは必要なコードじゃねーの？
バグったときにバグった箇所もわからないようなコードのどこがいいの？
極論を言うとプログラムなんて代入と四則演算と条件分岐を繰り返してるだけなので
それ以外は無駄な手間って言うならクラスも関数もいらねーよ
だからさ
それは必要なコードじゃねーの？
バグったときにバグった箇所もわからないようなコードのどこがいいの？
極論を言うとプログラムなんて代入と四則演算と条件分岐を繰り返してるだけなので
それ以外は無駄な手間って言うならクラスも関数もいらねーよ
258仕様書無しさん
2018/06/09(土) 12:10:35.07 例えばインターフェースが以下のようなものだったとしよう
interface Foo {
void method1();
void method2(int i);
}
この時、インターフェースを守っていなければ、
呼び出し側にバグがあるし
インターフェースを守っていれば、
呼び出し先にバグがある
プログラムでバグが発生したら、Fooのインターフェース
具体的には、method1を引数無しで呼び出しているか？
method2をint引数一つで呼び出しているか？
を確認すれば良い。
このインターフェースを守っていれば、呼び出し側にはバグはなく
呼び出し先にバグが有るということだ
interface Foo {
void method1();
void method2(int i);
}
この時、インターフェースを守っていなければ、
呼び出し側にバグがあるし
インターフェースを守っていれば、
呼び出し先にバグがある
プログラムでバグが発生したら、Fooのインターフェース
具体的には、method1を引数無しで呼び出しているか？
method2をint引数一つで呼び出しているか？
を確認すれば良い。
このインターフェースを守っていれば、呼び出し側にはバグはなく
呼び出し先にバグが有るということだ
259仕様書無しさん
2018/06/09(土) 12:11:38.98264仕様書無しさん
2018/06/09(土) 12:26:30.23265仕様書無しさん
2018/06/09(土) 12:31:38.30 >>257
だからインターフェースや抽象クラスに対応する条件分岐はバグった時にバグった箇所もわからないクソコードなんだよ
インターフェースや抽象クラスを使えば原因の切り分け、再現コード(テストケース)の作成、詳細の分析、修正の妥当性確認(テスト)まで高速で実行できる
対応する条件分岐では不可能
だからインターフェースや抽象クラスに対応する条件分岐はバグった時にバグった箇所もわからないクソコードなんだよ
インターフェースや抽象クラスを使えば原因の切り分け、再現コード(テストケース)の作成、詳細の分析、修正の妥当性確認(テスト)まで高速で実行できる
対応する条件分岐では不可能
266仕様書無しさん
2018/06/09(土) 12:34:52.93268仕様書無しさん
2018/06/09(土) 12:40:51.75 やっぱりパソコンのたとえがわかりやすい
インターフェース使わない派は
メモリが壊れたらパソコンが壊れたものとしてパソコン全体を修理に出すしかない
パソコンとして結合してないとテストできないからどこが壊れたかもわからないのでぼったくられる
ひどい時は修理代が馬鹿にならんならいっそパソコン買い替えちゃうかともったいないことを言い出す
そそてメモリだけを高性能なものに替えたい場合でもパソコンを買い換えるしかない
インターフェース使う派は
メモリが壊れたらパソコンの部品を個別にテストしてメモリが壊れてると判断できる
メモリだけ買い替えればいいので最小限のコストでパソコンが復活する
メモリだけを高性能なものに替えたい場合は文字通りメモリだけを取り替えればいい
インターフェース使わない派は
メモリが壊れたらパソコンが壊れたものとしてパソコン全体を修理に出すしかない
パソコンとして結合してないとテストできないからどこが壊れたかもわからないのでぼったくられる
ひどい時は修理代が馬鹿にならんならいっそパソコン買い替えちゃうかともったいないことを言い出す
そそてメモリだけを高性能なものに替えたい場合でもパソコンを買い換えるしかない
インターフェース使う派は
メモリが壊れたらパソコンの部品を個別にテストしてメモリが壊れてると判断できる
メモリだけ買い替えればいいので最小限のコストでパソコンが復活する
メモリだけを高性能なものに替えたい場合は文字通りメモリだけを取り替えればいい
271仕様書無しさん
2018/06/09(土) 12:43:53.01 インターフェースの先はバグらない世界に書き換えておいた
273仕様書無しさん
2018/06/09(土) 12:53:38.99 >>268
> インターフェース使わない派は
> メモリが壊れたらパソコンが壊れたものとしてパソコン全体を修理に出すしかない
その方がいい場合もあるよね？
例えばパソコンが動かない！どこが壊れたんだ？ってなった時
パソコンに詳しくない人はメモリかどうかを切り分けられない
どうせ切り分けないんだから、丸ごとメーカーに出したほうが良いし
メーカーも丸ごと交換したほうが安くて早い
それほど人件費は高い
> インターフェース使わない派は
> メモリが壊れたらパソコンが壊れたものとしてパソコン全体を修理に出すしかない
その方がいい場合もあるよね？
例えばパソコンが動かない！どこが壊れたんだ？ってなった時
パソコンに詳しくない人はメモリかどうかを切り分けられない
どうせ切り分けないんだから、丸ごとメーカーに出したほうが良いし
メーカーも丸ごと交換したほうが安くて早い
それほど人件費は高い
275仕様書無しさん
2018/06/09(土) 12:58:24.48 普通ダイナミックライブラリにして複数のアプリ間で共通に使うものを定義するのに使うよな？
276仕様書無しさん
2018/06/09(土) 12:59:27.73 >>274
バグをなおすこととインターフェースになんの関係があんの？
インターフェースを使っていようがいまいが、
バグの原因は一緒だろ
インターフェースを使わないからって
システムリプレースになるわけじゃない
バグをなおすこととインターフェースになんの関係があんの？
インターフェースを使っていようがいまいが、
バグの原因は一緒だろ
インターフェースを使わないからって
システムリプレースになるわけじゃない
278仕様書無しさん
2018/06/09(土) 13:34:30.55280仕様書無しさん
2018/06/09(土) 13:59:19.10 実行しないと原因わからんから糞って意見があるが、どんなソースでもログ仕込んだりしつつ実行するのが手っ取り早いだろとか思う。
んで、実行できないんだよボケとか言ってる奴らは、正にテスト出来ないソースを量産してる奴らってことだよな
んで、実行できないんだよボケとか言ってる奴らは、正にテスト出来ないソースを量産してる奴らってことだよな
281仕様書無しさん
2018/06/09(土) 14:11:48.87 >>278
依存先を直に参照、インスタンス化すると親に埋め込まれてしまう
これは依存先にバグがあると親もバグがあるということな
再起的にあらゆるクラスが異常となる
インターフェースで依存を切っておけばそうならない
依存先を直に参照、インスタンス化すると親に埋め込まれてしまう
これは依存先にバグがあると親もバグがあるということな
再起的にあらゆるクラスが異常となる
インターフェースで依存を切っておけばそうならない
282仕様書無しさん
2018/06/09(土) 14:14:54.36283仕様書無しさん
2018/06/09(土) 14:19:17.39 だからdllにして切り離せってのは、インターフェース介した作りかどうかと直接関係無いよな？
284仕様書無しさん
2018/06/09(土) 14:22:57.91 >>281
> 依存先を直に参照、インスタンス化すると親に埋め込まれてしまう
> これは依存先にバグがあると親もバグがあるということな
意味が全くわからん
依存先にバグが有って、親にはバグがない
依存ざきにバグはなくて、親にはバグが有る
両方にバグが有る
どれの可能性も存在するが、
インターフェースに洗脳されているお前は
その可能性が思いつかないって話？
銀の弾丸はないんだよ？
インターフェースを使ったらバグがないとか
はは、ありえないｗｗ
> 依存先を直に参照、インスタンス化すると親に埋め込まれてしまう
> これは依存先にバグがあると親もバグがあるということな
意味が全くわからん
依存先にバグが有って、親にはバグがない
依存ざきにバグはなくて、親にはバグが有る
両方にバグが有る
どれの可能性も存在するが、
インターフェースに洗脳されているお前は
その可能性が思いつかないって話？
銀の弾丸はないんだよ？
インターフェースを使ったらバグがないとか
はは、ありえないｗｗ
285仕様書無しさん
2018/06/09(土) 14:23:39.62286仕様書無しさん
2018/06/09(土) 14:43:48.21 >>284
まだわからないかー
子供用の説明ならどうだ？
依存先を直接参照インスタンス化するのは一体型パソコンと同じ
メモリが壊れてたらパソコン全体が壊れてることになるんだ
パソコン全体を修理に出すか買い替えてね
依存先をインターフェースで切るのは組み立て型のパソコンと同じ
メモリが壊れててもパソコンが壊れたことにはならないんだ
メモリだけを交換してね
まだわからないかー
子供用の説明ならどうだ？
依存先を直接参照インスタンス化するのは一体型パソコンと同じ
メモリが壊れてたらパソコン全体が壊れてることになるんだ
パソコン全体を修理に出すか買い替えてね
依存先をインターフェースで切るのは組み立て型のパソコンと同じ
メモリが壊れててもパソコンが壊れたことにはならないんだ
メモリだけを交換してね
287仕様書無しさん
2018/06/09(土) 14:59:56.95 インターフェース定義しただけなら切り離されてないからなぁ。
きちんとリンクライブラリにして初めて切り離される。
きちんとリンクライブラリにして初めて切り離される。
289仕様書無しさん
2018/06/09(土) 15:15:08.99 >>286
だからそれインターフェースと関係ないじゃん
モジュール（クラス）が壊れていたら
それを交換するだけだろ？
あとは、お前、はなっからメモリが壊れてるってことに
しているようだが、マザーボードのほうが壊れている場合だってあるんだぞ
インターフェースを使っていれば、絶対にメモリが壊れる
マザーボードが壊れることはないって言うつもりか？
だからそれインターフェースと関係ないじゃん
モジュール（クラス）が壊れていたら
それを交換するだけだろ？
あとは、お前、はなっからメモリが壊れてるってことに
しているようだが、マザーボードのほうが壊れている場合だってあるんだぞ
インターフェースを使っていれば、絶対にメモリが壊れる
マザーボードが壊れることはないって言うつもりか？
290仕様書無しさん
2018/06/09(土) 15:23:48.56291仕様書無しさん
2018/06/09(土) 15:26:19.26292仕様書無しさん
2018/06/09(土) 15:38:52.62293仕様書無しさん
2018/06/09(土) 15:44:07.05 インターフェースさん
開発の邪魔だから早く死んで
開発の邪魔だから早く死んで
294仕様書無しさん
2018/06/09(土) 15:45:18.81 | echo
295仕様書無しさん
2018/06/09(土) 15:54:54.09 C#なのにインターフェイスから実装に飛べないなんて言ってるアホの妄言だから気にするな
296仕様書無しさん
2018/06/09(土) 15:55:42.85 モノリスおじさん「インターフェースさん邪魔(うわあああ論理じゃ勝てない。そんだ！むかつくから悪口いったろwww)」
悲しいなぁ
悲しいなぁ
298仕様書無しさん
2018/06/09(土) 16:15:42.81 でもお前、ifがあるコードは追えるんでしょ？
299仕様書無しさん
2018/06/09(土) 16:23:59.60 ものによるね
インターフェースや抽象クラスでやるべきものを無理やり条件分岐にしたようなものは追う気しないね
実装クラス全部見るより大変だよ
インターフェースや抽象クラスでやるべきものを無理やり条件分岐にしたようなものは追う気しないね
実装クラス全部見るより大変だよ
301仕様書無しさん
2018/06/09(土) 18:06:39.52303仕様書無しさん
2018/06/09(土) 18:40:50.00 そもそもさ、壊れたメモリを交換するのと
モジュールを修理するのは意味がぜんぜん違う。
パソコンにインターフェースがあってよかったというのは、
インターフェースさえ一緒なら、他のメーカーであっても
正常なメモリに交換できるからだ
だけどソフトウェアは違う。インターフェースが同じで
機能が全く一緒のものなんて、殆ど無い。
バグがあったら交換するのではなく、そのモジュール修正するのだから
インターフェースがあることと、バグの修正には全く関係がない
モジュールを修理するのは意味がぜんぜん違う。
パソコンにインターフェースがあってよかったというのは、
インターフェースさえ一緒なら、他のメーカーであっても
正常なメモリに交換できるからだ
だけどソフトウェアは違う。インターフェースが同じで
機能が全く一緒のものなんて、殆ど無い。
バグがあったら交換するのではなく、そのモジュール修正するのだから
インターフェースがあることと、バグの修正には全く関係がない
307仕様書無しさん
2018/06/09(土) 18:49:28.42309仕様書無しさん
2018/06/09(土) 18:52:26.32311仕様書無しさん
2018/06/09(土) 18:57:25.28 インターフェースは交換しやすいだけで
バグが修正しやすくなるわけじゃないんだな
バグが修正しやすくなるわけじゃないんだな
312仕様書無しさん
2018/06/09(土) 19:03:50.67 バグが修正しやすくなるぞ
お気に入りのバイクが壊れたけど壊れてるパーツを修理すれば動くとする
インターフェースを使わない派は
バイクが組みあがった状態で修理作業をしないといけないので修正が最悪にしにくい
修理した後もぶっつけ本番でテストしなきゃならんから最悪の場合それで他の部分が壊れる
インターフェースを使う派は
部品を外して壊れた部品だけを作業机に置いて修理できるので超やりやすい
直したら部品の単機能テストをして本体に組みこんでテストできるから安心
お気に入りのバイクが壊れたけど壊れてるパーツを修理すれば動くとする
インターフェースを使わない派は
バイクが組みあがった状態で修理作業をしないといけないので修正が最悪にしにくい
修理した後もぶっつけ本番でテストしなきゃならんから最悪の場合それで他の部分が壊れる
インターフェースを使う派は
部品を外して壊れた部品だけを作業机に置いて修理できるので超やりやすい
直したら部品の単機能テストをして本体に組みこんでテストできるから安心
313仕様書無しさん
2018/06/09(土) 19:05:03.74314仕様書無しさん
2018/06/09(土) 19:07:31.20 どうやってクラスAの中に埋め込まれているクラスBをテストするのか？
そりゃクラスBだけ取り出して、
テストすればいいだけでは？
そりゃクラスBだけ取り出して、
テストすればいいだけでは？
315仕様書無しさん
2018/06/09(土) 19:09:33.66318仕様書無しさん
2018/06/09(土) 19:20:15.50 ソフトウェアだと全く同じものを複数作れるからな
半田で癒着したモジュールをテストする必要はない。
そのモジュール＝クラスがあるのだから、
そのクラス単体でテストすれば良いだけ
半田で癒着したモジュールをテストする必要はない。
そのモジュール＝クラスがあるのだから、
そのクラス単体でテストすれば良いだけ
319仕様書無しさん
2018/06/09(土) 19:21:42.93320仕様書無しさん
2018/06/09(土) 19:22:46.93 自分で例え話をして自滅するスタイルかな？
322仕様書無しさん
2018/06/09(土) 19:40:59.46 ABが癒着していたら Aを分離してテストする方法がないだろ
であれば、
ABが癒着していなければ Aを分離してテストする方法がある
という意味になる
で、インターフェースを使うことは必須ではない
インターフェースを使わず、かつ癒着しないようにすれば良い
であれば、
ABが癒着していなければ Aを分離してテストする方法がある
という意味になる
で、インターフェースを使うことは必須ではない
インターフェースを使わず、かつ癒着しないようにすれば良い
323仕様書無しさん
2018/06/09(土) 19:42:18.06 インターフェースを使わなければ、
絶対癒着してしまうんだー、ブンブン（手足を振り回す音）
ガキじゃないんだから、理由ぐらい言えよｗ
絶対癒着してしまうんだー、ブンブン（手足を振り回す音）
ガキじゃないんだから、理由ぐらい言えよｗ
325仕様書無しさん
2018/06/09(土) 19:49:38.37 はい、ガキいっちょいただきましたーｗ
やっぱり理由言えませんでしたね。
想定どおりです。
ほんとガキ
やっぱり理由言えませんでしたね。
想定どおりです。
ほんとガキ
326仕様書無しさん
2018/06/09(土) 19:50:23.18 ABが癒着していなければな
しかしAがBに依存するなら癒着は不可避
インターフェースを使うしかない
しかしAがBに依存するなら癒着は不可避
インターフェースを使うしかない
327仕様書無しさん
2018/06/09(土) 19:52:20.60 で、癒着してない例は？
それで任意のシステムを組める保証は？
できるったらできるんだーブンブン、ってかwww
それで任意のシステムを組める保証は？
できるったらできるんだーブンブン、ってかwww
328仕様書無しさん
2018/06/09(土) 19:59:15.61 >>327
くだらね。そんなこともわからんのか。
じゃあ、ぐうの音も出ない例だしてやるよ。
Aという会社にClassAの作成を依頼しました。
ClassAは完成しテストはしっかり行われています。
ClassAはどこにも癒着していません
数年後、Bという会社に、ClassAを使ってClassBを作るように仕事を依頼しました。
仕事を依頼する前は、ClassAは癒着していません。
ClassAのコードはなにも変えてないのだから
仕事完了後も、ClassAはどこにも癒着していません
くだらね。そんなこともわからんのか。
じゃあ、ぐうの音も出ない例だしてやるよ。
Aという会社にClassAの作成を依頼しました。
ClassAは完成しテストはしっかり行われています。
ClassAはどこにも癒着していません
数年後、Bという会社に、ClassAを使ってClassBを作るように仕事を依頼しました。
仕事を依頼する前は、ClassAは癒着していません。
ClassAのコードはなにも変えてないのだから
仕事完了後も、ClassAはどこにも癒着していません
329仕様書無しさん
2018/06/09(土) 20:01:35.18 つーかこんな茶番劇のような例を出さなくても
MSが作ったライブラリをラップしたオレオレライブラリが
癒着するわけ無いだろと
MSはそのライブラリ単体で開発・テストしてんだからさ
MSが作ったライブラリをラップしたオレオレライブラリが
癒着するわけ無いだろと
MSはそのライブラリ単体で開発・テストしてんだからさ
330仕様書無しさん
2018/06/09(土) 20:10:35.17331仕様書無しさん
2018/06/09(土) 20:14:50.16 >>329
オレオレラッパーはMSのライブラリと癒着してんだよ
そしてそのオレオレラッパーを使うクラスはオレオレラッパーに癒着する
癒着が連鎖してMSのライブラリに癒着することになる
オレオレラッパーをインターフェースを実装するように作れば
オレオレラッパーインターフェースを使うクラスは癒着から逃れられる
オレオレラッパーはMSのライブラリと癒着してんだよ
そしてそのオレオレラッパーを使うクラスはオレオレラッパーに癒着する
癒着が連鎖してMSのライブラリに癒着することになる
オレオレラッパーをインターフェースを実装するように作れば
オレオレラッパーインターフェースを使うクラスは癒着から逃れられる
332仕様書無しさん
2018/06/09(土) 20:15:29.58 > ClassBはClassAに依存しているから開発にもテストにもClassAが必要
ClassAならすでにあるじゃん？アホなの？
ClassAならすでにあるじゃん？アホなの？
333仕様書無しさん
2018/06/09(土) 20:15:54.02 アホなんだろｗ
334仕様書無しさん
2018/06/09(土) 20:20:55.14 >>332
それを癒着というんだよ
ClassAがあるからいいじゃんじゃなくてなかったらダメじゃんってのが正解な
ClassAがデータベースに依存してたらデータベースも整備しなきゃならん
ClassAが外部サービス依存してたら外部サービスと契約しなきゃいけない
そうやって癒着の連鎖が広がっていく
それを癒着というんだよ
ClassAがあるからいいじゃんじゃなくてなかったらダメじゃんってのが正解な
ClassAがデータベースに依存してたらデータベースも整備しなきゃならん
ClassAが外部サービス依存してたら外部サービスと契約しなきゃいけない
そうやって癒着の連鎖が広がっていく
335仕様書無しさん
2018/06/09(土) 20:21:21.75 仮にClassBを動かすのにClassAがまだできていなかったとしても
モックを使えばいいだけなのでインターフェースは必要ない
まあClassAの偽物を使ってテストしても
それは本当に動くことの証明にはならないから、
最終的にはClassAを組み込んだ状態でテストしなければいけないんだがな
モックを使えばいいだけなのでインターフェースは必要ない
まあClassAの偽物を使ってテストしても
それは本当に動くことの証明にはならないから、
最終的にはClassAを組み込んだ状態でテストしなければいけないんだがな
336仕様書無しさん
2018/06/09(土) 20:22:07.65337仕様書無しさん
2018/06/09(土) 20:23:32.48 >>334
> ClassAがデータベースに依存してたらデータベースも整備しなきゃならん
整備すればいい
> ClassAが外部サービス依存してたら外部サービスと契約しなきゃいけない
外部サービスのモックを使えばいい
接続先の切り替えは単に設定ファイルの接続先を変更するだけ
> ClassAがデータベースに依存してたらデータベースも整備しなきゃならん
整備すればいい
> ClassAが外部サービス依存してたら外部サービスと契約しなきゃいけない
外部サービスのモックを使えばいい
接続先の切り替えは単に設定ファイルの接続先を変更するだけ
338仕様書無しさん
2018/06/09(土) 20:23:42.80 >>335
それは言語機能的な意味でインターフェースを使っていないだけで
考え方としてはインターフェースを使って実装を切り替えるのと変わらんよ
インターフェースを使った場合との違いは手順が増えて面倒くさくなる
それは言語機能的な意味でインターフェースを使っていないだけで
考え方としてはインターフェースを使って実装を切り替えるのと変わらんよ
インターフェースを使った場合との違いは手順が増えて面倒くさくなる
340仕様書無しさん
2018/06/09(土) 20:26:41.02 >>338
> それは言語機能的な意味でインターフェースを使っていないだけで
> 考え方としてはインターフェースを使って実装を切り替えるのと変わらんよ
はぁ？ じゃあお前のその主張だと
すべてのクラスは、言語的な意味でのインターフェースを使ってないだけで
インターフェースを持っているので、別になにかを作る必要はないってことで終わりだな
はい、ClassAとClassBだけで十分ですーｗ
だって、インターフェースがあるのですからーｗ
> それは言語機能的な意味でインターフェースを使っていないだけで
> 考え方としてはインターフェースを使って実装を切り替えるのと変わらんよ
はぁ？ じゃあお前のその主張だと
すべてのクラスは、言語的な意味でのインターフェースを使ってないだけで
インターフェースを持っているので、別になにかを作る必要はないってことで終わりだな
はい、ClassAとClassBだけで十分ですーｗ
だって、インターフェースがあるのですからーｗ
343仕様書無しさん
2018/06/09(土) 20:33:41.77 >>340
インターフェースを使わない代わりに無駄なコストを呼び込んでるんだよ
古の時代では確かにビルド時のリンク設定を変えたりマクロ定数による分岐を使って実装の切り替えを行っていた
これは非常に原始的だけど依存性注入の原型と言っていい
だけどあまりに不安定で管理の手間がかかるから人類は新しい方法を考えた
それは抽象基底クラスや仮装メソッドだったりするがまだまだ実用には難があった
最終的に依存性を丸ごとインターフェースに切り出して外からインスタンス渡すのがいいねって進化した
君が言うようにインターフェースを使わなくても実装のの切り替えはできないことはないが
それはIT原始時代の非効率的で野蛮な方法なんだよ
そういうのは猿がやることだ
インターフェースを使わない代わりに無駄なコストを呼び込んでるんだよ
古の時代では確かにビルド時のリンク設定を変えたりマクロ定数による分岐を使って実装の切り替えを行っていた
これは非常に原始的だけど依存性注入の原型と言っていい
だけどあまりに不安定で管理の手間がかかるから人類は新しい方法を考えた
それは抽象基底クラスや仮装メソッドだったりするがまだまだ実用には難があった
最終的に依存性を丸ごとインターフェースに切り出して外からインスタンス渡すのがいいねって進化した
君が言うようにインターフェースを使わなくても実装のの切り替えはできないことはないが
それはIT原始時代の非効率的で野蛮な方法なんだよ
そういうのは猿がやることだ
346仕様書無しさん
2018/06/09(土) 20:54:53.19 インターフェース君、もう死んだ方がいいな
バカだし
バカだし
347仕様書無しさん
2018/06/09(土) 21:02:30.42 >>345
しやすいよ
余計な依存関係がクリアされるから作業対象に集中できる
作業対象の型も設定や命名規約からすぐわかるし全体からすれば極一部の動的なインスタンスだったとしてもログやファクトリーを見ればすぐにわかる
作業対象が依存してるのはインターフェースの契約でしかないのでインターフェースの先はもちろん知らなくていい
しやすいよ
余計な依存関係がクリアされるから作業対象に集中できる
作業対象の型も設定や命名規約からすぐわかるし全体からすれば極一部の動的なインスタンスだったとしてもログやファクトリーを見ればすぐにわかる
作業対象が依存してるのはインターフェースの契約でしかないのでインターフェースの先はもちろん知らなくていい
349仕様書無しさん
2018/06/09(土) 21:10:24.63 インターフェースを使わずにあちこちに条件分岐を撒き散らすほうが
バグ修正しにくいわ
バグ修正しにくいわ
351仕様書無しさん
2018/06/09(土) 22:45:58.47 まぁ実際のところ、interfaceまでガッツリ作る業務は今まであったことないんだけどね。
大体abstractクラスが限界
大体abstractクラスが限界
352仕様書無しさん
2018/06/09(土) 22:51:40.60 後はienumerableと受け取ったり返したりするヘルパー関数群とかは作るか。他はもはや趣味の領域な気がする
353仕様書無しさん
2018/06/09(土) 23:07:02.97 IT業界は企業間で10年、20年分ぐらい技術格差がある
当たり前のようにinterfaceを使うモダンな企業もある
JavaやC#を採用しているのにCやCOBOLみたいなプログラムを書いてる老舗企業もまだある
当たり前のようにinterfaceを使うモダンな企業もある
JavaやC#を採用しているのにCやCOBOLみたいなプログラムを書いてる老舗企業もまだある
354仕様書無しさん
2018/06/09(土) 23:22:41.12355仕様書無しさん
2018/06/09(土) 23:24:11.27 インターフェース君はどうやってインターフェースの先を知らずに不具合を直すのだろう？
356仕様書無しさん
2018/06/09(土) 23:59:51.23 作業対象の依存するインターフェースの先を知る必要はない
作業対象==バグってるクラスを治すだけ
作業対象==バグってるクラスを治すだけ
357仕様書無しさん
2018/06/10(日) 00:33:37.26 >じゃあ、型情報潰しちゃってるのにどうやって該当の処理まで飛ぶの？
作業対象の型も設定や命名規約からすぐわかるし全体からすれば極一部の動的なインスタンスだったとしてもログやファクトリーを見ればすぐにわかる
>インターフェース君はどうやってインターフェースの先を知らずに不具合を直すのだろう？
作業対象が依存してるのはインターフェースの契約でしかないのでインターフェースの先はもちろん知らなくていい
作業対象==バグってるクラス
作業対象の型も設定や命名規約からすぐわかるし全体からすれば極一部の動的なインスタンスだったとしてもログやファクトリーを見ればすぐにわかる
>インターフェース君はどうやってインターフェースの先を知らずに不具合を直すのだろう？
作業対象が依存してるのはインターフェースの契約でしかないのでインターフェースの先はもちろん知らなくていい
作業対象==バグってるクラス
358仕様書無しさん
2018/06/10(日) 00:41:27.33 >>356
IF「フフフ、我らを見抜けるかな？」
IF「3万のインスタンスをもち、150種のクラスをもつ我らを見抜くことは不可能」
IF「さらにメモリ、フォーム、コントロール、スレッド、ファイル、プロトコル、etc」
IF「すべての共通項を見出した万能クラス」
IF「フフフ、我らを見抜けるかな？」
IF「3万のインスタンスをもち、150種のクラスをもつ我らを見抜くことは不可能」
IF「さらにメモリ、フォーム、コントロール、スレッド、ファイル、プロトコル、etc」
IF「すべての共通項を見出した万能クラス」
359仕様書無しさん
2018/06/10(日) 00:44:12.74 実際には責務:クラス=1:1だから症状聞いた瞬間にあぁあのクラスだなってわかるんだけどね
クラス分けしないでif文書きまくるとそれができなくなってコード追いかけたり実際に動かさないとわからなくなる
クラス分けしないでif文書きまくるとそれができなくなってコード追いかけたり実際に動かさないとわからなくなる
361仕様書無しさん
2018/06/10(日) 01:05:06.67 バグがあるクラスを直す時にそのクラスが依存しているインターフェースの先を知る必要がない
インターフェースを守っていればいい
インターフェースを守っていればいい
362仕様書無しさん
2018/06/10(日) 01:07:08.85 これも成り立つよな？
バグがあるクラスを直す時にそのクラスが依存しているクラスの先を知る必要がない
バグがあるクラスを直す時にそのクラスが依存しているクラスの先を知る必要がない
363仕様書無しさん
2018/06/10(日) 01:14:58.26 インターフェースの先は知る必要はない
364仕様書無しさん
2018/06/10(日) 01:23:43.45 クラスを使ってるだけなら、クラスの実装を知る必要はないのと同じことか
そういやライブラリのソースコードって見ないもんな
そういやライブラリのソースコードって見ないもんな
365仕様書無しさん
2018/06/10(日) 01:31:56.78 クラスを使ってるだけならクラスの実装にも注意が必要
366仕様書無しさん
2018/06/10(日) 01:42:08.23 あー、勝負ついたなｗ
クラス（第三者が作ったライブラリ）のソースコード
普通見ねぇわ
クラス（第三者が作ったライブラリ）のソースコード
普通見ねぇわ
367仕様書無しさん
2018/06/10(日) 07:15:47.13 しかし、まだ、インターフェースの先がバグってる
368仕様書無しさん
2018/06/10(日) 09:54:12.51 バグってるクラスを直さないと誰が言ったのだろうか
369仕様書無しさん
2018/06/10(日) 12:35:52.36 インターフェースを使うとバグが無いことが証明される
なんでかな？
なんでかな？
370仕様書無しさん
2018/06/10(日) 12:48:41.54 インターフェースを使ってもバグはある
終わり
終わり
371仕様書無しさん
2018/06/10(日) 12:59:16.23 インターフェースの先は知らなくていい
↑これが間違ってる
↑これが間違ってる
372仕様書無しさん
2018/06/10(日) 13:05:49.06 なんでそこだけ切り取ってるの？馬鹿なの？
374仕様書無しさん
2018/06/14(木) 20:41:53.41 これが流行ってるからっで、レガシーコードにぶち込まれた数々のソリューション。
やるなら同等の箇所を完全に書き換えろ。
未来に責任が持てないならおとなしくしとけよ、糞が
やるなら同等の箇所を完全に書き換えろ。
未来に責任が持てないならおとなしくしとけよ、糞が
375仕様書無しさん
2018/06/14(木) 20:58:04.16 なんで同等の箇所が何個もあるの？
376仕様書無しさん
2018/06/14(木) 20:58:25.98 あ、未来のことなんか考えなかったからだね
未来の責任は放棄か
未来の責任は放棄か
377仕様書無しさん
2018/06/14(木) 21:55:10.14 残業、休出してリファクタリングってなんかおかしくねーか？
いま、足が出てるわけで、いま、なんとかしろよ
アリもしないお前が想定する未来はきっとこないんだ
いま、足が出てるわけで、いま、なんとかしろよ
アリもしないお前が想定する未来はきっとこないんだ
379仕様書無しさん
2018/06/15(金) 07:11:43.08 >>378
え？ちょっと頭使ってね
リファクタリングっていまの工数を使って明日の工数につなげましょうって作戦じゃん？
なのにいま足が出てるのにそんなことしたって一体いつのプロジェクトを成功させたいのかわけがわからないじゃん
え？ちょっと頭使ってね
リファクタリングっていまの工数を使って明日の工数につなげましょうって作戦じゃん？
なのにいま足が出てるのにそんなことしたって一体いつのプロジェクトを成功させたいのかわけがわからないじゃん
380仕様書無しさん
2018/06/15(金) 07:46:54.71 > リファクタリングっていまの工数を使って明日の工数につなげましょうって作戦じゃん？
え？違うよ
まず今日の仕事の準備としてリファクタリングする。
そして今日の仕事の仕上げとしてリファクタリングする
それで今日の仕事が終わったと言える
準備と仕上げを入れずに仕事を見積もってはいけない
足が出てるのは、その準備と仕上げを勤務時間中にやらないで
1時間早く出社して、残業もするような状態になってるから
え？違うよ
まず今日の仕事の準備としてリファクタリングする。
そして今日の仕事の仕上げとしてリファクタリングする
それで今日の仕事が終わったと言える
準備と仕上げを入れずに仕事を見積もってはいけない
足が出てるのは、その準備と仕上げを勤務時間中にやらないで
1時間早く出社して、残業もするような状態になってるから
382仕様書無しさん
2018/06/15(金) 08:04:01.47 気分に任せて組んでるから必要になってんじゃない？
お前の場合
お前の場合
383仕様書無しさん
2018/06/15(金) 09:52:47.39 まあリファクタして工数増えてんなら本末転倒だわな
386仕様書無しさん
2018/06/15(金) 14:53:06.17 野球で例えるならバッターが足場を慣らすのがリファクタリング
388仕様書無しさん
2018/06/15(金) 17:41:40.64 打てない奴に限ってだった
390仕様書無しさん
2018/06/15(金) 18:19:30.60 設計書通りだとバグ出るしバグの修正めちゃくちゃ大変
しかも当たり前のように仕様変更入るじゃん
だから設計書は参考までに止めてリファクタリングするしかない
文句言うなら最初から整理とテストまで実行した設計書をよこせや
しかも当たり前のように仕様変更入るじゃん
だから設計書は参考までに止めてリファクタリングするしかない
文句言うなら最初から整理とテストまで実行した設計書をよこせや
392仕様書無しさん
2018/06/15(金) 19:05:31.85 >>391
設計書はゴミだけど設計というプロセスは必要
設計した結果をコードとテストとしてアウトプットする
それらでカバーできない部分があれば別途図表や文章を用意するが設計書という体裁にはならない
後発の開発者やユーザーに対する解説書となる
設計書はゴミだけど設計というプロセスは必要
設計した結果をコードとテストとしてアウトプットする
それらでカバーできない部分があれば別途図表や文章を用意するが設計書という体裁にはならない
後発の開発者やユーザーに対する解説書となる
394仕様書無しさん
2018/06/15(金) 19:29:07.71 んで、設計書を通りのコードと言っても
わかりやすいコードと、わかりにくいコードがある
正しく動いていたとしても、わかりにくいコードだと
今後の作業に支障をきたす。
今後の作業を改善するためにリファクタリングするのではなく
今後の作業に支障をきたさないためにリファクタリングをする。
これは今やらなければいけない作業
工事終わりました。でも片付けはしてないです。じゃだめだろう？
片付けまでやるのが今日の仕事
わかりやすいコードと、わかりにくいコードがある
正しく動いていたとしても、わかりにくいコードだと
今後の作業に支障をきたす。
今後の作業を改善するためにリファクタリングするのではなく
今後の作業に支障をきたさないためにリファクタリングをする。
これは今やらなければいけない作業
工事終わりました。でも片付けはしてないです。じゃだめだろう？
片付けまでやるのが今日の仕事
395仕様書無しさん
2018/06/15(金) 19:46:24.48 ①良い設計を簡潔に記したもの
→必要です。これを設計書と言います。
②悪い設計を膨大な文書で誤魔化そうとしたもの
→不要です。むしろ害悪になります。
これは設計書とは言いません。ゴミです。
残念なことに日本のIT業界では②の事を設計書と呼び、盲信しています。
今すぐ②をリファクタリングして①に書き換えましょう。
そうすればコードのリファクタリングは最小限で済みます。
→必要です。これを設計書と言います。
②悪い設計を膨大な文書で誤魔化そうとしたもの
→不要です。むしろ害悪になります。
これは設計書とは言いません。ゴミです。
残念なことに日本のIT業界では②の事を設計書と呼び、盲信しています。
今すぐ②をリファクタリングして①に書き換えましょう。
そうすればコードのリファクタリングは最小限で済みます。
396仕様書無しさん
2018/06/15(金) 20:00:38.76 >>394
わかりにくい文章やな
わかりにくい文章やな
397仕様書無しさん
2018/06/15(金) 20:13:33.02 >>395
> ①良い設計を簡潔に記したもの
> →必要です。これを設計書と言います。
簡潔に書くのと、詳細なコードを書くことは
矛盾するからね。簡潔に書けば、書いてない部分が
増えるため汚いコードになってしまう可能性が増える
> ①良い設計を簡潔に記したもの
> →必要です。これを設計書と言います。
簡潔に書くのと、詳細なコードを書くことは
矛盾するからね。簡潔に書けば、書いてない部分が
増えるため汚いコードになってしまう可能性が増える
400仕様書無しさん
2018/06/18(月) 20:23:08.40 リファクタリングしながらやると美しいコードになるけどやっぱり時間かかるな
複雑なSQLで一気にデータ持ってきて表示、編集させて、ボタン押したらこれまた複雑な更新SQLで一気にデータを更新
コードめちゃくちゃになるけど、これが一番生速度が速い
複雑なSQLで一気にデータ持ってきて表示、編集させて、ボタン押したらこれまた複雑な更新SQLで一気にデータを更新
コードめちゃくちゃになるけど、これが一番生速度が速い
401KAC
2018/06/18(月) 21:53:41.21 いや、ちゃんと設計しろよ
402仕様書無しさん
2018/06/18(月) 22:53:05.35 設計は遠回り
最初から最短距離見えてるんだからそうすればいい
最初から最短距離見えてるんだからそうすればいい
403仕様書無しさん
2018/06/18(月) 22:58:25.68 どうせ引き継ぎ用の説明書作らなきゃならないだろうに…。
404仕様書無しさん
2018/06/18(月) 23:00:21.08 逃げ切るんでね
405仕様書無しさん
2018/06/18(月) 23:12:11.32 家にケータイに電話来まくる未来しか見えないw
408仕様書無しさん
2018/06/19(火) 07:39:04.26409仕様書無しさん
2018/06/30(土) 20:48:21.44 設計・設計書要らない派が挙げてる仕事って、
1時間で終わるレベルのタスクなんだろうなって思う。
人と設計を共有したりしないでいいんだろうな。
1時間で終わるレベルのタスクなんだろうなって思う。
人と設計を共有したりしないでいいんだろうな。
410仕様書無しさん
2018/07/01(日) 00:07:45.44 だからコードで設計を共有すればいいじゃん
設計書を記述するための「プログラム言語」という専用の言語で
設計書を記述すればいいでしょう？
設計書を記述するための「プログラム言語」という専用の言語で
設計書を記述すればいいでしょう？
413仕様書無しさん
2018/07/01(日) 03:46:41.54414仕様書無しさん
2018/07/01(日) 03:51:24.97 >>413
それはプログラムと設計書の工数によって変わるだろ
プログラムより設計書の工数がえらい小さい場合は、設計書を持ち寄ってレビューするべきだし
工数がほとんど変わらないなら、最初からプログラムでレビューすればいい
それはプログラムと設計書の工数によって変わるだろ
プログラムより設計書の工数がえらい小さい場合は、設計書を持ち寄ってレビューするべきだし
工数がほとんど変わらないなら、最初からプログラムでレビューすればいい
415仕様書無しさん
2018/07/01(日) 04:01:00.47 設計書は長時間うんうんうなって完成させてから
レビューするもんでしょ
大規模なものなら、1ヶ月とかそれ以上かかって完成させて、
でイメージが合ってなくて全面書き直しｗｗｗ
レビューするもんでしょ
大規模なものなら、1ヶ月とかそれ以上かかって完成させて、
でイメージが合ってなくて全面書き直しｗｗｗ
416仕様書無しさん
2018/07/01(日) 04:03:02.31 設計書は書き直すことなんてないよ
所詮絵に描いた餅なんだから
間違ってもOK。レビューなんてしない
間違いはコードでなおす
所詮絵に描いた餅なんだから
間違ってもOK。レビューなんてしない
間違いはコードでなおす
419仕様書無しさん
2018/07/15(日) 20:49:16.71 建築業なら企画書→仕様書→設計書→図面→といった工程の中の
一部分であることが設計書の存在意義なんだが
この業界って仕様変更の頻度が高すぎて工程という前提条件が破綻してる
とくに下請けはプロマネのレベルが低くて無知だから何でもハイハイで
再見積もりも無しに平気で工程をまき戻していつものデスマーチ
一部分であることが設計書の存在意義なんだが
この業界って仕様変更の頻度が高すぎて工程という前提条件が破綻してる
とくに下請けはプロマネのレベルが低くて無知だから何でもハイハイで
再見積もりも無しに平気で工程をまき戻していつものデスマーチ
420仕様書無しさん
2018/07/16(月) 23:47:33.28421仕様書無しさん
2018/07/17(火) 20:14:10.53 建築業界に例えたらプログラマは何に相当するんだ？
○○に相当するとして、建築業界では○○に対して
ちゃんとした資料を渡してるんだろ？
だけどプログラマに対して、それと同じぐらいの内容の
資料渡してないだろ
って結論になるのが、この話題の最後になるのが目に見えてる
○○に相当するとして、建築業界では○○に対して
ちゃんとした資料を渡してるんだろ？
だけどプログラマに対して、それと同じぐらいの内容の
資料渡してないだろ
って結論になるのが、この話題の最後になるのが目に見えてる
423仕様書無しさん
2018/07/18(水) 03:26:52.12 >>422
おい、先にレスしてるんだからその先を書けよ。
土方に渡す資料に
「4階建でマンションを建てます。
部屋はいくつで、階段、エレベータはここで。
詳細は全部任せます。材料とか適切なのを選んでください」
って書いてあったら、それ建築士が使えないって判断だぞ
おい、先にレスしてるんだからその先を書けよ。
土方に渡す資料に
「4階建でマンションを建てます。
部屋はいくつで、階段、エレベータはここで。
詳細は全部任せます。材料とか適切なのを選んでください」
って書いてあったら、それ建築士が使えないって判断だぞ
425仕様書無しさん
2018/07/18(水) 11:14:36.88 プログラマは土方に相当すると言ってのに
現場監督や棟梁に相当するって訂正かよｗ
現場監督や棟梁に相当するって訂正かよｗ
426仕様書無しさん
2018/07/21(土) 18:07:22.82 リファクタしたいけど影響範囲ひろがりすぎる
427仕様書無しさん
2018/07/21(土) 18:09:01.09 将来的には絶対いいしそうしないと先がふさがるけど
当面の課題解決の理由として正当化できないせいで採用できない
当面の課題解決の理由として正当化できないせいで採用できない
428仕様書無しさん
2018/07/21(土) 19:57:36.56 などと言い訳をしているところは
デスマ状態なんだろうってのがよく分かる
なぜならコード修正の見積もりには
予めリファクタリング分の工数を含めるものだからだ
その余裕も無いほどカツカツなスケジュールなら
デスマになるに決まっている
デスマ状態なんだろうってのがよく分かる
なぜならコード修正の見積もりには
予めリファクタリング分の工数を含めるものだからだ
その余裕も無いほどカツカツなスケジュールなら
デスマになるに決まっている
429仕様書無しさん
2018/07/21(土) 20:05:56.17 そのリファクタ見積もりが正当化できないんですけど
430仕様書無しさん
2018/07/21(土) 20:10:08.19 将来的に当たるかもしれない課題がある
でもそれは優先度低くてかなり先、一度後回しでいいやってなった
今回の改修は範囲狭くて緊急性たかい
今回のを理由に将来を見越した改修をしてしまうと、緊急性高いテストに関係ないモジュールまで巻き込まれてしまう
先で死ぬのが見えてるのに出口が
でもそれは優先度低くてかなり先、一度後回しでいいやってなった
今回の改修は範囲狭くて緊急性たかい
今回のを理由に将来を見越した改修をしてしまうと、緊急性高いテストに関係ないモジュールまで巻き込まれてしまう
先で死ぬのが見えてるのに出口が
431仕様書無しさん
2018/07/21(土) 20:55:20.97 コストカット原理主義が無くならない限りはリファクタリングの正当性を見出すのは無理だろうな
空いてる時間に今までのフィードバックをすることでよくしていくことが必要なのに空いた時間
そのものをコストとして敵対視してるのだから受け入れられることはない
空いた時間＝余裕＝コスト＝絶対悪 になっている人が多い
空いてる時間に今までのフィードバックをすることでよくしていくことが必要なのに空いた時間
そのものをコストとして敵対視してるのだから受け入れられることはない
空いた時間＝余裕＝コスト＝絶対悪 になっている人が多い
433仕様書無しさん
2018/07/21(土) 22:17:48.11 なんでだよ
434仕様書無しさん
2018/07/21(土) 22:25:55.48 そりゃ正しいコードの姿が見えてないのに
コード書くのにどれくらいかなんて見積もりできないだろｗ
それか修正前のコードがどんなに汚くて
修正箇所が大きくテスト範囲も広くなろうが
修正前のコードが綺麗でわずかの修正で解決できようが
全く同じ工数で修正できるって考えてるアホかのどちらかだ
コード書くのにどれくらいかなんて見積もりできないだろｗ
それか修正前のコードがどんなに汚くて
修正箇所が大きくテスト範囲も広くなろうが
修正前のコードが綺麗でわずかの修正で解決できようが
全く同じ工数で修正できるって考えてるアホかのどちらかだ
436仕様書無しさん
2018/07/21(土) 23:01:38.04 言語やOS、ライブラリ、フレームワークなんてのは変わり続けてたり、変わらないことで
使えなくなることがあったり、使用者の習熟度が上がるなんかでも変化するから正しい
コードの姿なんてものは幻想だよ。
極端な話、変更がなければリファクタリングなんてしなくてもいいがOSバージョンアップは
ほぼ確実に数年単位で起きるしそれに対する対応としてはリファクタリングなりなんなりの
事前によくしておくというのは必要なんだよな。
使えなくなることがあったり、使用者の習熟度が上がるなんかでも変化するから正しい
コードの姿なんてものは幻想だよ。
極端な話、変更がなければリファクタリングなんてしなくてもいいがOSバージョンアップは
ほぼ確実に数年単位で起きるしそれに対する対応としてはリファクタリングなりなんなりの
事前によくしておくというのは必要なんだよな。
438仕様書無しさん
2018/07/21(土) 23:04:48.61 >>436
> 使用者の習熟度が上がるなんかでも変化するから正しい
> コードの姿なんてものは幻想だよ。
コードの話をしてくれないかな？
お前が言ってるのは使用者の習熟度の話
お前が言ってるのは、正しいコードはあるが
それを使用者が理解できないって言ってるだけだろう？
> 使用者の習熟度が上がるなんかでも変化するから正しい
> コードの姿なんてものは幻想だよ。
コードの話をしてくれないかな？
お前が言ってるのは使用者の習熟度の話
お前が言ってるのは、正しいコードはあるが
それを使用者が理解できないって言ってるだけだろう？
442仕様書無しさん
2018/07/22(日) 11:49:00.45 >>441
そもそもそこまでコストカットする必要はあるのかっていう話だな。
お給料＝コストなんだからコストカット自体は自分の給料を減らすものとして考えなきゃ
ならないわけで、なんで自分の首を絞めることに肯定的なのかなあと。
効率化自体はかったるい作業をかったるくない作業にする自分ために必要なことだが
効率化しないと評価下げる、お前は低評価だみたいなのは違うだろうと。
そもそもそこまでコストカットする必要はあるのかっていう話だな。
お給料＝コストなんだからコストカット自体は自分の給料を減らすものとして考えなきゃ
ならないわけで、なんで自分の首を絞めることに肯定的なのかなあと。
効率化自体はかったるい作業をかったるくない作業にする自分ために必要なことだが
効率化しないと評価下げる、お前は低評価だみたいなのは違うだろうと。
443仕様書無しさん
2018/07/22(日) 12:10:14.32 資本主義の世界だと自分の成功とは他人より成果を出すことでつまり他人が失敗すること
つまり望まれてるのはお前がコケて失敗することなんだ
それでまわりが幸せになる
おまえの上司は
お前が失敗しないことを理由に地位と給与を下げ、失敗したことを理由に地位と給与を下げるだろう
成功者の側に立とうと思ったらうわべに隠された別の道を通らねばならない
つまり望まれてるのはお前がコケて失敗することなんだ
それでまわりが幸せになる
おまえの上司は
お前が失敗しないことを理由に地位と給与を下げ、失敗したことを理由に地位と給与を下げるだろう
成功者の側に立とうと思ったらうわべに隠された別の道を通らねばならない
445仕様書無しさん
2018/07/22(日) 14:20:05.45 >>444
だからそんなバカバカしい定量化しづらい、出来ない概念を信奉してるから
ちょっとした計算違いでどんどんドツボにはまっていくんだよ。
金は貯めたり削ったりするものじゃなくて使うものだという認識が出来てない。
だからそんなバカバカしい定量化しづらい、出来ない概念を信奉してるから
ちょっとした計算違いでどんどんドツボにはまっていくんだよ。
金は貯めたり削ったりするものじゃなくて使うものだという認識が出来てない。
446仕様書無しさん
2018/07/22(日) 14:23:00.79 減量が必要なボクサーじゃないんだから無駄なんてあっていいの、あって当たり前なの
そんな当たり前のことが分らなくなってきているから作業量が増え続けて仕事が楽に
ならないんだよ。
過労死するとかそれに近い状態が幸せなのか？
そんな当たり前のことが分らなくなってきているから作業量が増え続けて仕事が楽に
ならないんだよ。
過労死するとかそれに近い状態が幸せなのか？
447KAC
2018/07/22(日) 17:11:53.36 どうでもいいけど、
少なくとも給料上がった分くらいは効率化しろよ？
新人雇った方がコスパ良いとか笑えないから。
少なくとも給料上がった分くらいは効率化しろよ？
新人雇った方がコスパ良いとか笑えないから。
448仕様書無しさん
2018/07/22(日) 17:13:26.47 さきにあげてからいえ
ガッデム
ガッデム
449仕様書無しさん
2018/08/01(水) 22:38:50.65 われながらクラスとメソッドの名前がひどい
壊滅的な英語センスと気まぐれなルールで
日本語との対応や分類がえらいことになってる
名前かえるぐらいさせろよ
壊滅的な英語センスと気まぐれなルールで
日本語との対応や分類がえらいことになってる
名前かえるぐらいさせろよ
450仕様書無しさん
2018/09/03(月) 10:29:43.86 難読化とか何だったんだろう。
451仕様書無しさん
2018/10/01(月) 19:25:22.11 小売業者が定期的にやってる棚卸しみたいなもんだけどな
452仕様書無しさん
2018/10/02(火) 20:04:13.47 なんやかんや言って全然ちゃうけどね
453仕様書無しさん
2018/10/02(火) 20:15:37.69 リファクタリングは日々一人ひとりがやることだから
棚卸しのようにまとめてやる行事とはぜんぜん違う
棚卸しのようにまとめてやる行事とはぜんぜん違う
454仕様書無しさん
2018/10/02(火) 20:16:40.24 正確には無能がする日課のオナニーみたいなものやけどね
455仕様書無しさん
2018/10/02(火) 20:21:20.38 システム刷新の前にリファクタリング少しでもやると効果的なんだけど余計な手間だろって却下される
古い言語で書かれたゴミを新しい言語で書かれたゴミに刷新しても意味ないと思うんだけどな
古い言語で書かれたゴミを新しい言語で書かれたゴミに刷新しても意味ないと思うんだけどな
456仕様書無しさん
2018/10/02(火) 20:24:34.25 定期的な整理をしないと肝心なときにぐちゃぐちゃになる
んで、緊急だっつって慌てて直してカオス化が進む
そーなる前に整理しろってそんだけの話でしょ
なんか難しいところあるか？
んで、緊急だっつって慌てて直してカオス化が進む
そーなる前に整理しろってそんだけの話でしょ
なんか難しいところあるか？
457仕様書無しさん
2018/10/02(火) 20:26:18.31 整理整頓するつもりで散らかし放題やから無能と呼ばれとんのやぞおまえw
458仕様書無しさん
2018/10/02(火) 20:26:51.57 整理整頓するつもりで
整理整頓してればいいだけでしょう？
整理整頓してればいいだけでしょう？
459仕様書無しさん
2018/10/02(火) 20:28:30.77 出来とらんゆうとるやんw
460仕様書無しさん
2018/10/02(火) 20:31:19.14 整理整頓した結果が前よりマシになる保証がないことを奴隷主どもはよくわきまえている
まともな整理整頓できるぐらい理解が進んでたら
そもそも整理したいって思わないことも多い
まともな整理整頓できるぐらい理解が進んでたら
そもそも整理したいって思わないことも多い
461仕様書無しさん
2018/10/02(火) 21:19:29.11 リファクタリング何ぞ不要
その頃には丸ごと作り直せ
その頃には丸ごと作り直せ
462仕様書無しさん
2018/10/02(火) 21:23:26.63 自動テスト出来るならもうかなりキレイなコードになってるはず
リファクタリングが本当に必要なのはテスト困難な汚いコード
リファクタリングはテストと必ずセットだって常識は間違っていたのかも知れないな
テストしないでリファクタリングすることも時には必要
これをエクストリーム・リファクタリングと名付けよう
みんなこのワードを流行らしてくれ
流行ってるなら本番でも採用されるから
リファクタリングが本当に必要なのはテスト困難な汚いコード
リファクタリングはテストと必ずセットだって常識は間違っていたのかも知れないな
テストしないでリファクタリングすることも時には必要
これをエクストリーム・リファクタリングと名付けよう
みんなこのワードを流行らしてくれ
流行ってるなら本番でも採用されるから
463仕様書無しさん
2018/10/02(火) 22:06:17.68 エクストリームデグレードした記憶しかない
464仕様書無しさん
2018/10/02(火) 23:05:28.72 最初は何とかなってたのに
あれがたりないこれがたりないってプライベートメソッドが増えて
にっちもさっちも行かなくなった…
リファクタしたいけどテストできなくなったからリファクタできない
あれがたりないこれがたりないってプライベートメソッドが増えて
にっちもさっちも行かなくなった…
リファクタしたいけどテストできなくなったからリファクタできない
465仕様書無しさん
2018/10/03(水) 12:36:31.43 規模にもよるけど、機能の変更や追加依頼があった時にその部分だけリファクタをやってから手をつけてるなぁ
もちろんそれ込みの見積もりを出す
依頼もないのに勝手にリファクタやることはないわ
もちろんそれ込みの見積もりを出す
依頼もないのに勝手にリファクタやることはないわ
466仕様書無しさん
2018/10/03(水) 19:55:36.77 なんでこんなに変わってるんですか？
工数を増やさないでください
勝手にやった分の料金返してください
工数を増やさないでください
勝手にやった分の料金返してください
467仕様書無しさん
2018/10/03(水) 20:03:20.05 客からはその工数で金ふんだくってるくせに…
468KAC
2018/10/03(水) 23:24:31.41 本当にリファクタリングを綺麗にできるのなら、
そもそも設計が綺麗だから、リファクタリングなんて不要だろ？
まともに設計できずにぐちゃぐちゃ書いた奴が、
リファクタリングなんてできる訳が無い。
そもそも設計が綺麗だから、リファクタリングなんて不要だろ？
まともに設計できずにぐちゃぐちゃ書いた奴が、
リファクタリングなんてできる訳が無い。
469仕様書無しさん
2018/10/04(木) 01:10:25.08471仕様書無しさん
2018/10/04(木) 06:48:48.05 まともに設計できるかどうかじゃなくて、
将来を読めるかどうかだろ？
将来大規模になるなら、大規模な設計をするし、
そうでないなら小規模な設計をする
規模に応じて適切な設計は変わるのに
最初から規模が読めるとでも？
将来を読めるかどうかだろ？
将来大規模になるなら、大規模な設計をするし、
そうでないなら小規模な設計をする
規模に応じて適切な設計は変わるのに
最初から規模が読めるとでも？
472KAC
2018/10/04(木) 07:18:51.36 最近は設計できない奴の言い訳がすごいな。
まともに設計できてればそんなことでリファクタリングは発生しない。
まともに設計できてればそんなことでリファクタリングは発生しない。
473仕様書無しさん
2018/10/04(木) 07:50:59.20 まともの中身をまともに話せよ
具体的に
具体的に
474仕様書無しさん
2018/10/04(木) 10:03:32.69 そりゃ先の先の先まで考えて
必要ないことまで設計することだろｗ
必要ないことまで設計することだろｗ
475仕様書無しさん
2018/10/04(木) 21:36:10.68476仕様書無しさん
2018/10/04(木) 21:42:23.71 日本人は年末の大掃除が文化として根付いてる
なので「日々整理整頓してクリーンな状況を維持しよう」って外国人なら当たり前の感覚がどうしてもわからない
民族・文化のレベルでITが向いてないんだよね
なので「日々整理整頓してクリーンな状況を維持しよう」って外国人なら当たり前の感覚がどうしてもわからない
民族・文化のレベルでITが向いてないんだよね
477仕様書無しさん
2018/10/04(木) 21:46:24.65 設計を受け取ってコードを書くだけの人ほど>>472のような勘違いをする傾向が有るね
ドメインへの理解度は開発をすすめるにつれて深化する
ビジネスルールやニーズは時間経過で変化する
という2つの大前提を理解してないっぽい
ドメインへの理解度は開発をすすめるにつれて深化する
ビジネスルールやニーズは時間経過で変化する
という2つの大前提を理解してないっぽい
478仕様書無しさん
2018/10/04(木) 21:58:17.83 >>477
クソコテに反論したからと言っておまえがコーダーである事は隠せんよw
クソコテに反論したからと言っておまえがコーダーである事は隠せんよw
479KAC
2018/10/04(木) 22:05:46.37 もうコテも信用できない
俺だってKACのふりぐらいできる
俺だってKACのふりぐらいできる
482仕様書無しさん
2018/10/07(日) 17:21:06.95 リファクタリング出来る環境あるならテストも自動化されてるだろうに、何が問題なんだろ？
483仕様書無しさん
2018/10/07(日) 17:46:35.29 テストが自動化されてる現場なんてあるわけじゃないか！
だからリファクタリングは禁止！
だからリファクタリングは禁止！
485仕様書無しさん
2018/10/07(日) 18:48:09.16 まさか、人力でリファクタリングしといて、インターフェースは完全に互換だとかのたまうアホなん？
486仕様書無しさん
2018/10/08(月) 21:15:22.90 完全に互換です
動き違うのはもともと定義外の使い方してたからで
既存バグです
正しくなおしたわれわれのせいではない
動き違うのはもともと定義外の使い方してたからで
既存バグです
正しくなおしたわれわれのせいではない
487仕様書無しさん
2018/10/09(火) 09:59:33.83 齟齬があるのに観世互換とか、日本語が使えないのかな？
488仕様書無しさん
2018/10/10(水) 20:00:15.54 とりかえがきくから互換
489仕様書無しさん
2018/10/11(木) 12:28:59.32 金になるなら、やる
ならないのなら、やらない
ならないのなら、やらない
490仕様書無しさん
2018/10/11(木) 15:00:12.53 リファクタリングして、コードのメンテナンス性が上がって
メンテナンスに時間がかからなくなると、時間を節約で金になるんだよな
これをわかってないやつが多い
メンテナンスに時間がかからなくなると、時間を節約で金になるんだよな
これをわかってないやつが多い
491仕様書無しさん
2018/10/11(木) 15:03:03.80 ソース付きで売り切りの開発にリファクタリングなんて不要
492仕様書無しさん
2018/10/11(木) 15:04:09.91 ソースコードがなにもないところから生まれてくるとでも思ってるのだろうか？
493仕様書無しさん
2018/10/11(木) 15:04:41.03 切り売りするにはリファクタリングされきって
綺麗な設計になってないと無理だからなぁ
綺麗な設計になってないと無理だからなぁ
495仕様書無しさん
2018/10/11(木) 15:05:26.04 あ、無理っていうのは不可能って意味じゃないよ。
切り売りする時、綺麗な設計になってないと
修正が大量に必要なってコストがかかるという意味
切り売りする時、綺麗な設計になってないと
修正が大量に必要なってコストがかかるという意味
499仕様書無しさん
2018/10/11(木) 15:09:21.02 じゃあ売ってるのは使えないコードってことか
501仕様書無しさん
2018/10/11(木) 15:10:11.27 やっぱりリファクタリングしきった
綺麗なコードじゃないと売れないよね
綺麗なコードじゃないと売れないよね
502仕様書無しさん
2018/10/11(木) 15:10:45.43 動くんだから詐欺じゃないけどな。
505仕様書無しさん
2018/10/11(木) 15:12:59.57 切り売りってｗ
ライブラリとして無修正で提供できない時点で終わってるよね
ライブラリとして無修正で提供できない時点で終わってるよね
507仕様書無しさん
2018/10/11(木) 15:17:24.49 まずくても食べられれば売れますもんねｗｗｗ
508仕様書無しさん
2018/10/11(木) 15:17:40.13 おまえらはアホだな。
リファクタリングし切ったコードなんか売ったら、
顧客都合の仕様変更の仕事が来ないだろw
リファクタリングし切ったコードなんか売ったら、
顧客都合の仕様変更の仕事が来ないだろw
509仕様書無しさん
2018/10/11(木) 15:20:53.31 あぁ、時給で働いてんのなｗ
作業が減れば減るほど、稼げる金が減ると・
価値ではなく、作業時間で金額決めてるから
効率化すればするほど、稼げる金が減る。
地獄だね
作業が減れば減るほど、稼げる金が減ると・
価値ではなく、作業時間で金額決めてるから
効率化すればするほど、稼げる金が減る。
地獄だね
510仕様書無しさん
2018/10/11(木) 15:23:25.75 売り切り商売のどこが時給と関係してるんだろ？
511仕様書無しさん
2018/10/11(木) 15:28:20.99 >>510
ライブラリを売る場合、作業が0でもそのライブラリの価値として売るのは明白
何もしなくても金が稼げる
切り売りっていうのは、一つのプロダクトから、必要そうな部分を切り出して渡す。
まず切り出すという作業が必要になる。どこがどう影響してるかわからないから
そして仕様変更が来たら、追加でなにか作るのではなく、切り売りしたソースを修正する
クソ汚いコードだから、顧客には修正するのが無理。というのを利用して作業費用を受け取る
反対に言えば、作業しなければ金が稼げない
同じ金額を稼いでいたとしても、ライブラリは何もしないで稼いでいるが
切り売りにして作業しないと稼げないと思ってる。
作業時間＝金額 なのだから時給
ライブラリを売る場合、作業が0でもそのライブラリの価値として売るのは明白
何もしなくても金が稼げる
切り売りっていうのは、一つのプロダクトから、必要そうな部分を切り出して渡す。
まず切り出すという作業が必要になる。どこがどう影響してるかわからないから
そして仕様変更が来たら、追加でなにか作るのではなく、切り売りしたソースを修正する
クソ汚いコードだから、顧客には修正するのが無理。というのを利用して作業費用を受け取る
反対に言えば、作業しなければ金が稼げない
同じ金額を稼いでいたとしても、ライブラリは何もしないで稼いでいるが
切り売りにして作業しないと稼げないと思ってる。
作業時間＝金額 なのだから時給
512仕様書無しさん
2018/10/11(木) 15:59:39.41 あ？
誰が切り売りって言った？
売り切りだ。
売ったらそれでおしまいの商売な。
誰が切り売りって言った？
売り切りだ。
売ったらそれでおしまいの商売な。
515仕様書無しさん
2018/10/11(木) 19:36:16.50 >>513
人間は完璧ではない
システム化の対象が不変ではない
経営判断が不変ではない
情報源となる顧客が非協力的
最初から完璧なコードを書けない理由は沢山あるね
最初から完璧なコードが書けると思ってるうちはまだまだ初心者
人間は完璧ではない
システム化の対象が不変ではない
経営判断が不変ではない
情報源となる顧客が非協力的
最初から完璧なコードを書けない理由は沢山あるね
最初から完璧なコードが書けると思ってるうちはまだまだ初心者
516仕様書無しさん
2018/10/11(木) 19:56:17.84 リファクタしたいけど
きわめて明白なことに
根本的リファクタしたら2年ぐらい自分がやってた部分全部いらない
どうすればいい
きわめて明白なことに
根本的リファクタしたら2年ぐらい自分がやってた部分全部いらない
どうすればいい
517仕様書無しさん
2018/10/11(木) 20:11:38.77 いらないなら消せばいいじゃん
サンクコスト効果とか知らない？
いらないものをメンテするほうがコストがかかる
サンクコスト効果とか知らない？
いらないものをメンテするほうがコストがかかる
518仕様書無しさん
2018/10/11(木) 20:17:42.96 そのコストが俺の飯の種なんですけど
519仕様書無しさん
2018/10/11(木) 20:21:47.28 大きな猫用ドアと小さな猫用ドアがあって小さいほう作ってる
どっちのドアをくぐらせるか猫を誘導するのがまた
機能は実質まったく一緒
どっちのドアをくぐらせるか猫を誘導するのがまた
機能は実質まったく一緒
522仕様書無しさん
2018/10/11(木) 21:07:49.15 リファクタすると工数２、３倍
リファクタしないと指数関数的に複雑さがふえる
リファクタしないと指数関数的に複雑さがふえる
523仕様書無しさん
2018/10/11(木) 21:15:32.35 まともに書けないんじゃなくて、まともに書かないだけ。
時間をかければまともに書けるが、その時点では
そこまでする必要がなかったという判断
だが「その時点では」の話。時が変わればその判断も変わる
状況が変われば、その目的地も変わる。新しい目的地に向かって
既存のルートを変えることがリファクタリング
その反対の行為は、古い目的地のルートはそのままに古い目的地から
新しい目的地へルートを伸ばす。だから無駄が積み重なって最後には
入り組んだ迷路のようになる
時間をかければまともに書けるが、その時点では
そこまでする必要がなかったという判断
だが「その時点では」の話。時が変わればその判断も変わる
状況が変われば、その目的地も変わる。新しい目的地に向かって
既存のルートを変えることがリファクタリング
その反対の行為は、古い目的地のルートはそのままに古い目的地から
新しい目的地へルートを伸ばす。だから無駄が積み重なって最後には
入り組んだ迷路のようになる
525仕様書無しさん
2018/10/11(木) 22:00:48.50 まあ、リファクタリングするくらいなら新規で作った方が金も取れるからなぁ
526仕様書無しさん
2018/10/11(木) 22:13:18.61 >>524
リファクタリングって何かを修正するたびに、該当箇所だけを少しづつやるもんだぞ？
毎日状況が変わっていたら仕事にならんだろうが
お前みたいに、リファクタリングという特別な時間を使って大規模にまとめてやるって
間違った考え持ってるやつはいつ撲滅できるんだろうかね
ほんと害悪でしかないわ
リファクタリングって何かを修正するたびに、該当箇所だけを少しづつやるもんだぞ？
毎日状況が変わっていたら仕事にならんだろうが
お前みたいに、リファクタリングという特別な時間を使って大規模にまとめてやるって
間違った考え持ってるやつはいつ撲滅できるんだろうかね
ほんと害悪でしかないわ
528仕様書無しさん
2018/10/11(木) 22:26:11.34 >>527
だからさw
請け負いでやってても何でも
見積もりは作業工数から算出だろうに。
だからむしろ数時間で終わっちゃうリファクタリング作業なんかではたいした金は取れないんだよ。
電気屋が修理じゃなく新製品勧めて来るのと同じだ。
だからさw
請け負いでやってても何でも
見積もりは作業工数から算出だろうに。
だからむしろ数時間で終わっちゃうリファクタリング作業なんかではたいした金は取れないんだよ。
電気屋が修理じゃなく新製品勧めて来るのと同じだ。
529仕様書無しさん
2018/10/11(木) 22:54:07.97 >>524
そう
ずっと追いかけるんだよ
理想と現実の誤差がある程度の範囲に収まるように調整すんの
リファクタリングしないと誤差が大きくなりすぎて商品価値が暴落する
暴落してから焦って直そうとしても誤差が大きすぎてどっちに進めば理想に近くのかがわからなくなる
そう
ずっと追いかけるんだよ
理想と現実の誤差がある程度の範囲に収まるように調整すんの
リファクタリングしないと誤差が大きくなりすぎて商品価値が暴落する
暴落してから焦って直そうとしても誤差が大きすぎてどっちに進めば理想に近くのかがわからなくなる
532仕様書無しさん
2018/10/11(木) 23:14:59.67534仕様書無しさん
2018/10/11(木) 23:19:19.47 >>533
リファクタリングは不具合修正じゃないので
工数に入れていいってことになりますねぇｗ
2階建ての家を3階建てにする時、土台を補強するのは
不具合じゃないですよ？
ま、あんたは不具合は全部無償で修理するんでしょうがねｗ
リファクタリングは不具合修正じゃないので
工数に入れていいってことになりますねぇｗ
2階建ての家を3階建てにする時、土台を補強するのは
不具合じゃないですよ？
ま、あんたは不具合は全部無償で修理するんでしょうがねｗ
535仕様書無しさん
2018/10/11(木) 23:25:18.04 新規開発なら最初から三階建てだろw
536仕様書無しさん
2018/10/11(木) 23:33:59.67 新規開発のお金が取れるぐらいなら
リファクタリングのお金も当然取れる
リファクタリングのお金も当然取れる
537仕様書無しさん
2018/10/11(木) 23:35:41.03 リファクタに金がかかるってことは
リファクタで開発が楽になってないんだから
そのリファクタは間違いだと結論できる
リファクタで開発が楽になってないんだから
そのリファクタは間違いだと結論できる
540仕様書無しさん
2018/10/11(木) 23:43:14.80 >>537
おいおいｗ
リファクタリングで金がかかるのは最初で
開発が楽になるのは次回以降に決まってるだろ
そんなこともわからないのか？
しかも次回以降、請求金額はリファクタリングしてない場合の
金額にしておけば楽して稼げるんだぜ？
リスクゼロで金を稼ぐいい方法だ。
おいおいｗ
リファクタリングで金がかかるのは最初で
開発が楽になるのは次回以降に決まってるだろ
そんなこともわからないのか？
しかも次回以降、請求金額はリファクタリングしてない場合の
金額にしておけば楽して稼げるんだぜ？
リスクゼロで金を稼ぐいい方法だ。
541仕様書無しさん
2018/10/11(木) 23:43:34.33 新しいハードに新しい技術で作ったアプリと、
ガラケーのアプリに機能追加したアプリでもいいよ。
ガラケーのアプリに機能追加したアプリでもいいよ。
542仕様書無しさん
2018/10/11(木) 23:44:17.16 ハードを変えるという条件を追加するな
543仕様書無しさん
2018/10/11(木) 23:44:35.24 これからはリコンストラクトって呼ぼう
リファクタなんて陰謀くさい名前でいうからコストを考える気にならんのだ
リファクタなんて陰謀くさい名前でいうからコストを考える気にならんのだ
544仕様書無しさん
2018/10/11(木) 23:45:04.70 名前なんてどうでもいいわｗ
546仕様書無しさん
2018/10/11(木) 23:45:42.71548仕様書無しさん
2018/10/11(木) 23:47:13.10 名前が心理に与える影響をばかにしてはいけない
人間は絶望的にいい加減
人間は絶望的にいい加減
549仕様書無しさん
2018/10/11(木) 23:47:50.37550仕様書無しさん
2018/10/11(木) 23:49:06.68 まず、リファクタリングに金を出す客は居ないからなぁw
551仕様書無しさん
2018/10/11(木) 23:49:35.44 >>545
> だいたいどんなリファクタリングを先回りしてやってても
YAGNIって知ってるか？ 今必要になっていないならやらない。
必要になったときにやる。ということだ
先回りしないからこそあとでリファクタリングするんだよ。
先回りしてリファクタリングとか矛盾そのものだ
> だいたいどんなリファクタリングを先回りしてやってても
YAGNIって知ってるか？ 今必要になっていないならやらない。
必要になったときにやる。ということだ
先回りしないからこそあとでリファクタリングするんだよ。
先回りしてリファクタリングとか矛盾そのものだ
554仕様書無しさん
2018/10/11(木) 23:51:51.88555仕様書無しさん
2018/10/11(木) 23:52:14.62556仕様書無しさん
2018/10/11(木) 23:53:21.87559仕様書無しさん
2018/10/11(木) 23:55:51.21 > リファクタリング自体に金なんか誰も出さないから。
作業時間に含めるのが常識だから
当たり前の話だな。
リファクタリングで別に見積もりだせーって言っているやつが
リファクタリングで金だせないだろーって言ってる矛盾
なら作業時間に含めればいいだけなのに
その発想が出ない。おかしい。馬鹿じゃなくておかしい
作業時間に含めるのが常識だから
当たり前の話だな。
リファクタリングで別に見積もりだせーって言っているやつが
リファクタリングで金だせないだろーって言ってる矛盾
なら作業時間に含めればいいだけなのに
その発想が出ない。おかしい。馬鹿じゃなくておかしい
560仕様書無しさん
2018/10/11(木) 23:57:15.08566仕様書無しさん
2018/10/12(金) 00:00:57.18 >>563
もしかしてプロならバグを入れないと思ってる？
どんなコードでも一瞬で理解できると思ってる？
汚いコードであればあるほど、バグが含まれるし
どこがどう影響しているかなんて、わからなくなるんだが
だからリファクタリングが必要なの
もしかしてプロならバグを入れないと思ってる？
どんなコードでも一瞬で理解できると思ってる？
汚いコードであればあるほど、バグが含まれるし
どこがどう影響しているかなんて、わからなくなるんだが
だからリファクタリングが必要なの
567仕様書無しさん
2018/10/12(金) 00:02:00.50 おれは一切バグを出さない方法を知ってる。
さわらなきゃいいんだ
さわらなきゃいいんだ
568仕様書無しさん
2018/10/12(金) 00:02:05.75569仕様書無しさん
2018/10/12(金) 00:02:49.28570仕様書無しさん
2018/10/12(金) 00:02:55.85571仕様書無しさん
2018/10/12(金) 00:04:29.82 じゃあリファクタで余分な金なんかとれないじゃん
573仕様書無しさん
2018/10/12(金) 00:05:36.00 >>569
> この仕事何十年もやってる人なら処理内容からだいたいの工数は頭ん中にあるんだよ。
はは、何十年もやっていてそれか。
既存のコードの修正の工数は、既存のコードがどうなってるかで変わってくる
メンテナンスがしやすいコードとそうでないコードでは
修正の時間は何十倍も違ってくる
だから他人が作った見たこともないコードの修正の見積もりなんかしない
自分の仕事に責任を持っているからだ
> この仕事何十年もやってる人なら処理内容からだいたいの工数は頭ん中にあるんだよ。
はは、何十年もやっていてそれか。
既存のコードの修正の工数は、既存のコードがどうなってるかで変わってくる
メンテナンスがしやすいコードとそうでないコードでは
修正の時間は何十倍も違ってくる
だから他人が作った見たこともないコードの修正の見積もりなんかしない
自分の仕事に責任を持っているからだ
574仕様書無しさん
2018/10/12(金) 00:09:07.35 >>573
それも込みでだいたいの工数なんか決まってんだよ。
見た事も無いコードならリファクタリングが必要かすらわからないんだから、そもそも前提が意味がないって事に気づけ。
そして見た事も無いコードの修正作業の見積もりなんか普通はしない。見積もりに際してコードを提供してもらうのが普通だぞ。
それも込みでだいたいの工数なんか決まってんだよ。
見た事も無いコードならリファクタリングが必要かすらわからないんだから、そもそも前提が意味がないって事に気づけ。
そして見た事も無いコードの修正作業の見積もりなんか普通はしない。見積もりに際してコードを提供してもらうのが普通だぞ。
575仕様書無しさん
2018/10/12(金) 00:11:11.83 たぶん口だけだな
見積まともにできるやつは
改修による影響範囲とかパスとか
画面とかテストケースの数とか具体的に見積もる
コードがぐちゃぐちゃだからリファクタしたいなんていうやつに
稼働コードに指一本触れさせてはいけない
彼は優れたコードが書けるのではない。単に理解力が劣っているんだ。
見積まともにできるやつは
改修による影響範囲とかパスとか
画面とかテストケースの数とか具体的に見積もる
コードがぐちゃぐちゃだからリファクタしたいなんていうやつに
稼働コードに指一本触れさせてはいけない
彼は優れたコードが書けるのではない。単に理解力が劣っているんだ。
576仕様書無しさん
2018/10/12(金) 00:19:00.10 自分で書いたコードを自分の責任で弄り回すのは勝手にやればいい。
リファクタリングでも何でも好きな名目でやってれ。
でも、会社組織に組み込まれてる身分では、責任なんか取れないんだから、余計な事はするな。
それだけ。
リファクタリングでも何でも好きな名目でやってれ。
でも、会社組織に組み込まれてる身分では、責任なんか取れないんだから、余計な事はするな。
それだけ。
577KAC
2018/10/12(金) 00:46:04.92578KAC
2018/10/12(金) 00:51:10.56 >>575
概ね同意。
コードがグチャグチャになった根本原因すら理解できてない奴が
リファクタリングしたところでまともなコードにはならないのは明白だし。
時間と金の無駄どころが不要なリスクを上げるだけだろう。
概ね同意。
コードがグチャグチャになった根本原因すら理解できてない奴が
リファクタリングしたところでまともなコードにはならないのは明白だし。
時間と金の無駄どころが不要なリスクを上げるだけだろう。
579仕様書無しさん
2018/10/12(金) 06:53:26.39582KAC
2018/10/12(金) 07:54:59.96583仕様書無しさん
2018/10/12(金) 10:06:25.50 客先レビューすると、客からリファクタリング求めらる事もあるんだよな。でも工数は据え置きってのが普通だ。
585仕様書無しさん
2018/10/12(金) 11:41:44.63 >>583
そりゃリファクタリングが要求されるような
読みづらいコードは、バグと一緒だからね
だから、最初からリファクタリング込みで工数を出すんだよ。
動けば完成じゃない。客から文句を言われないものを作るまでが仕事だ
そりゃリファクタリングが要求されるような
読みづらいコードは、バグと一緒だからね
だから、最初からリファクタリング込みで工数を出すんだよ。
動けば完成じゃない。客から文句を言われないものを作るまでが仕事だ
586仕様書無しさん
2018/10/12(金) 14:19:06.40 読みづらいからって修正要求される事は無いなぁ
関数ヘッダのコメントが無いとかくらいならあるけどさ。
リファクタリング求められる一番多いのは、
同じ事をコピペかってくらい繰り返してたりするコードとかかなぁ
関数ヘッダのコメントが無いとかくらいならあるけどさ。
リファクタリング求められる一番多いのは、
同じ事をコピペかってくらい繰り返してたりするコードとかかなぁ
587仕様書無しさん
2018/10/12(金) 18:48:47.73 読みづらいコードとバグは違うだろw変なやつだなあw
588仕様書無しさん
2018/10/12(金) 20:00:21.60 繰り返しは目に見えてテスト工数にはねるのでリファクタされてしまう
条件分岐も
やっぱりまぎらわしい名前とか処理順序とか
ややこしい変数渡しがいちばんきくな
条件分岐も
やっぱりまぎらわしい名前とか処理順序とか
ややこしい変数渡しがいちばんきくな
590仕様書無しさん
2018/10/12(金) 21:04:58.85 ○○と一緒とかいうな
思考がめっちゃ雑になる
みんなは区別がつくから別の名前で呼んでるんだ
つまり
おまえだけ区別がつかないまぬけということになる
思考がめっちゃ雑になる
みんなは区別がつくから別の名前で呼んでるんだ
つまり
おまえだけ区別がつかないまぬけということになる
591仕様書無しさん
2018/10/12(金) 21:36:10.05 読みづらいコードはバグではない・・・そのとおり
読みづらいコードはバグと一緒で無償修正の対象・・・そのとおり
読みづらいコードはバグと一緒で無償修正の対象・・・そのとおり
593仕様書無しさん
2018/10/12(金) 22:12:19.93 下流が下流に納品する特殊事例をあげられましてもw
ソースコードなんか読みませんからw
ソースコードなんか読みませんからw
594仕様書無しさん
2018/10/12(金) 22:24:05.39595仕様書無しさん
2018/10/12(金) 23:05:45.10 執拗な下流押しw
596仕様書無しさん
2018/10/12(金) 23:36:20.41 ソース持ってなきゃ相手に依存しっぱなしになってしまう
何か仕込まれてもわからない
コードは権力そのものだ
コード読めないコード読まない上流など
金の上流なだけで立場は最下層
どれほど愚かであればそれを誇る気になるのだろう
何か仕込まれてもわからない
コードは権力そのものだ
コード読めないコード読まない上流など
金の上流なだけで立場は最下層
どれほど愚かであればそれを誇る気になるのだろう
597仕様書無しさん
2018/10/12(金) 23:55:25.51 自社から出す商品の品質がどうでもいいなんてアホ居るんだw
598仕様書無しさん
2018/10/12(金) 23:56:38.24 いやごめん
そんな上流いるわけないな
下流だけど適当に煽ってみただけだよね
そんな上流いるわけないな
下流だけど適当に煽ってみただけだよね
600仕様書無しさん
2018/10/13(土) 00:19:37.81 >>599
読まないしテストもろくな検証もしてない
だからむしられるだけの庶民
MSに勝手にメール見てもいいことにされ、いりもしないOSを無理やり入れさせられ
プライベートをくまなく抜き取られ
せっかく買ったパソコンを自分のもののように好き勝手にいじりまわされても
あきらめて黙って使うしかない
読まないしテストもろくな検証もしてない
だからむしられるだけの庶民
MSに勝手にメール見てもいいことにされ、いりもしないOSを無理やり入れさせられ
プライベートをくまなく抜き取られ
せっかく買ったパソコンを自分のもののように好き勝手にいじりまわされても
あきらめて黙って使うしかない
601仕様書無しさん
2018/10/14(日) 20:02:01.74 コードメトリクスの上限とか指示されないのかな
602仕様書無しさん
2018/10/15(月) 21:12:59.20 私たち日本人の、日本国憲法を改正しましょう。
総ム省の、『憲法改正國民投票法』、でググって
みてください。拡散も含め、お願い致します。
総ム省の、『憲法改正國民投票法』、でググって
みてください。拡散も含め、お願い致します。
603仕様書無しさん
2018/10/17(水) 08:13:37.09 リファクタリングが必要なとき、それは、システムをそもそもリプレイスしないといけないとき。
よって、リファクタリングなんぞ不要。
よって、リファクタリングなんぞ不要。
604仕様書無しさん
2018/10/17(水) 08:33:54.64605仕様書無しさん
2018/10/17(水) 09:03:34.82 むしろいつまで古いシステム使うつもりなんだって話
ハードの耐用年数だってあんだろ？
ハードの耐用年数だってあんだろ？
606仕様書無しさん
2018/10/17(水) 09:09:26.37607仕様書無しさん
2018/10/17(水) 20:32:07.89 移行プロジェクトで
既存システムにリプレースされそうな勢い
いろいろシャレにならない
既存システムにリプレースされそうな勢い
いろいろシャレにならない
610仕様書無しさん
2018/10/18(木) 21:58:06.14611仕様書無しさん
2018/10/18(木) 22:00:52.92 ちゃんと動いてるもんになんでわざわざ手を加えて金取ろうとするの？
612仕様書無しさん
2018/10/18(木) 22:09:10.01 >>611
リファクタだけで金取るビジネスなんて聞いたことないよ
機能追加や仕様変更時に、手を入れやすいようにリファクタするくらいだろ
もちろんリファクタの工数もスケジュールに入れる
当然だが、もしリファクタやらない方が工数が減るならリファクタはやらん
リファクタだけで金取るビジネスなんて聞いたことないよ
機能追加や仕様変更時に、手を入れやすいようにリファクタするくらいだろ
もちろんリファクタの工数もスケジュールに入れる
当然だが、もしリファクタやらない方が工数が減るならリファクタはやらん
614仕様書無しさん
2018/10/18(木) 23:36:15.00 べつのことがしたいからじゃないの
616仕様書無しさん
2018/10/19(金) 08:27:28.18 >>615
そう、改修依頼があってはじめてリファクタを検討する
リファクタした方が工数が少なそうならリファクしてから改修に着手するし
しない方が工数が少なそうならそのまま着手する
あと当然、リプレイスした方が工数が少なそうならリプレイスする
そう、改修依頼があってはじめてリファクタを検討する
リファクタした方が工数が少なそうならリファクしてから改修に着手するし
しない方が工数が少なそうならそのまま着手する
あと当然、リプレイスした方が工数が少なそうならリプレイスする
617仕様書無しさん
2018/10/19(金) 09:55:32.55 工数で考えるのはまだアマチュア。
プロなら金額で考えれ
プロなら金額で考えれ
619仕様書無しさん
2018/10/19(金) 11:06:03.34 立場？
金が全てに優先するだろw
金が全てに優先するだろw
620仕様書無しさん
2018/10/19(金) 12:09:00.13 社内では工数、社外では金だろ
621仕様書無しさん
2018/10/19(金) 12:20:49.04 客に対しては金、従業員に対しても金。
ただし、ベクトルはそれぞれ真逆だがなw
ただし、ベクトルはそれぞれ真逆だがなw
623仕様書無しさん
2018/10/20(土) 00:38:17.81 かしむら最低だな
624仕様書無しさん
2018/10/20(土) 10:16:15.04 客や従業員から見ても、経営者の思いとは逆ベクトルだけどな。
625仕様書無しさん
2018/10/20(土) 10:43:39.59 客
んなことより、要望の品作って
んなことより、要望の品作って
626仕様書無しさん
2018/10/20(土) 18:28:30.36 リファクタがリプレイスまでにちょくちょく必要なほど、毎回いきあたりばったりの汚いソースコードの開発会社か
発注したくねー
発注したくねー
627仕様書無しさん
2018/10/20(土) 18:44:51.16 >>626
何度言っても理解しなよな。
リファクタリングは、別途時間をとってやるってものじゃないの
ちょくちょく必要なんじゃなくて、
コード書くときにほぼ毎回必要なものなの
汚いからリファクタリングするんじゃないんだよ
テストコード書いてそれに通るコード書いて
リファクタリングしながら作り上げるの
プログラマが「できました」と言うまでに
何度もリファクタリングが行われる。
何度言っても理解しなよな。
リファクタリングは、別途時間をとってやるってものじゃないの
ちょくちょく必要なんじゃなくて、
コード書くときにほぼ毎回必要なものなの
汚いからリファクタリングするんじゃないんだよ
テストコード書いてそれに通るコード書いて
リファクタリングしながら作り上げるの
プログラマが「できました」と言うまでに
何度もリファクタリングが行われる。
629仕様書無しさん
2018/10/20(土) 19:38:54.60 リファクタはテスト工数を減らすために改修前にやるもの
630仕様書無しさん
2018/10/20(土) 20:11:23.63631仕様書無しさん
2018/10/20(土) 20:34:46.03633仕様書無しさん
2018/10/20(土) 20:58:54.14 リファクタリングを理解しない人はコスト意識がないんだよね
金を出すのは客だから知ったこっちゃないんだろうけど
コストだけじゃなくて開発時間も伸びるから結局いつも
時間足りなくなってクレームの元になってる
金を出すのは客だから知ったこっちゃないんだろうけど
コストだけじゃなくて開発時間も伸びるから結局いつも
時間足りなくなってクレームの元になってる
634仕様書無しさん
2018/10/20(土) 21:06:00.07 コードを共有するなって話だからリファクタリングとは全く関係ないな。
コードをコピペしてるからバグが出たら、体中に転移した
がん細胞探すように、全体を調べないといけない
一箇所直しただけでは、他の部分には影響しない（＝バグがあるまま）
コードをコピペしてるからバグが出たら、体中に転移した
がん細胞探すように、全体を調べないといけない
一箇所直しただけでは、他の部分には影響しない（＝バグがあるまま）
636仕様書無しさん
2018/10/20(土) 23:04:48.94 リファクタの欠点はどれだけやっても終わりがないことだ
コスト意識がないと
自己満足と脅迫概念にかられて延々非生産的な作業を続けることになる
コスト意識がないと
自己満足と脅迫概念にかられて延々非生産的な作業を続けることになる
638仕様書無しさん
2018/10/21(日) 01:41:05.39639仕様書無しさん
2018/10/21(日) 02:10:11.45 リファクタリングって一旦壊して再構築するんだから
テストし直すのは当たり前だよ
テストし直すのは当たり前だよ
640仕様書無しさん
2018/10/21(日) 02:32:19.64 > リファクタリングって一旦壊して再構築するんだから
壊すってどういう事？
壊すってどういう事？
642仕様書無しさん
2018/10/21(日) 06:11:25.20 リファクタで、最適化しているつもりになって、毎回、ソースコードを破壊していくやつ
643仕様書無しさん
2018/10/21(日) 06:15:32.12 リファクタリングが一旦壊すってどういう意味だろうか？
644仕様書無しさん
2018/10/21(日) 06:16:43.21 >>642
最適化はリファクタリングか？
http://bliki-ja.github.io/IsOptimizationRefactoring/
> 最適化とリファクタリングはどちらも変化を伴うものだが
> （なかには最適化かつリファクタリングとなる変化もあるが）、両者は別物だと私は考えている。
>
> なぜなら、両者の目的が異なるからである。リファクタリングは、
> コードを理解しやすくするためである。最適化は、プログラムを速くするためである。
最適化はリファクタリングか？
http://bliki-ja.github.io/IsOptimizationRefactoring/
> 最適化とリファクタリングはどちらも変化を伴うものだが
> （なかには最適化かつリファクタリングとなる変化もあるが）、両者は別物だと私は考えている。
>
> なぜなら、両者の目的が異なるからである。リファクタリングは、
> コードを理解しやすくするためである。最適化は、プログラムを速くするためである。
645仕様書無しさん
2018/10/21(日) 06:47:47.64646仕様書無しさん
2018/10/21(日) 06:51:04.63 よくもまぁ、マーチン・ファウラーにアホとか言えるもんだわ
お前はこの業界で世界に誇れるレベルの実績があるのか？
お前はこの業界で世界に誇れるレベルの実績があるのか？
647仕様書無しさん
2018/10/21(日) 07:09:30.10648仕様書無しさん
2018/10/21(日) 07:12:41.82 マーチン・ファウラーってあれだろ？
開発手法を開発しようとしているのやらｗｗｗ
それだけいろんな手法を開発してもなお改善しない。
これが何を示すのかわからん馬鹿ってことだ。
開発手法を開発しようとしているのやらｗｗｗ
それだけいろんな手法を開発してもなお改善しない。
これが何を示すのかわからん馬鹿ってことだ。
649仕様書無しさん
2018/10/21(日) 07:13:33.89 ガキが重箱の隅をつついてなんか叫んでるなぁｗ
この記事に最適化は速くする以外の目的もあるといった所で
「あぁ、そうだな」って言われて終わりだろうに
論点は「リファクタリングと最適化は違う」なんだから
この記事に最適化は速くする以外の目的もあるといった所で
「あぁ、そうだな」って言われて終わりだろうに
論点は「リファクタリングと最適化は違う」なんだから
650仕様書無しさん
2018/10/21(日) 07:20:42.62 辞書に最適化とは、速度を改善することである。
って書いてある辞書あるの？ｗｗｗねえ？ねえ？ねえ？
勝手に、言葉を変更しないでくださいな。大混乱ですわ。ｗｗｗｗ
って書いてある辞書あるの？ｗｗｗねえ？ねえ？ねえ？
勝手に、言葉を変更しないでくださいな。大混乱ですわ。ｗｗｗｗ
651仕様書無しさん
2018/10/21(日) 07:21:13.50 キチガイ認定していい？
653仕様書無しさん
2018/10/21(日) 07:22:33.83 「リファクタリングと最適化は違う」
この場合、「リファクタリング」「最適化」という２単語は極めて重い意味を持つ。
それを「重箱の隅」と片付ける馬鹿ｗ
この場合、「リファクタリング」「最適化」という２単語は極めて重い意味を持つ。
それを「重箱の隅」と片付ける馬鹿ｗ
654仕様書無しさん
2018/10/21(日) 07:24:02.39 重箱の隅と言ってるのは「リファクタリング」と「最適化」の比較の話で
「最適化とは速度以外のものもある」ということだよ。
お前は速度以外の最適化に何があると思ってるのか？
それがリファクタリングの比較と同影響が出るのかを答えなさい
「最適化とは速度以外のものもある」ということだよ。
お前は速度以外の最適化に何があると思ってるのか？
それがリファクタリングの比較と同影響が出るのかを答えなさい
655仕様書無しさん
2018/10/21(日) 07:24:40.84 コードを読みやすくすることは最適化って言いませんぇね（大爆笑）
657仕様書無しさん
2018/10/21(日) 07:29:14.81 コードを理解しやすくするための最適化
という日本語は存在できないんでしょうか？？？？？ｗｗｗｗ
という日本語は存在できないんでしょうか？？？？？ｗｗｗｗ
658仕様書無しさん
2018/10/21(日) 07:30:11.97 ちなみに、
俺は、著者を馬鹿にしてません。
読者のお前を馬鹿にしています。
俺は、著者を馬鹿にしてません。
読者のお前を馬鹿にしています。
661仕様書無しさん
2018/10/21(日) 07:47:33.05 馬鹿「りふぁくたー！」
周囲「新人さん、あの「りふぁくたー！」って言ってる馬鹿のコード使えないから、同じとこAさんが担当してるから。そっちと調整してね。」
周囲「新人さん、あの「りふぁくたー！」って言ってる馬鹿のコード使えないから、同じとこAさんが担当してるから。そっちと調整してね。」
663仕様書無しさん
2018/10/21(日) 07:48:46.51 stringクラスを変更するって平気で言い出すキチガイ
664仕様書無しさん
2018/10/21(日) 08:11:56.75 リファクタリングと最適化は違うものですよ
665仕様書無しさん
2018/10/21(日) 08:14:14.94 >>663
テストしてないの？
テストしていて、変更しても動きが変わらなければ問題ないでしょ
（前提：リファクタリングは、変更しても動きが変わらない。
動きが変わるものはリファクタリングにはあたらない）
テストしてないの？
テストしていて、変更しても動きが変わらなければ問題ないでしょ
（前提：リファクタリングは、変更しても動きが変わらない。
動きが変わるものはリファクタリングにはあたらない）
666仕様書無しさん
2018/10/21(日) 08:19:00.64 >>631
> 円周率が3.14じゃ精度が足りない計算が必要になっても
> 既存の円周率とは別に用意して
あの、リファクタリングは変えないものなので
精度を増やすことは、リファクタリングではなくて単なる仕様変更なんですけど？
なんてことはないリファクタリングの意味をわかってないだけかｗ
> 円周率が3.14じゃ精度が足りない計算が必要になっても
> 既存の円周率とは別に用意して
あの、リファクタリングは変えないものなので
精度を増やすことは、リファクタリングではなくて単なる仕様変更なんですけど？
なんてことはないリファクタリングの意味をわかってないだけかｗ
667仕様書無しさん
2018/10/21(日) 08:22:12.52 >>631
> 円周率が3.14じゃ精度が足りない計算が必要になっても
> 既存の円周率とは別に用意して
> 既存には一切手を付けない
別に用意する必要はないな。
（リファクタリングではなく）仕様変更の前後で互換性があればいいだけ
俺なら精度を上げるための省略可能なオプションを追加する
> 円周率が3.14じゃ精度が足りない計算が必要になっても
> 既存の円周率とは別に用意して
> 既存には一切手を付けない
別に用意する必要はないな。
（リファクタリングではなく）仕様変更の前後で互換性があればいいだけ
俺なら精度を上げるための省略可能なオプションを追加する
668仕様書無しさん
2018/10/21(日) 08:28:49.48 リファクタリング・・・動きは変えない。だから既存の自動テストがそのまま通る
仕様変更・・・動きが変わる。だから全部テストしないといけない
結論。リファクタリングはしてもよいが、仕様変更はするな。
仕様変更・・・動きが変わる。だから全部テストしないといけない
結論。リファクタリングはしてもよいが、仕様変更はするな。
670仕様書無しさん
2018/10/21(日) 08:51:49.32676仕様書無しさん
2018/10/21(日) 08:56:21.55 リファクタリング（動きが変わらないもの）の話で
仕様変更を持ってくるやつは、何も理解してないとしか言えないな
仕様変更を持ってくるやつは、何も理解してないとしか言えないな
679仕様書無しさん
2018/10/21(日) 08:58:11.51682仕様書無しさん
2018/10/21(日) 08:59:50.61683仕様書無しさん
2018/10/21(日) 09:00:03.73 リファクタリングもエンハンスも元あるものから手を加えるなら
それは一度壊す事を意味する
言葉上の意味だがこれが理解出来ないからテストを軽視する
それは一度壊す事を意味する
言葉上の意味だがこれが理解出来ないからテストを軽視する
684仕様書無しさん
2018/10/21(日) 09:00:09.32686仕様書無しさん
2018/10/21(日) 09:00:34.32691仕様書無しさん
2018/10/21(日) 09:02:43.75693仕様書無しさん
2018/10/21(日) 09:03:42.47 そもそも円周率の精度変更ってなんなんだ？
円周率取得関数の話してんの？
円周率は固定値なんだから、変更すべきコードなんて無いじゃん
でだしからおかしいのかよｗ
円周率取得関数の話してんの？
円周率は固定値なんだから、変更すべきコードなんて無いじゃん
でだしからおかしいのかよｗ
694仕様書無しさん
2018/10/21(日) 09:04:03.53 >>686
端的に言えば元あるものに手を加えて変更する事
変更してる最中は機能してないんだから壊している
作り上げてテストして元あるものと同等であることが確認出来て
初めてリファクタリングしたと言っていい
端的に言えば元あるものに手を加えて変更する事
変更してる最中は機能してないんだから壊している
作り上げてテストして元あるものと同等であることが確認出来て
初めてリファクタリングしたと言っていい
695仕様書無しさん
2018/10/21(日) 09:04:30.44 × 円周率は固定値なんだから、変更すべきコードなんて無いじゃん
○ 円周率は固定値なんだから、リファクタリングすべきコードなんて無いじゃん
○ 円周率は固定値なんだから、リファクタリングすべきコードなんて無いじゃん
696仕様書無しさん
2018/10/21(日) 09:05:46.67 >>694
> 端的に言えば元あるものに手を加えて変更する事
> 変更してる最中は機能してないんだから壊している
え？ 変更ってコミット単位じゃないの？
コミット単位では壊さないよ
まさか、ファイル保存した単位で壊してるって言ってる？
> 端的に言えば元あるものに手を加えて変更する事
> 変更してる最中は機能してないんだから壊している
え？ 変更ってコミット単位じゃないの？
コミット単位では壊さないよ
まさか、ファイル保存した単位で壊してるって言ってる？
701仕様書無しさん
2018/10/21(日) 09:10:55.30704仕様書無しさん
2018/10/21(日) 09:24:12.38 今回の追加分の処理の円周率は3.1415までは必要
既存の処理は3.14で十分
このとき既存処理と追加分の処理とで同じ円周率3.1415を共通で使うかどうかって話だな
ビジネスならNo
既存の処理を変更することになる
既存の処理は3.14で十分
このとき既存処理と追加分の処理とで同じ円周率3.1415を共通で使うかどうかって話だな
ビジネスならNo
既存の処理を変更することになる
705仕様書無しさん
2018/10/21(日) 09:28:18.38 今回の追加分の処理の円周率は3.1415までは必要
既存の処理は3.14で十分
このとき既存処理と追加分の処理とで同じ円周率3.1415を共通で使うかどうかって話だな
ビジネスならNo
既存の処理を変更することになる
既存の処理は3.14で十分
このとき既存処理と追加分の処理とで同じ円周率3.1415を共通で使うかどうかって話だな
ビジネスならNo
既存の処理を変更することになる
707仕様書無しさん
2018/10/21(日) 09:51:52.30 >>704
ビジネスならNoとか意味わからんし、こっちが恥ずかしくなるレベルｗ
仕様による。それだけ。仕様書がないのは論外
> このとき既存処理と追加分の処理とで同じ円周率3.1415を
共通で使うならば、それは仕様変更。なぜなら既存の処理の動きが変わってるから。
なお、動きが変わるのでこれはリファクタリングではない（リファクタリングと関係ない話）
仕様変更なのでいままでのテストは通らない可能性があるだろう
まあリファクタリングではないので、それはしかたない
> このとき既存処理と追加分の処理とで同じ円周率3.1415を
共通で使わないならば、既存の処理は変わらない
既存の処理は変わらないのであれば、追加分の処理を除いた既存の処理はリファクタリング可能（必須ではない）
既存の処理に関しては仕様変更しないので、いままでのテストはそのまま通る
追加分の処理は、そもそも存在しなかったものなのだから、この文は当然リファクタリングではない
ビジネスならNoとか意味わからんし、こっちが恥ずかしくなるレベルｗ
仕様による。それだけ。仕様書がないのは論外
> このとき既存処理と追加分の処理とで同じ円周率3.1415を
共通で使うならば、それは仕様変更。なぜなら既存の処理の動きが変わってるから。
なお、動きが変わるのでこれはリファクタリングではない（リファクタリングと関係ない話）
仕様変更なのでいままでのテストは通らない可能性があるだろう
まあリファクタリングではないので、それはしかたない
> このとき既存処理と追加分の処理とで同じ円周率3.1415を
共通で使わないならば、既存の処理は変わらない
既存の処理は変わらないのであれば、追加分の処理を除いた既存の処理はリファクタリング可能（必須ではない）
既存の処理に関しては仕様変更しないので、いままでのテストはそのまま通る
追加分の処理は、そもそも存在しなかったものなのだから、この文は当然リファクタリングではない
708仕様書無しさん
2018/10/21(日) 09:52:00.90709仕様書無しさん
2018/10/21(日) 09:52:59.68 >>703
質問に答えてくれないので、追加で追い打ちｗ
つまりサーバーにアップロードする前
個人のコンピューターの中でだけ
一時的に壊れてるってことですか？
他の人は壊れたことに気づかない＝壊れてないってことですか？
質問に答えてくれないので、追加で追い打ちｗ
つまりサーバーにアップロードする前
個人のコンピューターの中でだけ
一時的に壊れてるってことですか？
他の人は壊れたことに気づかない＝壊れてないってことですか？
711仕様書無しさん
2018/10/21(日) 09:54:02.20 コミット単位ってなに？
712仕様書無しさん
2018/10/21(日) 09:58:56.26 >>711
バージョン管理ソフト用語で、変更の1単位を表す
ソースコードの修正は複数のファイルにまたがることがあるが
その複数のファイルの変更をまとめて一つにしたものがコミット
通常はコミットごとにテストを実行し壊れていないことを確認する
バージョン管理ソフト用語で、変更の1単位を表す
ソースコードの修正は複数のファイルにまたがることがあるが
その複数のファイルの変更をまとめて一つにしたものがコミット
通常はコミットごとにテストを実行し壊れていないことを確認する
713仕様書無しさん
2018/10/21(日) 10:01:27.12 >>710
他人は関係なく自分で今プログラムをどういう状態にしようとしているか
編集を始めた時点で壊し始めている
当然他人にそんな事認識できるわけない
ローカルで勝手にやってる事が壊してるというのはおかしいというなら
俺とは考えが違う
他人は関係なく自分で今プログラムをどういう状態にしようとしているか
編集を始めた時点で壊し始めている
当然他人にそんな事認識できるわけない
ローカルで勝手にやってる事が壊してるというのはおかしいというなら
俺とは考えが違う
714仕様書無しさん
2018/10/21(日) 10:03:58.62716仕様書無しさん
2018/10/21(日) 10:07:16.67 ソースコードの修正途中に一時的に動かなくなることを壊すと言ってるのなら、
それをリリースするわけでもないので大したことじゃないから
心配する必要はなにもないってことになるのでいいんですよ。
それをリリースするわけでもないので大したことじゃないから
心配する必要はなにもないってことになるのでいいんですよ。
717仕様書無しさん
2018/10/21(日) 10:08:54.02 （自動化された）テストが重要なのは、壊れてないことを保証するためですからね
一時的に壊れてもコミット時に壊れてなければ問題ないので
リファクタリング（動きを変えない）の場合はテストを変える必要もないので、
機能追加と違って、安心して変更ができるわけなんですね。
一時的に壊れてもコミット時に壊れてなければ問題ないので
リファクタリング（動きを変えない）の場合はテストを変える必要もないので、
機能追加と違って、安心して変更ができるわけなんですね。
718仕様書無しさん
2018/10/21(日) 10:52:10.73 細井隼人最低だな
719仕様書無しさん
2018/10/21(日) 11:33:37.79 揚げ足取りしかできなくて自分の意見が表明できないなんて悲しいな
720仕様書無しさん
2018/10/21(日) 12:00:43.16 リファクタに耐えるようなうまいユニットテストつくれん
設定項目が膨大すぎてIF変更やDBの取得先変更で
あっさりで投げ捨てられる
F痛でDBの更新項目とか結果全部テストしてたからそういうふうにしてたが
世間の常識とちがうらしい
設定項目が膨大すぎてIF変更やDBの取得先変更で
あっさりで投げ捨てられる
F痛でDBの更新項目とか結果全部テストしてたからそういうふうにしてたが
世間の常識とちがうらしい
721仕様書無しさん
2018/10/21(日) 14:09:44.77 ゼネコン案件だったらほとんどがコーディングスキルゼロの素人が設計したスマートUI乱用システムだろ
そのようなシステムではそもそもユニットテストは作れないのが普通なんだ
無理してユニットテストを作るんじゃなくて設計か要件定義までロールバックしたほうがいい
そのようなシステムではそもそもユニットテストは作れないのが普通なんだ
無理してユニットテストを作るんじゃなくて設計か要件定義までロールバックしたほうがいい
723仕様書無しさん
2018/10/21(日) 14:54:49.81 このリファクタ馬鹿って、結婚障害だとか書いてる馬鹿と同一人物なんだろ
ほっとけよ
ほっとけよ
725仕様書無しさん
2018/10/21(日) 16:04:17.15 業務システムだと簡単すぎて時間が余る
暇を弄ぶのも苦痛なのでテストを整備してリファクタリングする
これぐらいでいいんだよ
無理してやるもんでもないし頑なに拒否するもんでもない
暇を弄ぶのも苦痛なのでテストを整備してリファクタリングする
これぐらいでいいんだよ
無理してやるもんでもないし頑なに拒否するもんでもない
726仕様書無しさん
2018/10/21(日) 16:05:15.11 うちのメンツだとリファクタはまずないわ
なにせ綺麗だもん常に
なにせ綺麗だもん常に
728仕様書無しさん
2018/10/21(日) 16:16:15.70 うちは正規職員しかいないから
正規職員も全員偏差値７０は最低でもある
だからソースも無駄がないのさ
馬鹿な派遣だらけの職場は大変ですね
正規職員も全員偏差値７０は最低でもある
だからソースも無駄がないのさ
馬鹿な派遣だらけの職場は大変ですね
729仕様書無しさん
2018/10/21(日) 16:21:32.14 その割に無駄話が多いですね
730仕様書無しさん
2018/10/21(日) 17:52:59.47 ビジネスが進歩してないｗ
731KAC
2018/10/21(日) 18:17:09.31 >>727
ビジネスが進歩とか、
お前の辞書（）には面白い単語が載ってるんだな。
つか、表面に見えてるビジネスに依存したソース書くのは素人丸出し。
まともに設計できる技術者なら、リファクタリングなんて無駄な事は発生させない。
ビジネスが進歩とか、
お前の辞書（）には面白い単語が載ってるんだな。
つか、表面に見えてるビジネスに依存したソース書くのは素人丸出し。
まともに設計できる技術者なら、リファクタリングなんて無駄な事は発生させない。
736仕様書無しさん
2018/10/21(日) 19:25:07.19 客「仕様変更をお願いしたいですが」
お前「リプレイスですね」
客「ちょっと仕様変更だけなんですが」
お前「無理です。変えられません。リプレイスしたほうが安いです」
客「来月さらに同じところの仕様変更を考えてるのですが」
お前「またリプレイスでしょうねーｗｗｗ」
お前「リプレイスですね」
客「ちょっと仕様変更だけなんですが」
お前「無理です。変えられません。リプレイスしたほうが安いです」
客「来月さらに同じところの仕様変更を考えてるのですが」
お前「またリプレイスでしょうねーｗｗｗ」
738仕様書無しさん
2018/10/21(日) 19:55:13.11 リファクタせずに機能追加しまくって
限界が来たらリプレース
理にかなっている
限界が来たらリプレース
理にかなっている
739仕様書無しさん
2018/10/21(日) 19:58:39.09 ・客先にて
客「広島から大阪を経由して東京へ行く仕様を、京都経由に変更してくれ」
上司「了解しました」
・社内にて
上司「大阪と京都は近くだから簡単だろう？すぐに修正してくれ」
お前「現状、広島から北海道を経由して福岡を経由して新潟を経由して京都を経由して東京に行くようになってますから
京都からさらに大阪を経由して東京に行くんですね」
上司「は？ 広島から京都を経由して東京にいくだけだろ。なんでそんなに遠回りしてるんだ？」
お前「動いているコードに手はださない。既存のルートに付け足すだけだ。今までずっとそうしてきた」
上司「それだとムダでわかりづいらいだろ。リファクタリングしろ」
お前「コードぐっちゃぐちゃやねん。手遅れだ。リプレイスしたほうが早い」
上司「なぜこまめにリファクタリングしなかったんだ？」
お前「リプレイスしたほうが早いからだ」
上司「手遅れにならないうちに！ こ・ま・めに！」
お前「知るか、リファクタリングなんか不要！」
客「広島から大阪を経由して東京へ行く仕様を、京都経由に変更してくれ」
上司「了解しました」
・社内にて
上司「大阪と京都は近くだから簡単だろう？すぐに修正してくれ」
お前「現状、広島から北海道を経由して福岡を経由して新潟を経由して京都を経由して東京に行くようになってますから
京都からさらに大阪を経由して東京に行くんですね」
上司「は？ 広島から京都を経由して東京にいくだけだろ。なんでそんなに遠回りしてるんだ？」
お前「動いているコードに手はださない。既存のルートに付け足すだけだ。今までずっとそうしてきた」
上司「それだとムダでわかりづいらいだろ。リファクタリングしろ」
お前「コードぐっちゃぐちゃやねん。手遅れだ。リプレイスしたほうが早い」
上司「なぜこまめにリファクタリングしなかったんだ？」
お前「リプレイスしたほうが早いからだ」
上司「手遅れにならないうちに！ こ・ま・めに！」
お前「知るか、リファクタリングなんか不要！」
740仕様書無しさん
2018/10/21(日) 20:03:24.02 ・客先にて
上司「この間の仕様変更の作業中に、遅かった理由が判明しました。
広島から大阪を経由して東京に行く仕様ですが、
広島から北海道を経由して福岡を経由して新潟を経由して大阪を経由して東京に行っていました」
客（絶句）
上司「担当者は今回の仕様で、上記に追加して大阪からさらに京都を経由しようとしていましたので、
ご安心ください。クビにしました」
上司「この間の仕様変更の作業中に、遅かった理由が判明しました。
広島から大阪を経由して東京に行く仕様ですが、
広島から北海道を経由して福岡を経由して新潟を経由して大阪を経由して東京に行っていました」
客（絶句）
上司「担当者は今回の仕様で、上記に追加して大阪からさらに京都を経由しようとしていましたので、
ご安心ください。クビにしました」
741仕様書無しさん
2018/10/21(日) 20:06:14.48 コードを書くのは下流だけど下流に行くほどリファクタリングに無頓着
派遣さんはコードを書かせたらサヨナラバイバイだから
彼らには後の事を考えてコーディングする機会がないのだろうね
そうなるとリファクタリングという発想自体が出てこなくなるのも仕方がない
派遣さんはコードを書かせたらサヨナラバイバイだから
彼らには後の事を考えてコーディングする機会がないのだろうね
そうなるとリファクタリングという発想自体が出てこなくなるのも仕方がない
744仕様書無しさん
2018/10/21(日) 20:15:20.27 新人「大阪経由を京都経由に変更するんですね！（簡単そうだ）任せてください！」
上司「ちなみに納期はこれこれだから」
新人「まあ、変更少なそうだし、大丈夫でしょう」
新人（コード見て絶句）
新人「え！！その期間でその修正を！？」
新人（無理や・・・大阪からさらに京都へ経由する処理を追加するしかない）
上司「おい、なんで。広島から北海道を経由して福岡を経由して新潟を経由して京都を経由して大阪を経由して東京に行ってるんだ？」
新人「知らねーよ。既存のコードがそうなってたんだから真似しただけだ」（暗黒面落ち）
上司「ちなみに納期はこれこれだから」
新人「まあ、変更少なそうだし、大丈夫でしょう」
新人（コード見て絶句）
新人「え！！その期間でその修正を！？」
新人（無理や・・・大阪からさらに京都へ経由する処理を追加するしかない）
上司「おい、なんで。広島から北海道を経由して福岡を経由して新潟を経由して京都を経由して大阪を経由して東京に行ってるんだ？」
新人「知らねーよ。既存のコードがそうなってたんだから真似しただけだ」（暗黒面落ち）
746仕様書無しさん
2018/10/21(日) 20:21:29.53 リプレースって既存システムの仕様解析を諦めてベタ移植するフラグが最初からたってる
汚いレガシーシステムを違う基盤上の汚いレガシーシステムに置き換えるだけに終わる
莫大なコストがかかるくせにビジネス上のメリットは殆どゼロ
汚いレガシーシステムを違う基盤上の汚いレガシーシステムに置き換えるだけに終わる
莫大なコストがかかるくせにビジネス上のメリットは殆どゼロ
747仕様書無しさん
2018/10/21(日) 20:25:08.48748仕様書無しさん
2018/10/21(日) 20:30:22.65 既存システムがめちゃくちゃで仕様解析は無理だ
↓
解析は諦める
行単位で移せば機能を維持したまま移植できるはず
↓
言語やライブラリの仕様の違いのせいでバグが多発
残業しまくって火消しするしかない
↓
なんとか移植完了
バグ数が多いので客は品質に強い懸念を抱いているがテストは通した
たとえスカスカでもテストは通したんだから大丈夫なはずだ
↓
経営陣に土下座させて客への説得もなんとかクリアして受け入れも済んだ
さあ本来の目的だった機能を追加するぞ
↓
コードがめちゃくちゃでどうやったら機能を追加できるかわからないよ
リプレースって毎回こんななるんだけど
リプレースがうまくいくことなんてあるの？
↓
解析は諦める
行単位で移せば機能を維持したまま移植できるはず
↓
言語やライブラリの仕様の違いのせいでバグが多発
残業しまくって火消しするしかない
↓
なんとか移植完了
バグ数が多いので客は品質に強い懸念を抱いているがテストは通した
たとえスカスカでもテストは通したんだから大丈夫なはずだ
↓
経営陣に土下座させて客への説得もなんとかクリアして受け入れも済んだ
さあ本来の目的だった機能を追加するぞ
↓
コードがめちゃくちゃでどうやったら機能を追加できるかわからないよ
リプレースって毎回こんななるんだけど
リプレースがうまくいくことなんてあるの？
749仕様書無しさん
2018/10/21(日) 20:38:22.90 リプレースついでに新しくしましょうとかやるからだろ
リプレースは古いものを使うのが鉄則
そんで限界が来るまで使って
限界が来たら、リプレースをする
リプレースは古いものを使うのが鉄則
そんで限界が来るまで使って
限界が来たら、リプレースをする
750仕様書無しさん
2018/10/21(日) 20:46:37.35 リファクタリングしてリプレースに耐えうるコードに書き換えてからリプレースするとうまくいくのだけど
コストをケチってリファクタリングが省略されて失敗する
コストをケチってリファクタリングが省略されて失敗する
751仕様書無しさん
2018/10/21(日) 20:54:45.22 リプレースって仕様書みて一から全部再実装するんだぞ
そのために仕様書があるわけで、
完璧な仕様書が求められてる
そのために仕様書があるわけで、
完璧な仕様書が求められてる
754仕様書無しさん
2018/10/21(日) 21:37:04.24 >>739
まさにお前のいうようにするわ
いままで北海道で下車できてたのにできなくなったら大デグレードじゃん
それリファクタじゃない
クビになるのは間違いなくお前のほう
多少遅いぐらいなんだってんだ
通常の現実世界とプログラムの世界の違いを知れよ
どうせ１秒２秒だろ？またせとけよ
まさにお前のいうようにするわ
いままで北海道で下車できてたのにできなくなったら大デグレードじゃん
それリファクタじゃない
クビになるのは間違いなくお前のほう
多少遅いぐらいなんだってんだ
通常の現実世界とプログラムの世界の違いを知れよ
どうせ１秒２秒だろ？またせとけよ
756仕様書無しさん
2018/10/21(日) 22:04:52.76 > 通常の現実世界とプログラムの世界の違いを知れよ
> どうせ１秒２秒だろ？またせとけよ
実行時間の問題じゃないのよ。解析にかかる時間が問題なの
別の担当者が作業した時、なんでこんなことをしているのかわからないコードを
自信を持って完成しましたと言えないことが問題なの
何をやってるか知りませんが、動くからバグはないんじゃない？
テストに漏れがないと良いですね。
こんな無責任なこと言えないの
> どうせ１秒２秒だろ？またせとけよ
実行時間の問題じゃないのよ。解析にかかる時間が問題なの
別の担当者が作業した時、なんでこんなことをしているのかわからないコードを
自信を持って完成しましたと言えないことが問題なの
何をやってるか知りませんが、動くからバグはないんじゃない？
テストに漏れがないと良いですね。
こんな無責任なこと言えないの
757仕様書無しさん
2018/10/21(日) 22:07:42.69 仕様変更で既存のコードに付け足してつじつま合わせのようなことをしてるなら
テストも同じように付け足してつじつまを合わせをすることになる
必要のないテストをするだけじゃなくテスト自体の自信もなくなる。
こんなテストしてますが、このテストは正しいのですか？
必要なさそうなテストですが、前の人がやっていたので繰り返しやります
時間かかりますね。
テストも同じように付け足してつじつまを合わせをすることになる
必要のないテストをするだけじゃなくテスト自体の自信もなくなる。
こんなテストしてますが、このテストは正しいのですか？
必要なさそうなテストですが、前の人がやっていたので繰り返しやります
時間かかりますね。
760仕様書無しさん
2018/10/21(日) 22:14:23.38 >>758
例えばCOBOLのバージョンを毎日確認したりしないよね
いつの間にか「あれ？バージョンが上がってる？」ってなる
数年スパンで起きる現象なんだから
お気づきの変化が起きた頃には（数年たっていて）リプレイスです。
例えばCOBOLのバージョンを毎日確認したりしないよね
いつの間にか「あれ？バージョンが上がってる？」ってなる
数年スパンで起きる現象なんだから
お気づきの変化が起きた頃には（数年たっていて）リプレイスです。
762仕様書無しさん
2018/10/21(日) 22:15:37.28763仕様書無しさん
2018/10/21(日) 22:16:25.32764仕様書無しさん
2018/10/21(日) 22:16:52.84 リファクタをリプレースと呼べば多少動きが変わっても許してもらえるという願望
765KAC
2018/10/21(日) 22:17:41.50768仕様書無しさん
2018/10/21(日) 22:19:18.50 >>765
だから意味がわからん。
> 客「広島から大阪を経由して東京へ行く仕様を、京都経由に変更してくれ」
どこにも北海道で下車したいなんて書いてない
仕様に書いてない挙動も、動作保証してるのかな？ｗ
だから意味がわからん。
> 客「広島から大阪を経由して東京へ行く仕様を、京都経由に変更してくれ」
どこにも北海道で下車したいなんて書いてない
仕様に書いてない挙動も、動作保証してるのかな？ｗ
770仕様書無しさん
2018/10/21(日) 22:22:20.47 客「仕様を変更し欲しい。どれくらいかかりますか？」
お前「仕様変更は認められん。こういう使い方してるかもしれないだろ」
客「いやそういう使い方してないから」
お前「お前が決めるな。客は神様ではない。」
客「お前の所に開発頼むのやめるわ」
お前「仕様変更は認められん。こういう使い方してるかもしれないだろ」
客「いやそういう使い方してないから」
お前「お前が決めるな。客は神様ではない。」
客「お前の所に開発頼むのやめるわ」
771仕様書無しさん
2018/10/21(日) 22:23:42.33773仕様書無しさん
2018/10/21(日) 22:24:28.92 客が求めてないのに、一旦リリースした以上
混乱を招くかもしれないからって仕様変更を拒否するとかイミフ
混乱を招くかもしれないからって仕様変更を拒否するとかイミフ
774KAC
2018/10/21(日) 22:24:39.11 >>768
そんなことすら理解できないから、
お前は素人だと言ってるんだよ。
現状それで運用されてるんだろ？
なんでわざわざ北海道経由してるのを
「お前の判断でやめてもいい」んだ？
それは最早リファクタリングでもなんでも無い。
ただのバグ追加だ。
そんなことすら理解できないから、
お前は素人だと言ってるんだよ。
現状それで運用されてるんだろ？
なんでわざわざ北海道経由してるのを
「お前の判断でやめてもいい」んだ？
それは最早リファクタリングでもなんでも無い。
ただのバグ追加だ。
775仕様書無しさん
2018/10/21(日) 22:25:27.78776仕様書無しさん
2018/10/21(日) 22:26:05.81 >>774
> 現状それで運用されてるんだろ？
> なんでわざわざ北海道経由してるのを
> 「お前の判断でやめてもいい」んだ？
↓どうみても客の判断なんだが？ 何を言ってるんだこいつ。
> 客「広島から大阪を経由して東京へ行く仕様を、京都経由に変更してくれ」
> 現状それで運用されてるんだろ？
> なんでわざわざ北海道経由してるのを
> 「お前の判断でやめてもいい」んだ？
↓どうみても客の判断なんだが？ 何を言ってるんだこいつ。
> 客「広島から大阪を経由して東京へ行く仕様を、京都経由に変更してくれ」
779仕様書無しさん
2018/10/21(日) 22:29:30.47 ？？？
781仕様書無しさん
2018/10/21(日) 22:31:58.51 ・客先にて
客「広島から大阪を経由して東京へ行く仕様を、京都経由に変更してくれ」
上司「了解しました」
・社内にて
上司「大阪と京都は近くだから簡単だろう？すぐに修正してくれ」
お前「現状、広島から北海道を経由して福岡を経由して新潟を経由して京都を経由して東京に行くようになってますから
京都からさらに大阪を経由して東京に行くんですね」
上司「は？ 広島から京都を経由して東京にいくだけだろ。なんでそんなに遠回りしてるんだ？」
お前「動いているコードに手はださない。既存のルートに付け足すだけだ。今までずっとそうしてきた」
上司「それだとムダでわかりづいらいだろ。リファクタリングしろ」
お前「コードぐっちゃぐちゃやねん。手遅れだ。リプレイスしたほうが早い」
上司「なぜこまめにリファクタリングしなかったんだ？」
お前「リプレイスしたほうが早いからだ」
上司「手遅れにならないうちに！ こ・ま・めに！」
お前「知るか、リファクタリングなんか不要！」
客「広島から大阪を経由して東京へ行く仕様を、京都経由に変更してくれ」
上司「了解しました」
・社内にて
上司「大阪と京都は近くだから簡単だろう？すぐに修正してくれ」
お前「現状、広島から北海道を経由して福岡を経由して新潟を経由して京都を経由して東京に行くようになってますから
京都からさらに大阪を経由して東京に行くんですね」
上司「は？ 広島から京都を経由して東京にいくだけだろ。なんでそんなに遠回りしてるんだ？」
お前「動いているコードに手はださない。既存のルートに付け足すだけだ。今までずっとそうしてきた」
上司「それだとムダでわかりづいらいだろ。リファクタリングしろ」
お前「コードぐっちゃぐちゃやねん。手遅れだ。リプレイスしたほうが早い」
上司「なぜこまめにリファクタリングしなかったんだ？」
お前「リプレイスしたほうが早いからだ」
上司「手遅れにならないうちに！ こ・ま・めに！」
お前「知るか、リファクタリングなんか不要！」
782仕様書無しさん
2018/10/21(日) 22:33:07.72 続き
・客先にて
上司「この間の仕様変更の作業中に、遅かった理由が判明しました。
広島から大阪を経由して東京に行く仕様ですが、
広島から北海道を経由して福岡を経由して新潟を経由して大阪を経由して東京に行っていました」
客「今までの経由の変更はすべてそんなことをしていたと？頼んでないんだけど？」（絶句）
上司「担当者は今回の仕様で、上記に追加して大阪からさらに京都を経由しようとしていましたので、
ご安心ください。クビにしました」
・客先にて
上司「この間の仕様変更の作業中に、遅かった理由が判明しました。
広島から大阪を経由して東京に行く仕様ですが、
広島から北海道を経由して福岡を経由して新潟を経由して大阪を経由して東京に行っていました」
客「今までの経由の変更はすべてそんなことをしていたと？頼んでないんだけど？」（絶句）
上司「担当者は今回の仕様で、上記に追加して大阪からさらに京都を経由しようとしていましたので、
ご安心ください。クビにしました」
783仕様書無しさん
2018/10/21(日) 22:33:56.94 おまえぐらい同じこと何回もコピペするのが好きなら
リファクタしたくなるのもわからんでもない
リファクタしたくなるのもわからんでもない
785仕様書無しさん
2018/10/21(日) 22:35:21.24 一見仕様にないように見えても
イクラ弁当がたべたいとか言い出すやつがいたりして
そこで仕様がねじくれてる可能性もある
ぜんぜん関係ないはずなのに勝手に機能削除してそこでデグレたらだいぶやばい
イクラ弁当がたべたいとか言い出すやつがいたりして
そこで仕様がねじくれてる可能性もある
ぜんぜん関係ないはずなのに勝手に機能削除してそこでデグレたらだいぶやばい
786仕様書無しさん
2018/10/21(日) 22:35:47.76 まず経路をデータとして扱うように改修して
既存の経路と同じ結果になるデータを投入してテスト
新しい経路のデータを投入
リファクタリングしてよかったな
しなければ経路を増やすたびにバカバカしい議論、コード分析、コード改修、ビルド、テスト、納品、客先説明をしなければならないところだった
とんでもないコストだよ
既存の経路と同じ結果になるデータを投入してテスト
新しい経路のデータを投入
リファクタリングしてよかったな
しなければ経路を増やすたびにバカバカしい議論、コード分析、コード改修、ビルド、テスト、納品、客先説明をしなければならないところだった
とんでもないコストだよ
788仕様書無しさん
2018/10/21(日) 22:42:37.01 客の仕様自体が間違ってた時な
べつにそこだけ変えりゃ今まで通り達成できるのに
全然関係ないとこでデグレてあんたが言ったからだって通んないでしょ
べつにそこだけ変えりゃ今まで通り達成できるのに
全然関係ないとこでデグレてあんたが言ったからだって通んないでしょ
791仕様書無しさん
2018/10/21(日) 22:49:03.97 支持者が一人も居ねえｗ
792仕様書無しさん
2018/10/21(日) 22:49:45.59 言い出した部分自体の仕様バグだったらね
これは関係ないとこの機能削除しようってんだからだめだろ
どっちにせよ現実に対しては何の解決にもならんが
これは関係ないとこの機能削除しようってんだからだめだろ
どっちにせよ現実に対しては何の解決にもならんが
793仕様書無しさん
2018/10/21(日) 22:49:47.18 そりゃリファクタリングしないほうが良いとか誰も支持せんわｗ
794仕様書無しさん
2018/10/21(日) 22:50:58.75795仕様書無しさん
2018/10/21(日) 22:58:53.14 今回の例↓みたいに
> 客「広島から大阪を経由して東京へ行く仕様を、京都経由に変更してくれ」
広島 → 大阪 → 東京 を
広島 → 京都 → 東京 に変更する場合
既存の処理（大阪に行く）を残して
広島 → 大阪 → 京都 → 東京 に変更する方法もある
だがそれは客は望んでいない
で、忘れてはいけないのはコレは ”リファクタリングではない" ということ
仕様変更なんだから当然リファクタリングではない
じゃあこの話のどこにリファクタリングが絡んでくるのかと言うと
（手っ取り早いという理由で）広島 → 大阪 → 京都 → 東京 と書いた後
（客の要望通り無駄な）大阪 を経由する処理を省くこと
広島 → 大阪 → 京都 → 東京 を
広島 → 京都 → 東京 にすることがリファクタリング
ここまでやって、完成と言えるのだが
こまったちゃんは動いたからOKでしょで、完成にしてしまうから
それが積み重なって、（客が要求してない）こんなクソコードになる
広島 → 北海道 → 福岡 → 新潟 → 大阪 → 京都 → 東京
> 客「広島から大阪を経由して東京へ行く仕様を、京都経由に変更してくれ」
広島 → 大阪 → 東京 を
広島 → 京都 → 東京 に変更する場合
既存の処理（大阪に行く）を残して
広島 → 大阪 → 京都 → 東京 に変更する方法もある
だがそれは客は望んでいない
で、忘れてはいけないのはコレは ”リファクタリングではない" ということ
仕様変更なんだから当然リファクタリングではない
じゃあこの話のどこにリファクタリングが絡んでくるのかと言うと
（手っ取り早いという理由で）広島 → 大阪 → 京都 → 東京 と書いた後
（客の要望通り無駄な）大阪 を経由する処理を省くこと
広島 → 大阪 → 京都 → 東京 を
広島 → 京都 → 東京 にすることがリファクタリング
ここまでやって、完成と言えるのだが
こまったちゃんは動いたからOKでしょで、完成にしてしまうから
それが積み重なって、（客が要求してない）こんなクソコードになる
広島 → 北海道 → 福岡 → 新潟 → 大阪 → 京都 → 東京
797仕様書無しさん
2018/10/21(日) 23:00:41.50 仕様変更のたびに、こうやって無駄になってしまったコードを
削除することもリファクタリングの一つなんだよ
削除することもリファクタリングの一つなんだよ
798仕様書無しさん
2018/10/21(日) 23:02:14.98 消したらもったいないじゃないか！
799仕様書無しさん
2018/10/21(日) 23:04:16.62 これからの修正で、時間がかかるほうがもったいない
800仕様書無しさん
2018/10/21(日) 23:06:41.33 >>795
その要望で、その直し方する且つそんな直しになるプログラムを組むバカがいるとこで働いてないので
その要望で、その直し方する且つそんな直しになるプログラムを組むバカがいるとこで働いてないので
801仕様書無しさん
2018/10/21(日) 23:07:55.25 ただの要望通りの仕様変更w
802仕様書無しさん
2018/10/21(日) 23:08:48.44 俺はそんなところで目隠しされた状態で働いてる
へたに動いて事故れない
へたに動いて事故れない
803KAC
2018/10/21(日) 23:17:19.02 >>776
だからお前はど素人なんだよ。
「現状のルートは京都を経由していない」
という可能性に気付け。
勝手に仕様を自分の中だけで完結するな。
相手の意図を正しく判断して、今のシステムと比較して確認しろ。
お前のいうとおりなら、そもそも京都を経由してるんだから
要望じたいが発生しない。
だからお前はど素人なんだよ。
「現状のルートは京都を経由していない」
という可能性に気付け。
勝手に仕様を自分の中だけで完結するな。
相手の意図を正しく判断して、今のシステムと比較して確認しろ。
お前のいうとおりなら、そもそも京都を経由してるんだから
要望じたいが発生しない。
805仕様書無しさん
2018/10/22(月) 00:30:11.82 >>786
いちばんヤバいやつ
データ化すると仕様変更にいちじるしく弱くなる
それこそ最初から設計されてなきゃ
なりゆきで変えちゃったらどつぼにはまるパターン
そしてどのみち駅ごとに別のことやるからテスト工数削減できないという
そのうえプログラムだとIF文ですんだところがデシジョンテーブルなんか使ったら
ちょっとしたきっかけで組み合わせ爆発、そのすべてをテストせざるを得なくなる
いちばんヤバいやつ
データ化すると仕様変更にいちじるしく弱くなる
それこそ最初から設計されてなきゃ
なりゆきで変えちゃったらどつぼにはまるパターン
そしてどのみち駅ごとに別のことやるからテスト工数削減できないという
そのうえプログラムだとIF文ですんだところがデシジョンテーブルなんか使ったら
ちょっとしたきっかけで組み合わせ爆発、そのすべてをテストせざるを得なくなる
806仕様書無しさん
2018/10/22(月) 00:32:27.85 客や上司が意地悪だとこっちの様子やプログラム見てわざと困るような要求してきたりするしな！
世界が敵に見えてる人間のやることではない
世界が敵に見えてる人間のやることではない
807仕様書無しさん
2018/10/22(月) 00:33:12.72 システムと自分とどっちが大事か考えろ
808仕様書無しさん
2018/10/22(月) 01:01:17.87 リファクタリング禁止とか言ってるやつが書いた（クソ）コード見てみたいよなー
でもクソコード書くようなやつは公開しないだろうなー
ってことでなんかないか探すスレ立ててみた
【反面教師】 オプソで汚いソースコードを見てみる
https://mevius.5ch.net/test/read.cgi/tech/1540137601/
でもクソコード書くようなやつは公開しないだろうなー
ってことでなんかないか探すスレ立ててみた
【反面教師】 オプソで汚いソースコードを見てみる
https://mevius.5ch.net/test/read.cgi/tech/1540137601/
810仕様書無しさん
2018/10/22(月) 01:23:59.03 じゃあ経路
811仕様書無しさん
2018/10/22(月) 01:36:43.04 木村はくそ
812仕様書無しさん
2018/10/22(月) 05:42:58.87 >>805
何言ってんだ？
ハードコードされてる方が変更に弱い
経路という明らかにデータで表現すべきものを手続きで実装するなんておかしいよ
そうやっておかしなことをやるから「既存の経路をコピペして付け足しましたー」などと無茶をする奴が現れる
データだったら「新規経路登録しました」で済む話だ
プログラムの変更がないからテストも最小限で済む
客への説明もこれ以上ないほど簡単だ
何言ってんだ？
ハードコードされてる方が変更に弱い
経路という明らかにデータで表現すべきものを手続きで実装するなんておかしいよ
そうやっておかしなことをやるから「既存の経路をコピペして付け足しましたー」などと無茶をする奴が現れる
データだったら「新規経路登録しました」で済む話だ
プログラムの変更がないからテストも最小限で済む
客への説明もこれ以上ないほど簡単だ
813仕様書無しさん
2018/10/22(月) 06:42:57.75 だから例えが例えになってないから
2018/10/22(月) 07:56:09.75
誰が何の例えをしたって？
815仕様書無しさん
2018/10/22(月) 18:29:43.39 けぇろ（経路、帰ろう）
816仕様書無しさん
2018/10/22(月) 19:08:28.04 この事例でパスをデータ化しない奴は即刻クビでもおかしくない
817仕様書無しさん
2018/10/22(月) 19:17:08.48 任意のデータを扱えることという要件がない以上やらんほうがいい
客の要望が都合よく同じ枠組みからずっと外れずにいる保証なんてないぞ
やっていいのはこっちが開発のアドバンテージを握ってるときだけだ
思い付きで下っ端がリファクタでやるとか自殺行為
客の要望が都合よく同じ枠組みからずっと外れずにいる保証なんてないぞ
やっていいのはこっちが開発のアドバンテージを握ってるときだけだ
思い付きで下っ端がリファクタでやるとか自殺行為
818仕様書無しさん
2018/10/22(月) 19:29:08.01 仕様が変わる可能性があるから「具体的な経路」と「枠組み」を分離してメンテナンス性を上げるんだろが
これらがハードコードされて絡み合ってたら直すに直せんぞ
これらがハードコードされて絡み合ってたら直すに直せんぞ
819仕様書無しさん
2018/10/22(月) 19:54:07.93 誰からも共感を得られない可愛そうな人
820仕様書無しさん
2018/10/22(月) 21:47:00.60 経路が本当は何を意味しているか気づいてないやつばかりだなｗ
これ、コードの修正方法の話よ？
例えば、既存の処理が
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` に変更するという方法もある
これ、コードの修正方法の話よ？
例えば、既存の処理が
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` に変更するという方法もある
822仕様書無しさん
2018/10/22(月) 22:27:50.23 状態遷移の話だとおもえばみんなハッピー
823KAC
2018/10/22(月) 22:56:41.52 >>812
既存システムで扱われている「経路」というものを
「データで扱った方が良い」と判断した根拠が示されていないんだから、
賛同者が居ないのは当たり前。
データに分離しない方が楽なときはまたリファクタリング（）するのか？
既存システムで扱われている「経路」というものを
「データで扱った方が良い」と判断した根拠が示されていないんだから、
賛同者が居ないのは当たり前。
データに分離しない方が楽なときはまたリファクタリング（）するのか？
827仕様書無しさん
2018/10/23(火) 08:20:45.42 誰も同調してくれないｗｗｗｗ
828仕様書無しさん
2018/10/23(火) 08:47:50.77 こんなに必死になっても、誰も同意してくれないってことは
自分に間違いがあるってことだってことに気が付かないんだろうな
人の意見に耳をかさず、自分の意見は主張し続ける
パヨク病だな完全に
自分に間違いがあるってことだってことに気が付かないんだろうな
人の意見に耳をかさず、自分の意見は主張し続ける
パヨク病だな完全に
829仕様書無しさん
2018/10/23(火) 14:55:09.75 >>828
こんなところで自己紹介しなくていいから
こんなところで自己紹介しなくていいから
830仕様書無しさん
2018/10/23(火) 17:14:02.28 >>820の言いたいことがわからん
方針決めずにダラダラ書いていくのがリファクタリングってこと？
方針決めずにダラダラ書いていくのがリファクタリングってこと？
831仕様書無しさん
2018/10/23(火) 18:38:15.96 不毛なスレだな
832KAC
2018/10/23(火) 18:38:36.36 設計もせずにいつもグダグダになるから
リファクタリングが必要とか言い出すんだろう
リファクタリングが必要とか言い出すんだろう
833仕様書無しさん
2018/10/23(火) 19:56:21.86 >>830
> 方針決めずにダラダラ書いていくのがリファクタリングってこと？
リファクタリングの利用の場面はいくつかあって、
その一つが、テストファーストであるという話
先にテストを書いて、そのテストに通る最低限のコードを書く
（ここまではリファクタリングじゃないぞ）
そしてテストに通る状態を維持したまま、質の高いコードに変える
これがリファクタリングの利用例の一つ
> 方針決めずにダラダラ書いていくのがリファクタリングってこと？
リファクタリングの利用の場面はいくつかあって、
その一つが、テストファーストであるという話
先にテストを書いて、そのテストに通る最低限のコードを書く
（ここまではリファクタリングじゃないぞ）
そしてテストに通る状態を維持したまま、質の高いコードに変える
これがリファクタリングの利用例の一つ
834仕様書無しさん
2018/10/23(火) 20:24:42.81 >>833
なんではじめから質の高いコードを書かないの？
なんではじめから質の高いコードを書かないの？
835仕様書無しさん
2018/10/23(火) 20:42:01.45 時間効率悪くても
最初は動くの確かめて安心したいから
最初は動くの確かめて安心したいから
836仕様書無しさん
2018/10/23(火) 20:55:40.64 >>834
既存のコードがあって、そこに付け足すから。
ちょうど今やってるんだが1関数50行のコードがある。
少々長めだが、switchである値はこれ、この値はこれ、みたいな処理の連続で
単純な処理なのでこのままで質には十分だった。
だけどその値のパターン数が5つだったが、新たに3個追加になる。
似たようなコードなので今のコードに単純に追加するのは簡単だが
これをやると単純計算で1関数80行にもなってしまう。1関数80行はさすがにヤバい。長過ぎる
許容範囲の品質が、悪い品質に変わる瞬間
だから今リファクタリングを行ってる段階。（3個追加はまだする段階ではない）テストはあるので安心。
関数の中にある似たようなコードを共通化して別の関数に追い出すことで15行減らした。
もう一箇所減らせそうなので15行、50行のコードが20行程度になる予定
これに3個追加しても+12行で32行なので十分な品質だろう
もしもっとパターン数が追加になれば、パターンごとに別関数にするだろうけど
まだそこまでやる段階じゃないな。今の段階でこれをやると逆に関数に分けすぎで見通しが悪くなる
既存のコードがあって、そこに付け足すから。
ちょうど今やってるんだが1関数50行のコードがある。
少々長めだが、switchである値はこれ、この値はこれ、みたいな処理の連続で
単純な処理なのでこのままで質には十分だった。
だけどその値のパターン数が5つだったが、新たに3個追加になる。
似たようなコードなので今のコードに単純に追加するのは簡単だが
これをやると単純計算で1関数80行にもなってしまう。1関数80行はさすがにヤバい。長過ぎる
許容範囲の品質が、悪い品質に変わる瞬間
だから今リファクタリングを行ってる段階。（3個追加はまだする段階ではない）テストはあるので安心。
関数の中にある似たようなコードを共通化して別の関数に追い出すことで15行減らした。
もう一箇所減らせそうなので15行、50行のコードが20行程度になる予定
これに3個追加しても+12行で32行なので十分な品質だろう
もしもっとパターン数が追加になれば、パターンごとに別関数にするだろうけど
まだそこまでやる段階じゃないな。今の段階でこれをやると逆に関数に分けすぎで見通しが悪くなる
838仕様書無しさん
2018/10/24(水) 01:16:44.88 俺なら３つ書き足して帰って寝る
ねるぞ
ねるぞ
840仕様書無しさん
2018/10/24(水) 04:04:07.52 ソースコードが仮に1万行だとすると、
1関数あたり平均20行として500関数ぐらいかな？
今作ってるのを見てみたら2000行程度で
120関数だから大体計算あってる
何が言いたいかって言うと、1万行で500関数ぐらいは
設計時点で関数名出してくださいよっていったら
不可能と言うだろうってこと。俺もそう思うｗ
1関数あたり平均20行として500関数ぐらいかな？
今作ってるのを見てみたら2000行程度で
120関数だから大体計算あってる
何が言いたいかって言うと、1万行で500関数ぐらいは
設計時点で関数名出してくださいよっていったら
不可能と言うだろうってこと。俺もそう思うｗ
841KAC
2018/10/24(水) 05:50:45.06842仕様書無しさん
2018/10/24(水) 06:07:24.09843仕様書無しさん
2018/10/24(水) 06:14:01.22 ガチガチに設計してしまったら、変更に弱くなるからな
作り直しが必要になるのは、やりすぎた設計が原因だよ
必要最小限の実装にしておけば、そこだけ修正すればいい
作り直しが必要になるのは、やりすぎた設計が原因だよ
必要最小限の実装にしておけば、そこだけ修正すればいい
844仕様書無しさん
2018/10/24(水) 06:23:03.42 全く設計しないみたいな論調はどこからでてきた？そして何故その前提を受け入れるんだ？
リファクタリングは必須だがだからといって設計をしないわけじゃない
どんなに注意深く設計しても多人数で時間をかけてコードを蓄積したらコードは劣化するからリファクタリングが必要なんだ
はじめから汚く書いてもいい免罪符にはならん
テストドリブンでもすべてを厳密に動く汚いコードから始めるメリットはない
普通はできるだけキレイで動くコードから始める
リファクタリングは必須だがだからといって設計をしないわけじゃない
どんなに注意深く設計しても多人数で時間をかけてコードを蓄積したらコードは劣化するからリファクタリングが必要なんだ
はじめから汚く書いてもいい免罪符にはならん
テストドリブンでもすべてを厳密に動く汚いコードから始めるメリットはない
普通はできるだけキレイで動くコードから始める
845仕様書無しさん
2018/10/24(水) 06:25:31.23 設計を変更するって言ってる時点で、
最初に設計してるの当たり前ですわｗ
客からなにを言われても、修正対応は受け付けない！って
突っぱねるなら話は別だけどｗｗｗ
最初に設計してるの当たり前ですわｗ
客からなにを言われても、修正対応は受け付けない！って
突っぱねるなら話は別だけどｗｗｗ
846仕様書無しさん
2018/10/24(水) 06:27:07.27 とりあえず、1万行のソースコードから
500個の関数名を始めに設計（？）できるもんなら
やってみなと
あーだこーだと机上の空論で手を動かさず
設計に何ヶ月もかかったりしてなｗｗｗ
500個の関数名を始めに設計（？）できるもんなら
やってみなと
あーだこーだと机上の空論で手を動かさず
設計に何ヶ月もかかったりしてなｗｗｗ
848仕様書無しさん
2018/10/24(水) 07:05:40.42 詳細設計書く力があったら普通にできるんじゃないか
やることって大体決まってるだろ
やることって大体決まってるだろ
850仕様書無しさん
2018/10/24(水) 07:07:50.29 あ、KACが言ってることが破綻してきたｗ
どう答える気だろうｗｗｗ
どう答える気だろうｗｗｗ
851仕様書無しさん
2018/10/24(水) 09:18:25.63 きむまさダメだろ荒らしたら
853仕様書無しさん
2018/10/24(水) 15:33:30.94 破綻してるな。
リファクタリングは内部構造（実装）の問題点を修正するものなんだから
設計していればリファクタリングが不要になるというのなら、
設計時点で、内部構造（実装）まで決まっていないといけない
リファクタリングは内部構造（実装）の問題点を修正するものなんだから
設計していればリファクタリングが不要になるというのなら、
設計時点で、内部構造（実装）まで決まっていないといけない
854仕様書無しさん
2018/10/24(水) 15:36:21.03 しかも、最初の時点で最終的な設計をしなければいけない
バージョンアップしていくという当たり前のことできない
バージョンアップしていくという当たり前のことできない
855仕様書無しさん
2018/10/24(水) 15:46:02.32 バージョンアップしてもリファクタリング不要にするってことは
初期バージョンの時点で最終バージョン用のコードを書くってことですかねぇｗ
最終バージョンの機能なんて決まってんの？
そもそも最終バージョンなんてものが存在するのか知りませんが
初期バージョンの時点で最終バージョン用のコードを書くってことですかねぇｗ
最終バージョンの機能なんて決まってんの？
そもそも最終バージョンなんてものが存在するのか知りませんが
856仕様書無しさん
2018/10/24(水) 15:59:42.63 最初のうちから完璧なものを出せって考え方だと
いつまでたってもリリースできないんやで
いつまでたってもリリースできないんやで
857KAC
2018/10/24(水) 18:25:15.77 なるほど。
お前が設計がどういうものか全く理解していない事はよく分かった。
お前が設計がどういうものか全く理解していない事はよく分かった。
858仕様書無しさん
2018/10/24(水) 18:38:41.80 昔はこの手の人を小ばかにした韜晦でいいようにつつきまわされたもんだ
今は死ねとしか思わん
今は死ねとしか思わん
861仕様書無しさん
2018/10/24(水) 19:50:52.27 IT技術者辞典
理解＝個人的解釈
当たり前＝根拠のない思い込み
理解＝個人的解釈
当たり前＝根拠のない思い込み
862仕様書無しさん
2018/10/24(水) 20:19:07.98 IT技術者辞典には設計すら載ってないってこと？
863仕様書無しさん
2018/10/24(水) 20:23:06.43 では設計を理解してるKACに問おう
設計とはなんぞや?
簡潔に述べよ
設計とはなんぞや?
簡潔に述べよ
864836
2018/10/24(水) 20:35:43.97 昨日の50行→80行になりそうだった関数。言ってなかったけど
あれからリファクタリングして35行に減らした。
で、そのあともう少し見直して、パターンごとで関数に分けるのではなく
中でやってる処理を複数の処理に分けられることに気づいた（適切な名前をつけられた）
そこで分割したら、メインの関数が25行に減って、そこから呼び出す4つの関数
（それぞれ15行、20行、5行、10行）に分割できた。
テストもそれぞれの関数ごとに行えるようになったので、よりシンプルになった
最初からこうしろと？無理だよ。一番最初は30行程度だったんだぜ。
初期バージョン時点の複雑になってない状態で分割とかしてたら
いつまでたってもリリースできない。
あれからリファクタリングして35行に減らした。
で、そのあともう少し見直して、パターンごとで関数に分けるのではなく
中でやってる処理を複数の処理に分けられることに気づいた（適切な名前をつけられた）
そこで分割したら、メインの関数が25行に減って、そこから呼び出す4つの関数
（それぞれ15行、20行、5行、10行）に分割できた。
テストもそれぞれの関数ごとに行えるようになったので、よりシンプルになった
最初からこうしろと？無理だよ。一番最初は30行程度だったんだぜ。
初期バージョン時点の複雑になってない状態で分割とかしてたら
いつまでたってもリリースできない。
865仕様書無しさん
2018/10/24(水) 20:39:05.09 行数で語るって、古いタイプの人かな？
866仕様書無しさん
2018/10/24(水) 20:54:53.77 >>865
？
時間をかけて35行に減らしたものを、さらに、25+15+5+10 = 合計55行に
増やして "改善された" って言ってるんだけど？
行数で "あんたが望んでいるようなこと" は何も語ってないよね？
このようにリファクタリングで時間がかかるのに
将来のバージョンアップでどうなかもわからないのに
最初のうちに将来のバージョンアップを想定してやるのは時間の無駄
だけど1関数80行を放置したら、さらに時間がかかる
このタイミングでリファクタリングするのはいいタイミングよ。
開発コストは行数とは無関係。だけど多くの場合複雑度とは関係ある
複雑だとテストの時間も長くなるし、バグも増える
コストを掛けて1関数の行数を減らす＝複雑度を減らすことは
将来のコストを減らすことにつながる
ただし1関数の行数は減っても全体の行数は増えることもある。
もちろんそれで良い。重要なのは複雑度
だから行数と開発コストを関連付けるなんて古いタイプの人間の考えとは全く違う
？
時間をかけて35行に減らしたものを、さらに、25+15+5+10 = 合計55行に
増やして "改善された" って言ってるんだけど？
行数で "あんたが望んでいるようなこと" は何も語ってないよね？
このようにリファクタリングで時間がかかるのに
将来のバージョンアップでどうなかもわからないのに
最初のうちに将来のバージョンアップを想定してやるのは時間の無駄
だけど1関数80行を放置したら、さらに時間がかかる
このタイミングでリファクタリングするのはいいタイミングよ。
開発コストは行数とは無関係。だけど多くの場合複雑度とは関係ある
複雑だとテストの時間も長くなるし、バグも増える
コストを掛けて1関数の行数を減らす＝複雑度を減らすことは
将来のコストを減らすことにつながる
ただし1関数の行数は減っても全体の行数は増えることもある。
もちろんそれで良い。重要なのは複雑度
だから行数と開発コストを関連付けるなんて古いタイプの人間の考えとは全く違う
867仕様書無しさん
2018/10/24(水) 21:09:35.62 あと設計で関数の名前を出すといってるのかしらんが、
実装（何行かかるか、どれくらい複雑か）がわからんうちに
どれくらいの数の関数が必要なのか、わかるはずがない
5行以下の関数を大量に作ったら、それはそれで分かりづらいし
そもそも関数に分割するべきかを行数で判断してはいけない
（ただし行数と複雑度に相関関係はある。俺は行数ではなく複雑度で判断して分割している）
実装（何行かかるか、どれくらい複雑か）がわからんうちに
どれくらいの数の関数が必要なのか、わかるはずがない
5行以下の関数を大量に作ったら、それはそれで分かりづらいし
そもそも関数に分割するべきかを行数で判断してはいけない
（ただし行数と複雑度に相関関係はある。俺は行数ではなく複雑度で判断して分割している）
868仕様書無しさん
2018/10/24(水) 21:22:49.00 ?
869仕様書無しさん
2018/10/24(水) 21:35:22.43 現実でも誰にも支持されてないんだろうな
これだけ利害関係もない多くの人がいるとこでも支持されない
無様w
誰でも極端なやつは相手にされないんだよ
適材適所
なんでもかんでも自分が読んだ本はすべての人が実践しなければならないって思い込んじゃうんだろう
精神病患者だな完全に
これだけ利害関係もない多くの人がいるとこでも支持されない
無様w
誰でも極端なやつは相手にされないんだよ
適材適所
なんでもかんでも自分が読んだ本はすべての人が実践しなければならないって思い込んじゃうんだろう
精神病患者だな完全に
870仕様書無しさん
2018/10/24(水) 21:45:50.78 40年ぐらい前なら支持されてたかもしれないなー
当時はリファクタリングなんて用語はなかっただろうし
自動テストってのもなかっただろう
当時はリファクタリングなんて用語はなかっただろうし
自動テストってのもなかっただろう
871仕様書無しさん
2018/10/24(水) 21:52:28.05 まあ待て支持を得られているかどうかを判断するのは
KACが設計とはなにかを語ってからにしようじゃないか
今は何も言ってないから支持を集められないだけ
KACが設計とはなにかを語ってからにしようじゃないか
今は何も言ってないから支持を集められないだけ
872仕様書無しさん
2018/10/24(水) 21:58:06.90 IT技術者辞典には設計すら載ってないってこと？
873仕様書無しさん
2018/10/24(水) 21:59:48.70 KACが考える設計がそれ（世間一般の常識）とずれてるって話
874仕様書無しさん
2018/10/24(水) 22:00:38.93 なるほど
875仕様書無しさん
2018/10/24(水) 22:29:48.00876仕様書無しさん
2018/10/24(水) 22:30:25.03 >>873
たとえば？
たとえば？
877仕様書無しさん
2018/10/24(水) 22:35:05.33 根本的に海外の人の設計思想って、日本で言うところの内製環境が絶対的前提条件だしなあ
ぶん投げた先の派遣の馬鹿に設計なんてやらせないし
ぶん投げた先の派遣の馬鹿に設計なんてやらせないし
879仕様書無しさん
2018/10/24(水) 22:36:23.29 なるほど
880仕様書無しさん
2018/10/24(水) 22:39:09.95881仕様書無しさん
2018/10/24(水) 22:43:09.39882仕様書無しさん
2018/10/24(水) 22:43:35.01883仕様書無しさん
2018/10/24(水) 22:46:22.00 日本の場合プログラマは大半が派遣・少し外部、部内プログラマは極小
海外の場合プログラマは大半が部内プログラマ、少し派遣・外部
海外の場合プログラマは大半が部内プログラマ、少し派遣・外部
884仕様書無しさん
2018/10/24(水) 22:48:25.40 日本で開発設計手法を語るなら、日本の開発環境を大前提とした開発設計手法を独自に考えないと意味がないね
たとえガラパゴスと言われようとも
それが嫌なら、海外とプログラマの立ち位置を同じようにしないと話しにならん
たとえガラパゴスと言われようとも
それが嫌なら、海外とプログラマの立ち位置を同じようにしないと話しにならん
887仕様書無しさん
2018/10/24(水) 23:15:09.93 > 日本で開発設計手法を語るなら、日本の開発環境を大前提とした開発設計手法を独自に考えないと意味がないね
念の為に言っておくけど、海外の開発設計手法は
全て日本には当てはまらないという話にしたらだめだよ？
海外の開発設計手法は全く使ってないと言うのなら別だけど。
念の為に言っておくけど、海外の開発設計手法は
全て日本には当てはまらないという話にしたらだめだよ？
海外の開発設計手法は全く使ってないと言うのなら別だけど。
888仕様書無しさん
2018/10/25(木) 10:18:39.16 結局リファクタリングって何してるの？
関数を小分けにして作業時間の水増しを図るって事？
関数を小分けにして作業時間の水増しを図るって事？
889仕様書無しさん
2018/10/25(木) 10:33:02.50 ソースコードの複雑性を解消して
メンテナンス性を上げてる
メンテナンス性を上げてる
890仕様書無しさん
2018/10/25(木) 10:34:13.41 まああれだな。
整理整頓するのには時間がかかる
だから散らかっている方が、時間の節約になる
と短絡的に考えてる人には理解できないｗ
整理整頓するのには時間がかかる
だから散らかっている方が、時間の節約になる
と短絡的に考えてる人には理解できないｗ
891KAC
2018/10/25(木) 10:36:27.26 そもそも散らかさない
という考えには至らないんだよな
という考えには至らないんだよな
892仕様書無しさん
2018/10/25(木) 10:39:06.57 >>891
面白くないよ
バージョンアップすると、
必ず無駄な部分、効率が悪い部分が出てくるんだから
それよりキミ、自分の宿題をなかったコトにしないように
863 名前：仕様書無しさん[sage] 投稿日：2018/10/24(水) 20:23:06.43
では設計を理解してるKACに問おう
設計とはなんぞや?
簡潔に述べよ
面白くないよ
バージョンアップすると、
必ず無駄な部分、効率が悪い部分が出てくるんだから
それよりキミ、自分の宿題をなかったコトにしないように
863 名前：仕様書無しさん[sage] 投稿日：2018/10/24(水) 20:23:06.43
では設計を理解してるKACに問おう
設計とはなんぞや?
簡潔に述べよ
893仕様書無しさん
2018/10/25(木) 10:59:58.22894仕様書無しさん
2018/10/25(木) 11:09:17.07895仕様書無しさん
2018/10/25(木) 11:26:05.54 >>894
でも整理整頓は一般常識の範囲なんで普通は仕事とは言わないよね？
その作業を仕事といってお金取るのはどうなんだろう
整理整頓をリファクタリングっていう言葉に置き換えて仰々しくみせてるだけな気がする
でも整理整頓は一般常識の範囲なんで普通は仕事とは言わないよね？
その作業を仕事といってお金取るのはどうなんだろう
整理整頓をリファクタリングっていう言葉に置き換えて仰々しくみせてるだけな気がする
896仕様書無しさん
2018/10/25(木) 11:27:18.07 1剣件あたり10nsでやらないといけないとこを勝手に無学なやつにリファクタされる悪夢
897仕様書無しさん
2018/10/25(木) 11:29:37.49899仕様書無しさん
2018/10/25(木) 11:37:15.50900仕様書無しさん
2018/10/25(木) 11:39:49.65 1. 作業をしていると散らかるのは避けられない
2. だから整理整頓やリファクタリングをしないといけない
3. 整理整頓もリファクタリングも作業効率が上がるという効果がある
4. 整理整頓は仕事ではないが、リファクタリングは仕事である
2. だから整理整頓やリファクタリングをしないといけない
3. 整理整頓もリファクタリングも作業効率が上がるという効果がある
4. 整理整頓は仕事ではないが、リファクタリングは仕事である
902仕様書無しさん
2018/10/25(木) 11:41:25.40 >>899
はい？ 整理整頓は仕事じゃないですが、
リファクタリングは仕事だって言っただけですよ？
そりゃどちらも効果はあるでしょう？
効果はありますが、整理整頓は仕事とは言わないといわれたから
リファクタリングは仕事かつ効果があるって話をしてるんですよ
はい？ 整理整頓は仕事じゃないですが、
リファクタリングは仕事だって言っただけですよ？
そりゃどちらも効果はあるでしょう？
効果はありますが、整理整頓は仕事とは言わないといわれたから
リファクタリングは仕事かつ効果があるって話をしてるんですよ
905仕様書無しさん
2018/10/25(木) 11:43:31.55906仕様書無しさん
2018/10/25(木) 11:44:14.49 作業をしていると散らかるのは避けられないので、整理整頓やリファクタを「しなければならない」
整理整頓やリファクタは「効果がある」
だけど、整理整頓は仕事では「ない」。リファクタは仕事で「ある」
なにが起こったんだ？？？ｗｗｗｗ
整理整頓やリファクタは「効果がある」
だけど、整理整頓は仕事では「ない」。リファクタは仕事で「ある」
なにが起こったんだ？？？ｗｗｗｗ
909仕様書無しさん
2018/10/25(木) 11:46:18.41 なんだよｗ 結局、整理整頓もリファクタリングも
仕事なんじゃねーかｗ
仕事なんじゃねーかｗ
911仕様書無しさん
2018/10/25(木) 11:47:26.67 （リファクタリングの）アンチって行き当たりばったりで
しゃべてるから、すぐ矛盾起すよねｗ
しゃべてるから、すぐ矛盾起すよねｗ
912仕様書無しさん
2018/10/25(木) 11:48:29.32 >作業をしていると散らかるのは避けられないので、整理整頓やリファクタを「しなければならない」
この「作業をしていると散らかるのは避けられないので、整理整頓やリファクタを「しなければならない」」から、お前以外誰も同意してないけどな。
この「作業をしていると散らかるのは避けられないので、整理整頓やリファクタを「しなければならない」」から、お前以外誰も同意してないけどな。
915仕様書無しさん
2018/10/25(木) 11:52:58.38 コードのリファクタより重要なことは
ユーザーのシステム仕様に対する記憶や理解、把握が劣化しないようにすること
これをダメポシステムが教えた。
ユーザーのシステム仕様に対する記憶や理解、把握が劣化しなければ、システムの再開発は容易い。
ユーザーのシステム仕様に対する記憶や理解、把握が劣化しないようにすること
これをダメポシステムが教えた。
ユーザーのシステム仕様に対する記憶や理解、把握が劣化しなければ、システムの再開発は容易い。
917仕様書無しさん
2018/10/25(木) 11:56:36.73 十分な時間が与えられ、誰も間違いをおかさず、仕様、設計が変更にならず
バージョンアップ（段階リリース）することもなく
最初から最終バージョンをいきなりリリースして
その後バグ修正以外のことをしないなら
リファクタリングなんか必要ない
バージョンアップ（段階リリース）することもなく
最初から最終バージョンをいきなりリリースして
その後バグ修正以外のことをしないなら
リファクタリングなんか必要ない
920仕様書無しさん
2018/10/25(木) 12:00:01.96 895だけど整理整頓を仕事の範囲なんて書いてないけど？
一般常識でいう整理整頓って普通は仕事前とか終わりなんかに自主的にするもので仕事外の作業だと思うんだけど…
そもそもコード書いたときに日常的にコードの整理を最後に加えておけばいいだけなんじゃないの？
なんでリファクタリングっていう整理だけの工程が仕事になってるの？
一般常識でいう整理整頓って普通は仕事前とか終わりなんかに自主的にするもので仕事外の作業だと思うんだけど…
そもそもコード書いたときに日常的にコードの整理を最後に加えておけばいいだけなんじゃないの？
なんでリファクタリングっていう整理だけの工程が仕事になってるの？
922仕様書無しさん
2018/10/25(木) 12:05:41.16923仕様書無しさん
2018/10/25(木) 12:08:40.67 別名：無職
司法「仕事は？」
リファクタリアン「社畜どもがｗｗｗ」
司法「無職ね」
司法「仕事は？」
リファクタリアン「社畜どもがｗｗｗ」
司法「無職ね」
926仕様書無しさん
2018/10/25(木) 23:29:22.79 かしむら役立たず
927仕様書無しさん
2018/10/26(金) 20:29:05.48 まだ支持を得られないのか
928仕様書無しさん
2018/10/26(金) 22:16:38.49 リファクタリングは不要
誰か支持をくれ！
誰か支持をくれ！
929仕様書無しさん
2018/10/26(金) 22:29:21.15 おまえを支持するくらいだったら無駄にリファクタリングするわ
930仕様書無しさん
2018/10/26(金) 22:31:03.30 まあ、その時点で無駄だと認めてるわけだが。
931仕様書無しさん
2018/10/27(土) 01:02:38.21 支持しなくていいなら？
932仕様書無しさん
2018/10/27(土) 09:00:10.47 無駄なリファクタリングもあれば必要なリファクタリングもあるよ
当たり前だろ
当たり前だろ
933仕様書無しさん
2018/10/27(土) 13:15:05.68 整理整頓って言った方が心理的抵抗感が減ってGoサインが出やすくなることに気付いた
934仕様書無しさん
2018/10/27(土) 13:51:57.30 でもまあGoサインとかもらうもんじゃないけどな
修正作業に含まれるものなんだから
修正作業に含まれるものなんだから
935仕様書無しさん
2018/10/27(土) 14:51:05.56 コードの複雑さを数値化して
複雑すぎるモジュールは作り直すんだよ
もちろんテストは全部やり直す
複雑すぎるモジュールは作り直すんだよ
もちろんテストは全部やり直す
938仕様書無しさん
2018/10/28(日) 19:36:53.15 複雑かどうかより、追加変更のしやすい形に直すんだぞ。
変更しやすければ、より複雑でも構わないんだ。
仕組みの複雑さより、見た目の複雑さの方が問題なのさ。
変更しやすければ、より複雑でも構わないんだ。
仕組みの複雑さより、見た目の複雑さの方が問題なのさ。
939仕様書無しさん
2018/10/28(日) 21:01:09.00 部下が勝手にリファクタやってたら懲戒にするわマジで
940仕様書無しさん
2018/10/28(日) 21:31:17.25943仕様書無しさん
2018/10/28(日) 22:09:02.77 複雑と言うのは、既存機能モジュールに置き換えしたら結果全体的には複雑化になるって話だぞ。
複雑さと読みにくさは比例しない。
複数の分岐処理と論理演算駆使した１分岐処理と、どっちが複雑？
でその論理演算を１つの関数にまとめたら、最初のものと比べてどっちが複雑？
複雑さと読みにくさは比例しない。
複数の分岐処理と論理演算駆使した１分岐処理と、どっちが複雑？
でその論理演算を１つの関数にまとめたら、最初のものと比べてどっちが複雑？
944仕様書無しさん
2018/10/29(月) 18:59:02.42 規模の大きい企業システムが混乱する原因はほぼ100%データベースだから
アプリケーションコードだけリファクタリングしてもあまり意味がないと思う
アプリケーションコードだけリファクタリングしてもあまり意味がないと思う
945仕様書無しさん
2018/10/29(月) 19:15:39.71947仕様書無しさん
2018/10/29(月) 19:24:20.10 > 業務系では絶対に許可が出ないから
それはノウハウがないってことでは？
許可が出ないのにノウハウなんて貯まるわけ無いでしょｗ
ってか、仕様変更があったらどうすんの？
DB変えられないので、仕様変更は受け付けませんって
客の要求を突っぱねるの？
それはノウハウがないってことでは？
許可が出ないのにノウハウなんて貯まるわけ無いでしょｗ
ってか、仕様変更があったらどうすんの？
DB変えられないので、仕様変更は受け付けませんって
客の要求を突っぱねるの？
948仕様書無しさん
2018/10/29(月) 19:27:14.60 仕様変更は(多大な労力が必要だけど)許可が出る
そこをはき違えちゃいかん
そこをはき違えちゃいかん
949仕様書無しさん
2018/10/29(月) 19:32:27.86 だから仕様変更でリファクタリング（が必要な場合）の許可がでるでしょ
仕様変更などで（客などから要求があって）変更する許可がでたときに
作業工程の一つとしていれるのがリファクタリングだって何度も言われてるじゃん
なんでまたいつものように、勝手にやるのがリファクタリングだって思いこんでるのさ？
仕様変更などで（客などから要求があって）変更する許可がでたときに
作業工程の一つとしていれるのがリファクタリングだって何度も言われてるじゃん
なんでまたいつものように、勝手にやるのがリファクタリングだって思いこんでるのさ？
950仕様書無しさん
2018/10/29(月) 19:35:10.73 余計なことするなって言われて終わり
最小限の変更は許可するがそれ以外は認めない
これ常識ね
最小限の変更は許可するがそれ以外は認めない
これ常識ね
951仕様書無しさん
2018/10/29(月) 19:40:07.80 リファクタリングは余計なことじゃないですよｗ
952仕様書無しさん
2018/10/29(月) 19:42:14.06 そう思ってるのは末端だけ
決定権持ってる人は揃って無駄な工程と言う
決定権持ってる人は揃って無駄な工程と言う
953仕様書無しさん
2018/10/29(月) 19:44:29.09 でも、無駄な工程と言ってるあんたは
決定権持ってないじゃんｗ
決定権持ってないじゃんｗ
954仕様書無しさん
2018/10/29(月) 19:44:55.74 リファクタリングは余計なことじゃないのかもしれんが
おまえらがやってるのはゴミを別のゴミに変えとるだけやからな
そもそもリファクタリングちゃうし
おまえらがやってるのはゴミを別のゴミに変えとるだけやからな
そもそもリファクタリングちゃうし
955仕様書無しさん
2018/10/29(月) 19:46:16.61 どうしておまえらごとき一介のコーダーがリファクタリングできると勘違いしてしまったのか
闇は深いでこれ
闇は深いでこれ
956仕様書無しさん
2018/10/29(月) 19:46:56.47 つまり、一介のコーダーじゃないからでは？
957仕様書無しさん
2018/10/29(月) 19:46:58.68 コーダーはコードしかみてないからな
変えた後の単体から受け入れまでのテスト工数
デグレのリスク
なのに後から参加して詳細知らないPGほど積極的で
最悪前よりさらにぐちゃぐちゃになる
変えた後の単体から受け入れまでのテスト工数
デグレのリスク
なのに後から参加して詳細知らないPGほど積極的で
最悪前よりさらにぐちゃぐちゃになる
958仕様書無しさん
2018/10/29(月) 19:47:43.87 そもそも問題ないとこさわるな
一生経っても終わらんなる
一生経っても終わらんなる
959仕様書無しさん
2018/10/29(月) 19:49:02.28 つまり、問題あるならリファクタリングしてよし！
960仕様書無しさん
2018/10/29(月) 19:49:27.03 そこの関連のテストがナンボあるかわかってないやつに限って触ろうとする狂気
961仕様書無しさん
2018/10/29(月) 19:49:48.89 コードの問題じゃないぞ
動きに問題があるときだけだぞ
動きに問題があるときだけだぞ
963仕様書無しさん
2018/10/29(月) 19:50:13.38 2位じゃダメなんでしょうか？
966仕様書無しさん
2018/10/29(月) 19:52:22.32967仕様書無しさん
2018/10/29(月) 19:53:21.89 >>960
> そこの関連のテストがナンボあるかわかってないやつに限って触ろうとする狂気
でも、客から修正しろって言われたんですよ？
客にテストがなんぼあるかわからんから、修正は受け付けないって突っぱねるの？
> そこの関連のテストがナンボあるかわかってないやつに限って触ろうとする狂気
でも、客から修正しろって言われたんですよ？
客にテストがなんぼあるかわからんから、修正は受け付けないって突っぱねるの？
968仕様書無しさん
2018/10/29(月) 19:53:39.83 リファクタリングの許可が出ない現実は変わらない
これだけは確かだ
これだけは確かだ
972仕様書無しさん
2018/10/29(月) 19:57:22.53 大きいプロジェクトはな、詳細なんて誰もわかんねーんだよ
だから動くと自信を持って開発することなんかできやしない
動くかも？動くと良いな。で開発してあとはひたすらテストして
あ、動いてる？良かったよかったってのを増やすしか無いんだよ
その程度のプロとは思えない仕事をするのが現実なんだから
リファクタリングして動くと自信を持てるコードになんかする必要ないの
動いてるといいなーレベルで十分。
だから動くと自信を持って開発することなんかできやしない
動くかも？動くと良いな。で開発してあとはひたすらテストして
あ、動いてる？良かったよかったってのを増やすしか無いんだよ
その程度のプロとは思えない仕事をするのが現実なんだから
リファクタリングして動くと自信を持てるコードになんかする必要ないの
動いてるといいなーレベルで十分。
974仕様書無しさん
2018/10/29(月) 19:59:12.01 > DB管理者が抱え込んでるからアプリ開発者などには手出しできん
DB管理者がリファクタリングするんでしょ？
動きを変えないのがリファクタリングなんだから
アプリ開発者にとっては関係ないこと
DB管理者がリファクタリングするんでしょ？
動きを変えないのがリファクタリングなんだから
アプリ開発者にとっては関係ないこと
975仕様書無しさん
2018/10/29(月) 19:59:20.91 新人が結合テスト中にコードリファクタして文字とか定数に変えまくってて
全体がめっちゃ変更履歴ついてて肝が冷えた
でも問題おこってないからわりかし大丈夫なのかもしれない
全体がめっちゃ変更履歴ついてて肝が冷えた
でも問題おこってないからわりかし大丈夫なのかもしれない
976仕様書無しさん
2018/10/29(月) 20:03:03.59 やっぱ>>945（データベース・リファクタリング）読んだほうが良いぜ
お前（ら？）、どうせ無停止（もしくは短時間の停止）で
（客からの支持に伴う仕様変更で必須な）データベースの構造変更とかできないだろ？
データベースとアプリを同時に変更しなきゃいけないから
どうしても停止時間が必要ですとか思ってそう
（データベースの）リファクタリングは動きを変えないものなんだから
データベースのみ変更できるんだよ。
お前（ら？）、どうせ無停止（もしくは短時間の停止）で
（客からの支持に伴う仕様変更で必須な）データベースの構造変更とかできないだろ？
データベースとアプリを同時に変更しなきゃいけないから
どうしても停止時間が必要ですとか思ってそう
（データベースの）リファクタリングは動きを変えないものなんだから
データベースのみ変更できるんだよ。
977仕様書無しさん
2018/10/29(月) 20:04:37.93978仕様書無しさん
2018/10/29(月) 20:52:54.85 >>976
んなあほな…
止められるときは止めたほうが安全だろ
変更中にシステムが正常に稼働し続けるテストとか
手続きを間違いなく行うための準備とか
その変更プロセス自体のリスクと重さ考えたら
よっぽどのことじゃなきゃやれん
んなあほな…
止められるときは止めたほうが安全だろ
変更中にシステムが正常に稼働し続けるテストとか
手続きを間違いなく行うための準備とか
その変更プロセス自体のリスクと重さ考えたら
よっぽどのことじゃなきゃやれん
979仕様書無しさん
2018/10/29(月) 20:54:12.47 > 止められるときは止めたほうが安全だろ
止められない時の話をしてる
止められない時の話をしてる
980仕様書無しさん
2018/10/29(月) 20:56:24.73 > 変更中にシステムが正常に稼働し続けるテストとか
そんなんじゃAmazonのように24時間稼働しつづけてかつ
変更もされていくシステムなんか到底できそうもありませんね
そんなんじゃAmazonのように24時間稼働しつづけてかつ
変更もされていくシステムなんか到底できそうもありませんね
981仕様書無しさん
2018/10/29(月) 20:58:03.05 Amazon神
983仕様書無しさん
2018/10/29(月) 21:57:06.02 データベースは共有してるに決まってるだろ
984仕様書無しさん
2018/10/29(月) 22:03:49.78 リファクタの手続きとしてはわかる
でもこれってほんとにシステムを停止させないための話なの？
切り替えるのはサブ構成作ってマシンごとごっそりやっちゃうみたいな感じじゃないの
でもこれってほんとにシステムを停止させないための話なの？
切り替えるのはサブ構成作ってマシンごとごっそりやっちゃうみたいな感じじゃないの
985仕様書無しさん
2018/10/29(月) 22:24:01.04 おい急にだまるなし
986仕様書無しさん
2018/10/29(月) 22:26:49.17 本気で無停止にするならイベントソースにするんでね
987仕様書無しさん
2018/10/30(火) 01:28:43.31 >>984
アプリとは違ってデータベースはサブ構成作ってえいやって
置き換えることはできないんだよ
すでに大量のデータが溜まってるんだから
データの変換作業というものが必要になる
そういうのをどうやるかが「データベースリファクタリング」には
書いてあるんだが絶版
アプリとは違ってデータベースはサブ構成作ってえいやって
置き換えることはできないんだよ
すでに大量のデータが溜まってるんだから
データの変換作業というものが必要になる
そういうのをどうやるかが「データベースリファクタリング」には
書いてあるんだが絶版
988仕様書無しさん
2018/10/30(火) 08:50:35.16 サーバーを分散しているに決まってるだろ。
990仕様書無しさん
2018/10/30(火) 09:41:24.67 えいやって置き換えなくていい様に分散化だろうに。
992仕様書無しさん
2018/10/30(火) 11:05:26.41 あ？
まさか、単にバラバラにデータばら撒いてるだけだと思ってる？
主な目的は、相互補完だぞ。
まさか、単にバラバラにデータばら撒いてるだけだと思ってる？
主な目的は、相互補完だぞ。
993仕様書無しさん
2018/10/30(火) 11:30:09.11 そういうのは良いから、何（どういう問題）がどう解決するのか書いて
どうせわかってないから誤魔化かしてるんだろうけどｗ
どうせわかってないから誤魔化かしてるんだろうけどｗ
994仕様書無しさん
2018/10/30(火) 11:30:38.12 ちなみにデータベースのリファクタリングの話をしてるんだからな
995仕様書無しさん
2018/10/30(火) 12:19:25.73 リファクタリングするよりクリアなスキーマ設計のデータベースを立ててデータ転送する方が楽
996仕様書無しさん
2018/10/30(火) 13:09:45.94 はいはい。それを無停止でやる方法が上で書いた
「データベースリファクタリング」に書いてあるんですってば
何周も回ってやっと追いついた感じだなｗ
「データベースリファクタリング」に書いてあるんですってば
何周も回ってやっと追いついた感じだなｗ
997仕様書無しさん
2018/10/30(火) 18:42:47.80 残念ですが許可されません
998仕様書無しさん
2018/10/30(火) 19:14:37.28 技術の問題じゃないんです。
無能の問題なんです。
無能の問題なんです。
999仕様書無しさん
2018/10/30(火) 19:16:07.13 だめな会社は、優れたこと（リファクタリング）でも
理解できないので、なんでもだめといいます。
ゲーム？よくわからないからだめ
漫画？よくわからないからだめ
インターネット？よくわからないからだめ
これと一緒です。
とりあえず否定からはいって
会社をダメにする奴らです
理解できないので、なんでもだめといいます。
ゲーム？よくわからないからだめ
漫画？よくわからないからだめ
インターネット？よくわからないからだめ
これと一緒です。
とりあえず否定からはいって
会社をダメにする奴らです
1000仕様書無しさん
2018/10/30(火) 19:16:23.66 ﾘﾌｧｸﾀﾘﾝｸﾞすると全部ﾃｽﾄしろと言ってくる奴の矛盾3
https://medaka.5ch.net/test/read.cgi/prog/1540809569/
https://medaka.5ch.net/test/read.cgi/prog/1540809569/
10011001
Over 1000Thread このスレッドは１０００を超えました。
新しいスレッドを立ててください。
life time: 164日 1時間 10分 26秒
新しいスレッドを立ててください。
life time: 164日 1時間 10分 26秒
10021002
Over 1000Thread 5ちゃんねるの運営はプレミアム会員の皆さまに支えられています。
運営にご協力お願いいたします。
───────────────────
《プレミアム会員の主な特典》
★ 5ちゃんねる専用ブラウザからの広告除去
★ 5ちゃんねるの過去ログを取得
★ 書き込み規制の緩和
───────────────────
会員登録には個人情報は一切必要ありません。
月300円から匿名でご購入いただけます。
▼ プレミアム会員登録はこちら ▼
https://premium.5ch.net/
▼ 浪人ログインはこちら ▼
https://login.5ch.net/login.php
運営にご協力お願いいたします。
───────────────────
《プレミアム会員の主な特典》
★ 5ちゃんねる専用ブラウザからの広告除去
★ 5ちゃんねるの過去ログを取得
★ 書き込み規制の緩和
───────────────────
会員登録には個人情報は一切必要ありません。
月300円から匿名でご購入いただけます。
▼ プレミアム会員登録はこちら ▼
https://premium.5ch.net/
▼ 浪人ログインはこちら ▼
https://login.5ch.net/login.php
レス数が1000を超えています。これ以上書き込みはできません。
