ふらっと C#,C♯,C#(初心者用) Part132
■ このスレッドは過去ログ倉庫に格納されています
「どんなにくだらないC#プログラミングやVisual C#の使い方に関する質問でも誰かが優しくレスをしてくれるスレッド」です。
他のスレッドでは書き込めないような低レベルな質問、
質問者自身なんだか意味がよく分からない質問、
ググろうにもキーワードが分からないなど、勇気をもって書き込んでください。
内容に応じて他スレ・他板へ行くことを勧められることがあります。ご了承下さい。
なお、テンプレが読めない回答者は邪魔なので後述のC#相談室に移動して下さい。
C#に関係の無い話題や荒らしの相手や罵倒レスはやめてください
>>980を踏んだ人は新スレを建てて下さい。
>>980が無理な場合、話し合って新スレを建てる人を決めて下さい。
■前スレ
ふらっと C#,C♯,C#(初心者用) Part131
http://mevius.5ch.net/test/read.cgi/tech/1504861931/
■関連スレ
C#, C♯, C#相談室 Part94 [無断転載禁止]©2ch.net
http://mevius.5ch.net/test/read.cgi/tech/1492843013/
■コードを貼る場合は↓を使いましょう。
http://ideone.com/
https://dotnetfiddle.net/
■情報源
https://msdn.microsoft.com/en-us/library/gg145045.aspx
http://referencesource.microsoft.com/
VIPQ2_EXTDAT: checked:vvvvv:1000:512:----: EXT was configured >>189
あくまでお客とのやり取りではなく、コードは会社の資産という観点でリファクタリングするという考えですね
お客の要望で機能追加する前提のものなので、そこで保守するコストやバグによる信用低下からプログラムそのものの価値が下がるって概念になると思います
まぁ実際はリファクタリングするには大きすぎるので理想はあっても実行は中々できないと思いますが >>173
letとSelectManyの連鎖はクエリー式でないと辛すぎるですたい リファクタリングのやり方がおかしいんじゃないかな
リファクタリングでコードがシンプルになればその後の開発工数が激減する レガシーシステムに手をつける前に必ずリファクタリングするって常識でしょ
レガシーシステムは恐ろしいスパゲティの塊なのでそのまま手を出すとあっという間に破綻する
まずはリファクタリングで保守可能な状態を作らなければならない
最悪でも拡張する機能をテスト可能な状態にすること
顧客がバカでコミットできない場合でも知識を得るためにリファクタリングが最適
腐ったコードはどれだけ読み込んでも理解できない >>190
いや今まで設定ファイルから読んでたけど
ネットワークから取得するわ
一括ではなく個々のデータを使用するときに常に最新データを個別に取得するわ
ってなったら絶対無駄になるよね? >>192
それは改修時にする設計だよね
それは理解できる
でも、動いてるところをわざわざぶっ壊して作り直すって
お客に見積り通らないよね >>194
それで無駄になるケースってどういう場面でしょうか?
設定ファイルとコードが依存してなければ設定ファイルの取得部分の追加変更でリファクタリング自体は無駄にならないと思いますが
変更できないような設計なら確かに無駄になると思いますが・・・ >>196
設定ファイルを読み込む前提でリファクタリングしたなら
ネットワークからデータを個別に取得するようになるわけだから無駄だよね? 無駄になる可能性もあるけど無駄にならない可能性もある
汚いコードだった場合ほど無駄にならない 設定ファイルは起動時に1回一括で読み込むだけかも知れないね
でもネットワークからデータが必要になるたびに個別に最新を取得だから
ぶっちゃけ対応できないんじゃないかな? >>199
そう?
逆にこれが対応できるほど汎用性を上げたら明らかに無駄なコードだと思うよ ID:BTwHB29Waが何言ってるかわかるエスパーいる? >>203
簡単にいうと仕様変更がかかったらリファクタリングなんて意味ねーじゃんってこと >>204
仕様変更ってリファクタリングしててよかった〜って一番実感するときだろ
まあやったことない人にはわからない感覚だとは思う
リファクタリングに工数かかるのは事実だから
目の前のコストしか見えない人だってそりゃいるよね >>207
設定ファイル一括読み込みクラスをリファクタリングして
設定問い合わせインターフェースにする
設定ファイル一括読み込みクラスは設定読み込みインターフェースを実装する
設定読み込みネットワークになったわー読み取りは毎回取り直しだわ〜ってなったら
設定テーブルセレクトクラスを作る
設定テーブルセレクトクラスは設定読み込みインターフェースを実装する
DIの設定を変更して終わり
簡単だろ? >>208
誤字訂正
>設定ファイル一括読み込みクラスは設定読み込みインターフェースを実装する
設定問い合わせインターフェースを実装する
>設定テーブルセレクトクラスは設定読み込みインターフェースを実装する
設定問い合わせインターフェースを実装する 設定ファイル一括読み込みクラスは会社の資産とのことだけど
どこ行くの?
また、設定ファイルから読み込むこともあるかも知んないから残しとく?
別の会社に売ったら
「うちはいちいちネットワークなんて繋げなくていいよ」
って言うかもね
こっちもサポートし続ける?
捨てちゃう? >>195
業態によるんじゃないかな
客先の社内に入ってる常駐型とかweb開発では継続的インテグレーションが当たり前
納品して終わりのシステムなんて大手は少ないんじゃないかな? リファクタリングしてないと組み直しになる
ネットワークから取ってくるって機能に切り替えたいだけなのに
なぜか設定読み込み処理そのものやそれを呼び出してるところを一生懸命調べたり直さなきゃならない
本当にやりたいことはそんなことじゃないのに!
リファクタリングしてあればまさにネットワークから取ってくる処理を追加するだけで済む
既存の処理はそのまんま
やりたいことを過不足なくやるだけ
解放閉鎖原則ってやつだね >>212
継続案件でも納得してリファクタリングに金払う客居たら見てみたいわ
どうにもならなくなった糞コードを何とかする手段としてリファクタリングを使うケースは偶に見かけるけど >>212
京都市とシステムズが争ってんじゃん
11億円の案件らしいけど
次の仕事あると思う? >>213
浅はかだな
一部設定ファイルから
一部ネットワークから
って可能性もあるよ
改修仕様が決まってから出ないとリファクタリングもゴミだなって気づけよ >>211
必要な顧客と不要な顧客が居るなら取っておいたほうがいいね
インターフェースで綺麗に分離されてるから機能有効化無効化の管理も超簡単 てかマ板でやれよ
底辺チンカスコーダーの分際でうるさいわ >>218
ネットワーク状態によって分岐するかもしんねーぞw
どこまでインターフェースで対応できんだ?w >>217
それもリファクタリングしてあれば簡単にできるよ
単に設定ファイル読み込みクラスとネットワーク問い合わせクラスのミックスインを作るだけ
実装するのにまあ15分もかからないと思うね
リファクタリングしてなかったらこれは絶望的だよ >>214
MacはOSを途中で変えた
古いOSは改修に次ぐ改修で複雑に絡み合いリファクタリングすらできず
将来性がなかったから
windowsだって10までバージョンがあがったけど
そこまでのOSの変更費用は利用者が払ってる
将来性や利点があるならちゃんと説明して金をとるべき リファクタリングは組み直しだろ。
なんでやるのかっつーと、いろんな意味でその次を楽にするため。
次の改修だったり、次の案件に使いたかったり。
ただし、それは改修と併せてやってはいかん。
改修、つまり「今より良くするもの」「悪いものを直すもの」の正しい評価ができん。
会社でやるなら、金の出処は研究開発扱いとしてやるしか無い物だと思うわ。
機械で言うと「新素材の研究が一段落していい感じだったんで、それ使ってネジのコストカットしました」とか「量産安定してきたんで金型のランナーをちょっと樹脂ケチる感じに引き直しました」とかそんなレベルの話。
もし客にバレたなら、単なる不具合の改修でしかない。 >>220
それも簡単に対応できるね
ネットワークの状態を見てスイッチングするデコレーターを作るだけでしょ
リファクタリングしてなかったらあっという間に炎上する案件だよねこれって >>221
どのデータがネットワークからでどのデータが設定ファイルからかわからないのに?
自由に変えられるように組んであるの? >>223
だから次の仕様が明確にならないと意味ないって >>224
そもそもそれは俺が言ってから君がリファクタリングの方法を変えてるだけで
実際はもう対応できてないじゃん アウアウオー Sa63-qY8G
ワントンキン MMd3-pbEI
板違いで真っ赤とかNG推奨 >>225
仕様はあるんだろ?
それ見て作ればいいだけ
なんならそれも設定から読むようにしようか?
ルート設定情報を見てファイルかネットワークか選ぶ
ネットワークが死んでたら何回かリトライ
それでもダメならファイルから
ファイルがダメなら埋め込みデフォルト値
みたいな感じで
リファクタリングしてれば簡単にできるぞ >>193
不思議なもんで、理解はできるが、なんでこうなってんのかわかんねえ、って半日悩んで、スクラッチすっか、と最低限の条件からだんだん込み入った事書いてくと最終的に「これ最適解じゃん。すげぇ」ってなる事あるな。
Fortranの処理系のメンテしたほうがマシ、と言う結論に至った事がある。
>>226
次の仕様に合わせてやるのは、対応。
そうじゃなくて、「これ事故りそうだな、今手が空いてるから直しとくか」がリファクタリング。
フツーに仕事してたら納期次第で不味い手を打たざるを得ない事もあるしな。
32767回目で死ぬ事がわかってる、年に100回しか打たれないはずのコマンド、とか。
何故かそういう物に限って変な活用されたり、10年生きてたりする。 そもそも設定ファイルの読み込みルーチンだけど
すでに納めた客の対応はどうするの?
変えちゃうのはいいけどさ
動いて無いとまずいんちゃう?
インターフェースで対応できるの? お前ら、プログラムの仕様を変えたらリファクタリングじゃねーわw >>231
出しても出さなくても良いのがリファクタリング。 >>226
仕様が曖昧なときほどリファクタリングは有効だよ
リファクタリングしてないと全く身動き取れない
リファクタリングしてあれば暫定で進められる
確定したらごく僅かな工数で本実装に切り替え可能
仕様が確定するまでの待ち時間の金は誰が払うんだ?
あれがこれが決まってないから進められないなんて泣き言は顧客は聞いてくれないぞ? >>228
あ〜それは悪かった
専ブラだとスレタイが目に入らないんだよね
オブジェクト指向スレかなんかと勘違いしてたわ そんなパッケージ販売みたいの視野に入れるなら
○○様向け読み込み処理とか
すっげー勢いででき続けるけどな
すでに動いてる部分をぶっ壊すなんて最早正気ではないな 充分にモジュール化されてれば、可換な筈だからな。
それが仕様。
中身がどう変わろうが、口はUSBです。これも仕様。
口がどう変わろうが、テキストの電文でやりとりしてます。これも仕様。
どんなキーボード繋いでもHIDデバイスとして認識出来れば文字が打てます。そんなもん。
ボタンの改良でパソコン買い替えてたら世話無いだろ。 >>237
でもね
メモリだけ増やしたいなぁって思っても
SSDにしたいなぁって思っても
マザボごと全部交換必須
これが現実 >>236
パッケージ売りするなら、で全然パッケージ売りしてねえじゃんw
普通は帳票パックとか売るんじゃねえの?ソフト屋って。
コストで悩むのは理解できるが、だから研究開発費なんだよ。 >>238
全然現実じゃなくない…?
どんな商売してるの? バグだらけでリファクタリングできない頭の見本市がこちらです >>239
マジで
個別対応で金貰う商売だと思ってたぜ >>242
なんで個別対応で金取れるかわかってる?
個別対応部分が可換だからだろ?
単に経験浅すぎて仕組みがわかってないだけだと思いたいな。 >>246
いいけど
すべての個別対応を一つのソースにぶち込みつつ保守してくって無理だと思うぜ
扱うデータ自体が違うのにインターフェースもクソもねーし >>247
なんで一つのソースにしちゃうかな?
インターフェイスが統一されてれば、違うソース、違うリポジトリで充分でしょ?
扱うデータが違うのに云々ってのは、コンテナ形式のファイル見たら皆がどうやって回避してきたか理解できると思うわ。
DICOMまでガチの話でもなく、tiffファイルのフォーマット眺めるだけで充分わかる。 >>248
だからされねーだろ
データが違うんだから
始点と幅と高さでもっても
中点と幅と高さでもっても
四角は四角なんだよ >>249
内容に惑わされ過ぎだろ。
始点と幅と高さでできてる四角(四角A)と、中点と幅と高さで出来てる四角(四角B)であろうと、
ただのデータなんだから。
「四角」ってスーパークラス切り出して、「どちらかはわからんが、四角には変わりない。どっちかはそれぞれ読み手が考えるように。」ってデータ型を用意するのがリファクタリングだよ。
そしたら、図形ってデータ型が出来たり、面積のある図形ってインターフェイスが出来たりするだろうね。
typeof演算子の存在意義に疑問を持ってる類の人間なのかな。 インターフェイスについて突っ込まれそうだけど、シリアライズしてXMLにでもしときゃ、容量は食うだろうけど、C#でならだいたい何とかなる。 >>251
あめーんだよ
お前想像力がたんねーから
インターフェースでなんでも対応できる気がすんだよ
ちなみに中点、右幅、左幅、上幅、下幅指定は中点で回転するからその指定で回転角も付く
同じ四角だってすでに別もんの場合もある
こういうのたくさんあり過ぎて現実にはインターフェースなんてなんの役にもたたねーだろ インフラも依存性もないたかが四角形クラスでインターフェース否定した気になっちゃったの? >>254
じゃあ、さっきのネットワークからデータをとる話にしたってバカがインターフェースで対応できるとか言ってたけど
実際はデータ毎に取得日時も保存しておかないと
最新かどうかわからないよねw
アホだからこんなもんで対応できると思うんやで >>256
( ‘д‘⊂彡☆))Д´) パーン
>>257
( ‘д‘⊂彡☆))Д´) パーン
(*゚∀゚)なんで殴られたか言ってみろ! 伸びすぎだろ
おまえらってこういう話題になるとイキイキするのな
会社ではモテない頼りない無能社員のくせに >>253
だから、統一できるコンテナフォーマットな形式のデータ入れに突っ込んでしまって、
必要な奴が必要な分だけパースするんよね。
ホントに実務経験あるの?甘くない?
>>255
横からだけど「取得したデータ」は「取得した何か」を継承してたり、「取得した日付」を取得するインターフェイスがあれば充分でしょ。
無知でした、ごめんなさい。が言えるのもエンジニアとして大切だと思うが、いかがなもんかのう。 スレチ指摘されても理解できない頭のヤツにリファクタリングの必要性説いてどうすんの 最近独学で勉強始めたんだけど難しすぎる…
自分で考えたり工夫する能力がないんだろうな
自分がやりたい事と全く同じサンプルが無いと何も出来ない
みんなどうやって見につけたんだ?
やっぱアホには無理なのかな >>269
できることからやればいい
できないことをやろうとすると達成感が得られなくてやる気が無くなるループになる
自分の頭の中で必要な要件を切り分けられないものには手を出すな
サンプルは全く同じものがあるはずがないので近いものを探す。一つだけでなくいくつも探す >>269
c#ってかなり難しいと思うよ。
抽象的な概念がかなりある。
今は、ひたすら写経に励めよ。 c#がそれなりに使えるのには5年は掛かるね。
表面上使いこなせるのには他の言語を知ってりゃ3か月だ。 >>269
やりたい事を初めて見た他人が代わりにできるくらいのメモにまとめて、それをコードに落としていけば良いんじゃない?
最初は言語の機能全部使う必要無いんだから。
そのうち、これ毎回書くな…とか思ったら、そういう機能があるかどうか調べたら良い。大体ある。 >>269です
レスありがとう
最近仕事で使うことになって人生初のプログラミングを経験中なんだけど何もかも分からないから質問も出来ないし、しても分からないし、何回か聞くともっと自分で考えてやれみたいな感じだから毎日悩みっぱなしだ
出来ることから地道にやれたら良いんだけど仕事だからなかなか厳しいね…
とりあえず独習って本を読んだり試してまずは基礎をしっかり理解するようにしてる
みんなもひたすらサンプルを書いたりして理解して行った感じなのかな C#難しいのかなあ?
自分はこんな便利なのか!と感動したけど >>274
作りながら覚える本のがいいよ
俺は
まあ、人によるけど C#が難しいってオブジェクト志向な設計が難しいってこと? C#が難しいんじゃなくて、
オブジェクト指向が難しいとかプログラミング自体が難しいって話だな >>281
上の人は、C#特有の要素がどうこう以前に
プログラミングその物で躓いてるからなあ
多言語経験者がC#特有の要素で躓くとしたら、デリゲートじゃないの >>274
おれも独学だけど、ここの人達は何だかんだで面倒見いいから、頼るといい。 最初、文法だけを説明している入門書(猫でも〜)で勉強したけど
「インターフェース? 規約だけを定めたもの? 具体的に何の役に立つんだ?」
「構造体? クラスとどう使い分けるんだ?」
「デリゲート? C/C++の関数へのポインタみたいなもの? Cなんて知らんがな」
みたいな疑問が次々と湧くのに解決されないまま、文法の丸暗記だけしてる感があってしんどかった
サンプルコードも、最低限の説明用のシンプルすぎるもので、実用性っぽいものが皆無だったし
もう少し丁寧に解説してる本から始めればよかった >>284
ありがとう
馬鹿だから質問すらなんて聞いて良いか分からないんだけどね
入門書みたいなのは何冊か読んだり試したりして、コード見ればぼんやりこういう事してるんだなっていうのは分かるんだけど、いざ自分で1からやろうと思うと何も書き出せなかったりする
>>285が言うようにこれが何に活きてくるんだ?っていうような疑問も沢山あるし…
実務だとアプリ作ってって仕様書渡されてデータベースから値をとって加工してグリッドに表示させたりとか、何かたった一行でも表示させるのに丸一日かかって結局分からないとかも多々ある
機転が利かないっていうか自分で考えてこういう風に組み替えたり応用したりしようってのが出来ない…
知識が付けば出来るようになるのかな
愚痴吐いてごめん
勉強してきます とりあえずデータベースとグリッドの事は忘れてコンソールアプリを作るべきだ
最近の若者は順序がめちゃくちゃ Webだと仕組みを理解すれば案外コンソールと変わんなかったりするけどね 「言語その物の機能」と
「外部の物にアクセスする手段」とは、分けて学習するべきだわな 非常に申し訳ないんですがLINQの質問いいですか?
インデックスが対応する二つの配列A、Bがあります
Aには氏(string)、Bには性(bool)が入っていて
女性で田中が何人いるってのは、どう書けばいいですか? ■ このスレッドは過去ログ倉庫に格納されています