X
ﾘﾌｧｸﾀﾘﾝｸﾞすると全部ﾃｽﾄしろと言ってくる奴の矛盾2
レス数が1000を超えています。これ以上書き込みはできません。
0002仕様書無しさん
垢版 |
2018/05/19(土) 18:35:02.73
アンチは論破された。泣き崩れている。
ウソと詭弁で自分を守ることしかできていない。
様々な証拠がリファクタリングの有用性を示している。

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

もう誰にも止められない。
アンチはウソと詭弁を繰り返すだけ
0003仕様書無しさん
垢版 |
2018/05/19(土) 18:38:38.63
嘘つき嘘つき嘘つき嘘つき嘘つき嘘つき嘘つき嘘つき嘘つき嘘つき嘘つき嘘つき
嘘つき嘘つき嘘つき嘘つき嘘つき嘘つき嘘つき嘘つき嘘つき嘘つき嘘つき嘘つき
嘘つき嘘つき嘘つき嘘つき嘘つき嘘つき嘘つき嘘つき嘘つき嘘つき嘘つき嘘つき
嘘つき嘘つき嘘つき嘘つき嘘つき嘘つき嘘つき嘘つき嘘つき嘘つき嘘つき嘘つき
嘘つき嘘つき嘘つき嘘つき嘘つき嘘つき嘘つき嘘つき嘘つき嘘つき嘘つき嘘つき
嘘つき嘘つき嘘つき嘘つき嘘つき嘘つき嘘つき嘘つき嘘つき嘘つき嘘つき嘘つき
嘘つき嘘つき嘘つき嘘つき嘘つき嘘つき嘘つき嘘つき嘘つき嘘つき嘘つき嘘つき
嘘つき嘘つき嘘つき嘘つき嘘つき嘘つき嘘つき嘘つき嘘つき嘘つき嘘つき嘘つき
嘘つき嘘つき嘘つき嘘つき嘘つき嘘つき嘘つき嘘つき嘘つき嘘つき嘘つき嘘つき
嘘つき嘘つき嘘つき嘘つき嘘つき嘘つき嘘つき嘘つき嘘つき嘘つき嘘つき嘘つき
0005仕様書無しさん
垢版 |
2018/05/19(土) 18:42:49.96
>>4
もう論破されてる。いくらやっても負け犬の遠吠えにしかならない。
金を稼いでいる所は全てリファクタリングしてる
0006仕様書無しさん
垢版 |
2018/05/19(土) 18:44:55.59
そろそろリファクタリングよりもそれをする頭の悪い>>2自身が全ての元凶だって気がついた？
0007仕様書無しさん
垢版 |
2018/05/19(土) 18:47:56.31
>>5
犯罪者はパンを食べている理論に通じるものがあるな
0008仕様書無しさん
垢版 |
2018/05/19(土) 18:49:10.87
リファクタリングを定義することから始めないと
それぞれの話が噛み合わないかもわからんね
0009仕様書無しさん
垢版 |
2018/05/19(土) 18:52:41.61
リファクタリングなど全ての人間が持っているやり直したい欲求の大義名分にすぎんのだから定義など無理なのだよ
0010仕様書無しさん
垢版 |
2018/05/19(土) 19:09:33.77
マーチンファウラーは悔しかったら使えるアプリ作ってみろよ
ハゲなんか信用できないんだよ
0012仕様書無しさん
垢版 |
2018/05/19(土) 20:47:42.17
マーチンファウラーは所詮有名な技術書を出しているだけのやつ
仕事している俺（>>10）の方がすごいに決まってる
0013仕様書無しさん
垢版 |
2018/05/19(土) 20:51:24.39
2000年3月から、ThoughtWorks社に主席技術者として勤務している[1]。同社は、システムインテグレーションとコンサルティングを業務とする会社である。

SIかあ
0014仕様書無しさん
垢版 |
2018/05/19(土) 20:57:08.26
アメリカのシステムインテグレーションなんて
ろくなもんないだろ
SIなら日本が最高だよ
0016仕様書無しさん
垢版 |
2018/05/19(土) 21:36:07.81
>>12
いや、アレ詐欺師だろ
なんの実績もないじゃん
有名だと言うことにして売り込んでいる何かだ
0017仕様書無しさん
垢版 |
2018/05/19(土) 21:40:24.54
言っとくけど有名な技術書書いたって実績とは認めないからな
うちの新人の初めのコードコミットのほうが何倍も価値がある
0018仕様書無しさん
垢版 |
2018/05/19(土) 21:43:16.16
>>17
すまんがおまえんとこのコードには何の価値もない
0019仕様書無しさん
垢版 |
2018/05/19(土) 21:48:04.63
雑誌社かソフトウェア会社か
そーゆーのの広告塔なんだろうな
なんの実績もねーのにあの祭り上げ方はおかしい
0020仕様書無しさん
垢版 |
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
002119
垢版 |
2018/05/19(土) 21:50:58.75
言っとくが、有名な技術書執筆は実績とは認めねーからな
0022仕様書無しさん
垢版 |
2018/05/19(土) 21:53:10.80
世界中にどれだけ影響を与えようが本が売れようが
客から金をもらえる1行の方が価値がある
0023仕様書無しさん
垢版 |
2018/05/19(土) 21:53:41.92
だから給料を上げろ
マーチンファウラーよりも俺のほうが給料が高くあるべきだ
0025仕様書無しさん
垢版 |
2018/05/19(土) 22:05:07.06
俺らは技術者なんだから技術についてちゃんと精査しないと駄目だってことだな
0026仕様書無しさん
垢版 |
2018/05/19(土) 22:06:38.55
技術とはコードを書くことである
本を書くことは技術ではない
0028仕様書無しさん
垢版 |
2018/05/19(土) 23:30:03.76
マーチンファウラーを貶めると
自分の価値が上がるはず
0029仕様書無しさん
垢版 |
2018/05/19(土) 23:35:47.97
>>28
ただ、怪しいとは思っておいた方がいいよ
なんもやってねーのに名前だけがひとり歩きしてる
0030仕様書無しさん
垢版 |
2018/05/19(土) 23:37:56.25
俺の会社じゃ有名な技術書書いても、
なにもやってないの同じだからなー
0031仕様書無しさん
垢版 |
2018/05/19(土) 23:44:35.06
>>30
売れるのはいいけど
それが役に立つかどうかは別の話じゃん

ホーキンス博士やでんじろう先生が役に立たないってわけじゃないけど
そればっかりでも駄目なんだよ
0033仕様書無しさん
垢版 |
2018/05/19(土) 23:47:02.57
そのとおりだ。世界中で有効活用されている本でも
俺のにとっては別だからな。
俺が理解できないとどんな本も役立たずだ
0035仕様書無しさん
垢版 |
2018/05/19(土) 23:57:51.61
>>34
じゃあ言い出しっぺが
精査の方法を出してくれ
技術書一般に当てはまるやつ
0036仕様書無しさん
垢版 |
2018/05/19(土) 23:58:46.61
Amazonの評価とかでいいんやないか？
他にもっといい案があればよろしく
なければこれで
0037仕様書無しさん
垢版 |
2018/05/19(土) 23:59:44.46
企業が発表する技術を精査するのは雑音が多くて大変だ

敵はマーチンファウラーなんて実績の無いおっさんを有名人に仕立て上げることができる強敵だ
ネームバリューに負けて中身を見れないような雑魚は
そもそも技術書なんか手に取るべきでは無かった
0039仕様書無しさん
垢版 |
2018/05/20(日) 00:01:24.46
日本のAmazonだと翻訳が悪くて～っていうのがあるので
アメリカのAmazonでの評価にしよう
そっちの方がレビュー多そうだし
0040仕様書無しさん
垢版 |
2018/05/20(日) 00:02:17.95
他にいい案はないかな？
ないならamazon.comの評価で判断するけど
0041仕様書無しさん
垢版 |
2018/05/20(日) 00:03:16.17
反対する人もないようだし
いいんじゃないですかね
0042仕様書無しさん
垢版 |
2018/05/20(日) 00:03:49.29
リファクタはプログラマ自身のためのもの
街並みがきれいなところに住むと幸福度が上がるように
自分の作ったコードがきれいに整頓されていると居心地が良い

効率？物の価値のわからんやっちゃな
プログラマになったら人生の３分の１をコードと共に過ごすんだぞ
0043仕様書無しさん
垢版 |
2018/05/20(日) 00:06:40.82
そもそもお前らはどうなの？

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

前者であればハゲに同調するのも正しい選択なんだ
0044仕様書無しさん
垢版 |
2018/05/20(日) 00:07:47.31
>>42
それって君の感想じゃん
なんかどういう仕組みでお金になるのか説明できる資料はないの？
0045仕様書無しさん
垢版 |
2018/05/20(日) 00:09:24.00
このままだと本が有用かどうかがamazon.comでの
評価になっちゃうよ？それでいいの？
0048仕様書無しさん
垢版 |
2018/05/20(日) 00:11:40.71
5ちゃんねるには見えないIDでNGにする方法があるのだ
その方法は教えられないがな
0051仕様書無しさん
垢版 |
2018/05/20(日) 00:14:17.23
>>44
最終的には金が入ると嬉しいのだって人間の感想じゃないか
0052仕様書無しさん
垢版 |
2018/05/20(日) 00:15:23.07
仕事は遊びじゃない。楽しいと思った時点で
それは仕事じゃないんだよ。金を稼ぐことだけ考えてろ
0054仕様書無しさん
垢版 |
2018/05/20(日) 00:18:35.05
満場一致ってことでAmazonでの評価が高ければ、
世界中で有効活用されているとみなします。
0055仕様書無しさん
垢版 |
2018/05/20(日) 00:19:00.94
マーチンファウラーの本すごいな。
世界中で有効活用されてるじゃん
0056仕様書無しさん
垢版 |
2018/05/20(日) 00:34:54.29
は？Amazonの評価なんて認めるわけねーじゃん。ばーかーばーか
0057仕様書無しさん
垢版 |
2018/05/20(日) 00:35:12.65
>>51
そう、そこまで肯定してしまうと
彼らの虚業にも正当性ができてしまう

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

それの何が悪いのかと？
言われると何も悪くはない
0058仕様書無しさん
垢版 |
2018/05/20(日) 00:36:42.51
>>56
遅すぎｗ 他に代替案出せなかったお前の負け
負け犬は負け犬らしく遠吠え吐いて逃げなさい
0059仕様書無しさん
垢版 |
2018/05/20(日) 00:37:46.74
>>57
> 彼らははじめからかあるいはいつの時点からか
> 全く役に立たない技術をさも役に立つかのように

あー、君。悪いんだけどマーチンファウラーの書籍は
Amazonの評価で役に立つって証明されたばかりなんだわ
その結果を無視せんといてな
0060仕様書無しさん
垢版 |
2018/05/20(日) 00:40:27.24
無視してるのはわざとだろｗ
わざとであることを指摘したら
可愛そうじゃないかｗ
0063仕様書無しさん
垢版 |
2018/05/20(日) 07:20:00.68
反論のなにも、そうやって仕事失った人がいますよ。
改良してください→「動いているからいじりません」
バグ修正してください→「動いているからいじりません」
0064仕様書無しさん
垢版 |
2018/05/20(日) 09:31:34.08
>>59
証明はされてないんじゃないかな
どっかの誰かが賛同したかもしれないけど
それが正しいかは別の話でしょ
もっと論理的に考えなよ
君プログラマーなの？
0066仕様書無しさん
垢版 |
2018/05/20(日) 13:15:34.69
>>64
もっといい案を出せなかった時点で
お前の言葉には説得力がない
0068仕様書無しさん
垢版 |
2018/05/20(日) 15:50:28.92
>>66
(´；ω；｀)
0069仕様書無しさん
垢版 |
2018/05/20(日) 16:36:20.66
>>64
おまえらのような有象無象の馬鹿に多くの賛同が得られたという事は
すなわちその評価を得た対象は正しくないという事を意味する
これが論理的な考え方というものだ
0070仕様書無しさん
垢版 |
2018/05/20(日) 17:02:30.35
俺らみんな地球が丸いと思ってたがうそだったのか
0071仕様書無しさん
垢版 |
2018/05/20(日) 17:12:26.04
バカでも安全にコードを変更できるんだし良いよ
0072仕様書無しさん
垢版 |
2018/05/20(日) 17:23:57.92
賢いのが世間と違うこというのって自分の知識や経験で判断してるからじゃん

世間が世間のいうこと鵜呑みにするのは、だいたいはそれなりに世間が正しくてなんとかなってるからで
それだけを根拠にその逆に判断するのって最悪じゃね？
0074仕様書無しさん
垢版 |
2018/05/20(日) 17:49:46.08
馬鹿の直感と真実が一致してるかどうかが重要
1+1は馬鹿の直感も真実も2になるので馬鹿の逆張りをしてはいけない
量子力学のような直感と真実が一致しない問題や、巧妙に思考を誘導する引っ掛け問題に対しては馬鹿の逆張りをした方が有利となる
そもそも馬鹿の答えは白紙になるってツッコミはなしな
0075仕様書無しさん
垢版 |
2018/05/20(日) 18:25:02.66
>>74
そもそもおまえは馬鹿
0076仕様書無しさん
垢版 |
2018/05/20(日) 22:58:26.39
マーチンファウラーが直近でなんかソフトの一つでも作ってりゃなぁ
でも実績を見ると典型的な詐欺師だね

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

と
0079仕様書無しさん
垢版 |
2018/05/22(火) 00:24:18.28
ジャップの財政破綻、早く来い。
俺を笑った奴らが真でいくのを笑い返して復習してやる。
0082仕様書無しさん
垢版 |
2018/05/22(火) 07:12:59.30
あんなハゲ信仰してるやつは終わってるってことだ
0086仕様書無しさん
垢版 |
2018/05/22(火) 08:04:05.58
>>85
テストはできる。ただ時間がかかるから
コストも掛かるだけだ
0087仕様書無しさん
垢版 |
2018/05/22(火) 11:16:01.54
とても簡単な自宅で稼げる方法
参考までに書いておきます
グーグルで検索するといいかも『ネットで稼ぐ方法　モニアレフヌノ』

4TTGQ
0091仕様書無しさん
垢版 |
2018/05/22(火) 19:54:46.87
コストがかかるとテスト回数を減らすだろ
テストってのは何回もやらなきゃダメなんだよ
1回だけじゃたまたまテスト通っただけかもしれんぞ
これは数学的にも正しいことが証明されてるから国外の大手機械メーカーなどは凄まじい回数のテストを繰り返す
0092仕様書無しさん
垢版 |
2018/05/23(水) 00:20:00.32
アプリケーションのリファクタリングは実はそんなに重要じゃない
データベースのリファクタリングしろマジで
0093仕様書無しさん
垢版 |
2018/05/23(水) 02:28:17.27
リファクタリングを読みやすくするものだとすると
データベースよりもアプリケーションの方が
よく読む
0095仕様書無しさん
垢版 |
2018/05/23(水) 07:46:08.29
不確定要素が無いことを証明できない限り不確定要素が無いからテストは1回でいいとは言えない
そんなことは物理的に不可能なのでテスト回数を増やしてこの程度の確率でなら正常動作を保証しますとしか言えんのだよ
科学的な実験をしたことのある理系ならわかってることだけどね
0097仕様書無しさん
垢版 |
2018/05/23(水) 21:57:34.51
バグが無いことを証明できないからテストするしかないっていう
0098仕様書無しさん
垢版 |
2018/05/24(木) 06:18:17.54
テストしなくちゃいけない
↓
日本凄い
↓
俺凄い
0101仕様書無しさん
垢版 |
2018/05/24(木) 18:21:34.59
リファクタリングって・・・
聞いてるこっちが恥ずかしくなるぜ
マー○ンファ○ラーってのは詐欺師のヘビー級チャンピオンの事
お前ら信者がやっているのは過労によるハゲの量産化
技術者は世の中を便利にするために行動しようとするものだが
信者どもはありもしない仕様変更を想定してリファクタリングとか言ってるわけだろ？
リファクタリングとか聞くたびに思ってたのよ
「今回の○○は△△に対応してるのでいくつでも追加可能にしておきました」
これって訳すと「設計書通りに実装しませんでした」
って事だろ
プログラマとか関係なく
世界中の生物を賢い順に並べたら
お前は先頭どころか下から数えた方が早いんじゃねーか？
0103仕様書無しさん
垢版 |
2018/05/24(木) 18:50:41.09
>>101
ん？違うよ
ファウラーのリファクタリングを読み返して理解してからまた来なよ
0104仕様書無しさん
垢版 |
2018/05/24(木) 18:58:55.64
>>103

1. 俺の理解によるとマーチンファウラーは詐欺師である
2. 詐欺師は信用してはいけない
3. 詐欺師であることを見抜いた俺はすごい
0106仕様書無しさん
垢版 |
2018/05/24(木) 19:18:23.48
ハゲに有能はいない
これが全て
0107仕様書無しさん
垢版 |
2018/05/24(木) 22:09:06.89
大規模リファクタリングって普通それを作った・大きく関わってきたメンバーが入るもんだよね
0109仕様書無しさん
垢版 |
2018/05/25(金) 07:52:06.62
ノルマこなした上でちゃんとテスト書くならリファクタリングしていいよって言われたから取り組んでるんだが
DB層が腐りきってるからどうにもならんという事に気が付いた
DB層を無視してDB層より上を綺麗にしようたってそうはいかないんだ

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

そんな腐りきった巨大な企業データベースをリファクタリングする体系的なテクニックって無いものか
0110仕様書無しさん
垢版 |
2018/05/25(金) 15:46:30.70
難しい構造なのに無理矢理
簡単（？）な構造に押し込めるから
余計におかしくなってしまうんよ
0111仕様書無しさん
垢版 |
2018/05/25(金) 19:58:20.08
>>109
設計やプログラミングを体系的に学ぶ方法はなんぼでもあるんやで
これを機会に1から学びなおしてみたらどうや無能くん
0112仕様書無しさん
垢版 |
2018/05/25(金) 20:08:33.77
リファクタの許可がでたら
企業の既存大規模ＤＢの刷新を考えだす新人ｗ

古いのはもういろいろプログラムが紐づいてるから個人で変更は難しい
お前の脳をＤＢに合わせてリファクタしたほうが
将来にわたって絶対楽
https://qiita.com/opengl-8080/items/37beac5e210f5363af4b
0113仕様書無しさん
垢版 |
2018/05/25(金) 20:32:07.11
お前らは何もわかってねえよ
ドメインロジックはおろかプレゼンテーションロジックまでデータベースを侵食しているシステムのヤバさをな
ホストアプリケーションのちょっとした変更がデータベースを破壊する
そんな地獄をたっぷりと味わってから出直してこい
0114仕様書無しさん
垢版 |
2018/05/25(金) 20:37:34.69
>>112
ただのバージョン管理じゃん
機械的な等価変換もできないしテスト支援でもない
ストアドにもホストアプリケーションにも非対応
リファクタリングとは名ばかり
0115仕様書無しさん
垢版 |
2018/05/25(金) 20:40:21.58
>>113
なんやそれw
「大人は何もわかってくれない」的なwwww
おまえリアル中二やな無能www
0117仕様書無しさん
垢版 |
2018/05/26(土) 08:42:29.02
マーチン・ファウラー : 数十年にわたってビジネスへのオブジェクト指向の適用に尽力する独立コンサルタント。
ヘルスケア、金融取引、企業財務などの分野におけるシステムのコンサル経験を持つ。
顧客にはクライスラー、シティバンク、英国民保健サービス、アンダーセン・コンサルティング、
ネットスケープ・コミュニケーションズなどが名を連ねる
0118仕様書無しさん
垢版 |
2018/05/26(土) 08:56:33.31
すごい実績だな
そんなファウラーが言うなら間違いない
JavaScriptのリファクタリング本楽しみ
0119仕様書無しさん
垢版 |
2018/05/26(土) 10:14:39.33
その人のリファクタリング本持ってるけど
そんなに目から鱗なこと書いてあるか？って思ったけどな
0120仕様書無しさん
垢版 |
2018/05/26(土) 10:16:13.77
今や常識だからな
地球が太陽の周りを回っているのだって現代人に行ってもなにを今更ってなるじゃん？
それと同じ
でも常識を定着させるのって大変なんだぜ
0122仕様書無しさん
垢版 |
2018/05/26(土) 13:14:13.69
アルゴリズムを考える人より
アルゴリズムを特定の言語で実装するほうが
偉いに決まってるだろ
0125仕様書無しさん
垢版 |
2018/05/26(土) 14:50:11.14
マーチンファウラーはRailsのActiveRecordの基本を考えただけ
それを実装したRailsの開発者のほうがすごい
そのActiveRecordを使いこなしている俺のほうがもっとすごい
やつはリファクタリングを考え出しただけ
使いこなしている俺のほうがもっとすごい
0128仕様書無しさん
垢版 |
2018/05/26(土) 16:14:47.09
マーチンファウラーはRailsのActiveRecordの基本を考えただけ
それを実装したRailsの開発者のほうがすごい
そのActiveRecordを使いこなしている俺のほうがもっとすごい
やつはリファクタリングを考え出しただけ
使いこなしている俺のほうがもっとすごい
0130仕様書無しさん
垢版 |
2018/05/29(火) 13:38:17.98
>>128
サービス使うだけのオレの方がもっとすごい
0132仕様書無しさん
垢版 |
2018/05/29(火) 21:31:16.12
普通に考えて丸投げされてる方がすごいやんコーダーさん
0135仕様書無しさん
垢版 |
2018/05/31(木) 06:56:15.54
本当に頑張っても問題が解決できないなら
その頑張りが問題を解決できない原因です。
0136仕様書無しさん
垢版 |
2018/05/31(木) 07:09:12.81
>>134
は？コーダーさんすごいね言うとるやん
何を言うとるんやおのれは？w
0137仕様書無しさん
垢版 |
2018/06/01(金) 21:41:56.20
リファクタ厨はマーチンファウラーのハゲがバレて逃げちゃったんだろ？
0138仕様書無しさん
垢版 |
2018/06/01(金) 22:43:08.05
>>137
ハゲにコンプレックス持ってる奴は、そういう発想がナチュラルに出て来るんだな。
0139仕様書無しさん
垢版 |
2018/06/02(土) 03:08:10.24
まさか、あのマー○ンファ○ラーがハゲとか誰も予想だにしなかったよね
0142仕様書無しさん
垢版 |
2018/06/02(土) 19:00:26.84
ハゲに人権なし
0143仕様書無しさん
垢版 |
2018/06/05(火) 10:16:30.55
リファクタリング出来る環境なら、テストも自動化されてるはずだよな？
まさか手作業でリファクタリングしてるとか？
0145仕様書無しさん
垢版 |
2018/06/05(火) 11:28:09.65
手作業でテストしている所が
リファクタリングに文句つけてるんだろうね
0146仕様書無しさん
垢版 |
2018/06/05(火) 13:35:11.08
テストがないとリファクタリングできない
リファクタリングしないとテストが整備できない


はい終わり
リファクタリングは机上の空論
0147仕様書無しさん
垢版 |
2018/06/05(火) 13:46:40.92
最近のビジュアルスタジオって、そここっちのコードの方が良いよって言って来るよな？
0148仕様書無しさん
垢版 |
2018/06/05(火) 13:59:43.66
>>146
え？テストができないコードをどうやって今修正してるの？
修正できるならいくらでもテストできるように修正できるはずだよね？
0149仕様書無しさん
垢版 |
2018/06/05(火) 14:08:09.27
>>148
手作業で必要なテストをするだけ
悪いけどこっちはリファクタリング厨みたいに無計画じゃないから安定的でバグはそんなに出ないんだわ
なので手作業のテストで変更を十分カバーできるのな
0150仕様書無しさん
垢版 |
2018/06/05(火) 14:41:13.07
>>149
じゃあ手作業でテストすればリファクタリングできるね（大爆笑）
おら？どうした？墓穴踏んだ気分はｗｗｗｗ
0153KAC
垢版 |
2018/06/05(火) 17:58:50.19
>>143
お前は自動テストだけやって製品出荷するつもりか？
0157仕様書無しさん
垢版 |
2018/06/05(火) 22:18:12.30
コードレビューとかうざすぎる
うごきゃいんだよ動きゃ
汎用性なんか知るか
全部コードベタ書きにしてやるわ
0160仕様書無しさん
垢版 |
2018/06/05(火) 23:05:18.43
綺麗なコードを書いてリファクタリングを繰り返したほうが楽に動くコードを維持できると思うんだが
0161仕様書無しさん
垢版 |
2018/06/05(火) 23:06:29.62
動かすだけなら汚くてもいい
綺麗に書いたら時間がかかるって前提がまず狂ってる
0162仕様書無しさん
垢版 |
2018/06/05(火) 23:08:28.75
汚いコードを書いてリファクタリングしたら時間かかったが？
0163仕様書無しさん
垢版 |
2018/06/05(火) 23:11:55.06
それは汚いままだともっと時間がかかってたんだよ
リファクタリングしたことによって被害が最小化した
0164仕様書無しさん
垢版 |
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
0165仕様書無しさん
垢版 |
2018/06/05(火) 23:27:42.79
上のコードなら3分で書ける
コードもシンプルで誰が見てもわかりやすい
リポジトリやらドメインサービスやらおバカなことをやりだすとクラスが一気に増えて意味不明になる
コーディング時間も10倍じゃ足らんくなる
世間一般で言う綺麗なコードを書くのは実は非合理的なんやな
コンサルさんはそれでお金貰っとるから綺麗に書かなアカンって洗脳しようと企んどるようやけど騙されへんで
0167仕様書無しさん
垢版 |
2018/06/05(火) 23:29:45.86
このように、たったこれだけのコードが
自分が作っているものの全てだと
言ってるような人の浅い考えなのです
0168仕様書無しさん
垢版 |
2018/06/05(火) 23:32:10.27
なんや論理的反論できひんなら素直にそう言いや
負け惜しみはみっともないで
0169仕様書無しさん
垢版 |
2018/06/05(火) 23:38:18.13
悔しかったら、自分が普段どれだけのコードを書いてるのか言ってみいや
100行か？ 1000行か？
0170仕様書無しさん
垢版 |
2018/06/05(火) 23:40:00.55
普段1万行とか普通に書いてる人間に
たった10行のコード持ってきて
ほら、この場合はいらないでしょ？と言われてもな（苦笑）
0171仕様書無しさん
垢版 |
2018/06/05(火) 23:45:13.51
上のコードなら3分で書けるといっただろ？
10行で3分なら、100行で30分、1000行で300分
1万行でも3000分だ。50時間、2日あればできる量だ
いちいちリファクタリングする意味はない
0172仕様書無しさん
垢版 |
2018/06/05(火) 23:45:54.47
リポジトリやらドメインサービスやらくだらない余計なクラスを書くから何万行も無駄なステップ数が生じるんやで
0173仕様書無しさん
垢版 |
2018/06/06(水) 01:34:19.28
c#のインターフェース機能が百害あって一利無しだ
0176仕様書無しさん
垢版 |
2018/06/06(水) 08:14:52.01
>>174
ソースが追えない
インターフェース読んでる箇所全部見ないといけない
動かさないと挙動がわからない
動かせないときの開発のヤバさは異常
0179仕様書無しさん
垢版 |
2018/06/06(水) 12:21:34.08
設計者が何のためにインターフェース切って疎結合にしたのかわかってないのでは？
インターフェースの先まで見に行かないとクライアントを保守できないとしたら
それは設計が間違ってるからインターフェースを超えて結合しちゃってるんだよ
0180仕様書無しさん
垢版 |
2018/06/06(水) 12:23:37.73
動かせないってのも何言ってんだかって感じだね
モックを書くって発想がないのかな？
ユニットテストしてないの？
ユニットテストは個別に動かすこともできるよ
0181仕様書無しさん
垢版 |
2018/06/06(水) 12:41:30.48
>>179
同じインターフェースでほとんど似てる機能なんだから機能重複しまくりだと思うけど見たら負けなの？
0184仕様書無しさん
垢版 |
2018/06/06(水) 13:00:12.33
>>183
え？自分で呼び出し口で違いがわからないようにしたんだよね？
知る必要がないってことで
忘れちゃったの？
だからそこは追えないのが正解でしょ？
0185仕様書無しさん
垢版 |
2018/06/06(水) 13:30:39.28
>>179
リリースした後のバグっていうのは通常アプリケーションを
使っているときに見つかるんだわ
○○という設定でボタンをクリックしたときとか

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

その時、インターフェースの先を見ないでバグのある箇所を
見つけることはできないよ。だってインターフェースの先に
バグがあるんだから
0186仕様書無しさん
垢版 |
2018/06/06(水) 13:33:57.19
>>182
モックはなるべく書かないほうが良い。
なぜならモックはOKだけど、実際のアプリでは
バグになることがあるから

なお、インターフェースはモックにすり替えるためにあるのではなく
同じインターフェースを持つ複数のモジュールを使うためにある
テストを用意にするためでも疎結合にするためでもない
0187仕様書無しさん
垢版 |
2018/06/06(水) 13:38:25.16
c#のinterfaceでソースが追えないってのは、そもそも追い方からして間違ってる気がする
追加や保守なら何も考えずに呼び出し履歴追って修正に対する影響範囲調べりゃいいだけだし、それでクラス設計やデザインパターン機構の根っこを弄らんといけないなら、大改修だろ。
そもそも別の手がないか考えろよってのもある
0188仕様書無しさん
垢版 |
2018/06/06(水) 13:57:01.37
修正に対する影響範囲調べて
それでどうやって最初から存在するバグを見つけられるの？
0189仕様書無しさん
垢版 |
2018/06/06(水) 15:30:27.75
どんなクソコードも解読して作り直すみたいな
特殊能力持った奴も中にはいるのかな
0191仕様書無しさん
垢版 |
2018/06/06(水) 19:46:21.82
最低限ユニットテストしておけよってことじゃないのか
0193仕様書無しさん
垢版 |
2018/06/06(水) 21:47:01.50
　　　　　　　　　　　　　　　　　　　　ﾊ_ﾊ　_
　　　　　　　　　　　　　　　　　　　∩ﾟ∀ﾟ)ﾉ　　飛べるよ！
　　　　　　　　　　　　　　　　　　　 ）　　/
　　　　　　　　　　　　　　　　　　　(_ﾉ_ﾉ

　　　　　　　　　　　　　　　彡
　　　　　　.
　_,,..-―'"⌒"~￣"~⌒ﾞﾞ"'''ｮ
ﾞ~,,,....-=-‐√"ﾞﾞＴ"~￣Y"ﾞ=ﾐ
Ｔ　　|　　 l,＿,,/＼　,,/l　　|
,.-r '"l＼,,j　　/　 |/　 L,,,/
,,/|,／＼,/　_,|＼_,i_,,,/ ／
_V＼　,,/＼,| 　,,∧,,|_/
0195仕様書無しさん
垢版 |
2018/06/06(水) 22:33:07.03
ポケモン
デジモン
やれるもん

ヤダモン
ドラえもん
やれるもん
0196仕様書無しさん
垢版 |
2018/06/06(水) 23:01:14.34
設計書の段階でリプレースしてえ
日本のSEさん設計能力低すぎてアーキテクチャすら定まってない
0197仕様書無しさん
垢版 |
2018/06/06(水) 23:37:14.88
>>187
うまくいってる間はいいけど
発生率の低いバグが出たときに
インターフェースは死ぬ
動かしてみないと何が生成されてるのかわからないうえに
影響範囲はインターフェースをもつクラス全部になる
一つ一つ可能性を排除していく作業を行わなければならない
0199仕様書無しさん
垢版 |
2018/06/07(木) 07:11:25.09
>>198
え？具体的に右クリックからどうやって追ってくの？
そもそも知らなくていいってのが君の主張だったよね？
何、一生懸命できるみたいなこと言ってるの？
必要ないんでしょ？
0205仕様書無しさん
垢版 |
2018/06/07(木) 08:21:56.25
本当にインターフェイスから実装に飛べないやつなんているのかよ…
0207KAC
垢版 |
2018/06/07(木) 10:42:30.32
コード読む力が無いだけかと
0210仕様書無しさん
垢版 |
2018/06/07(木) 19:45:28.92
インターフェースの契約をテストするコードを書いて実装クラス全部についてテスト実行するだけだろ
それでオールグリーンならインターフェースの先がなんだろうと関係ない
バグはクライアントクラスにあるとわかる
もちろんレッドが出たらインターフェースのどの実装クラスが犯人か即座にわかる
0211仕様書無しさん
垢版 |
2018/06/07(木) 19:54:58.72
>>210
テストでバグがないことが証明できるなら
そうだろうな。

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

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

結局バグを見つけるために、インターフェースの呼び出し側が悪いのか
呼び出し先が悪いのか、特定の実装クラスだけで起こる問題なのか
探し回る必要がある
0213仕様書無しさん
垢版 |
2018/06/07(木) 20:33:15.96
>>211
なるよ
それが契約というものなんだよ
契約はそうあれと定められたものだからね

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

契約そのものが矛盾してるってこともあるけどそれは契約が間違っているわけではなく
すべてのインターフェース実装クラスが間違っているということになる
それはそれで赤信号が出まくるからすぐにわかる
バグではないが役に立たない矛盾した契約を解消しようってことになるね
0214仕様書無しさん
垢版 |
2018/06/07(木) 20:36:53.10
ちなみにその矛盾した契約ってのはバグよりも遥かに発生しにくい
契約は実装よりもずっとシンプルだからね
なのでほぼすべてのケースで契約をテストするだけでクライアント側かインターフェース実装側のどちらかが悪いか決着がつく
0215仕様書無しさん
垢版 |
2018/06/07(木) 20:38:41.72
>>213
> なるよ
> それが契約というものなんだよ
> 契約はそうあれと定められたものだからね

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

まずそう定められたものとか
嘘言わないで理由を言おうか
0216仕様書無しさん
垢版 |
2018/06/07(木) 20:47:13.17
人間はミスする
故に人間が作ったものに完璧はない。

「契約」が人間が作ったものであれば
完璧なものは存在しないのでバグない証明にはならない
0219仕様書無しさん
垢版 |
2018/06/07(木) 23:01:28.40
インターフェースに間違いって言われてもなぁ？

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

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

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

ぶっちゃけオーダーメイドのビジネスアプリにこんなもん適用してる奴
頭が悪いだろ
0220仕様書無しさん
垢版 |
2018/06/07(木) 23:54:14.02
バグってるインターフェースは存在しない
嘘だと思うなら何か例を挙げてみな
絶対の不可能だから
0221仕様書無しさん
垢版 |
2018/06/07(木) 23:58:52.34
>>219
ちがう
「200Vでなければならない」
が本質

「100Vしかないから変圧して200Vにしよう」
これは実装
0222仕様書無しさん
垢版 |
2018/06/08(金) 00:31:57.52
>>220
論点がおかしい。
いくらテストしても、バグがないことは証明できず
いざバグが発生したとなったときに、
インターフェースの呼び出し側に問題があるか
呼び出し先にあるのかわからないから
インターフェースの先まで調べないといけないって話だろ
0223仕様書無しさん
垢版 |
2018/06/08(金) 00:37:50.29
>>222
インターフェースにはバグは無い
実装にバグがあるか
クライアントにバグがある
0225仕様書無しさん
垢版 |
2018/06/08(金) 01:42:03.55
>>224
頭悪いのかな？

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

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

テストしてない場合にどうやってわかるの？
0226仕様書無しさん
垢版 |
2018/06/08(金) 06:07:35.14
>>225
テスト実施してない場合はテスト実施してください
大丈夫ですかあなた？
0227仕様書無しさん
垢版 |
2018/06/08(金) 06:25:46.17
プロフェッショナルならログを取ろう
スタックトレースを見れば実行時型はすぐわかる
インターフェースへのIOをログして仕様通りか確認すれば即座に具象クラスのバグかどうかわかる
具象クラスのバグじゃなければモックでIOを再現すれば新しいテストケースになる
どんなバグも定数時間で解ける
0228仕様書無しさん
垢版 |
2018/06/08(金) 07:24:46.93
無理だな
ゲームでよくあるごった煮リストだろ？
上履きとか黒板消しも鍋に入ってるし
0230仕様書無しさん
垢版 |
2018/06/08(金) 08:20:12.44
テストすればバグを無くせると
いう、壮大な勘違い。
0231仕様書無しさん
垢版 |
2018/06/08(金) 12:49:02.36
>>227
だからそれ実行しないとわかんないって言ってるんでしょ？
インターフェースなんてゴミ機能使うからこのザマなわけ
0234仕様書無しさん
垢版 |
2018/06/08(金) 19:08:52.90
ソース見てもわからないソースにしたわけだ
実行しないとわからないクソソースって理解できた？
0236仕様書無しさん
垢版 |
2018/06/08(金) 23:00:48.32
>>235
全部見ればなｗ
インターフェースは呪いだ
こいつを通すと問答無用で全部読まなければならなくなる
普通は不具合がでてもいいように影響範囲を絞るように組むものだが
こいつは同じインターフェースを使う奴全員を問答無用で容疑者にする
プロジェクトを破綻させたいならオススメの手法
0237仕様書無しさん
垢版 |
2018/06/08(金) 23:02:35.01
ソース見ればわかるよ
インターフェースが使われていると大変だけど
0238仕様書無しさん
垢版 |
2018/06/09(土) 00:33:43.99
>>236
影響範囲を極限まで絞るためのインターフェース
もし直接参照したら連鎖的に影響が広がりコードベース全体が影響範囲になってしまう
インターフェースできっとけばあらゆる影響が局所化する
0240仕様書無しさん
垢版 |
2018/06/09(土) 09:01:03.39
そもそも違いを知らなくていいように自分でしたのに特定なんかできるわけないじゃん
自分が何をやってるのかわかってる？
君が作ってるのはごった煮リストって言われる闇鍋
0241仕様書無しさん
垢版 |
2018/06/09(土) 10:32:37.55
例えばインターフェースが以下のようなものだったとしよう

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


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

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


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

このインターフェースを守っていれば、呼び出し側にはバグはなく
呼び出し先にバグが有るということだ
0242仕様書無しさん
垢版 |
2018/06/09(土) 10:33:15.97
インターフェースの先がどうなってるかは気にしなくていい
気にしなければならないなら設計ミス
0243仕様書無しさん
垢版 |
2018/06/09(土) 10:41:45.13
呼び出し先にバグがあるなら、呼び出し先を見ないといけない
↓
どうやって呼び出し先を特定するの？

が疑問らしいよ。騒いでいる人は。
0245仕様書無しさん
垢版 |
2018/06/09(土) 11:11:20.05
>>244
実行しないとわかんないクソソースなんだろ？
どうしてそこを認めないの？
0247仕様書無しさん
垢版 |
2018/06/09(土) 11:17:20.69
>>246
インターフェースの先は絶対にバグらない
そういう世界に書き換えておいた
0248仕様書無しさん
垢版 |
2018/06/09(土) 11:18:16.03
DIコンテナにインターフェースの実装クラスは
これを使いますって書くじゃんすぐ分かるじゃん
0250仕様書無しさん
垢版 |
2018/06/09(土) 11:35:07.25
>>245
実行すりゃいいじゃん
ソースを目視チェックするより簡単だよ
0251仕様書無しさん
垢版 |
2018/06/09(土) 11:36:59.79
>>249
インターフェースの利用側は知らなくていいだけ。
インターフェースの提供側(DIコンテナ)でクラスを切り替えることにより、
利用側はコードを変えずに実装を変えられるのがメリット。
0252仕様書無しさん
垢版 |
2018/06/09(土) 11:41:27.66
>>248
だからみんな99%のインターフェースは問題なしって認識で納得してるよ
実行時にダイナミックに型が変わる場合に限ってバグを出した型の特定が難しいからインターフェースはダメなんじゃないかと議論してるところ
0254仕様書無しさん
垢版 |
2018/06/09(土) 11:51:44.90
switch (kubun) {
case Kubum.Hoge:
// super long code
break;
case Kubun.Fuga:
// super long code
break;
case ...
}

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

しかも分岐バージョンの方はインターフェースや抽象クラスと違って各バリエーションがバラバラに引きちぎられてプログラム全体に散らばってるからトレースが死ぬほど大変
0255仕様書無しさん
垢版 |
2018/06/09(土) 11:55:23.51
>>252
お前はifやswitchを使わずにコードを書くのか？
インターフェースの提供側にifやswitch文が出来たらコードを追えないの？
0256仕様書無しさん
垢版 |
2018/06/09(土) 12:09:55.53
>>255
インターフェースや抽象クラスに分離するほどのものでない小さく局所的な条件分岐ならコードを見ればいい
でも今はインターフェースや抽象との対比としての条件分岐を話題にしてる
その場合の条件分岐はとてもじゃないけどコードを追いかける気にはならないね
0257仕様書無しさん
垢版 |
2018/06/09(土) 12:10:22.15
>>254
だからさ
それは必要なコードじゃねーの？
バグったときにバグった箇所もわからないようなコードのどこがいいの？

極論を言うとプログラムなんて代入と四則演算と条件分岐を繰り返してるだけなので
それ以外は無駄な手間って言うならクラスも関数もいらねーよ
0258仕様書無しさん
垢版 |
2018/06/09(土) 12:10:35.07
例えばインターフェースが以下のようなものだったとしよう

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


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

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


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

このインターフェースを守っていれば、呼び出し側にはバグはなく
呼び出し先にバグが有るということだ
0259仕様書無しさん
垢版 |
2018/06/09(土) 12:11:38.98
>>251
> 利用側はコードを変えずに実装を変えられるのがメリット。

コードは変えませんが設定ファイルは変えます
って言いたいの？
0264仕様書無しさん
垢版 |
2018/06/09(土) 12:26:30.23
>>263
変える必要性がある ＝ インターフェースを使う
変える必要性がない ＝ インターフェースは使わない

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

インターフェースや抽象クラスを使えば原因の切り分け、再現コード(テストケース)の作成、詳細の分析、修正の妥当性確認(テスト)まで高速で実行できる
対応する条件分岐では不可能
0266仕様書無しさん
垢版 |
2018/06/09(土) 12:34:52.93
>>265
え？何いってん？
そもそも型情報は必要ないって
潰しちゃってるのがインターフェースだよね？
知る必要もないってのが君の主張だったよね？
0268仕様書無しさん
垢版 |
2018/06/09(土) 12:40:51.75
やっぱりパソコンのたとえがわかりやすい

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

インターフェース使う派は
メモリが壊れたらパソコンの部品を個別にテストしてメモリが壊れてると判断できる
メモリだけ買い替えればいいので最小限のコストでパソコンが復活する
メモリだけを高性能なものに替えたい場合は文字通りメモリだけを取り替えればいい
0271仕様書無しさん
垢版 |
2018/06/09(土) 12:43:53.01
インターフェースの先はバグらない世界に書き換えておいた
0273仕様書無しさん
垢版 |
2018/06/09(土) 12:53:38.99
>>268
> インターフェース使わない派は
> メモリが壊れたらパソコンが壊れたものとしてパソコン全体を修理に出すしかない

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

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

どうせ切り分けないんだから、丸ごとメーカーに出したほうが良いし
メーカーも丸ごと交換したほうが安くて早い
それほど人件費は高い
0274仕様書無しさん
垢版 |
2018/06/09(土) 12:57:27.66
>>273
ということは君はバグが発生する度にシステムリプレース案件立ち上げればいいんじゃないかな
0275仕様書無しさん
垢版 |
2018/06/09(土) 12:58:24.48
普通ダイナミックライブラリにして複数のアプリ間で共通に使うものを定義するのに使うよな？
0276仕様書無しさん
垢版 |
2018/06/09(土) 12:59:27.73
>>274
バグをなおすこととインターフェースになんの関係があんの？
インターフェースを使っていようがいまいが、
バグの原因は一緒だろ

インターフェースを使わないからって
システムリプレースになるわけじゃない
0277仕様書無しさん
垢版 |
2018/06/09(土) 13:04:30.80
>>276
インターフェースを使わないと原因のスコープが広くなりすぎて全体に影響するんだよ
0278仕様書無しさん
垢版 |
2018/06/09(土) 13:34:30.55
>>277
インターフェース使わなくても、小さなモジュール（クラス）に分ければ十分では？
そもそもクラスですらなくても十分なC言語ｗ
0280仕様書無しさん
垢版 |
2018/06/09(土) 13:59:19.10
実行しないと原因わからんから糞って意見があるが、どんなソースでもログ仕込んだりしつつ実行するのが手っ取り早いだろとか思う。
んで、実行できないんだよボケとか言ってる奴らは、正にテスト出来ないソースを量産してる奴らってことだよな
0281仕様書無しさん
垢版 |
2018/06/09(土) 14:11:48.87
>>278
依存先を直に参照、インスタンス化すると親に埋め込まれてしまう
これは依存先にバグがあると親もバグがあるということな
再起的にあらゆるクラスが異常となる
インターフェースで依存を切っておけばそうならない
0282仕様書無しさん
垢版 |
2018/06/09(土) 14:14:54.36
>>280
その通り
クラスの実体に直接依存してしまうとインフラストラクチャにも依存することになる
すると全てのインフラストラクチャが整備されていないとテストもデバッグもできくなってしまう
0283仕様書無しさん
垢版 |
2018/06/09(土) 14:19:17.39
だからdllにして切り離せってのは、インターフェース介した作りかどうかと直接関係無いよな？
0284仕様書無しさん
垢版 |
2018/06/09(土) 14:22:57.91
>>281
> 依存先を直に参照、インスタンス化すると親に埋め込まれてしまう
> これは依存先にバグがあると親もバグがあるということな

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

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

銀の弾丸はないんだよ？
インターフェースを使ったらバグがないとか
はは、ありえないｗｗ
0285仕様書無しさん
垢版 |
2018/06/09(土) 14:23:39.62
>>282
> すると全てのインフラストラクチャが整備されていないとテストもデバッグもできくなってしまう

そんなことはないが？ テスト用のモックを使えば良いだけだよ
0286仕様書無しさん
垢版 |
2018/06/09(土) 14:43:48.21
>>284
まだわからないかー
子供用の説明ならどうだ？

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

依存先をインターフェースで切るのは組み立て型のパソコンと同じ
メモリが壊れててもパソコンが壊れたことにはならないんだ
メモリだけを交換してね
0287仕様書無しさん
垢版 |
2018/06/09(土) 14:59:56.95
インターフェース定義しただけなら切り離されてないからなぁ。
きちんとリンクライブラリにして初めて切り離される。
0289仕様書無しさん
垢版 |
2018/06/09(土) 15:15:08.99
>>286
だからそれインターフェースと関係ないじゃん
モジュール（クラス）が壊れていたら
それを交換するだけだろ？

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

インターフェースを使っていれば、絶対にメモリが壊れる
マザーボードが壊れることはないって言うつもりか？
0290仕様書無しさん
垢版 |
2018/06/09(土) 15:23:48.56
>>289
やれやれ
メモリが壊れてるのも何が壊れてるのも話の要点は同じだろ
例え話に変なツッコミ入れる人ってホント要点から目をそらしたがるよね
0291仕様書無しさん
垢版 |
2018/06/09(土) 15:26:19.26
>>290
あれ？インターフェースは関係ないというツッコミへの
レスはしないの？

これがたとえ話ではなく一番重要な点なんだが
反論できない所からは目をそらすんだねｗ
0292仕様書無しさん
垢版 |
2018/06/09(土) 15:38:52.62
>>291
は？
頓珍漢すぎてスルーしてたわ
パソコン部品はインターフェースの考え方を応用して成功した代表例だぞ？
インターフェース関係ないとかまじ大丈夫か？
0293仕様書無しさん
垢版 |
2018/06/09(土) 15:44:07.05
インターフェースさん
開発の邪魔だから早く死んで
0295仕様書無しさん
垢版 |
2018/06/09(土) 15:54:54.09
C#なのにインターフェイスから実装に飛べないなんて言ってるアホの妄言だから気にするな
0296仕様書無しさん
垢版 |
2018/06/09(土) 15:55:42.85
モノリスおじさん「インターフェースさん邪魔(うわあああ論理じゃ勝てない。そんだ！むかつくから悪口いったろwww)」


悲しいなぁ
0297仕様書無しさん
垢版 |
2018/06/09(土) 16:01:27.94
>>295
無理だろ
型情報を削っちまったんだから
それに知る必要がないんだろ？
主張に責任持てよｗ
0299仕様書無しさん
垢版 |
2018/06/09(土) 16:23:59.60
ものによるね
インターフェースや抽象クラスでやるべきものを無理やり条件分岐にしたようなものは追う気しないね
実装クラス全部見るより大変だよ
0301仕様書無しさん
垢版 |
2018/06/09(土) 18:06:39.52
>>300
ごった煮のクソッタレ条件分岐をインターフェースで綺麗に分離、パッケージングしたわけさ
インターフェース使わないとごった煮っていうのは同意
0302仕様書無しさん
垢版 |
2018/06/09(土) 18:37:42.37
>>292
パソコンの話をしたいのなら
別の板に言ってください。

インターフェースは関係ありません
0303仕様書無しさん
垢版 |
2018/06/09(土) 18:40:50.00
そもそもさ、壊れたメモリを交換するのと
モジュールを修理するのは意味がぜんぜん違う。

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

だけどソフトウェアは違う。インターフェースが同じで
機能が全く一緒のものなんて、殆ど無い。
バグがあったら交換するのではなく、そのモジュール修正するのだから
インターフェースがあることと、バグの修正には全く関係がない
0304仕様書無しさん
垢版 |
2018/06/09(土) 18:43:41.64
>>301
ごった煮になるのはインターフェース使うからだろ？
フツーに組めよフツーにｗ
0305仕様書無しさん
垢版 |
2018/06/09(土) 18:47:29.04
>>303
メーカーの気持ちがわかってないね
君は開発者じゃなくてユーザーということなんだろう
0306仕様書無しさん
垢版 |
2018/06/09(土) 18:48:02.70
>>305
だからパソコンの話をしたいなら
他の板に逝けって言ったよね？
0307仕様書無しさん
垢版 |
2018/06/09(土) 18:49:28.42
>>304
フツーに組んだらインターフェースになんだって
オブジェクト指向でなんで手続き型丸出しの条件分岐地獄をワザワザ使わないといけないのか
マゾなのかな
0309仕様書無しさん
垢版 |
2018/06/09(土) 18:52:26.32
>>306
その論法だとインターフェース使いたくないならプログラム板とプロフラマ板には入れないね
どちらもインターフェースと密接に関わる板だから
0310仕様書無しさん
垢版 |
2018/06/09(土) 18:56:32.58
>>308

>>303を読むと、パソコンのインターフェースと
ソフトウェアのインターフェースは共通してないことがわかる
0311仕様書無しさん
垢版 |
2018/06/09(土) 18:57:25.28
インターフェースは交換しやすいだけで
バグが修正しやすくなるわけじゃないんだな
0312仕様書無しさん
垢版 |
2018/06/09(土) 19:03:50.67
バグが修正しやすくなるぞ

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

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

インターフェースを使う派は
部品を外して壊れた部品だけを作業机に置いて修理できるので超やりやすい
直したら部品の単機能テストをして本体に組みこんでテストできるから安心
0313仕様書無しさん
垢版 |
2018/06/09(土) 19:05:03.74
>>312
だからそれ、インターフェースがあるからじゃなくて
単にモジュールとして別れていればいいだけだよねｗ
0314仕様書無しさん
垢版 |
2018/06/09(土) 19:07:31.20
どうやってクラスAの中に埋め込まれているクラスBをテストするのか？

そりゃクラスBだけ取り出して、
テストすればいいだけでは？
0315仕様書無しさん
垢版 |
2018/06/09(土) 19:09:33.66
>>313
モジュールとして分けるためのインターフェースな
インターフェースなかったらモジュール化してもハンダで癒着させるしかない
0316仕様書無しさん
垢版 |
2018/06/09(土) 19:10:53.19
>>315
普通にインターフェース無くても分離できるけど？

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

そのモジュール＝クラスがあるのだから、
そのクラス単体でテストすれば良いだけ
0319仕様書無しさん
垢版 |
2018/06/09(土) 19:21:42.93
>>317
だからクラスAの中にあるクラスBを分離するんでしょ？
クラスBだけをテストすれば終わりじゃん
なにか難しいことでもあんの
クラスBはクラスAがなければテストできないわけじゃないんだしさぁ
0321仕様書無しさん
垢版 |
2018/06/09(土) 19:25:43.51
>>319
そもそもBは依存先がないのだからその例は無意味だな
ABが癒着していたらAを分離してテストする方法がないだろ
0322仕様書無しさん
垢版 |
2018/06/09(土) 19:40:59.46
ABが癒着していたら　Aを分離してテストする方法がないだろ

であれば、

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

という意味になる


で、インターフェースを使うことは必須ではない
インターフェースを使わず、かつ癒着しないようにすれば良い
0323仕様書無しさん
垢版 |
2018/06/09(土) 19:42:18.06
インターフェースを使わなければ、
絶対癒着してしまうんだー、ブンブン（手足を振り回す音）


ガキじゃないんだから、理由ぐらい言えよｗ
0325仕様書無しさん
垢版 |
2018/06/09(土) 19:49:38.37
はい、ガキいっちょいただきましたーｗ

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

ほんとガキ
0326仕様書無しさん
垢版 |
2018/06/09(土) 19:50:23.18
ABが癒着していなければな
しかしAがBに依存するなら癒着は不可避
インターフェースを使うしかない
0327仕様書無しさん
垢版 |
2018/06/09(土) 19:52:20.60
で、癒着してない例は？
それで任意のシステムを組める保証は？
できるったらできるんだーブンブン、ってかwww
0328仕様書無しさん
垢版 |
2018/06/09(土) 19:59:15.61
>>327
くだらね。そんなこともわからんのか。
じゃあ、ぐうの音も出ない例だしてやるよ。


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


数年後、Bという会社に、ClassAを使ってClassBを作るように仕事を依頼しました。
仕事を依頼する前は、ClassAは癒着していません。
ClassAのコードはなにも変えてないのだから
仕事完了後も、ClassAはどこにも癒着していません
0329仕様書無しさん
垢版 |
2018/06/09(土) 20:01:35.18
つーかこんな茶番劇のような例を出さなくても
MSが作ったライブラリをラップしたオレオレライブラリが
癒着するわけ無いだろと

MSはそのライブラリ単体で開発・テストしてんだからさ
0330仕様書無しさん
垢版 |
2018/06/09(土) 20:10:35.17
>>328
意味不明
ClassBはClassAに依存しているから開発にもテストにもClassAが必要
もう少しまともな意見を期待してたんだがこりゃ話にならんかな
0331仕様書無しさん
垢版 |
2018/06/09(土) 20:14:50.16
>>329
オレオレラッパーはMSのライブラリと癒着してんだよ
そしてそのオレオレラッパーを使うクラスはオレオレラッパーに癒着する
癒着が連鎖してMSのライブラリに癒着することになる

オレオレラッパーをインターフェースを実装するように作れば
オレオレラッパーインターフェースを使うクラスは癒着から逃れられる
0332仕様書無しさん
垢版 |
2018/06/09(土) 20:15:29.58
> ClassBはClassAに依存しているから開発にもテストにもClassAが必要

ClassAならすでにあるじゃん？アホなの？
0334仕様書無しさん
垢版 |
2018/06/09(土) 20:20:55.14
>>332
それを癒着というんだよ
ClassAがあるからいいじゃんじゃなくてなかったらダメじゃんってのが正解な
ClassAがデータベースに依存してたらデータベースも整備しなきゃならん
ClassAが外部サービス依存してたら外部サービスと契約しなきゃいけない
そうやって癒着の連鎖が広がっていく
0335仕様書無しさん
垢版 |
2018/06/09(土) 20:21:21.75
仮にClassBを動かすのにClassAがまだできていなかったとしても
モックを使えばいいだけなのでインターフェースは必要ない

まあClassAの偽物を使ってテストしても
それは本当に動くことの証明にはならないから、
最終的にはClassAを組み込んだ状態でテストしなければいけないんだがな
0336仕様書無しさん
垢版 |
2018/06/09(土) 20:22:07.65
>>334
> それを癒着というんだよ

言わない。ソフトウェア業界のどの文献を探しても
癒着なんて書いてあるものはない
勉強し直したほうが良いよ？
あんた自分の妄想の世界で生きてる
0337仕様書無しさん
垢版 |
2018/06/09(土) 20:23:32.48
>>334
> ClassAがデータベースに依存してたらデータベースも整備しなきゃならん
整備すればいい

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

接続先の切り替えは単に設定ファイルの接続先を変更するだけ
0338仕様書無しさん
垢版 |
2018/06/09(土) 20:23:42.80
>>335
それは言語機能的な意味でインターフェースを使っていないだけで
考え方としてはインターフェースを使って実装を切り替えるのと変わらんよ
インターフェースを使った場合との違いは手順が増えて面倒くさくなる
0339仕様書無しさん
垢版 |
2018/06/09(土) 20:25:00.97
>>336
文献ベースで話進めるなら世界中で言及されてるインターフェースを使うのが正義ってことになるぞ
0340仕様書無しさん
垢版 |
2018/06/09(土) 20:26:41.02
>>338
> それは言語機能的な意味でインターフェースを使っていないだけで
> 考え方としてはインターフェースを使って実装を切り替えるのと変わらんよ

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

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

はい、ClassAとClassBだけで十分ですーｗ
だって、インターフェースがあるのですからーｗ
0341仕様書無しさん
垢版 |
2018/06/09(土) 20:26:46.54
>>337
整備のコストがもったいない
モック使うって発想はインターフェース肯定だぞ
0343仕様書無しさん
垢版 |
2018/06/09(土) 20:33:41.77
>>340
インターフェースを使わない代わりに無駄なコストを呼び込んでるんだよ

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

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

君が言うようにインターフェースを使わなくても実装のの切り替えはできないことはないが
それはIT原始時代の非効率的で野蛮な方法なんだよ
そういうのは猿がやることだ
0345仕様書無しさん
垢版 |
2018/06/09(土) 20:54:19.46
>>312
いや、型情報が潰されてるしバグ修正なんてしにくいと思うけど
しかも、インターフェースの先は知る必要がないんでしょ？
0346仕様書無しさん
垢版 |
2018/06/09(土) 20:54:53.19
インターフェース君、もう死んだ方がいいな
バカだし
0347仕様書無しさん
垢版 |
2018/06/09(土) 21:02:30.42
>>345
しやすいよ
余計な依存関係がクリアされるから作業対象に集中できる
作業対象の型も設定や命名規約からすぐわかるし全体からすれば極一部の動的なインスタンスだったとしてもログやファクトリーを見ればすぐにわかる
作業対象が依存してるのはインターフェースの契約でしかないのでインターフェースの先はもちろん知らなくていい
0349仕様書無しさん
垢版 |
2018/06/09(土) 21:10:24.63
インターフェースを使わずにあちこちに条件分岐を撒き散らすほうが
バグ修正しにくいわ
0351仕様書無しさん
垢版 |
2018/06/09(土) 22:45:58.47
まぁ実際のところ、interfaceまでガッツリ作る業務は今まであったことないんだけどね。
大体abstractクラスが限界
0352仕様書無しさん
垢版 |
2018/06/09(土) 22:51:40.60
後はienumerableと受け取ったり返したりするヘルパー関数群とかは作るか。他はもはや趣味の領域な気がする
0353仕様書無しさん
垢版 |
2018/06/09(土) 23:07:02.97
IT業界は企業間で10年、20年分ぐらい技術格差がある
当たり前のようにinterfaceを使うモダンな企業もある
JavaやC#を採用しているのにCやCOBOLみたいなプログラムを書いてる老舗企業もまだある
0354仕様書無しさん
垢版 |
2018/06/09(土) 23:22:41.12
>>347
じゃあ、型情報潰しちゃってるのにどうやって該当の処理まで飛ぶの？
っていうか君はインターフェースの先は知る必要がないって主張だから
不具合も直せないよね？ｗ
0355仕様書無しさん
垢版 |
2018/06/09(土) 23:24:11.27
インターフェース君はどうやってインターフェースの先を知らずに不具合を直すのだろう？
0356仕様書無しさん
垢版 |
2018/06/09(土) 23:59:51.23
作業対象の依存するインターフェースの先を知る必要はない
作業対象==バグってるクラスを治すだけ
0357仕様書無しさん
垢版 |
2018/06/10(日) 00:33:37.26
>じゃあ、型情報潰しちゃってるのにどうやって該当の処理まで飛ぶの？
作業対象の型も設定や命名規約からすぐわかるし全体からすれば極一部の動的なインスタンスだったとしてもログやファクトリーを見ればすぐにわかる

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

作業対象==バグってるクラス
0358仕様書無しさん
垢版 |
2018/06/10(日) 00:41:27.33
>>356
IF「フフフ、我らを見抜けるかな？」
IF「3万のインスタンスをもち、150種のクラスをもつ我らを見抜くことは不可能」
IF「さらにメモリ、フォーム、コントロール、スレッド、ファイル、プロトコル、etc」
IF「すべての共通項を見出した万能クラス」
0359仕様書無しさん
垢版 |
2018/06/10(日) 00:44:12.74
実際には責務:クラス=1:1だから症状聞いた瞬間にあぁあのクラスだなってわかるんだけどね
クラス分けしないでif文書きまくるとそれができなくなってコード追いかけたり実際に動かさないとわからなくなる
0360仕様書無しさん
垢版 |
2018/06/10(日) 00:46:05.56
>>357
いや、お前の主張はインターフェースの先は知らなくていいんだから
不具合直せないだろ
そこでチンコでもいじってろよ
0361仕様書無しさん
垢版 |
2018/06/10(日) 01:05:06.67
バグがあるクラスを直す時にそのクラスが依存しているインターフェースの先を知る必要がない
インターフェースを守っていればいい
0362仕様書無しさん
垢版 |
2018/06/10(日) 01:07:08.85
これも成り立つよな？

バグがあるクラスを直す時にそのクラスが依存しているクラスの先を知る必要がない
0364仕様書無しさん
垢版 |
2018/06/10(日) 01:23:43.45
クラスを使ってるだけなら、クラスの実装を知る必要はないのと同じことか
そういやライブラリのソースコードって見ないもんな
0365仕様書無しさん
垢版 |
2018/06/10(日) 01:31:56.78
クラスを使ってるだけならクラスの実装にも注意が必要
0366仕様書無しさん
垢版 |
2018/06/10(日) 01:42:08.23
あー、勝負ついたなｗ

クラス（第三者が作ったライブラリ）のソースコード
普通見ねぇわ
0367仕様書無しさん
垢版 |
2018/06/10(日) 07:15:47.13
しかし、まだ、インターフェースの先がバグってる
0368仕様書無しさん
垢版 |
2018/06/10(日) 09:54:12.51
バグってるクラスを直さないと誰が言ったのだろうか
0369仕様書無しさん
垢版 |
2018/06/10(日) 12:35:52.36
インターフェースを使うとバグが無いことが証明される

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

↑これが間違ってる
0374仕様書無しさん
垢版 |
2018/06/14(木) 20:41:53.41
これが流行ってるからっで、レガシーコードにぶち込まれた数々のソリューション。
やるなら同等の箇所を完全に書き換えろ。
未来に責任が持てないならおとなしくしとけよ、糞が
0376仕様書無しさん
垢版 |
2018/06/14(木) 20:58:25.98
あ、未来のことなんか考えなかったからだね
未来の責任は放棄か
0377仕様書無しさん
垢版 |
2018/06/14(木) 21:55:10.14
残業、休出してリファクタリングってなんかおかしくねーか？
いま、足が出てるわけで、いま、なんとかしろよ
アリもしないお前が想定する未来はきっとこないんだ
0379仕様書無しさん
垢版 |
2018/06/15(金) 07:11:43.08
>>378
え？ちょっと頭使ってね
リファクタリングっていまの工数を使って明日の工数につなげましょうって作戦じゃん？
なのにいま足が出てるのにそんなことしたって一体いつのプロジェクトを成功させたいのかわけがわからないじゃん
0380仕様書無しさん
垢版 |
2018/06/15(金) 07:46:54.71
> リファクタリングっていまの工数を使って明日の工数につなげましょうって作戦じゃん？

え？違うよ

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

準備と仕上げを入れずに仕事を見積もってはいけない
足が出てるのは、その準備と仕上げを勤務時間中にやらないで
1時間早く出社して、残業もするような状態になってるから
0381仕様書無しさん
垢版 |
2018/06/15(金) 08:03:25.86
>>380
は？
それなんのためにやってるの？
設計書通りに組んだんだよね？
0382仕様書無しさん
垢版 |
2018/06/15(金) 08:04:01.47
気分に任せて組んでるから必要になってんじゃない？
お前の場合
0383仕様書無しさん
垢版 |
2018/06/15(金) 09:52:47.39
まあリファクタして工数増えてんなら本末転倒だわな
0386仕様書無しさん
垢版 |
2018/06/15(金) 14:53:06.17
野球で例えるならバッターが足場を慣らすのがリファクタリング
0389仕様書無しさん
垢版 |
2018/06/15(金) 18:13:39.98
>>388
それ統計データでもあるの？
それともあなたの思い込み？
嘘つかないでくれませんか？
0390仕様書無しさん
垢版 |
2018/06/15(金) 18:19:30.60
設計書通りだとバグ出るしバグの修正めちゃくちゃ大変
しかも当たり前のように仕様変更入るじゃん
だから設計書は参考までに止めてリファクタリングするしかない
文句言うなら最初から整理とテストまで実行した設計書をよこせや
0392仕様書無しさん
垢版 |
2018/06/15(金) 19:05:31.85
>>391
設計書はゴミだけど設計というプロセスは必要
設計した結果をコードとテストとしてアウトプットする
それらでカバーできない部分があれば別途図表や文章を用意するが設計書という体裁にはならない
後発の開発者やユーザーに対する解説書となる
0394仕様書無しさん
垢版 |
2018/06/15(金) 19:29:07.71
んで、設計書を通りのコードと言っても
わかりやすいコードと、わかりにくいコードがある
正しく動いていたとしても、わかりにくいコードだと
今後の作業に支障をきたす。

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

工事終わりました。でも片付けはしてないです。じゃだめだろう？
片付けまでやるのが今日の仕事
0395仕様書無しさん
垢版 |
2018/06/15(金) 19:46:24.48
①良い設計を簡潔に記したもの
→必要です。これを設計書と言います。

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

残念なことに日本のIT業界では②の事を設計書と呼び、盲信しています。
今すぐ②をリファクタリングして①に書き換えましょう。
そうすればコードのリファクタリングは最小限で済みます。
0396仕様書無しさん
垢版 |
2018/06/15(金) 20:00:38.76
>>394
わかりにくい文章やな
0397仕様書無しさん
垢版 |
2018/06/15(金) 20:13:33.02
>>395
> ①良い設計を簡潔に記したもの
> →必要です。これを設計書と言います。

簡潔に書くのと、詳細なコードを書くことは
矛盾するからね。簡潔に書けば、書いてない部分が
増えるため汚いコードになってしまう可能性が増える
0399KAC
垢版 |
2018/06/15(金) 21:10:13.88
>>397
お前さんが設計できない事だけは判った
0400仕様書無しさん
垢版 |
2018/06/18(月) 20:23:08.40
リファクタリングしながらやると美しいコードになるけどやっぱり時間かかるな

複雑なSQLで一気にデータ持ってきて表示、編集させて、ボタン押したらこれまた複雑な更新SQLで一気にデータを更新
コードめちゃくちゃになるけど、これが一番生速度が速い
0401KAC
垢版 |
2018/06/18(月) 21:53:41.21
いや、ちゃんと設計しろよ
0402仕様書無しさん
垢版 |
2018/06/18(月) 22:53:05.35
設計は遠回り
最初から最短距離見えてるんだからそうすればいい
0403仕様書無しさん
垢版 |
2018/06/18(月) 22:58:25.68
どうせ引き継ぎ用の説明書作らなきゃならないだろうに…。
0406KAC
垢版 |
2018/06/18(月) 23:35:19.24
>>402
じゃあリファクタリングいらんだろ
0408仕様書無しさん
垢版 |
2018/06/19(火) 07:39:04.26
>>402
設計は必須。
お前さんは書き込みする時に、カキコの影響とか考えるだろ？
それは広い意味での設計。
「設計書」と称する、実は設計書になってないゴミは要らんけどね。
0409仕様書無しさん
垢版 |
2018/06/30(土) 20:48:21.44
設計・設計書要らない派が挙げてる仕事って、
1時間で終わるレベルのタスクなんだろうなって思う。
人と設計を共有したりしないでいいんだろうな。
0410仕様書無しさん
垢版 |
2018/07/01(日) 00:07:45.44
だからコードで設計を共有すればいいじゃん
設計書を記述するための「プログラム言語」という専用の言語で
設計書を記述すればいいでしょう？
0411KAC
垢版 |
2018/07/01(日) 02:15:52.13
>>410
プログラム書いて持ちよった結果
イメージが合って無くて全面書き直しになっても
直ぐに書き直せるのならそうかもな
0412仕様書無しさん
垢版 |
2018/07/01(日) 02:16:11.30
>>410
小規模ならそれもいいけど、大規模になったらそうもいかんのよ
0413仕様書無しさん
垢版 |
2018/07/01(日) 03:46:41.54
>>411
お前が言う「設計書」を書いて持ち寄った結果
イメージが合って無くて全面書き直しになるのと何が違うの？

全面書き直しが問題なら、単に早めに
レビューすればいいだけ。別の問題だろ
0414仕様書無しさん
垢版 |
2018/07/01(日) 03:51:24.97
>>413
それはプログラムと設計書の工数によって変わるだろ
プログラムより設計書の工数がえらい小さい場合は、設計書を持ち寄ってレビューするべきだし
工数がほとんど変わらないなら、最初からプログラムでレビューすればいい
0415仕様書無しさん
垢版 |
2018/07/01(日) 04:01:00.47
設計書は長時間うんうんうなって完成させてから
レビューするもんでしょ

大規模なものなら、1ヶ月とかそれ以上かかって完成させて、
でイメージが合ってなくて全面書き直しｗｗｗ
0416仕様書無しさん
垢版 |
2018/07/01(日) 04:03:02.31
設計書は書き直すことなんてないよ
所詮絵に描いた餅なんだから
間違ってもOK。レビューなんてしない
間違いはコードでなおす
0417仕様書無しさん
垢版 |
2018/07/01(日) 12:16:15.96
>>416
いや、設計書書いたならレビューしろよw
何のために書いてんの？
0419仕様書無しさん
垢版 |
2018/07/15(日) 20:49:16.71
建築業なら企画書→仕様書→設計書→図面→といった工程の中の
一部分であることが設計書の存在意義なんだが
この業界って仕様変更の頻度が高すぎて工程という前提条件が破綻してる
とくに下請けはプロマネのレベルが低くて無知だから何でもハイハイで
再見積もりも無しに平気で工程をまき戻していつものデスマーチ
0420仕様書無しさん
垢版 |
2018/07/16(月) 23:47:33.28
>>419
建築はしっかりしてるというような隣の芝生は青く見えるんだろうけど、
あっちもやっぱり似たようにgdgdだよ。
特に今は作業員に外国人が増えてるから意思疎通も大変だし。
0421仕様書無しさん
垢版 |
2018/07/17(火) 20:14:10.53
建築業界に例えたらプログラマは何に相当するんだ？

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

って結論になるのが、この話題の最後になるのが目に見えてる
0423仕様書無しさん
垢版 |
2018/07/18(水) 03:26:52.12
>>422
おい、先にレスしてるんだからその先を書けよ。

土方に渡す資料に
「4階建でマンションを建てます。
部屋はいくつで、階段、エレベータはここで。
詳細は全部任せます。材料とか適切なのを選んでください」
って書いてあったら、それ建築士が使えないって判断だぞ
0424仕様書無しさん
垢版 |
2018/07/18(水) 04:54:54.12
>>423
末端の土方はそれくらいの情報しか持ってなさそう
で、現場監督や棟梁には詳細な資料が渡ってると
0425仕様書無しさん
垢版 |
2018/07/18(水) 11:14:36.88
プログラマは土方に相当すると言ってのに
現場監督や棟梁に相当するって訂正かよｗ
0427仕様書無しさん
垢版 |
2018/07/21(土) 18:09:01.09
将来的には絶対いいしそうしないと先がふさがるけど
当面の課題解決の理由として正当化できないせいで採用できない
0428仕様書無しさん
垢版 |
2018/07/21(土) 19:57:36.56
などと言い訳をしているところは
デスマ状態なんだろうってのがよく分かる

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

その余裕も無いほどカツカツなスケジュールなら
デスマになるに決まっている
0429仕様書無しさん
垢版 |
2018/07/21(土) 20:05:56.17
そのリファクタ見積もりが正当化できないんですけど
0430仕様書無しさん
垢版 |
2018/07/21(土) 20:10:08.19
将来的に当たるかもしれない課題がある
でもそれは優先度低くてかなり先、一度後回しでいいやってなった

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

先で死ぬのが見えてるのに出口が
0431仕様書無しさん
垢版 |
2018/07/21(土) 20:55:20.97
コストカット原理主義が無くならない限りはリファクタリングの正当性を見出すのは無理だろうな

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

空いた時間＝余裕＝コスト＝絶対悪 になっている人が多い
0434仕様書無しさん
垢版 |
2018/07/21(土) 22:25:55.48
そりゃ正しいコードの姿が見えてないのに
コード書くのにどれくらいかなんて見積もりできないだろｗ

それか修正前のコードがどんなに汚くて
修正箇所が大きくテスト範囲も広くなろうが
修正前のコードが綺麗でわずかの修正で解決できようが
全く同じ工数で修正できるって考えてるアホかのどちらかだ
0435仕様書無しさん
垢版 |
2018/07/21(土) 22:33:30.78
正当化できない理由は>>430
コードの正しい姿とかどっからでてきた話だ
0436仕様書無しさん
垢版 |
2018/07/21(土) 23:01:38.04
言語やOS、ライブラリ、フレームワークなんてのは変わり続けてたり、変わらないことで
使えなくなることがあったり、使用者の習熟度が上がるなんかでも変化するから正しい
コードの姿なんてものは幻想だよ。

極端な話、変更がなければリファクタリングなんてしなくてもいいがOSバージョンアップは
ほぼ確実に数年単位で起きるしそれに対する対応としてはリファクタリングなりなんなりの
事前によくしておくというのは必要なんだよな。
0437仕様書無しさん
垢版 |
2018/07/21(土) 23:03:41.98
>>435
え？ コードを適当に修正してんの？
動けばどんなコードでもOKって人？
0438仕様書無しさん
垢版 |
2018/07/21(土) 23:04:48.61
>>436
> 使用者の習熟度が上がるなんかでも変化するから正しい
> コードの姿なんてものは幻想だよ。

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

お前が言ってるのは、正しいコードはあるが
それを使用者が理解できないって言ってるだけだろう？
0440KAC
垢版 |
2018/07/22(日) 01:02:58.95
>>428
なんで正しい設計をしようとしない？
0441仕様書無しさん
垢版 |
2018/07/22(日) 07:42:33.24
>>431
テストやリファクタリングをサボって、コストカットしたと勘違いしてるのが多いけどね。
0442仕様書無しさん
垢版 |
2018/07/22(日) 11:49:00.45
>>441
そもそもそこまでコストカットする必要はあるのかっていう話だな。

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

効率化自体はかったるい作業をかったるくない作業にする自分ために必要なことだが
効率化しないと評価下げる、お前は低評価だみたいなのは違うだろうと。
0443仕様書無しさん
垢版 |
2018/07/22(日) 12:10:14.32
資本主義の世界だと自分の成功とは他人より成果を出すことでつまり他人が失敗すること
つまり望まれてるのはお前がコケて失敗することなんだ
それでまわりが幸せになる

おまえの上司は
お前が失敗しないことを理由に地位と給与を下げ、失敗したことを理由に地位と給与を下げるだろう
成功者の側に立とうと思ったらうわべに隠された別の道を通らねばならない
0445仕様書無しさん
垢版 |
2018/07/22(日) 14:20:05.45
>>444
だからそんなバカバカしい定量化しづらい、出来ない概念を信奉してるから
ちょっとした計算違いでどんどんドツボにはまっていくんだよ。
金は貯めたり削ったりするものじゃなくて使うものだという認識が出来てない。
0446仕様書無しさん
垢版 |
2018/07/22(日) 14:23:00.79
減量が必要なボクサーじゃないんだから無駄なんてあっていいの、あって当たり前なの
そんな当たり前のことが分らなくなってきているから作業量が増え続けて仕事が楽に
ならないんだよ。

過労死するとかそれに近い状態が幸せなのか？
0447KAC
垢版 |
2018/07/22(日) 17:11:53.36
どうでもいいけど、
少なくとも給料上がった分くらいは効率化しろよ？
新人雇った方がコスパ良いとか笑えないから。
0449仕様書無しさん
垢版 |
2018/08/01(水) 22:38:50.65
われながらクラスとメソッドの名前がひどい
壊滅的な英語センスと気まぐれなルールで
日本語との対応や分類がえらいことになってる

名前かえるぐらいさせろよ
0451仕様書無しさん
垢版 |
2018/10/01(月) 19:25:22.11
小売業者が定期的にやってる棚卸しみたいなもんだけどな
0452仕様書無しさん
垢版 |
2018/10/02(火) 20:04:13.47
なんやかんや言って全然ちゃうけどね
0453仕様書無しさん
垢版 |
2018/10/02(火) 20:15:37.69
リファクタリングは日々一人ひとりがやることだから
棚卸しのようにまとめてやる行事とはぜんぜん違う
0454仕様書無しさん
垢版 |
2018/10/02(火) 20:16:40.24
正確には無能がする日課のオナニーみたいなものやけどね
0455仕様書無しさん
垢版 |
2018/10/02(火) 20:21:20.38
システム刷新の前にリファクタリング少しでもやると効果的なんだけど余計な手間だろって却下される
古い言語で書かれたゴミを新しい言語で書かれたゴミに刷新しても意味ないと思うんだけどな
0456仕様書無しさん
垢版 |
2018/10/02(火) 20:24:34.25
定期的な整理をしないと肝心なときにぐちゃぐちゃになる
んで、緊急だっつって慌てて直してカオス化が進む
そーなる前に整理しろってそんだけの話でしょ
なんか難しいところあるか？
0457仕様書無しさん
垢版 |
2018/10/02(火) 20:26:18.31
整理整頓するつもりで散らかし放題やから無能と呼ばれとんのやぞおまえw
0458仕様書無しさん
垢版 |
2018/10/02(火) 20:26:51.57
整理整頓するつもりで
整理整頓してればいいだけでしょう？
0459仕様書無しさん
垢版 |
2018/10/02(火) 20:28:30.77
出来とらんゆうとるやんw
0460仕様書無しさん
垢版 |
2018/10/02(火) 20:31:19.14
整理整頓した結果が前よりマシになる保証がないことを奴隷主どもはよくわきまえている

まともな整理整頓できるぐらい理解が進んでたら
そもそも整理したいって思わないことも多い
0461仕様書無しさん
垢版 |
2018/10/02(火) 21:19:29.11
リファクタリング何ぞ不要

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

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

みんなこのワードを流行らしてくれ
流行ってるなら本番でも採用されるから
0464仕様書無しさん
垢版 |
2018/10/02(火) 23:05:28.72
最初は何とかなってたのに
あれがたりないこれがたりないってプライベートメソッドが増えて
にっちもさっちも行かなくなった…

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

依頼もないのに勝手にリファクタやることはないわ
0466仕様書無しさん
垢版 |
2018/10/03(水) 19:55:36.77
なんでこんなに変わってるんですか？
工数を増やさないでください
勝手にやった分の料金返してください
0468KAC
垢版 |
2018/10/03(水) 23:24:31.41
本当にリファクタリングを綺麗にできるのなら、
そもそも設計が綺麗だから、リファクタリングなんて不要だろ？

まともに設計できずにぐちゃぐちゃ書いた奴が、
リファクタリングなんてできる訳が無い。
0469仕様書無しさん
垢版 |
2018/10/04(木) 01:10:25.08
>>468
コードを修正する必要がないなら、
最初からきれいに書けるよ

実際には機能追加、変更、バグ修正などで
コードを変更する必要があるから、リファクタリングが必要なんだよ
0470KAC
垢版 |
2018/10/04(木) 02:22:27.37
>>469
そうだね。
まともに設計できない奴はそうなるね。
0471仕様書無しさん
垢版 |
2018/10/04(木) 06:48:48.05
まともに設計できるかどうかじゃなくて、
将来を読めるかどうかだろ？

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

規模に応じて適切な設計は変わるのに
最初から規模が読めるとでも？
0472KAC
垢版 |
2018/10/04(木) 07:18:51.36
最近は設計できない奴の言い訳がすごいな。

まともに設計できてればそんなことでリファクタリングは発生しない。
0474仕様書無しさん
垢版 |
2018/10/04(木) 10:03:32.69
そりゃ先の先の先まで考えて
必要ないことまで設計することだろｗ
0475仕様書無しさん
垢版 |
2018/10/04(木) 21:36:10.68
>>474
クソコテの戯言はおいとくとしても
設計はコーディングとちゃうで？それはコーディングの話や
0476仕様書無しさん
垢版 |
2018/10/04(木) 21:42:23.71
日本人は年末の大掃除が文化として根付いてる
なので「日々整理整頓してクリーンな状況を維持しよう」って外国人なら当たり前の感覚がどうしてもわからない
民族・文化のレベルでITが向いてないんだよね
0477仕様書無しさん
垢版 |
2018/10/04(木) 21:46:24.65
設計を受け取ってコードを書くだけの人ほど>>472のような勘違いをする傾向が有るね
ドメインへの理解度は開発をすすめるにつれて深化する
ビジネスルールやニーズは時間経過で変化する
という2つの大前提を理解してないっぽい
0478仕様書無しさん
垢版 |
2018/10/04(木) 21:58:17.83
>>477
クソコテに反論したからと言っておまえがコーダーである事は隠せんよw
0479KAC
垢版 |
2018/10/04(木) 22:05:46.37
もうコテも信用できない
俺だってKACのふりぐらいできる
0480KAC
垢版 |
2018/10/04(木) 22:40:27.98
>>477
設計できない事はよく分かった。
つか、開発プロセスすらまともに理解できてないんだな。
0482仕様書無しさん
垢版 |
2018/10/07(日) 17:21:06.95
リファクタリング出来る環境あるならテストも自動化されてるだろうに、何が問題なんだろ？
0483仕様書無しさん
垢版 |
2018/10/07(日) 17:46:35.29
テストが自動化されてる現場なんてあるわけじゃないか！
だからリファクタリングは禁止！
0485仕様書無しさん
垢版 |
2018/10/07(日) 18:48:09.16
まさか、人力でリファクタリングしといて、インターフェースは完全に互換だとかのたまうアホなん？
0486仕様書無しさん
垢版 |
2018/10/08(月) 21:15:22.90
完全に互換です
動き違うのはもともと定義外の使い方してたからで
既存バグです
正しくなおしたわれわれのせいではない
0487仕様書無しさん
垢版 |
2018/10/09(火) 09:59:33.83
齟齬があるのに観世互換とか、日本語が使えないのかな？
0489仕様書無しさん
垢版 |
2018/10/11(木) 12:28:59.32
金になるなら、やる
ならないのなら、やらない
0490仕様書無しさん
垢版 |
2018/10/11(木) 15:00:12.53
リファクタリングして、コードのメンテナンス性が上がって
メンテナンスに時間がかからなくなると、時間を節約で金になるんだよな
これをわかってないやつが多い
0491仕様書無しさん
垢版 |
2018/10/11(木) 15:03:03.80
ソース付きで売り切りの開発にリファクタリングなんて不要
0492仕様書無しさん
垢版 |
2018/10/11(木) 15:04:09.91
ソースコードがなにもないところから生まれてくるとでも思ってるのだろうか？
0493仕様書無しさん
垢版 |
2018/10/11(木) 15:04:41.03
切り売りするにはリファクタリングされきって
綺麗な設計になってないと無理だからなぁ
0495仕様書無しさん
垢版 |
2018/10/11(木) 15:05:26.04
あ、無理っていうのは不可能って意味じゃないよ。
切り売りする時、綺麗な設計になってないと
修正が大量に必要なってコストがかかるという意味
0497仕様書無しさん
垢版 |
2018/10/11(木) 15:07:22.98
>>495
売り切りなのに修正なんてあるはず無いだろ。
修正するとすれば、購入した顧客側の仕事だしな。
0498仕様書無しさん
垢版 |
2018/10/11(木) 15:08:44.74
>>497
じゃあ売ってる使えないコードってことか
詐欺という仕事も、そりゃありますよねぇｗｗｗｗ
0501仕様書無しさん
垢版 |
2018/10/11(木) 15:10:11.27
やっぱりリファクタリングしきった
綺麗なコードじゃないと売れないよね
0503仕様書無しさん
垢版 |
2018/10/11(木) 15:11:30.29
>>500
ゴミを飾り立ててもゴミでしかありませんよｗ

あ、ゴミを騙して売る商売でしたね
商売の邪魔してすみませんｗｗｗ
0505仕様書無しさん
垢版 |
2018/10/11(木) 15:12:59.57
切り売りってｗ
ライブラリとして無修正で提供できない時点で終わってるよね
0506仕様書無しさん
垢版 |
2018/10/11(木) 15:13:52.83
>>504
あ？
リファクタリングの意味も分からずここに来てんのか？
正しく動くから商売してんだろ？
0508仕様書無しさん
垢版 |
2018/10/11(木) 15:17:40.13
おまえらはアホだな。
リファクタリングし切ったコードなんか売ったら、
顧客都合の仕様変更の仕事が来ないだろw
0509仕様書無しさん
垢版 |
2018/10/11(木) 15:20:53.31
あぁ、時給で働いてんのなｗ
作業が減れば減るほど、稼げる金が減ると・

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

地獄だね
0510仕様書無しさん
垢版 |
2018/10/11(木) 15:23:25.75
売り切り商売のどこが時給と関係してるんだろ？
0511仕様書無しさん
垢版 |
2018/10/11(木) 15:28:20.99
>>510
ライブラリを売る場合、作業が0でもそのライブラリの価値として売るのは明白
何もしなくても金が稼げる

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

同じ金額を稼いでいたとしても、ライブラリは何もしないで稼いでいるが
切り売りにして作業しないと稼げないと思ってる。
作業時間＝金額　なのだから時給
0512仕様書無しさん
垢版 |
2018/10/11(木) 15:59:39.41
あ？
誰が切り売りって言った？
売り切りだ。
売ったらそれでおしまいの商売な。
0513KAC
垢版 |
2018/10/11(木) 18:05:55.46
>>490
なんで最初からまともなコードを書けないの？
0515仕様書無しさん
垢版 |
2018/10/11(木) 19:36:16.50
>>513
人間は完璧ではない
システム化の対象が不変ではない
経営判断が不変ではない
情報源となる顧客が非協力的

最初から完璧なコードを書けない理由は沢山あるね
最初から完璧なコードが書けると思ってるうちはまだまだ初心者
0516仕様書無しさん
垢版 |
2018/10/11(木) 19:56:17.84
リファクタしたいけど
きわめて明白なことに
根本的リファクタしたら2年ぐらい自分がやってた部分全部いらない

どうすればいい
0517仕様書無しさん
垢版 |
2018/10/11(木) 20:11:38.77
いらないなら消せばいいじゃん

サンクコスト効果とか知らない？
いらないものをメンテするほうがコストがかかる
0519仕様書無しさん
垢版 |
2018/10/11(木) 20:21:47.28
大きな猫用ドアと小さな猫用ドアがあって小さいほう作ってる
どっちのドアをくぐらせるか猫を誘導するのがまた

機能は実質まったく一緒
0520仕様書無しさん
垢版 |
2018/10/11(木) 20:33:14.61
>>518
時給ってやつだね
作業時間がそのまま金になる
だから効率化すると逆に金が減る
0521KAC
垢版 |
2018/10/11(木) 21:03:17.24
>>515
まともに書けない理由がそれなら、
なんでリファクタリングすれば
成功すると思ったの？
0522仕様書無しさん
垢版 |
2018/10/11(木) 21:07:49.15
リファクタすると工数２、３倍
リファクタしないと指数関数的に複雑さがふえる
0523仕様書無しさん
垢版 |
2018/10/11(木) 21:15:32.35
まともに書けないんじゃなくて、まともに書かないだけ。
時間をかければまともに書けるが、その時点では
そこまでする必要がなかったという判断

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

その反対の行為は、古い目的地のルートはそのままに古い目的地から
新しい目的地へルートを伸ばす。だから無駄が積み重なって最後には
入り組んだ迷路のようになる
0524KAC
垢版 |
2018/10/11(木) 21:54:50.87
>>523
で、リファクタリングして作り直してるるあいだに状況が変わるんだよな？
開発プロセスから見直した方がいいぞ。
0525仕様書無しさん
垢版 |
2018/10/11(木) 22:00:48.50
まあ、リファクタリングするくらいなら新規で作った方が金も取れるからなぁ
0526仕様書無しさん
垢版 |
2018/10/11(木) 22:13:18.61
>>524
リファクタリングって何かを修正するたびに、該当箇所だけを少しづつやるもんだぞ？
毎日状況が変わっていたら仕事にならんだろうが

お前みたいに、リファクタリングという特別な時間を使って大規模にまとめてやるって
間違った考え持ってるやつはいつ撲滅できるんだろうかね
ほんと害悪でしかないわ
0527仕様書無しさん
垢版 |
2018/10/11(木) 22:21:42.14
>>525
時給で請求金額を決めてるんですね
大変ですね。開発時間を短くすると金が取れない仕組みなんてｗ
0528仕様書無しさん
垢版 |
2018/10/11(木) 22:26:11.34
>>527
だからさw
請け負いでやってても何でも
見積もりは作業工数から算出だろうに。
だからむしろ数時間で終わっちゃうリファクタリング作業なんかではたいした金は取れないんだよ。
電気屋が修理じゃなく新製品勧めて来るのと同じだ。
0529仕様書無しさん
垢版 |
2018/10/11(木) 22:54:07.97
>>524
そう
ずっと追いかけるんだよ
理想と現実の誤差がある程度の範囲に収まるように調整すんの
リファクタリングしないと誤差が大きくなりすぎて商品価値が暴落する
暴落してから焦って直そうとしても誤差が大きすぎてどっちに進めば理想に近くのかがわからなくなる
0530仕様書無しさん
垢版 |
2018/10/11(木) 23:05:27.01
>>528
矛盾してるなぁｗ

リファクタリングの時間を作業工数に含めたら
むしろ金は取れるだろうに
0531KAC
垢版 |
2018/10/11(木) 23:13:37.93
>>529
その誤差をリファクタリングで埋めようとするのが間違ってるって話なんだけど？
0532仕様書無しさん
垢版 |
2018/10/11(木) 23:14:59.67
>>531
リファクタリングは修正のたびに小さくやるもので
1日以内で終わるような誤差をなぜリファクタリングで埋めたらダメなんだ？
0533仕様書無しさん
垢版 |
2018/10/11(木) 23:15:45.02
>>530
リファクタリングってのは、そもそも設計不具合だからな。
新規開発の工数に入れられるはずが無いだろw
0534仕様書無しさん
垢版 |
2018/10/11(木) 23:19:19.47
>>533
リファクタリングは不具合修正じゃないので
工数に入れていいってことになりますねぇｗ

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

ま、あんたは不具合は全部無償で修理するんでしょうがねｗ
0536仕様書無しさん
垢版 |
2018/10/11(木) 23:33:59.67
新規開発のお金が取れるぐらいなら
リファクタリングのお金も当然取れる
0537仕様書無しさん
垢版 |
2018/10/11(木) 23:35:41.03
リファクタに金がかかるってことは
リファクタで開発が楽になってないんだから
そのリファクタは間違いだと結論できる
0538仕様書無しさん
垢版 |
2018/10/11(木) 23:39:30.65
>>536
おまえさ、くたびれたババアだけとわ処女再生手術したのと、ピチピチの女子高生と、どっちと付き合いたい？
0540仕様書無しさん
垢版 |
2018/10/11(木) 23:43:14.80
>>537
おいおいｗ

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

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

リスクゼロで金を稼ぐいい方法だ。
0541仕様書無しさん
垢版 |
2018/10/11(木) 23:43:34.33
新しいハードに新しい技術で作ったアプリと、
ガラケーのアプリに機能追加したアプリでもいいよ。
0543仕様書無しさん
垢版 |
2018/10/11(木) 23:44:35.24
これからはリコンストラクトって呼ぼう
リファクタなんて陰謀くさい名前でいうからコストを考える気にならんのだ
0545仕様書無しさん
垢版 |
2018/10/11(木) 23:45:36.50
>>540
じゃあ今回は認めるけど今後の機能追加は恒久的に料金４割引きで
0546仕様書無しさん
垢版 |
2018/10/11(木) 23:45:42.71
>>540
そんなの夢物語だぞ。
顧客のニーズは思いがけない方向にあって、
だいたいどんなリファクタリングを先回りしてやってても
無意味だったりするのが現実だぞ。
0547仕様書無しさん
垢版 |
2018/10/11(木) 23:47:06.88
>>542
おまえは商売の話をしてないから無意味な事に金を使いたがるんだろ？
0548仕様書無しさん
垢版 |
2018/10/11(木) 23:47:13.10
名前が心理に与える影響をばかにしてはいけない
人間は絶望的にいい加減
0549仕様書無しさん
垢版 |
2018/10/11(木) 23:47:50.37
>>545
時給で請求金額決めてるところは大変だなぁ
開発を楽にしたら儲けが減るんだからｗ

ビジネスモデルが破綻してることにも気づいていない
自分で自分の首を絞めてることに気づいていない
0550仕様書無しさん
垢版 |
2018/10/11(木) 23:49:06.68
まず、リファクタリングに金を出す客は居ないからなぁw
0551仕様書無しさん
垢版 |
2018/10/11(木) 23:49:35.44
>>545
> だいたいどんなリファクタリングを先回りしてやってても

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

先回りしないからこそあとでリファクタリングするんだよ。
先回りしてリファクタリングとか矛盾そのものだ
0552仕様書無しさん
垢版 |
2018/10/11(木) 23:50:08.49
>>550
リファクタリングを作業工数に入れるという発想がないから
自分で自分の首を絞めてるんだろうねｗ
0553仕様書無しさん
垢版 |
2018/10/11(木) 23:50:51.93
>>549
え？機能で値段決めてるのに機能増えないリファクタで金とるの？
0554仕様書無しさん
垢版 |
2018/10/11(木) 23:51:51.88
>>553
機能を実現するコードを作り出すためなんだから
当然入れるに決まってるだろ。

本当に頭がおかしい。馬鹿じゃなくておかしい
0555仕様書無しさん
垢版 |
2018/10/11(木) 23:52:14.62
>>551
だからリファクタリングは無意味なんだって。
仕様変更があって初めて秘密裏にリファクタリングするくらいが関の山なんだよ。
リファクタリング自体に金なんか誰も出さないから。
0556仕様書無しさん
垢版 |
2018/10/11(木) 23:53:21.87
>>555
秘密裏っていうか、お前客にやってること全部説明するのか？
ここのi+1というのはですね（略
コードの説明なんてわざわざしねーよ
0559仕様書無しさん
垢版 |
2018/10/11(木) 23:55:51.21
> リファクタリング自体に金なんか誰も出さないから。

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

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

なら作業時間に含めればいいだけなのに
その発想が出ない。おかしい。馬鹿じゃなくておかしい
0560仕様書無しさん
垢版 |
2018/10/11(木) 23:57:15.08
>>558
> おまえは、客先コードレビューもやらない素人相手のマか？

コードレビューした気になってるだけだろ。
リファクタリングされてない奇怪なコードの解読に
数時間かけても何も生まれないよ
0561仕様書無しさん
垢版 |
2018/10/11(木) 23:57:53.64
>>559
おまえは、見積もりの内訳も分からない素人を相手にしているマなのか？
0562仕様書無しさん
垢版 |
2018/10/11(木) 23:58:19.33
>>557
矛盾してる所があったら指摘してみて
できないなら黙るか、関係ない話にすり替えてみてｗ
0564仕様書無しさん
垢版 |
2018/10/11(木) 23:59:31.06
>>561
お前は見積もりの内訳としてコード一行一行の値段なんか出してんのか？
0565仕様書無しさん
垢版 |
2018/10/12(金) 00:00:26.94
>>559
人間がバグったｗｗ

コード量と時間と機能のどれで金とるの？
0566仕様書無しさん
垢版 |
2018/10/12(金) 00:00:57.18
>>563
もしかしてプロならバグを入れないと思ってる？
どんなコードでも一瞬で理解できると思ってる？

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

だからリファクタリングが必要なの
0567仕様書無しさん
垢版 |
2018/10/12(金) 00:02:00.50
おれは一切バグを出さない方法を知ってる。

さわらなきゃいいんだ
0568仕様書無しさん
垢版 |
2018/10/12(金) 00:02:05.75
>>565
> コード量と時間と機能のどれで金とるの？

顧客への価値に決まってんだろ
いらない機能を追加しても金なんかもらえない
発想自体が根本からずれてる
0569仕様書無しさん
垢版 |
2018/10/12(金) 00:02:49.28
>>564
この仕事何十年もやってる人なら処理内容からだいたいの工数は頭ん中にあるんだよ。
その工数に見合わない見積もり出したら、突っ込まれて詳細聞かれるんだよ。
0570仕様書無しさん
垢版 |
2018/10/12(金) 00:02:55.85
>>567
だからリファクタリングは修正する必要があるときに
作業時間に含めてやることになるわけなんですね。

さわらなきゃいけないときにやるもの
0571仕様書無しさん
垢版 |
2018/10/12(金) 00:04:29.82
じゃあリファクタで余分な金なんかとれないじゃん
0573仕様書無しさん
垢版 |
2018/10/12(金) 00:05:36.00
>>569
> この仕事何十年もやってる人なら処理内容からだいたいの工数は頭ん中にあるんだよ。

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

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

だから他人が作った見たこともないコードの修正の見積もりなんかしない
自分の仕事に責任を持っているからだ
0574仕様書無しさん
垢版 |
2018/10/12(金) 00:09:07.35
>>573
それも込みでだいたいの工数なんか決まってんだよ。
見た事も無いコードならリファクタリングが必要かすらわからないんだから、そもそも前提が意味がないって事に気づけ。
そして見た事も無いコードの修正作業の見積もりなんか普通はしない。見積もりに際してコードを提供してもらうのが普通だぞ。
0575仕様書無しさん
垢版 |
2018/10/12(金) 00:11:11.83
たぶん口だけだな

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

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

彼は優れたコードが書けるのではない。単に理解力が劣っているんだ。
0576仕様書無しさん
垢版 |
2018/10/12(金) 00:19:00.10
自分で書いたコードを自分の責任で弄り回すのは勝手にやればいい。
リファクタリングでも何でも好きな名目でやってれ。
でも、会社組織に組み込まれてる身分では、責任なんか取れないんだから、余計な事はするな。
それだけ。
0577KAC
垢版 |
2018/10/12(金) 00:46:04.92
>>558
話の本質とは違うけど気になったのでツッコんどく。
「それは客の定義によるだろ」

例えばお前さんが客として買ったゲームソフト、開発者とレビューしたか？
0578KAC
垢版 |
2018/10/12(金) 00:51:10.56
>>575
概ね同意。
コードがグチャグチャになった根本原因すら理解できてない奴が
リファクタリングしたところでまともなコードにはならないのは明白だし。
時間と金の無駄どころが不要なリスクを上げるだけだろう。
0579仕様書無しさん
垢版 |
2018/10/12(金) 06:53:26.39
>>578
理解して整理するためにリファクタリングするんだよ
素人は知らないだろうけどプロジェクトの最初から全てのコードの歴史を知ってる人材なんてほとんどいないからな
0580KAC
垢版 |
2018/10/12(金) 07:00:56.22
>>579
理解するためにリファクタリングするとか、
素人丸出しの意見だな。。。
0581仕様書無しさん
垢版 |
2018/10/12(金) 07:09:11.43
>>580
お前さんがな
最低限マーティン・ファウラーの本は読んでからこい
でなければ議論の場に立つには早すぎる
0582KAC
垢版 |
2018/10/12(金) 07:54:59.96
>>581
なるほど。
事象に対する理解力すらないのか。

そりゃあ、自分の間違った行動を正当化するために
リファクタリングをしているってことにしたいわけだ。
0583仕様書無しさん
垢版 |
2018/10/12(金) 10:06:25.50
客先レビューすると、客からリファクタリング求めらる事もあるんだよな。でも工数は据え置きってのが普通だ。
0584仕様書無しさん
垢版 |
2018/10/12(金) 11:39:54.32
>>583
はい。交渉力がなければ、工数据え置きでやらされるでしょうね
おそらく仕様変更も無償でやらされてますよ。
0585仕様書無しさん
垢版 |
2018/10/12(金) 11:41:44.63
>>583
そりゃリファクタリングが要求されるような
読みづらいコードは、バグと一緒だからね

だから、最初からリファクタリング込みで工数を出すんだよ。
動けば完成じゃない。客から文句を言われないものを作るまでが仕事だ
0586仕様書無しさん
垢版 |
2018/10/12(金) 14:19:06.40
読みづらいからって修正要求される事は無いなぁ
関数ヘッダのコメントが無いとかくらいならあるけどさ。
リファクタリング求められる一番多いのは、
同じ事をコピペかってくらい繰り返してたりするコードとかかなぁ
0587仕様書無しさん
垢版 |
2018/10/12(金) 18:48:47.73
読みづらいコードとバグは違うだろw変なやつだなあw
0588仕様書無しさん
垢版 |
2018/10/12(金) 20:00:21.60
繰り返しは目に見えてテスト工数にはねるのでリファクタされてしまう
条件分岐も

やっぱりまぎらわしい名前とか処理順序とか
ややこしい変数渡しがいちばんきくな
0590仕様書無しさん
垢版 |
2018/10/12(金) 21:04:58.85
○○と一緒とかいうな
思考がめっちゃ雑になる

みんなは区別がつくから別の名前で呼んでるんだ
つまり
おまえだけ区別がつかないまぬけということになる
0591仕様書無しさん
垢版 |
2018/10/12(金) 21:36:10.05
読みづらいコードはバグではない・・・そのとおり
読みづらいコードはバグと一緒で無償修正の対象・・・そのとおり
0592仕様書無しさん
垢版 |
2018/10/12(金) 21:40:43.46
>>591
ソースコードを納品する場合で
相手側のソースコードのレビューがある場合は当然だな
そのためのレビューなんだし
0593仕様書無しさん
垢版 |
2018/10/12(金) 22:12:19.93
下流が下流に納品する特殊事例をあげられましてもw
ソースコードなんか読みませんからw
0594仕様書無しさん
垢版 |
2018/10/12(金) 22:24:05.39
>>593

558 返信：仕様書無しさん[sage] 投稿日：2018/10/11(木) 23:54:32.36
>>556
おまえは、客先コードレビューもやらない素人相手のマか？
0595仕様書無しさん
垢版 |
2018/10/12(金) 23:05:45.10
執拗な下流押しw
0596仕様書無しさん
垢版 |
2018/10/12(金) 23:36:20.41
ソース持ってなきゃ相手に依存しっぱなしになってしまう
何か仕込まれてもわからない

コードは権力そのものだ

コード読めないコード読まない上流など
金の上流なだけで立場は最下層
どれほど愚かであればそれを誇る気になるのだろう
0597仕様書無しさん
垢版 |
2018/10/12(金) 23:55:25.51
自社から出す商品の品質がどうでもいいなんてアホ居るんだw
0598仕様書無しさん
垢版 |
2018/10/12(金) 23:56:38.24
いやごめん
そんな上流いるわけないな
下流だけど適当に煽ってみただけだよね
0599KAC
垢版 |
2018/10/13(土) 00:15:55.54
>>596
お前さんは買った商品の全部のコードを読んでから使うのか？
Windowsはさぞかし読むの大変だったろうな。
0600仕様書無しさん
垢版 |
2018/10/13(土) 00:19:37.81
>>599
読まないしテストもろくな検証もしてない
だからむしられるだけの庶民

MSに勝手にメール見てもいいことにされ、いりもしないOSを無理やり入れさせられ
プライベートをくまなく抜き取られ
せっかく買ったパソコンを自分のもののように好き勝手にいじりまわされても
あきらめて黙って使うしかない
0601仕様書無しさん
垢版 |
2018/10/14(日) 20:02:01.74
コードメトリクスの上限とか指示されないのかな
0602仕様書無しさん
垢版 |
2018/10/15(月) 21:12:59.20
　私たち日本人の、日本国憲法を改正しましょう。
総ム省の、『憲法改正國民投票法』、でググって
みてください。拡散も含め、お願い致します。
0603仕様書無しさん
垢版 |
2018/10/17(水) 08:13:37.09
リファクタリングが必要なとき、それは、システムをそもそもリプレイスしないといけないとき。
よって、リファクタリングなんぞ不要。
0604仕様書無しさん
垢版 |
2018/10/17(水) 08:33:54.64
>>603
リファクタリングの工数とリプレイスの工数が同じならそれも真だが
多くの場合はそうではないからリファクタリングは必要だよ
0605仕様書無しさん
垢版 |
2018/10/17(水) 09:03:34.82
むしろいつまで古いシステム使うつもりなんだって話
ハードの耐用年数だってあんだろ？
0606仕様書無しさん
垢版 |
2018/10/17(水) 09:09:26.37
>>604
だから、リプレイスが必要なレベルなのに、リファクタを提案すること自体愚かだって話だ。
宇宙軍だの言ってる時代に、未だに、石器時代の石で作った武器の石を研ぐことを提案するのか？
0607仕様書無しさん
垢版 |
2018/10/17(水) 20:32:07.89
移行プロジェクトで
既存システムにリプレースされそうな勢い

いろいろシャレにならない
0610仕様書無しさん
垢版 |
2018/10/18(木) 21:58:06.14
>>606
リプレイスが必要なレベルならリプレイスするのが最適だろ
そうでもないレベルでリファクタが必要なケースもある

「不要」と断言する方が俺には信じられないよ
0611仕様書無しさん
垢版 |
2018/10/18(木) 22:00:52.92
ちゃんと動いてるもんになんでわざわざ手を加えて金取ろうとするの？
0612仕様書無しさん
垢版 |
2018/10/18(木) 22:09:10.01
>>611
リファクタだけで金取るビジネスなんて聞いたことないよ

機能追加や仕様変更時に、手を入れやすいようにリファクタするくらいだろ
もちろんリファクタの工数もスケジュールに入れる
当然だが、もしリファクタやらない方が工数が減るならリファクタはやらん
0613仕様書無しさん
垢版 |
2018/10/18(木) 23:18:45.15
>>612
ちゃんと動いてるもんになんでわざわざ機能追加や仕様変更しようとするの？
0616仕様書無しさん
垢版 |
2018/10/19(金) 08:27:28.18
>>615
そう、改修依頼があってはじめてリファクタを検討する
リファクタした方が工数が少なそうならリファクしてから改修に着手するし
しない方が工数が少なそうならそのまま着手する

あと当然、リプレイスした方が工数が少なそうならリプレイスする
0617仕様書無しさん
垢版 |
2018/10/19(金) 09:55:32.55
工数で考えるのはまだアマチュア。
プロなら金額で考えれ
0618仕様書無しさん
垢版 |
2018/10/19(金) 11:03:58.34
>>617
工数で考えるべきか金額で考えるべきかは立場によるだろ
それに、馬鹿正直に工数と金額を比例させる必要はない
0621仕様書無しさん
垢版 |
2018/10/19(金) 12:20:49.04
客に対しては金、従業員に対しても金。
ただし、ベクトルはそれぞれ真逆だがなw
0623仕様書無しさん
垢版 |
2018/10/20(土) 00:38:17.81
かしむら最低だな
0624仕様書無しさん
垢版 |
2018/10/20(土) 10:16:15.04
客や従業員から見ても、経営者の思いとは逆ベクトルだけどな。
0625仕様書無しさん
垢版 |
2018/10/20(土) 10:43:39.59
客
　んなことより、要望の品作って
0626仕様書無しさん
垢版 |
2018/10/20(土) 18:28:30.36
リファクタがリプレイスまでにちょくちょく必要なほど、毎回いきあたりばったりの汚いソースコードの開発会社か
発注したくねー
0627仕様書無しさん
垢版 |
2018/10/20(土) 18:44:51.16
>>626
何度言っても理解しなよな。

リファクタリングは、別途時間をとってやるってものじゃないの
ちょくちょく必要なんじゃなくて、
コード書くときにほぼ毎回必要なものなの

汚いからリファクタリングするんじゃないんだよ
テストコード書いてそれに通るコード書いて
リファクタリングしながら作り上げるの

プログラマが「できました」と言うまでに
何度もリファクタリングが行われる。
0628仕様書無しさん
垢版 |
2018/10/20(土) 19:24:53.05
>>627
前に動いたところが触る必要もないのに動かなくなってるお前を信じるビジネスパートナーはこの世にいねーんだよ
0629仕様書無しさん
垢版 |
2018/10/20(土) 19:38:54.60
リファクタはテスト工数を減らすために改修前にやるもの
0630仕様書無しさん
垢版 |
2018/10/20(土) 20:11:23.63
>>628
それってさぁ、リファクタリング関係ない話だよね。

共通関数修正したら、前に動いたところが触る必要もないのに動かなくなるじゃん
0631仕様書無しさん
垢版 |
2018/10/20(土) 20:34:46.03
>>630
だから普通は避ける
円周率が3.14じゃ精度が足りない計算が必要になっても
既存の円周率とは別に用意して
既存には一切手を付けない
そういう管理が必要なんだよ
0632仕様書無しさん
垢版 |
2018/10/20(土) 20:49:41.21
>>631
ようするにコピペするってことでしょ？
テストの工数が倍増する問題はどう解決するの？
0633仕様書無しさん
垢版 |
2018/10/20(土) 20:58:54.14
リファクタリングを理解しない人はコスト意識がないんだよね
金を出すのは客だから知ったこっちゃないんだろうけど
コストだけじゃなくて開発時間も伸びるから結局いつも
時間足りなくなってクレームの元になってる
0634仕様書無しさん
垢版 |
2018/10/20(土) 21:06:00.07
コードを共有するなって話だからリファクタリングとは全く関係ないな。

コードをコピペしてるからバグが出たら、体中に転移した
がん細胞探すように、全体を調べないといけない
一箇所直しただけでは、他の部分には影響しない（＝バグがあるまま）
0635仕様書無しさん
垢版 |
2018/10/20(土) 23:00:14.60
>>632
リグレッションテストどうすんだよ
ちょっと機能追加するたびに共通化して毎回テストするんか
倍増どころじゃないな
0636仕様書無しさん
垢版 |
2018/10/20(土) 23:04:48.94
リファクタの欠点はどれだけやっても終わりがないことだ
コスト意識がないと
自己満足と脅迫概念にかられて延々非生産的な作業を続けることになる
0637仕様書無しさん
垢版 |
2018/10/21(日) 01:19:18.08
>>632
は？
お前のやり方じゃ、円周率使ってるとこ全部見直すって言ってるんだぞ
追加分だけじゃ済まないぞ
0638仕様書無しさん
垢版 |
2018/10/21(日) 01:41:05.39
>>635
リファクタリングとは全く関係ない話だが
テストは自動化しないとリグレッションテストなんてやってられないだろ？

>>637
> お前のやり方じゃ、円周率使ってるとこ全部見直すって言ってるんだぞ

円周率使ってるところが100箇所あるとして、1箇所に変更があったら、
100箇所同様の変更をして100箇所テスト（自動化されたテストの変更も100箇所ある）を
行わないといけないんだぞ。そんな事やってられないだろ
0639仕様書無しさん
垢版 |
2018/10/21(日) 02:10:11.45
リファクタリングって一旦壊して再構築するんだから
テストし直すのは当たり前だよ
0640仕様書無しさん
垢版 |
2018/10/21(日) 02:32:19.64
> リファクタリングって一旦壊して再構築するんだから

壊すってどういう事？
0641仕様書無しさん
垢版 |
2018/10/21(日) 06:05:26.58
>>627
毎回、リファクタｗｗｗｗ
どんだけ、きたねーソースコードなんだよｗｗｗｗ
0642仕様書無しさん
垢版 |
2018/10/21(日) 06:11:25.20
リファクタで、最適化しているつもりになって、毎回、ソースコードを破壊していくやつ
0643仕様書無しさん
垢版 |
2018/10/21(日) 06:15:32.12
リファクタリングが一旦壊すってどういう意味だろうか？
0644仕様書無しさん
垢版 |
2018/10/21(日) 06:16:43.21
>>642
最適化はリファクタリングか？
http://bliki-ja.github.io/IsOptimizationRefactoring/

> 最適化とリファクタリングはどちらも変化を伴うものだが
> （なかには最適化かつリファクタリングとなる変化もあるが）、両者は別物だと私は考えている。
>
> なぜなら、両者の目的が異なるからである。リファクタリングは、
> コードを理解しやすくするためである。最適化は、プログラムを速くするためである。
0645仕様書無しさん
垢版 |
2018/10/21(日) 06:47:47.64
>>644
最適化＝速度に対する

という完全な視野の狭いアホの落書きｗ

辞書
　最適化とは、速度を改善することである。
って書いてある辞書あるの？ｗｗｗ
0646仕様書無しさん
垢版 |
2018/10/21(日) 06:51:04.63
よくもまぁ、マーチン・ファウラーにアホとか言えるもんだわ
お前はこの業界で世界に誇れるレベルの実績があるのか？
0647仕様書無しさん
垢版 |
2018/10/21(日) 07:09:30.10
>>646
マーチン・ファウラーさんは、アホですわあｗｗ
ねえ。
辞書に最適化とは、速度を改善することである。
って書いてある辞書あるの？ｗｗｗねえ？ねえ？ねえ？
0648仕様書無しさん
垢版 |
2018/10/21(日) 07:12:41.82
マーチン・ファウラーってあれだろ？
開発手法を開発しようとしているのやらｗｗｗ
それだけいろんな手法を開発してもなお改善しない。
これが何を示すのかわからん馬鹿ってことだ。
0649仕様書無しさん
垢版 |
2018/10/21(日) 07:13:33.89
ガキが重箱の隅をつついてなんか叫んでるなぁｗ
この記事に最適化は速くする以外の目的もあるといった所で
「あぁ、そうだな」って言われて終わりだろうに
論点は「リファクタリングと最適化は違う」なんだから
0650仕様書無しさん
垢版 |
2018/10/21(日) 07:20:42.62
辞書に最適化とは、速度を改善することである。
って書いてある辞書あるの？ｗｗｗねえ？ねえ？ねえ？

勝手に、言葉を変更しないでくださいな。大混乱ですわ。ｗｗｗｗ
0653仕様書無しさん
垢版 |
2018/10/21(日) 07:22:33.83
「リファクタリングと最適化は違う」

この場合、「リファクタリング」「最適化」という２単語は極めて重い意味を持つ。
それを「重箱の隅」と片付ける馬鹿ｗ
0654仕様書無しさん
垢版 |
2018/10/21(日) 07:24:02.39
重箱の隅と言ってるのは「リファクタリング」と「最適化」の比較の話で
「最適化とは速度以外のものもある」ということだよ。

お前は速度以外の最適化に何があると思ってるのか？
それがリファクタリングの比較と同影響が出るのかを答えなさい
0655仕様書無しさん
垢版 |
2018/10/21(日) 07:24:40.84
コードを読みやすくすることは最適化って言いませんぇね（大爆笑）
0656仕様書無しさん
垢版 |
2018/10/21(日) 07:27:03.30
>>655
　最適化は、プログラムを速くするためである。
だなんて、断言しているアホｗｗｗ

辞書に書いてあるの？ｗｗｗ
0657仕様書無しさん
垢版 |
2018/10/21(日) 07:29:14.81
コードを理解しやすくするための最適化

という日本語は存在できないんでしょうか？？？？？ｗｗｗｗ
0658仕様書無しさん
垢版 |
2018/10/21(日) 07:30:11.97
ちなみに、
俺は、著者を馬鹿にしてません。
読者のお前を馬鹿にしています。
0661仕様書無しさん
垢版 |
2018/10/21(日) 07:47:33.05
馬鹿「りふぁくたー！」
周囲「新人さん、あの「りふぁくたー！」って言ってる馬鹿のコード使えないから、同じとこAさんが担当してるから。そっちと調整してね。」
0662仕様書無しさん
垢版 |
2018/10/21(日) 07:47:33.55
>>638
何を言ってるのかわからない
円周率の精度のテストを新たに作った上でのテストだろ
0663仕様書無しさん
垢版 |
2018/10/21(日) 07:48:46.51
stringクラスを変更するって平気で言い出すキチガイ
0665仕様書無しさん
垢版 |
2018/10/21(日) 08:14:14.94
>>663
テストしてないの？
テストしていて、変更しても動きが変わらなければ問題ないでしょ

（前提：リファクタリングは、変更しても動きが変わらない。
動きが変わるものはリファクタリングにはあたらない）
0666仕様書無しさん
垢版 |
2018/10/21(日) 08:19:00.64
>>631
> 円周率が3.14じゃ精度が足りない計算が必要になっても
> 既存の円周率とは別に用意して

あの、リファクタリングは変えないものなので
精度を増やすことは、リファクタリングではなくて単なる仕様変更なんですけど？

なんてことはないリファクタリングの意味をわかってないだけかｗ
0667仕様書無しさん
垢版 |
2018/10/21(日) 08:22:12.52
>>631
> 円周率が3.14じゃ精度が足りない計算が必要になっても
> 既存の円周率とは別に用意して
> 既存には一切手を付けない

別に用意する必要はないな。
（リファクタリングではなく）仕様変更の前後で互換性があればいいだけ
俺なら精度を上げるための省略可能なオプションを追加する
0668仕様書無しさん
垢版 |
2018/10/21(日) 08:28:49.48
リファクタリング・・・動きは変えない。だから既存の自動テストがそのまま通る

仕様変更・・・動きが変わる。だから全部テストしないといけない


結論。リファクタリングはしてもよいが、仕様変更はするな。
0670仕様書無しさん
垢版 |
2018/10/21(日) 08:51:49.32
>>666
いいや、仕様には円周率の精度なんて書いてないよ
精度がたまたま必要になっちゃったのは今回の追加処理だけ
それだって明記されてるわけじゃない
0676仕様書無しさん
垢版 |
2018/10/21(日) 08:56:21.55
リファクタリング（動きが変わらないもの）の話で
仕様変更を持ってくるやつは、何も理解してないとしか言えないな
0678仕様書無しさん
垢版 |
2018/10/21(日) 08:57:26.32
>>675
あるよ
円周率を割と入力しないと違いが出てほしいとこで出ない計算式とかあるぜ
0679仕様書無しさん
垢版 |
2018/10/21(日) 08:58:11.51
>>673
いいか？仕事とはこうやるんだ

仕様書がないということは、いかなる動作変更も仕様変更ではないということなんだ

だから客にはこう言うんだ。

「動作は変わりましたが仕様変更ではありません」
0682仕様書無しさん
垢版 |
2018/10/21(日) 08:59:50.61
>>678
だから今まで低い精度で行っていた仕様を
精度を上げるというふうに仕様変更したんでしょう？

まさか、そもそも変更すべき仕様がない = 仕様変更ではない とでも？
0683仕様書無しさん
垢版 |
2018/10/21(日) 09:00:03.73
リファクタリングもエンハンスも元あるものから手を加えるなら
それは一度壊す事を意味する
言葉上の意味だがこれが理解出来ないからテストを軽視する
0684仕様書無しさん
垢版 |
2018/10/21(日) 09:00:09.32
>>680
だから必要なのは今回の追加分だけだっつの
客からしたらな
円周率をソース内で使いまわしたいのはテメーのおかしい頭だけなんだよ
0686仕様書無しさん
垢版 |
2018/10/21(日) 09:00:34.32
>>683
> リファクタリングもエンハンスも元あるものから手を加えるなら
> それは一度壊す事を意味する

だからリファクタリングで壊すってなに？
0690仕様書無しさん
垢版 |
2018/10/21(日) 09:02:01.47
>>684
だから今回追加分は、今までと同じ精度では足りなかったから
それに対応する精度に仕様変更するんでしょう？
0691仕様書無しさん
垢版 |
2018/10/21(日) 09:02:43.75
>>682
え？誰も既存処理を変えろなんて言ってないよね？
円周率を何で使いまわしたいの？
精度が必要なのは今回の追加分だけだよ
0693仕様書無しさん
垢版 |
2018/10/21(日) 09:03:42.47
そもそも円周率の精度変更ってなんなんだ？

円周率取得関数の話してんの？
円周率は固定値なんだから、変更すべきコードなんて無いじゃん

でだしからおかしいのかよｗ
0694仕様書無しさん
垢版 |
2018/10/21(日) 09:04:03.53
>>686
端的に言えば元あるものに手を加えて変更する事
変更してる最中は機能してないんだから壊している
作り上げてテストして元あるものと同等であることが確認出来て
初めてリファクタリングしたと言っていい
0695仕様書無しさん
垢版 |
2018/10/21(日) 09:04:30.44
× 円周率は固定値なんだから、変更すべきコードなんて無いじゃん
○ 円周率は固定値なんだから、リファクタリングすべきコードなんて無いじゃん
0696仕様書無しさん
垢版 |
2018/10/21(日) 09:05:46.67
>>694
> 端的に言えば元あるものに手を加えて変更する事
> 変更してる最中は機能してないんだから壊している

え？ 変更ってコミット単位じゃないの？
コミット単位では壊さないよ

まさか、ファイル保存した単位で壊してるって言ってる？
0697仕様書無しさん
垢版 |
2018/10/21(日) 09:06:33.50
>>684
あるシステムにはA機能しかありません。ここにB機能を追加します。
はいこれ仕様変更ね。
0701仕様書無しさん
垢版 |
2018/10/21(日) 09:10:55.30
>>696
編集してる最中が壊している状態
編集完了してもテストしてない状態が壊れている状態
テストまで完了して完全に機能している事が保証できたらリファクタリング完了
0702仕様書無しさん
垢版 |
2018/10/21(日) 09:12:59.55
>>701
いや、だから「編集」とはコミット単位で考えてないんですか？
YES か NO でお応えください
0704仕様書無しさん
垢版 |
2018/10/21(日) 09:24:12.38
今回の追加分の処理の円周率は3.1415までは必要
既存の処理は3.14で十分

このとき既存処理と追加分の処理とで同じ円周率3.1415を共通で使うかどうかって話だな

ビジネスならNo
既存の処理を変更することになる
0705仕様書無しさん
垢版 |
2018/10/21(日) 09:28:18.38
今回の追加分の処理の円周率は3.1415までは必要
既存の処理は3.14で十分

このとき既存処理と追加分の処理とで同じ円周率3.1415を共通で使うかどうかって話だな

ビジネスならNo
既存の処理を変更することになる
0706仕様書無しさん
垢版 |
2018/10/21(日) 09:37:24.73
>>703
つまりサーバーにアップロードする前
個人のコンピューターの中でだけ
一時的に壊れてるってことですか？
0707仕様書無しさん
垢版 |
2018/10/21(日) 09:51:52.30
>>704
ビジネスならNoとか意味わからんし、こっちが恥ずかしくなるレベルｗ
仕様による。それだけ。仕様書がないのは論外

> このとき既存処理と追加分の処理とで同じ円周率3.1415を
共通で使うならば、それは仕様変更。なぜなら既存の処理の動きが変わってるから。
なお、動きが変わるのでこれはリファクタリングではない（リファクタリングと関係ない話）

仕様変更なのでいままでのテストは通らない可能性があるだろう
まあリファクタリングではないので、それはしかたない

> このとき既存処理と追加分の処理とで同じ円周率3.1415を
共通で使わないならば、既存の処理は変わらない
既存の処理は変わらないのであれば、追加分の処理を除いた既存の処理はリファクタリング可能（必須ではない）
既存の処理に関しては仕様変更しないので、いままでのテストはそのまま通る

追加分の処理は、そもそも存在しなかったものなのだから、この文は当然リファクタリングではない
0708仕様書無しさん
垢版 |
2018/10/21(日) 09:52:00.90
>>706
コミット単位と言ってる意味が
「毎回機能が保たれた状態に編集してテストまでして問題なくコミットすること」を意味しているなら壊れてない状態
それ以外は壊れてる状態
0709仕様書無しさん
垢版 |
2018/10/21(日) 09:52:59.68
>>703
質問に答えてくれないので、追加で追い打ちｗ

つまりサーバーにアップロードする前
個人のコンピューターの中でだけ
一時的に壊れてるってことですか？

他の人は壊れたことに気づかない＝壊れてないってことですか？
0710仕様書無しさん
垢版 |
2018/10/21(日) 09:53:56.25
>>708
でも他の人は誰も、一時的に壊れたことに気づかないんですよね？
0712仕様書無しさん
垢版 |
2018/10/21(日) 09:58:56.26
>>711
バージョン管理ソフト用語で、変更の1単位を表す

ソースコードの修正は複数のファイルにまたがることがあるが
その複数のファイルの変更をまとめて一つにしたものがコミット

通常はコミットごとにテストを実行し壊れていないことを確認する
0713仕様書無しさん
垢版 |
2018/10/21(日) 10:01:27.12
>>710
他人は関係なく自分で今プログラムをどういう状態にしようとしているか
編集を始めた時点で壊し始めている
当然他人にそんな事認識できるわけない
ローカルで勝手にやってる事が壊してるというのはおかしいというなら
俺とは考えが違う
0714仕様書無しさん
垢版 |
2018/10/21(日) 10:03:58.62
>>713
え？だってあなたの定義だと既存の機能に全く手を付けなくても
機能追加中も壊れますよね？
ソースコードコンパイルできなくなるんだから
0715仕様書無しさん
垢版 |
2018/10/21(日) 10:06:39.57
>>714
機能追加中はエンハンスだから壊してる状態
文法エラーでコンパイルできないならそれ以前の問題
0716仕様書無しさん
垢版 |
2018/10/21(日) 10:07:16.67
ソースコードの修正途中に一時的に動かなくなることを壊すと言ってるのなら、
それをリリースするわけでもないので大したことじゃないから
心配する必要はなにもないってことになるのでいいんですよ。
0717仕様書無しさん
垢版 |
2018/10/21(日) 10:08:54.02
（自動化された）テストが重要なのは、壊れてないことを保証するためですからね
一時的に壊れてもコミット時に壊れてなければ問題ないので
リファクタリング（動きを変えない）の場合はテストを変える必要もないので、
機能追加と違って、安心して変更ができるわけなんですね。
0718仕様書無しさん
垢版 |
2018/10/21(日) 10:52:10.73
細井隼人最低だな
0719仕様書無しさん
垢版 |
2018/10/21(日) 11:33:37.79
揚げ足取りしかできなくて自分の意見が表明できないなんて悲しいな
0720仕様書無しさん
垢版 |
2018/10/21(日) 12:00:43.16
リファクタに耐えるようなうまいユニットテストつくれん
設定項目が膨大すぎてIF変更やDBの取得先変更で
あっさりで投げ捨てられる

F痛でDBの更新項目とか結果全部テストしてたからそういうふうにしてたが
世間の常識とちがうらしい
0721仕様書無しさん
垢版 |
2018/10/21(日) 14:09:44.77
ゼネコン案件だったらほとんどがコーディングスキルゼロの素人が設計したスマートUI乱用システムだろ
そのようなシステムではそもそもユニットテストは作れないのが普通なんだ
無理してユニットテストを作るんじゃなくて設計か要件定義までロールバックしたほうがいい
0723仕様書無しさん
垢版 |
2018/10/21(日) 14:54:49.81
このリファクタ馬鹿って、結婚障害だとか書いてる馬鹿と同一人物なんだろ
ほっとけよ
0724KAC
垢版 |
2018/10/21(日) 15:52:55.50
>>627
毎回リファクタリングが必要とか、
無能すぎてもう何やってるか理解できてないんだな。
0725仕様書無しさん
垢版 |
2018/10/21(日) 16:04:17.15
業務システムだと簡単すぎて時間が余る
暇を弄ぶのも苦痛なのでテストを整備してリファクタリングする
これぐらいでいいんだよ
無理してやるもんでもないし頑なに拒否するもんでもない
0726仕様書無しさん
垢版 |
2018/10/21(日) 16:05:15.11
うちのメンツだとリファクタはまずないわ
なにせ綺麗だもん常に
0728仕様書無しさん
垢版 |
2018/10/21(日) 16:16:15.70
うちは正規職員しかいないから
正規職員も全員偏差値７０は最低でもある
だからソースも無駄がないのさ
馬鹿な派遣だらけの職場は大変ですね
0731KAC
垢版 |
2018/10/21(日) 18:17:09.31
>>727
ビジネスが進歩とか、
お前の辞書（）には面白い単語が載ってるんだな。


つか、表面に見えてるビジネスに依存したソース書くのは素人丸出し。
まともに設計できる技術者なら、リファクタリングなんて無駄な事は発生させない。
0733仕様書無しさん
垢版 |
2018/10/21(日) 18:51:26.49
>>1って、自分以外誰も支持してくれない現実どう受け止めてんの？ｗ
ああキチガイだから受け止めないかｗ
0734仕様書無しさん
垢版 |
2018/10/21(日) 18:52:19.63
>>732
そうそう
お気づきの変化が起きた頃にはリプレイスです
リファクタ不要だろ？ｗ
0736仕様書無しさん
垢版 |
2018/10/21(日) 19:25:07.19
客「仕様変更をお願いしたいですが」
お前「リプレイスですね」

客「ちょっと仕様変更だけなんですが」
お前「無理です。変えられません。リプレイスしたほうが安いです」

客「来月さらに同じところの仕様変更を考えてるのですが」
お前「またリプレイスでしょうねーｗｗｗ」
0737仕様書無しさん
垢版 |
2018/10/21(日) 19:38:13.47
>>731
まあそこが君んとこの限界なんだろうね
業務ルールや要望が変化するたびに秘伝のタレを付け足していけばいいさ
0738仕様書無しさん
垢版 |
2018/10/21(日) 19:55:13.11
リファクタせずに機能追加しまくって
限界が来たらリプレース
理にかなっている
0739仕様書無しさん
垢版 |
2018/10/21(日) 19:58:39.09
・客先にて

客「広島から大阪を経由して東京へ行く仕様を、京都経由に変更してくれ」
上司「了解しました」

・社内にて

上司「大阪と京都は近くだから簡単だろう？すぐに修正してくれ」

お前「現状、広島から北海道を経由して福岡を経由して新潟を経由して京都を経由して東京に行くようになってますから
京都からさらに大阪を経由して東京に行くんですね」

上司「は？ 広島から京都を経由して東京にいくだけだろ。なんでそんなに遠回りしてるんだ？」
お前「動いているコードに手はださない。既存のルートに付け足すだけだ。今までずっとそうしてきた」

上司「それだとムダでわかりづいらいだろ。リファクタリングしろ」
お前「コードぐっちゃぐちゃやねん。手遅れだ。リプレイスしたほうが早い」

上司「なぜこまめにリファクタリングしなかったんだ？」
お前「リプレイスしたほうが早いからだ」

上司「手遅れにならないうちに！　こ・ま・めに！」
お前「知るか、リファクタリングなんか不要！」
0740仕様書無しさん
垢版 |
2018/10/21(日) 20:03:24.02
・客先にて

上司「この間の仕様変更の作業中に、遅かった理由が判明しました。
広島から大阪を経由して東京に行く仕様ですが、
広島から北海道を経由して福岡を経由して新潟を経由して大阪を経由して東京に行っていました」

客（絶句）

上司「担当者は今回の仕様で、上記に追加して大阪からさらに京都を経由しようとしていましたので、
ご安心ください。クビにしました」
0741仕様書無しさん
垢版 |
2018/10/21(日) 20:06:14.48
コードを書くのは下流だけど下流に行くほどリファクタリングに無頓着
派遣さんはコードを書かせたらサヨナラバイバイだから
彼らには後の事を考えてコーディングする機会がないのだろうね
そうなるとリファクタリングという発想自体が出てこなくなるのも仕方がない
0742仕様書無しさん
垢版 |
2018/10/21(日) 20:08:30.12
>>738
正解
その頃にはシステム担当者が変わってるから、引き継ぎを兼ねて新しく作るのが吉
0743KAC
垢版 |
2018/10/21(日) 20:13:07.98
>>732
フレームワークに振り回されるのは素人
0744仕様書無しさん
垢版 |
2018/10/21(日) 20:15:20.27
新人「大阪経由を京都経由に変更するんですね！（簡単そうだ）任せてください！」

上司「ちなみに納期はこれこれだから」

新人「まあ、変更少なそうだし、大丈夫でしょう」

新人（コード見て絶句）

新人「え！！その期間でその修正を！？」

新人（無理や・・・大阪からさらに京都へ経由する処理を追加するしかない）

上司「おい、なんで。広島から北海道を経由して福岡を経由して新潟を経由して京都を経由して大阪を経由して東京に行ってるんだ？」

新人「知らねーよ。既存のコードがそうなってたんだから真似しただけだ」（暗黒面落ち）
0745仕様書無しさん
垢版 |
2018/10/21(日) 20:15:54.98
>>742
新しく作るには、ぐっちゃぐちゃのコードを解析しないといけないんやで？
0746仕様書無しさん
垢版 |
2018/10/21(日) 20:21:29.53
リプレースって既存システムの仕様解析を諦めてベタ移植するフラグが最初からたってる
汚いレガシーシステムを違う基盤上の汚いレガシーシステムに置き換えるだけに終わる
莫大なコストがかかるくせにビジネス上のメリットは殆どゼロ
0747仕様書無しさん
垢版 |
2018/10/21(日) 20:25:08.48
>>738
> リファクタせずに機能追加しまくって
> 限界が来たらリプレース
> 理にかなっている

限界が来る前の修正でリファクタリングしない理由がわからん
0748仕様書無しさん
垢版 |
2018/10/21(日) 20:30:22.65
既存システムがめちゃくちゃで仕様解析は無理だ
↓
解析は諦める
行単位で移せば機能を維持したまま移植できるはず
↓
言語やライブラリの仕様の違いのせいでバグが多発
残業しまくって火消しするしかない
↓
なんとか移植完了
バグ数が多いので客は品質に強い懸念を抱いているがテストは通した
たとえスカスカでもテストは通したんだから大丈夫なはずだ
↓
経営陣に土下座させて客への説得もなんとかクリアして受け入れも済んだ
さあ本来の目的だった機能を追加するぞ
↓
コードがめちゃくちゃでどうやったら機能を追加できるかわからないよ

リプレースって毎回こんななるんだけど
リプレースがうまくいくことなんてあるの？
0749仕様書無しさん
垢版 |
2018/10/21(日) 20:38:22.90
リプレースついでに新しくしましょうとかやるからだろ

リプレースは古いものを使うのが鉄則
そんで限界が来るまで使って
限界が来たら、リプレースをする
0750仕様書無しさん
垢版 |
2018/10/21(日) 20:46:37.35
リファクタリングしてリプレースに耐えうるコードに書き換えてからリプレースするとうまくいくのだけど
コストをケチってリファクタリングが省略されて失敗する
0751仕様書無しさん
垢版 |
2018/10/21(日) 20:54:45.22
リプレースって仕様書みて一から全部再実装するんだぞ
そのために仕様書があるわけで、
完璧な仕様書が求められてる
0754仕様書無しさん
垢版 |
2018/10/21(日) 21:37:04.24
>>739
まさにお前のいうようにするわ

いままで北海道で下車できてたのにできなくなったら大デグレードじゃん
それリファクタじゃない
クビになるのは間違いなくお前のほう

多少遅いぐらいなんだってんだ
通常の現実世界とプログラムの世界の違いを知れよ
どうせ１秒２秒だろ？またせとけよ
0755仕様書無しさん
垢版 |
2018/10/21(日) 21:52:52.70
>>754
> いままで北海道で下車できてたのにできなくなったら大デグレードじゃん
勝手に仕様を追加するな
0756仕様書無しさん
垢版 |
2018/10/21(日) 22:04:52.76
> 通常の現実世界とプログラムの世界の違いを知れよ
> どうせ１秒２秒だろ？またせとけよ

実行時間の問題じゃないのよ。解析にかかる時間が問題なの

別の担当者が作業した時、なんでこんなことをしているのかわからないコードを
自信を持って完成しましたと言えないことが問題なの

何をやってるか知りませんが、動くからバグはないんじゃない？
テストに漏れがないと良いですね。

こんな無責任なこと言えないの
0757仕様書無しさん
垢版 |
2018/10/21(日) 22:07:42.69
仕様変更で既存のコードに付け足してつじつま合わせのようなことをしてるなら
テストも同じように付け足してつじつまを合わせをすることになる

必要のないテストをするだけじゃなくテスト自体の自信もなくなる。
こんなテストしてますが、このテストは正しいのですか？
必要なさそうなテストですが、前の人がやっていたので繰り返しやります
時間かかりますね。
0759KAC
垢版 |
2018/10/21(日) 22:13:40.43
>>748
リプレースの目的と、今後必要な機能を整理して、
現状よりも効率の良い新システムとして提案するのが正解。
0760仕様書無しさん
垢版 |
2018/10/21(日) 22:14:23.38
>>758
例えばCOBOLのバージョンを毎日確認したりしないよね
いつの間にか「あれ？バージョンが上がってる？」ってなる
数年スパンで起きる現象なんだから
お気づきの変化が起きた頃には（数年たっていて）リプレイスです。
0761仕様書無しさん
垢版 |
2018/10/21(日) 22:15:14.60
>>755
理由もなくそんなことになるもんか
変えたら何がおこるかわからん
0762仕様書無しさん
垢版 |
2018/10/21(日) 22:15:37.28
>>759
> リプレースの目的

リファクタリングしてなかったので
想定よりずっと早くコードの寿命が来てしまった
仕方がないのでリプレースで対応します
0763仕様書無しさん
垢版 |
2018/10/21(日) 22:16:25.32
>>761
意味がわからん。

> 客「広島から大阪を経由して東京へ行く仕様を、京都経由に変更してくれ」

どこにも北海道で下車したいなんて書いてない
0764仕様書無しさん
垢版 |
2018/10/21(日) 22:16:52.84
リファクタをリプレースと呼べば多少動きが変わっても許してもらえるという願望
0765KAC
垢版 |
2018/10/21(日) 22:17:41.50
>>755
自分が知らない仕様を他人のせいにするなよ。。。

こういう馬鹿が「聞いてない」「勝手に仕様が追加された」とか言い出すんだよな。

利用者にとって当たり前の仕様くらい把握する力を持てよ？
0766KAC
垢版 |
2018/10/21(日) 22:18:48.13
>>762
コードの寿命。。。？
お前の書いたコードは経年劣化するのか？
0767仕様書無しさん
垢版 |
2018/10/21(日) 22:18:52.07
>>763
客も開発者もすべての仕様を常に把握してるわけじゃないからな
どっかでだれか急に悲鳴上げて大混乱になる
0768仕様書無しさん
垢版 |
2018/10/21(日) 22:19:18.50
>>765
だから意味がわからん。

> 客「広島から大阪を経由して東京へ行く仕様を、京都経由に変更してくれ」

どこにも北海道で下車したいなんて書いてない


仕様に書いてない挙動も、動作保証してるのかな？ｗ
0770仕様書無しさん
垢版 |
2018/10/21(日) 22:22:20.47
客「仕様を変更し欲しい。どれくらいかかりますか？」

お前「仕様変更は認められん。こういう使い方してるかもしれないだろ」

客「いやそういう使い方してないから」

お前「お前が決めるな。客は神様ではない。」

客「お前の所に開発頼むのやめるわ」
0771仕様書無しさん
垢版 |
2018/10/21(日) 22:23:42.33
>>769
仕様変更の依頼があったら大手を振って変えられるし
多少デグレしても言い訳は立つ

ちょっと大阪を京都にするだけだろ？そこだけ対応するよ？
0772仕様書無しさん
垢版 |
2018/10/21(日) 22:24:16.92
>>759
増改築繰り返したシステムではその必要な機能を解析することがほぼ不可能
0773仕様書無しさん
垢版 |
2018/10/21(日) 22:24:28.92
客が求めてないのに、一旦リリースした以上
混乱を招くかもしれないからって仕様変更を拒否するとかイミフ
0774KAC
垢版 |
2018/10/21(日) 22:24:39.11
>>768
そんなことすら理解できないから、
お前は素人だと言ってるんだよ。

現状それで運用されてるんだろ？
なんでわざわざ北海道経由してるのを
「お前の判断でやめてもいい」んだ？

それは最早リファクタリングでもなんでも無い。
ただのバグ追加だ。
0775仕様書無しさん
垢版 |
2018/10/21(日) 22:25:27.78
>>771
> ちょっと大阪を京都にするだけだろ？そこだけ対応するよ？
大阪で下車するかもしれないだろ？

というような（意味不明な）話だったはずですが？
0776仕様書無しさん
垢版 |
2018/10/21(日) 22:26:05.81
>>774
> 現状それで運用されてるんだろ？
> なんでわざわざ北海道経由してるのを
> 「お前の判断でやめてもいい」んだ？

↓どうみても客の判断なんだが？ 何を言ってるんだこいつ。

> 客「広島から大阪を経由して東京へ行く仕様を、京都経由に変更してくれ」
0777仕様書無しさん
垢版 |
2018/10/21(日) 22:27:35.48
>>775
なんか気づけば指摘してやるが
そこは客が言い出したんだから間違いがあったら客のせいにできる
0778仕様書無しさん
垢版 |
2018/10/21(日) 22:29:20.71
>>777
つまり
> いままで北海道で下車できてたのにできなくなったら大デグレードじゃん
っていうのは間違いってことね
0780仕様書無しさん
垢版 |
2018/10/21(日) 22:30:13.47
>>778
そりゃ客が北海道で下車したいって今まで言ってないなら
そんなことに対応する必要はありませんね
0781仕様書無しさん
垢版 |
2018/10/21(日) 22:31:58.51
・客先にて

客「広島から大阪を経由して東京へ行く仕様を、京都経由に変更してくれ」
上司「了解しました」

・社内にて

上司「大阪と京都は近くだから簡単だろう？すぐに修正してくれ」

お前「現状、広島から北海道を経由して福岡を経由して新潟を経由して京都を経由して東京に行くようになってますから
京都からさらに大阪を経由して東京に行くんですね」

上司「は？ 広島から京都を経由して東京にいくだけだろ。なんでそんなに遠回りしてるんだ？」
お前「動いているコードに手はださない。既存のルートに付け足すだけだ。今までずっとそうしてきた」

上司「それだとムダでわかりづいらいだろ。リファクタリングしろ」
お前「コードぐっちゃぐちゃやねん。手遅れだ。リプレイスしたほうが早い」

上司「なぜこまめにリファクタリングしなかったんだ？」
お前「リプレイスしたほうが早いからだ」

上司「手遅れにならないうちに！　こ・ま・めに！」
お前「知るか、リファクタリングなんか不要！」
0782仕様書無しさん
垢版 |
2018/10/21(日) 22:33:07.72
続き

・客先にて

上司「この間の仕様変更の作業中に、遅かった理由が判明しました。
広島から大阪を経由して東京に行く仕様ですが、
広島から北海道を経由して福岡を経由して新潟を経由して大阪を経由して東京に行っていました」

客「今までの経由の変更はすべてそんなことをしていたと？頼んでないんだけど？」（絶句）

上司「担当者は今回の仕様で、上記に追加して大阪からさらに京都を経由しようとしていましたので、
ご安心ください。クビにしました」
0783仕様書無しさん
垢版 |
2018/10/21(日) 22:33:56.94
おまえぐらい同じこと何回もコピペするのが好きなら
リファクタしたくなるのもわからんでもない
0784仕様書無しさん
垢版 |
2018/10/21(日) 22:35:05.48
>>783
読まないで途中参加するやつがいるから
これ結構効果あるんだよ。
0785仕様書無しさん
垢版 |
2018/10/21(日) 22:35:21.24
一見仕様にないように見えても
イクラ弁当がたべたいとか言い出すやつがいたりして
そこで仕様がねじくれてる可能性もある

ぜんぜん関係ないはずなのに勝手に機能削除してそこでデグレたらだいぶやばい
0786仕様書無しさん
垢版 |
2018/10/21(日) 22:35:47.76
まず経路をデータとして扱うように改修して
既存の経路と同じ結果になるデータを投入してテスト
新しい経路のデータを投入

リファクタリングしてよかったな
しなければ経路を増やすたびにバカバカしい議論、コード分析、コード改修、ビルド、テスト、納品、客先説明をしなければならないところだった
とんでもないコストだよ
0787KAC
垢版 |
2018/10/21(日) 22:36:23.70
>>785
何度も言わせるな

なんか気づけば指摘してやるが
そこは客が言い出したんだから間違いがあったら客のせいにできる
0788仕様書無しさん
垢版 |
2018/10/21(日) 22:42:37.01
客の仕様自体が間違ってた時な

べつにそこだけ変えりゃ今まで通り達成できるのに
全然関係ないとこでデグレてあんたが言ったからだって通んないでしょ
0790仕様書無しさん
垢版 |
2018/10/21(日) 22:45:52.81
>>788
そこは客が言い出したんだから間違いがあったら客のせいにできる
0792仕様書無しさん
垢版 |
2018/10/21(日) 22:49:45.59
言い出した部分自体の仕様バグだったらね
これは関係ないとこの機能削除しようってんだからだめだろ

どっちにせよ現実に対しては何の解決にもならんが
0793仕様書無しさん
垢版 |
2018/10/21(日) 22:49:47.18
そりゃリファクタリングしないほうが良いとか誰も支持せんわｗ
0794仕様書無しさん
垢版 |
2018/10/21(日) 22:50:58.75
>>792
やっぱり現実的に解決できるのは
リファクタリングしかないのかな
仕様変更で無駄になったコードは削除しないといけないね
0795仕様書無しさん
垢版 |
2018/10/21(日) 22:58:53.14
今回の例↓みたいに
> 客「広島から大阪を経由して東京へ行く仕様を、京都経由に変更してくれ」

広島 → 大阪 → 東京 を
広島 → 京都 → 東京 に変更する場合

既存の処理（大阪に行く）を残して
広島 → 大阪 → 京都 → 東京 に変更する方法もある

だがそれは客は望んでいない

で、忘れてはいけないのはコレは ”リファクタリングではない" ということ
仕様変更なんだから当然リファクタリングではない


じゃあこの話のどこにリファクタリングが絡んでくるのかと言うと
（手っ取り早いという理由で）広島 → 大阪 → 京都 → 東京 と書いた後
（客の要望通り無駄な）大阪 を経由する処理を省くこと

広島 → 大阪 → 京都 → 東京 を
広島 → 京都 → 東京 にすることがリファクタリング

ここまでやって、完成と言えるのだが
こまったちゃんは動いたからOKでしょで、完成にしてしまうから
それが積み重なって、（客が要求してない）こんなクソコードになる
広島 → 北海道 → 福岡 → 新潟 → 大阪 → 京都 → 東京
0797仕様書無しさん
垢版 |
2018/10/21(日) 23:00:41.50
仕様変更のたびに、こうやって無駄になってしまったコードを
削除することもリファクタリングの一つなんだよ
0799仕様書無しさん
垢版 |
2018/10/21(日) 23:04:16.62
これからの修正で、時間がかかるほうがもったいない
0800仕様書無しさん
垢版 |
2018/10/21(日) 23:06:41.33
>>795
その要望で、その直し方する且つそんな直しになるプログラムを組むバカがいるとこで働いてないので
0802仕様書無しさん
垢版 |
2018/10/21(日) 23:08:48.44
俺はそんなところで目隠しされた状態で働いてる
へたに動いて事故れない
0803KAC
垢版 |
2018/10/21(日) 23:17:19.02
>>776
だからお前はど素人なんだよ。

「現状のルートは京都を経由していない」
という可能性に気付け。

勝手に仕様を自分の中だけで完結するな。
相手の意図を正しく判断して、今のシステムと比較して確認しろ。

お前のいうとおりなら、そもそも京都を経由してるんだから
要望じたいが発生しない。
0804仕様書無しさん
垢版 |
2018/10/21(日) 23:58:51.08
>>803
お前一人でずれたこと言ってるぞ
もう少し落ちつて書いてある要望を見ろ
それが全てなんだから
0805仕様書無しさん
垢版 |
2018/10/22(月) 00:30:11.82
>>786
いちばんヤバいやつ
データ化すると仕様変更にいちじるしく弱くなる
それこそ最初から設計されてなきゃ
なりゆきで変えちゃったらどつぼにはまるパターン

そしてどのみち駅ごとに別のことやるからテスト工数削減できないという

そのうえプログラムだとIF文ですんだところがデシジョンテーブルなんか使ったら
ちょっとしたきっかけで組み合わせ爆発、そのすべてをテストせざるを得なくなる
0806仕様書無しさん
垢版 |
2018/10/22(月) 00:32:27.85
客や上司が意地悪だとこっちの様子やプログラム見てわざと困るような要求してきたりするしな！
世界が敵に見えてる人間のやることではない
0808仕様書無しさん
垢版 |
2018/10/22(月) 01:01:17.87
リファクタリング禁止とか言ってるやつが書いた（クソ）コード見てみたいよなー
でもクソコード書くようなやつは公開しないだろうなー
ってことでなんかないか探すスレ立ててみた

【反面教師】 オプソで汚いソースコードを見てみる
https://mevius.5ch.net/test/read.cgi/tech/1540137601/
0809仕様書無しさん
垢版 |
2018/10/22(月) 01:03:06.50
>>805
> そしてどのみち駅ごとに別のことやるからテスト工数削減できないという

駅の話なんて一言も言ってないよ
0811仕様書無しさん
垢版 |
2018/10/22(月) 01:36:43.04
木村はくそ
0812仕様書無しさん
垢版 |
2018/10/22(月) 05:42:58.87
>>805
何言ってんだ？
ハードコードされてる方が変更に弱い
経路という明らかにデータで表現すべきものを手続きで実装するなんておかしいよ
そうやっておかしなことをやるから「既存の経路をコピペして付け足しましたー」などと無茶をする奴が現れる
データだったら「新規経路登録しました」で済む話だ
プログラムの変更がないからテストも最小限で済む
客への説明もこれ以上ないほど簡単だ
0816仕様書無しさん
垢版 |
2018/10/22(月) 19:08:28.04
この事例でパスをデータ化しない奴は即刻クビでもおかしくない
0817仕様書無しさん
垢版 |
2018/10/22(月) 19:17:08.48
任意のデータを扱えることという要件がない以上やらんほうがいい
客の要望が都合よく同じ枠組みからずっと外れずにいる保証なんてないぞ

やっていいのはこっちが開発のアドバンテージを握ってるときだけだ
思い付きで下っ端がリファクタでやるとか自殺行為
0818仕様書無しさん
垢版 |
2018/10/22(月) 19:29:08.01
仕様が変わる可能性があるから「具体的な経路」と「枠組み」を分離してメンテナンス性を上げるんだろが
これらがハードコードされて絡み合ってたら直すに直せんぞ
0820仕様書無しさん
垢版 |
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` に変更するという方法もある
0821KAC
垢版 |
2018/10/22(月) 22:08:32.62
>>820
内容が理解できないなら無理して話に加わらなくてもいいんだよ？
0823KAC
垢版 |
2018/10/22(月) 22:56:41.52
>>812
既存システムで扱われている「経路」というものを
「データで扱った方が良い」と判断した根拠が示されていないんだから、
賛同者が居ないのは当たり前。

データに分離しない方が楽なときはまたリファクタリング（）するのか？
0825KAC
垢版 |
2018/10/23(火) 02:50:52.88
>>824
お前は、自分の書いたことすら理解できてないだろ。
1つのレス内ですら筋が通ってない。

真ん中頃と最後の発言比べてみ？
0827仕様書無しさん
垢版 |
2018/10/23(火) 08:20:45.42
誰も同調してくれないｗｗｗｗ
0828仕様書無しさん
垢版 |
2018/10/23(火) 08:47:50.77
こんなに必死になっても、誰も同意してくれないってことは
自分に間違いがあるってことだってことに気が付かないんだろうな

人の意見に耳をかさず、自分の意見は主張し続ける
パヨク病だな完全に
0829仕様書無しさん
垢版 |
2018/10/23(火) 14:55:09.75
>>828
こんなところで自己紹介しなくていいから
0830仕様書無しさん
垢版 |
2018/10/23(火) 17:14:02.28
>>820の言いたいことがわからん
方針決めずにダラダラ書いていくのがリファクタリングってこと？
0832KAC
垢版 |
2018/10/23(火) 18:38:36.36
設計もせずにいつもグダグダになるから
リファクタリングが必要とか言い出すんだろう
0833仕様書無しさん
垢版 |
2018/10/23(火) 19:56:21.86
>>830
> 方針決めずにダラダラ書いていくのがリファクタリングってこと？

リファクタリングの利用の場面はいくつかあって、
その一つが、テストファーストであるという話

先にテストを書いて、そのテストに通る最低限のコードを書く
（ここまではリファクタリングじゃないぞ）

そしてテストに通る状態を維持したまま、質の高いコードに変える
これがリファクタリングの利用例の一つ
0834仕様書無しさん
垢版 |
2018/10/23(火) 20:24:42.81
>>833
なんではじめから質の高いコードを書かないの？
0835仕様書無しさん
垢版 |
2018/10/23(火) 20:42:01.45
時間効率悪くても
最初は動くの確かめて安心したいから
0836仕様書無しさん
垢版 |
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行なので十分な品質だろう
もしもっとパターン数が追加になれば、パターンごとに別関数にするだろうけど
まだそこまでやる段階じゃないな。今の段階でこれをやると逆に関数に分けすぎで見通しが悪くなる
0837KAC
垢版 |
2018/10/24(水) 00:57:51.29
>>836
設計しろよ。。。
スケーラビリティーの考慮なんて基本中の基本。
0840仕様書無しさん
垢版 |
2018/10/24(水) 04:04:07.52
ソースコードが仮に1万行だとすると、
1関数あたり平均20行として500関数ぐらいかな？

今作ってるのを見てみたら2000行程度で
120関数だから大体計算あってる

何が言いたいかって言うと、1万行で500関数ぐらいは
設計時点で関数名出してくださいよっていったら
不可能と言うだろうってこと。俺もそう思うｗ
0841KAC
垢版 |
2018/10/24(水) 05:50:45.06
>>839
設計もせずに書き始めるから書き直す羽目になるんだろ。
コスト意識ないバカはこれだから・・・
0842仕様書無しさん
垢版 |
2018/10/24(水) 06:07:24.09
>>841
設計っていうのは規模で変わるんだよ
一階建ての家と二階建ての家の設計が違うように
設計は変えないといけないの

お前MS-DOSの時代にWindowsの設計をする馬鹿じゃないだろうな？ｗ
0843仕様書無しさん
垢版 |
2018/10/24(水) 06:14:01.22
ガチガチに設計してしまったら、変更に弱くなるからな
作り直しが必要になるのは、やりすぎた設計が原因だよ
必要最小限の実装にしておけば、そこだけ修正すればいい
0844仕様書無しさん
垢版 |
2018/10/24(水) 06:23:03.42
全く設計しないみたいな論調はどこからでてきた？そして何故その前提を受け入れるんだ？
リファクタリングは必須だがだからといって設計をしないわけじゃない
どんなに注意深く設計しても多人数で時間をかけてコードを蓄積したらコードは劣化するからリファクタリングが必要なんだ
はじめから汚く書いてもいい免罪符にはならん

テストドリブンでもすべてを厳密に動く汚いコードから始めるメリットはない
普通はできるだけキレイで動くコードから始める
0845仕様書無しさん
垢版 |
2018/10/24(水) 06:25:31.23
設計を変更するって言ってる時点で、
最初に設計してるの当たり前ですわｗ

客からなにを言われても、修正対応は受け付けない！って
突っぱねるなら話は別だけどｗｗｗ
0846仕様書無しさん
垢版 |
2018/10/24(水) 06:27:07.27
とりあえず、1万行のソースコードから
500個の関数名を始めに設計（？）できるもんなら
やってみなと

あーだこーだと机上の空論で手を動かさず
設計に何ヶ月もかかったりしてなｗｗｗ
0847KAC
垢版 |
2018/10/24(水) 07:04:48.93
>>844
リファクタリング必須とか言ってる時点で設計とは何かを理解していない
0848仕様書無しさん
垢版 |
2018/10/24(水) 07:05:40.42
詳細設計書く力があったら普通にできるんじゃないか
やることって大体決まってるだろ
0849仕様書無しさん
垢版 |
2018/10/24(水) 07:06:14.45
>>847
設計と内部構造に何の関係があるの？

設計をしていれば、内部構造も決まるってこと？
0850仕様書無しさん
垢版 |
2018/10/24(水) 07:07:50.29
あ、KACが言ってることが破綻してきたｗ

どう答える気だろうｗｗｗ
0851仕様書無しさん
垢版 |
2018/10/24(水) 09:18:25.63
きむまさダメだろ荒らしたら
0852KAC
垢版 |
2018/10/24(水) 11:39:54.06
>>850
なにが破綻してるというのか。

内容が理解できないなら無理して煽らなくていいぞ？
0853仕様書無しさん
垢版 |
2018/10/24(水) 15:33:30.94
破綻してるな。

リファクタリングは内部構造（実装）の問題点を修正するものなんだから
設計していればリファクタリングが不要になるというのなら、
設計時点で、内部構造（実装）まで決まっていないといけない
0854仕様書無しさん
垢版 |
2018/10/24(水) 15:36:21.03
しかも、最初の時点で最終的な設計をしなければいけない
バージョンアップしていくという当たり前のことできない
0855仕様書無しさん
垢版 |
2018/10/24(水) 15:46:02.32
バージョンアップしてもリファクタリング不要にするってことは
初期バージョンの時点で最終バージョン用のコードを書くってことですかねぇｗ
最終バージョンの機能なんて決まってんの？
そもそも最終バージョンなんてものが存在するのか知りませんが
0856仕様書無しさん
垢版 |
2018/10/24(水) 15:59:42.63
最初のうちから完璧なものを出せって考え方だと
いつまでたってもリリースできないんやで
0857KAC
垢版 |
2018/10/24(水) 18:25:15.77
なるほど。
お前が設計がどういうものか全く理解していない事はよく分かった。
0858仕様書無しさん
垢版 |
2018/10/24(水) 18:38:41.80
昔はこの手の人を小ばかにした韜晦でいいようにつつきまわされたもんだ
今は死ねとしか思わん
0859仕様書無しさん
垢版 |
2018/10/24(水) 18:57:06.39
>>857
みんなお前がわかってないと思ってるよ
なぜならお前は設計がどんなものかを何一つ言ってないから
0860KAC
垢版 |
2018/10/24(水) 19:30:24.36
>>859
おまえ、周りの人達も「設計を理解していない」とか思ってる？

理解してて当たり前だって事すら知らないんだな。
0861仕様書無しさん
垢版 |
2018/10/24(水) 19:50:52.27
IT技術者辞典

理解＝個人的解釈
当たり前＝根拠のない思い込み
0862仕様書無しさん
垢版 |
2018/10/24(水) 20:19:07.98
IT技術者辞典には設計すら載ってないってこと？
0863仕様書無しさん
垢版 |
2018/10/24(水) 20:23:06.43
では設計を理解してるKACに問おう

設計とはなんぞや?

簡潔に述べよ
0864836
垢版 |
2018/10/24(水) 20:35:43.97
昨日の50行→80行になりそうだった関数。言ってなかったけど
あれからリファクタリングして35行に減らした。

で、そのあともう少し見直して、パターンごとで関数に分けるのではなく
中でやってる処理を複数の処理に分けられることに気づいた（適切な名前をつけられた）
そこで分割したら、メインの関数が25行に減って、そこから呼び出す4つの関数
（それぞれ15行、20行、5行、10行）に分割できた。

テストもそれぞれの関数ごとに行えるようになったので、よりシンプルになった

最初からこうしろと？無理だよ。一番最初は30行程度だったんだぜ。
初期バージョン時点の複雑になってない状態で分割とかしてたら
いつまでたってもリリースできない。
0866仕様書無しさん
垢版 |
2018/10/24(水) 20:54:53.77
>>865
？

時間をかけて35行に減らしたものを、さらに、25+15+5+10 = 合計55行に
増やして "改善された" って言ってるんだけど？
行数で "あんたが望んでいるようなこと" は何も語ってないよね？


このようにリファクタリングで時間がかかるのに
将来のバージョンアップでどうなかもわからないのに
最初のうちに将来のバージョンアップを想定してやるのは時間の無駄

だけど1関数80行を放置したら、さらに時間がかかる
このタイミングでリファクタリングするのはいいタイミングよ。

開発コストは行数とは無関係。だけど多くの場合複雑度とは関係ある
複雑だとテストの時間も長くなるし、バグも増える

コストを掛けて1関数の行数を減らす＝複雑度を減らすことは
将来のコストを減らすことにつながる
ただし1関数の行数は減っても全体の行数は増えることもある。
もちろんそれで良い。重要なのは複雑度

だから行数と開発コストを関連付けるなんて古いタイプの人間の考えとは全く違う
0867仕様書無しさん
垢版 |
2018/10/24(水) 21:09:35.62
あと設計で関数の名前を出すといってるのかしらんが、
実装（何行かかるか、どれくらい複雑か）がわからんうちに
どれくらいの数の関数が必要なのか、わかるはずがない

5行以下の関数を大量に作ったら、それはそれで分かりづらいし
そもそも関数に分割するべきかを行数で判断してはいけない
（ただし行数と複雑度に相関関係はある。俺は行数ではなく複雑度で判断して分割している）
0868仕様書無しさん
垢版 |
2018/10/24(水) 21:22:49.00
?
0869仕様書無しさん
垢版 |
2018/10/24(水) 21:35:22.43
現実でも誰にも支持されてないんだろうな
これだけ利害関係もない多くの人がいるとこでも支持されない
無様w

誰でも極端なやつは相手にされないんだよ
適材適所
なんでもかんでも自分が読んだ本はすべての人が実践しなければならないって思い込んじゃうんだろう
精神病患者だな完全に
0870仕様書無しさん
垢版 |
2018/10/24(水) 21:45:50.78
40年ぐらい前なら支持されてたかもしれないなー
当時はリファクタリングなんて用語はなかっただろうし
自動テストってのもなかっただろう
0871仕様書無しさん
垢版 |
2018/10/24(水) 21:52:28.05
まあ待て支持を得られているかどうかを判断するのは
KACが設計とはなにかを語ってからにしようじゃないか
今は何も言ってないから支持を集められないだけ
0872仕様書無しさん
垢版 |
2018/10/24(水) 21:58:06.90
IT技術者辞典には設計すら載ってないってこと？
0873仕様書無しさん
垢版 |
2018/10/24(水) 21:59:48.70
KACが考える設計がそれ（世間一般の常識）とずれてるって話
0875仕様書無しさん
垢版 |
2018/10/24(水) 22:29:48.00
>>870
40年前だと、ほんとに露骨なほど、
腕の良いプログラマとそうでないプログラマの作ったソースコードの差が酷かったからなw
0876仕様書無しさん
垢版 |
2018/10/24(水) 22:30:25.03
>>873
たとえば？
0877仕様書無しさん
垢版 |
2018/10/24(水) 22:35:05.33
根本的に海外の人の設計思想って、日本で言うところの内製環境が絶対的前提条件だしなあ
ぶん投げた先の派遣の馬鹿に設計なんてやらせないし
0878仕様書無しさん
垢版 |
2018/10/24(水) 22:35:55.62
>>876
本人が設計を言わないで、
オラの考える設計と違うだと言ってるから
KACが間違ってるんだろうって話だよ
0880仕様書無しさん
垢版 |
2018/10/24(水) 22:39:09.95
>>877
海外と同じように、派遣がやってる設計を全部
自分の所で引き取って、自分で設計すれば良いのでは？

本当の理由は、派遣が～じゃなくて
あんたの会社に、開発リソースがないってことでしょう？
0881仕様書無しさん
垢版 |
2018/10/24(水) 22:43:09.39
>>878
設計なんて皆普通に理解できるけど
貴方には無理って事？
0882仕様書無しさん
垢版 |
2018/10/24(水) 22:43:35.01
>>880
は？
プログラマの立場。日本と海外とどういうスタンスの差があるか調べたら？
その違いから、根本的に海外の開発設計思想を日本で語ろうというのが間違いなんだよ
0883仕様書無しさん
垢版 |
2018/10/24(水) 22:46:22.00
日本の場合プログラマは大半が派遣・少し外部、部内プログラマは極小
海外の場合プログラマは大半が部内プログラマ、少し派遣・外部
0884仕様書無しさん
垢版 |
2018/10/24(水) 22:48:25.40
日本で開発設計手法を語るなら、日本の開発環境を大前提とした開発設計手法を独自に考えないと意味がないね
たとえガラパゴスと言われようとも
それが嫌なら、海外とプログラマの立ち位置を同じようにしないと話しにならん
0885仕様書無しさん
垢版 |
2018/10/24(水) 23:03:12.36
>>882
いやいや、派遣のせいにするのではなくて、
そういう開発してるのはあんたの会社でしょうって話。
0887仕様書無しさん
垢版 |
2018/10/24(水) 23:15:09.93
> 日本で開発設計手法を語るなら、日本の開発環境を大前提とした開発設計手法を独自に考えないと意味がないね

念の為に言っておくけど、海外の開発設計手法は
全て日本には当てはまらないという話にしたらだめだよ？
海外の開発設計手法は全く使ってないと言うのなら別だけど。
0888仕様書無しさん
垢版 |
2018/10/25(木) 10:18:39.16
結局リファクタリングって何してるの？
関数を小分けにして作業時間の水増しを図るって事？
0889仕様書無しさん
垢版 |
2018/10/25(木) 10:33:02.50
ソースコードの複雑性を解消して
メンテナンス性を上げてる
0890仕様書無しさん
垢版 |
2018/10/25(木) 10:34:13.41
まああれだな。

整理整頓するのには時間がかかる
だから散らかっている方が、時間の節約になる
と短絡的に考えてる人には理解できないｗ
0891KAC
垢版 |
2018/10/25(木) 10:36:27.26
そもそも散らかさない
という考えには至らないんだよな
0892仕様書無しさん
垢版 |
2018/10/25(木) 10:39:06.57
>>891
面白くないよ

バージョンアップすると、
必ず無駄な部分、効率が悪い部分が出てくるんだから

それよりキミ、自分の宿題をなかったコトにしないように

863 名前：仕様書無しさん[sage] 投稿日：2018/10/24(水) 20:23:06.43
では設計を理解してるKACに問おう

設計とはなんぞや?

簡潔に述べよ
0893仕様書無しさん
垢版 |
2018/10/25(木) 10:59:58.22
>>890
なるほど
整理整頓・ゴミ掃除が下手な人の言い訳なんだね
0894仕様書無しさん
垢版 |
2018/10/25(木) 11:09:17.07
>>893
そうそう。片付けるのには時間がかかるからと言ってやらない
結果余計に時間がかかる。
それを防ぐのがリファクタリングなわけさ。
こまめにリファクタリングしましょう
0895仕様書無しさん
垢版 |
2018/10/25(木) 11:26:05.54
>>894
でも整理整頓は一般常識の範囲なんで普通は仕事とは言わないよね？
その作業を仕事といってお金取るのはどうなんだろう
整理整頓をリファクタリングっていう言葉に置き換えて仰々しくみせてるだけな気がする
0896仕様書無しさん
垢版 |
2018/10/25(木) 11:27:18.07
1剣件あたり10nsでやらないといけないとこを勝手に無学なやつにリファクタされる悪夢
0897仕様書無しさん
垢版 |
2018/10/25(木) 11:29:37.49
>>895
> でも整理整頓は一般常識の範囲なんで普通は仕事とは言わないよね？

それは「整理整頓」の話ですね。
リファクタリングの話じゃないです。
0898仕様書無しさん
垢版 |
2018/10/25(木) 11:30:29.77
>>896
リファクタリングしても10nsで実行できていれば問題ないのでは？？？
0899仕様書無しさん
垢版 |
2018/10/25(木) 11:37:15.50
>>897
え？リファクタリングってコードを整理する事でしょ
処理の共通化や細分化ってコードの整理じゃないの？
整理整頓と同義だと思うんだけど
0900仕様書無しさん
垢版 |
2018/10/25(木) 11:39:49.65
1. 作業をしていると散らかるのは避けられない
2. だから整理整頓やリファクタリングをしないといけない
3. 整理整頓もリファクタリングも作業効率が上がるという効果がある
4. 整理整頓は仕事ではないが、リファクタリングは仕事である
0902仕様書無しさん
垢版 |
2018/10/25(木) 11:41:25.40
>>899
はい？ 整理整頓は仕事じゃないですが、
リファクタリングは仕事だって言っただけですよ？

そりゃどちらも効果はあるでしょう？

効果はありますが、整理整頓は仕事とは言わないといわれたから
リファクタリングは仕事かつ効果があるって話をしてるんですよ
0903仕様書無しさん
垢版 |
2018/10/25(木) 11:42:08.37
>>901
そりゃ、違うものなんだから違う部分ぐらいあるでしょう

頭大丈夫なのか？

効果は一緒。
仕事かどうかは違う
0904仕様書無しさん
垢版 |
2018/10/25(木) 11:42:20.24
>>900の話で、整理整頓が仕事から除外された理由がわからんわｗｗｗｗｗｗｗｗ

やっぱりキチガイだｗこいつ
0905仕様書無しさん
垢版 |
2018/10/25(木) 11:43:31.55
>>904
> でも整理整頓は一般常識の範囲なんで普通は仕事とは言わないよね？

整理整頓は仕事なんですか？仕事じゃないんですか？
仕事なんですよね？
0906仕様書無しさん
垢版 |
2018/10/25(木) 11:44:14.49
作業をしていると散らかるのは避けられないので、整理整頓やリファクタを「しなければならない」
整理整頓やリファクタは「効果がある」

だけど、整理整頓は仕事では「ない」。リファクタは仕事で「ある」
なにが起こったんだ？？？ｗｗｗｗ
0907仕様書無しさん
垢版 |
2018/10/25(木) 11:44:47.56
普通に考えれば、会社でやる整理整頓は仕事の一環ですよ
もちろんリファクタリングも仕事の一環

おかしいのは>>895
0908仕様書無しさん
垢版 |
2018/10/25(木) 11:45:50.09
>>906


よし>>895を問い詰めようぜ。
この馬鹿が、整理整頓は仕事じゃないって言ったんだ
0909仕様書無しさん
垢版 |
2018/10/25(木) 11:46:18.41
なんだよｗ 結局、整理整頓もリファクタリングも
仕事なんじゃねーかｗ
0910906
垢版 |
2018/10/25(木) 11:47:06.61
>>907-908
おかしいのはおめーだよｗ
0911仕様書無しさん
垢版 |
2018/10/25(木) 11:47:26.67
（リファクタリングの）アンチって行き当たりばったりで
しゃべてるから、すぐ矛盾起すよねｗ
0912仕様書無しさん
垢版 |
2018/10/25(木) 11:48:29.32
>作業をしていると散らかるのは避けられないので、整理整頓やリファクタを「しなければならない」

この「作業をしていると散らかるのは避けられないので、整理整頓やリファクタを「しなければならない」」から、お前以外誰も同意してないけどな。
0913仕様書無しさん
垢版 |
2018/10/25(木) 11:48:56.72
>>910
整理整頓は仕事じゃないって言っちゃった本人ですかｗ
社会人失格ですよ
0915仕様書無しさん
垢版 |
2018/10/25(木) 11:52:58.38
コードのリファクタより重要なことは
　ユーザーのシステム仕様に対する記憶や理解、把握が劣化しないようにすること
これをダメポシステムが教えた。

ユーザーのシステム仕様に対する記憶や理解、把握が劣化しなければ、システムの再開発は容易い。
0917仕様書無しさん
垢版 |
2018/10/25(木) 11:56:36.73
十分な時間が与えられ、誰も間違いをおかさず、仕様、設計が変更にならず
バージョンアップ（段階リリース）することもなく
最初から最終バージョンをいきなりリリースして
その後バグ修正以外のことをしないなら
リファクタリングなんか必要ない
0919仕様書無しさん
垢版 |
2018/10/25(木) 11:57:20.48
>>915の対応作として最近出てきてるのが、担当者交代毎のリプレイス法なんだがトップが理解してくれない悲しい現実
0920仕様書無しさん
垢版 |
2018/10/25(木) 12:00:01.96
895だけど整理整頓を仕事の範囲なんて書いてないけど？
一般常識でいう整理整頓って普通は仕事前とか終わりなんかに自主的にするもので仕事外の作業だと思うんだけど…
そもそもコード書いたときに日常的にコードの整理を最後に加えておけばいいだけなんじゃないの？
なんでリファクタリングっていう整理だけの工程が仕事になってるの？
0922仕様書無しさん
垢版 |
2018/10/25(木) 12:05:41.16
>>921
あ！なるほど…いいよねフリーダム
束縛されない人生って素敵やん
0923仕様書無しさん
垢版 |
2018/10/25(木) 12:08:40.67
別名：無職

司法「仕事は？」
リファクタリアン「社畜どもがｗｗｗ」
司法「無職ね」
0924仕様書無しさん
垢版 |
2018/10/25(木) 12:29:26.94
>>922
え？なに極端なこと言ってんの？

仕事なんだから仕事時間内にやれって言ってるだけなのに

そんなんだから社畜なんだよｗ
0926仕様書無しさん
垢版 |
2018/10/25(木) 23:29:22.79
かしむら役立たず
0929仕様書無しさん
垢版 |
2018/10/26(金) 22:29:21.15
おまえを支持するくらいだったら無駄にリファクタリングするわ
0932仕様書無しさん
垢版 |
2018/10/27(土) 09:00:10.47
無駄なリファクタリングもあれば必要なリファクタリングもあるよ
当たり前だろ
0933仕様書無しさん
垢版 |
2018/10/27(土) 13:15:05.68
整理整頓って言った方が心理的抵抗感が減ってGoサインが出やすくなることに気付いた
0934仕様書無しさん
垢版 |
2018/10/27(土) 13:51:57.30
でもまあGoサインとかもらうもんじゃないけどな
修正作業に含まれるものなんだから
0935仕様書無しさん
垢版 |
2018/10/27(土) 14:51:05.56
コードの複雑さを数値化して
複雑すぎるモジュールは作り直すんだよ
もちろんテストは全部やり直す
0937仕様書無しさん
垢版 |
2018/10/28(日) 13:47:55.32
>>935
正しいけれど
真の馬鹿は閾値を馬鹿みたいに上昇させて
結局リファクタリングなんてさせない。
0938仕様書無しさん
垢版 |
2018/10/28(日) 19:36:53.15
複雑かどうかより、追加変更のしやすい形に直すんだぞ。
変更しやすければ、より複雑でも構わないんだ。
仕組みの複雑さより、見た目の複雑さの方が問題なのさ。
0939仕様書無しさん
垢版 |
2018/10/28(日) 21:01:09.00
部下が勝手にリファクタやってたら懲戒にするわマジで
0940仕様書無しさん
垢版 |
2018/10/28(日) 21:31:17.25
>>938
「複雑」という言葉の意味を理解してないように見える

コードが複雑という話。重要なのは「コード」
読めない人がいる というのは「人の話」

この２つをごっちゃにしてはいけない

変更しやすいが複雑なコードなんてものはないだろう

>>939
リファクタリングは修正作業の中に含まれるものなんだが？
勝手に修正はしませんよ。客などからの要求があって作業します。
修正しろと言われたら、案に必要ならリファクタリングすることも含まれるってだけです。
0942仕様書無しさん
垢版 |
2018/10/28(日) 22:06:04.61
>>940
>変更しやすいが複雑なコードなんてものはないだろう

そんなことないよ
0943仕様書無しさん
垢版 |
2018/10/28(日) 22:09:02.77
複雑と言うのは、既存機能モジュールに置き換えしたら結果全体的には複雑化になるって話だぞ。
複雑さと読みにくさは比例しない。
複数の分岐処理と論理演算駆使した１分岐処理と、どっちが複雑？
でその論理演算を１つの関数にまとめたら、最初のものと比べてどっちが複雑？
0944仕様書無しさん
垢版 |
2018/10/29(月) 18:59:02.42
規模の大きい企業システムが混乱する原因はほぼ100%データベースだから
アプリケーションコードだけリファクタリングしてもあまり意味がないと思う
0946仕様書無しさん
垢版 |
2018/10/29(月) 19:20:41.34
>>945
DBリファクタリングはノウハウがあっても業務系では絶対に許可が出ないから需要がない
0947仕様書無しさん
垢版 |
2018/10/29(月) 19:24:20.10
> 業務系では絶対に許可が出ないから

それはノウハウがないってことでは？
許可が出ないのにノウハウなんて貯まるわけ無いでしょｗ

ってか、仕様変更があったらどうすんの？
DB変えられないので、仕様変更は受け付けませんって
客の要求を突っぱねるの？
0948仕様書無しさん
垢版 |
2018/10/29(月) 19:27:14.60
仕様変更は(多大な労力が必要だけど)許可が出る
そこをはき違えちゃいかん
0949仕様書無しさん
垢版 |
2018/10/29(月) 19:32:27.86
だから仕様変更でリファクタリング（が必要な場合）の許可がでるでしょ

仕様変更などで（客などから要求があって）変更する許可がでたときに
作業工程の一つとしていれるのがリファクタリングだって何度も言われてるじゃん

なんでまたいつものように、勝手にやるのがリファクタリングだって思いこんでるのさ？
0950仕様書無しさん
垢版 |
2018/10/29(月) 19:35:10.73
余計なことするなって言われて終わり
最小限の変更は許可するがそれ以外は認めない
これ常識ね
0951仕様書無しさん
垢版 |
2018/10/29(月) 19:40:07.80
リファクタリングは余計なことじゃないですよｗ
0952仕様書無しさん
垢版 |
2018/10/29(月) 19:42:14.06
そう思ってるのは末端だけ
決定権持ってる人は揃って無駄な工程と言う
0953仕様書無しさん
垢版 |
2018/10/29(月) 19:44:29.09
でも、無駄な工程と言ってるあんたは
決定権持ってないじゃんｗ
0954仕様書無しさん
垢版 |
2018/10/29(月) 19:44:55.74
リファクタリングは余計なことじゃないのかもしれんが
おまえらがやってるのはゴミを別のゴミに変えとるだけやからな
そもそもリファクタリングちゃうし
0955仕様書無しさん
垢版 |
2018/10/29(月) 19:46:16.61
どうしておまえらごとき一介のコーダーがリファクタリングできると勘違いしてしまったのか
闇は深いでこれ
0957仕様書無しさん
垢版 |
2018/10/29(月) 19:46:58.68
コーダーはコードしかみてないからな
変えた後の単体から受け入れまでのテスト工数
デグレのリスク

なのに後から参加して詳細知らないPGほど積極的で
最悪前よりさらにぐちゃぐちゃになる
0958仕様書無しさん
垢版 |
2018/10/29(月) 19:47:43.87
そもそも問題ないとこさわるな
一生経っても終わらんなる
0959仕様書無しさん
垢版 |
2018/10/29(月) 19:49:02.28
つまり、問題あるならリファクタリングしてよし！
0960仕様書無しさん
垢版 |
2018/10/29(月) 19:49:27.03
そこの関連のテストがナンボあるかわかってないやつに限って触ろうとする狂気
0961仕様書無しさん
垢版 |
2018/10/29(月) 19:49:48.89
コードの問題じゃないぞ
動きに問題があるときだけだぞ
0965仕様書無しさん
垢版 |
2018/10/29(月) 19:51:34.32
>>962
コードを修正するときにより複雑にしていまい
不具合が発生する。大問題ですね
0966仕様書無しさん
垢版 |
2018/10/29(月) 19:52:22.32
>>964
せやな。上であるお前（笑）が
無駄と言ってるかどうかは関係ないなｗ
0967仕様書無しさん
垢版 |
2018/10/29(月) 19:53:21.89
>>960
> そこの関連のテストがナンボあるかわかってないやつに限って触ろうとする狂気

でも、客から修正しろって言われたんですよ？
客にテストがなんぼあるかわからんから、修正は受け付けないって突っぱねるの？
0968仕様書無しさん
垢版 |
2018/10/29(月) 19:53:39.83
リファクタリングの許可が出ない現実は変わらない
これだけは確かだ
0970仕様書無しさん
垢版 |
2018/10/29(月) 19:55:08.86
>>967
客の命令は仕方がないので直して全部テストする
余計な修正はしちゃダメ
0971仕様書無しさん
垢版 |
2018/10/29(月) 19:56:22.43
>>969
出ないよ
データベースの話だぞ
DB管理者が抱え込んでるからアプリ開発者などには手出しできん
0972仕様書無しさん
垢版 |
2018/10/29(月) 19:57:22.53
大きいプロジェクトはな、詳細なんて誰もわかんねーんだよ
だから動くと自信を持って開発することなんかできやしない

動くかも？動くと良いな。で開発してあとはひたすらテストして
あ、動いてる？良かったよかったってのを増やすしか無いんだよ

その程度のプロとは思えない仕事をするのが現実なんだから
リファクタリングして動くと自信を持てるコードになんかする必要ないの
動いてるといいなーレベルで十分。
0974仕様書無しさん
垢版 |
2018/10/29(月) 19:59:12.01
> DB管理者が抱え込んでるからアプリ開発者などには手出しできん

DB管理者がリファクタリングするんでしょ？
動きを変えないのがリファクタリングなんだから
アプリ開発者にとっては関係ないこと
0975仕様書無しさん
垢版 |
2018/10/29(月) 19:59:20.91
新人が結合テスト中にコードリファクタして文字とか定数に変えまくってて
全体がめっちゃ変更履歴ついてて肝が冷えた

でも問題おこってないからわりかし大丈夫なのかもしれない
0976仕様書無しさん
垢版 |
2018/10/29(月) 20:03:03.59
やっぱ>>945（データベース・リファクタリング）読んだほうが良いぜ

お前（ら？）、どうせ無停止（もしくは短時間の停止）で
（客からの支持に伴う仕様変更で必須な）データベースの構造変更とかできないだろ？

データベースとアプリを同時に変更しなきゃいけないから
どうしても停止時間が必要ですとか思ってそう

（データベースの）リファクタリングは動きを変えないものなんだから
データベースのみ変更できるんだよ。
0977仕様書無しさん
垢版 |
2018/10/29(月) 20:04:37.93
>>975
リファクタリングは動きを変えないものだからねー

動きを変えるものの変更は大変だけど
理論上動きが変わらないと確立されている
変更を行うだけだから問題は起きにくいんだよ
0978仕様書無しさん
垢版 |
2018/10/29(月) 20:52:54.85
>>976
んなあほな…
止められるときは止めたほうが安全だろ

変更中にシステムが正常に稼働し続けるテストとか
手続きを間違いなく行うための準備とか
その変更プロセス自体のリスクと重さ考えたら
よっぽどのことじゃなきゃやれん
0979仕様書無しさん
垢版 |
2018/10/29(月) 20:54:12.47
> 止められるときは止めたほうが安全だろ
止められない時の話をしてる
0980仕様書無しさん
垢版 |
2018/10/29(月) 20:56:24.73
> 変更中にシステムが正常に稼働し続けるテストとか

そんなんじゃAmazonのように24時間稼働しつづけてかつ
変更もされていくシステムなんか到底できそうもありませんね
0984仕様書無しさん
垢版 |
2018/10/29(月) 22:03:49.78
リファクタの手続きとしてはわかる
でもこれってほんとにシステムを停止させないための話なの？

切り替えるのはサブ構成作ってマシンごとごっそりやっちゃうみたいな感じじゃないの
0986仕様書無しさん
垢版 |
2018/10/29(月) 22:26:49.17
本気で無停止にするならイベントソースにするんでね
0987仕様書無しさん
垢版 |
2018/10/30(火) 01:28:43.31
>>984
アプリとは違ってデータベースはサブ構成作ってえいやって
置き換えることはできないんだよ

すでに大量のデータが溜まってるんだから
データの変換作業というものが必要になる

そういうのをどうやるかが「データベースリファクタリング」には
書いてあるんだが絶版
0989仕様書無しさん
垢版 |
2018/10/30(火) 09:05:52.95
>>988
意味がわからん。データベースはサーバーを分散したとしても
えいやって置き換えることはできないって話をしてる
0990仕様書無しさん
垢版 |
2018/10/30(火) 09:41:24.67
えいやって置き換えなくていい様に分散化だろうに。
0991仕様書無しさん
垢版 |
2018/10/30(火) 09:55:25.28
>>990
データベースを分散化することで、何がどう解決するのか言ってみ
お前、目的を忘れてるみたいだからさ
0992仕様書無しさん
垢版 |
2018/10/30(火) 11:05:26.41
あ？
まさか、単にバラバラにデータばら撒いてるだけだと思ってる？
主な目的は、相互補完だぞ。
0993仕様書無しさん
垢版 |
2018/10/30(火) 11:30:09.11
そういうのは良いから、何（どういう問題）がどう解決するのか書いて
どうせわかってないから誤魔化かしてるんだろうけどｗ
0994仕様書無しさん
垢版 |
2018/10/30(火) 11:30:38.12
ちなみにデータベースのリファクタリングの話をしてるんだからな
0995仕様書無しさん
垢版 |
2018/10/30(火) 12:19:25.73
リファクタリングするよりクリアなスキーマ設計のデータベースを立ててデータ転送する方が楽
0996仕様書無しさん
垢版 |
2018/10/30(火) 13:09:45.94
はいはい。それを無停止でやる方法が上で書いた
「データベースリファクタリング」に書いてあるんですってば
何周も回ってやっと追いついた感じだなｗ
0998仕様書無しさん
垢版 |
2018/10/30(火) 19:14:37.28
技術の問題じゃないんです。
無能の問題なんです。
0999仕様書無しさん
垢版 |
2018/10/30(火) 19:16:07.13
だめな会社は、優れたこと（リファクタリング）でも
理解できないので、なんでもだめといいます。

ゲーム？よくわからないからだめ
漫画？よくわからないからだめ
インターネット？よくわからないからだめ

これと一緒です。

とりあえず否定からはいって
会社をダメにする奴らです
10011001
垢版 |
Over 1000Thread
このスレッドは１０００を超えました。
新しいスレッドを立ててください。
life time: 164日 1時間 10分 26秒
10021002
垢版 |
Over 1000Thread
5ちゃんねるの運営はプレミアム会員の皆さまに支えられています。
運営にご協力お願いいたします。


───────────────────
《プレミアム会員の主な特典》
★ 5ちゃんねる専用ブラウザからの広告除去
★ 5ちゃんねるの過去ログを取得
★ 書き込み規制の緩和
───────────────────

会員登録には個人情報は一切必要ありません。
月300円から匿名でご購入いただけます。

▼ プレミアム会員登録はこちら ▼
https://premium.5ch.net/

▼ 浪人ログインはこちら ▼
https://login.5ch.net/login.php
レス数が1000を超えています。これ以上書き込みはできません。
ニューススポーツなんでも実況