プログラマの雑談部屋 ★38
■ このスレッドは過去ログ倉庫に格納されています
プログラマは
こちらで雑談してください。
ユーザ、ＳＥが馬鹿過ぎる、
上司がバカだからもう辞めたい、
もう少し簡単な仕事に転職したい、
彼女が欲しい、
などなど愚痴、妬み、妄想などなんでもどうぞ。
※前スレ
プログラマの雑談部屋 ★36
https://medaka.5ch.net/test/read.cgi/prog/1529287662/
プログラマの雑談部屋 ★37
http://medaka.5ch.net/test/read.cgi/prog/1530182616/ >>140
1,2はいいが、やっぱり3って嫌いだわ
ラムダって他と考え方が違うから、コードの中で浮いて見える 10時間もコード書き続けるとか、頭悪過ぎ。
そんな無能な奴が隣にいたらブースから叩き出してる。 コードは考えながらかくもんじゃない
必要な定数、依存、クラス、リソース
場当たり的でない一貫した名前
ぜんぶ整理してから一気に書き下すもの
いきなり着手したら変数名のコピペ元を探すだけで一苦労 ワシが設計とプロトタイプ作る人やから
長時間やるのは仕方あらへん
他に出来る奴おらんし上級エンジニアの名前ももろたし 10時間も経てば退社時刻だからな。
そりゃあ放り出されるわな、お疲れ様です、って。 >>148
浪速金融道かなんかに出てきた肩書もらっただけで嬉々としてこき使われる土方みたいな ラムダ式の利点がさっぱりわからんなぁ
あくまで利用する側がラムダ式で書く対象のインターフェースの型を
わざわざ参照しなくても最初からわかってる前提で書く場合に”少し”だけ長ったらしい記述を
省略できるだけであって長期的に見てほとんどの奴にとって何の利点ももたらさないように見える ばかな
まさに>>8の答えだ
where使ったら分岐がへるんだぞ
土方からは見えない
後方フェーズの分岐のコスト やあやあ
gamen.Syokuhi = dataRows
.Where(e => e["データ区分"] == 0)
.Select(e => e.["データ値"])
.Sum();
gamen.Kounetsuhi = dataRows
.Where(e => e["データ区分"] == 1)
.Select(e => e.["データ値"])
.Sum();
gamen.pachinkoKubun = dataRows
.Where(e => e["データ区分"] == 2)
.Select(e => e.["パチンコ区分"] == "W" ? -e["データ値"] : e["データ値"])
.Sum();
gamen.PachinkoCss = gamen.Pachinkohi < 0 ? "gold" : "black"; はっきし言って>>156も>>8も目糞鼻糞
これは規約でラムダ式禁止の現場が定着するのが目に浮かぶ なんでだよ
そもそも入力が汚いんだからしょうがないじゃん
それでも分岐減ったし状態変数も減ったし処理が分割されて扱いやすくなっただろ！ >>160
実際そういうのでもいいと思う
そもそもこの記述に全くメリットないわけで アブラハムとシェルバーン家当主はどっちの方が凄いですか？ >>160
俺もそうだが、チームの大多数がわからないなら禁止すべきだな ラムダがないと構造体の一部のメンバの値の合計をもとめるだけの処理ですら
自前で実装しないといけなかった
Sumって共通メソッドが使えるだけで随分嬉しいじゃないか？ チームメンバがわからなかったら禁止
それは大正義であり
もう致しかたのないことだ
でもわかってよ！たいして難しくないだろ！ メトリクスツールでも使って複雑度>>8とくらべてみやがれ >>166
関数作ればいいじゃん
ラムダで書いた処理は再利用できるの？ 文句言うなら一人で全部作ればいい。
やれるもんならやってみろ
・・・って言ったら、自称俺は出来るヤツ様、
泣きそうになってたぞ。 >>144
体力落ちてるだけだろ
一流のプログラマはみんな身体も鍛えてる >>145
3が当たり前の世界だと1, 2が浮いて見えるぞ
つうか浮いてる浮いてないはどうでもいいんだよね
なんども似たようなループを書いて生産性を落とすほうが問題
DRYの精神に則り3を使おう 1メソッドや1クラスの行数は少ない方が良いってのは分かるんだけど、
実際仕事でやってると名付けやら何やらで面倒臭くなってやらないよね？
他メソッドに飛びまくると処理追うの大変になるし >>156
いいコードですね
やはりif elseはゴミだったと思わせてくれる綺麗なコードです
このコードの素晴らしいポイントは
if elseによって結合されてしまった本来無関係なstatementが分割されて独立したexpressionに置き換わったことでしょう
expressionに置き換えればこのようにメソッドに抽出することが簡単にできます
int TotalSyokuhi => dataRows
.Where(d => 0.Equals(d["データ区分"]))
.Sum(d => (int) d["データ値"]);
expressionにフレンドリーな名前が付いてコードがより美しく明快になりましたね
if elseを使った惨めなコードではここまでたどり着くのは難しかったでしょう
そしてこのように美しく整列したコードではパターンが視覚的にはっきりと見えるようになります
いとも簡単に処理の共通性を抽出してメソッドにできるのです
int CalculateTotal(int dataKubum) => dataRows
.Where(d => dataKubun.Equals(d["データ区分"]))
.Sum(d => (int) d["データ値"]);
int TotalSyokuhi => CalculateTotal(0);
int TotalKonetsuhi => CalculateTotal(1);
素晴らしい
if elseのないコードは最高だ >>165
ラムダぐらいは知ってて当然だろ
仮に知らなくても1時間くらいで教育すればいい
社会人は幼稚園児じゃないぞ
俺さまがわからんから俺さまに合わせて周りの人間が俺さまに配慮して使用禁止にしろ
こんな理屈が通るのが当たり前だと思ってる奴は本気でバカなんじゃないのか？ まあここに出てるぐらいのﾗﾑﾀﾞなら全然かわいいもんだけど
出来るプログラマーさんは何十ネストした凶悪なラムダコード書くから
あそこまで行くと誰でもわかるようにそこはラムダ以外の部分で
もっと分割しろよとは思う >>187
とか叫んでも別にメリットも無ければ
出した見積り以上に金が儲かるわけでもなし
意味ねーこと拘っててバカみたい ラムダが糞なところは三項演算子と同じで
本来なら一目で10見渡せる処理の”実態”を隠蔽して他に移譲してるだけ
ラムダ厨はおまじないのように使ってるだけの無能しかいないからわからんだろうけど
ラムダのソース見ても開発者のオナニーだと言うのがわかる わからん奴だらけである以上は迂闊に使っちゃダメだよ、
あくまでも人売りビジネスなんだからさ。 ラムダで作っていくのでこれだけの工数が削減できます
まで言えないなら
ちょっといい程度で抑えておきなよ >>191
足し算ができない社員が足し算できるようになることにメリットを見いだせないなら死ね >>196
それやって少数精鋭部隊なんて作っても
開発人数確保できなかったらプロジェクトポシャるってわかっていってるのか？
バーカ >>199
お前のとこは足し算できれば精鋭なのか？ >>198
ならない
人数確保するために未経験のコンビニ戦士（コンビニバイトしかやったことないおっさん）を経験3年として補充してる始末 >>201
ここにも足し算もできないやつがいるからな >>199
そんなプロジェクトに関わるくらいなら辞めちまえ >>205
嫌いなプロジェクトに当たるたびに辞めてるのか？ >>182
名前をつけない場合でもその処理は書くんだから
名前が無いとどこで何してるかわからなくなって処理を追うのが余計に大変になる
飛びまくると考えるんじゃなくパッケージングされてればその先を見なくて済むと考えよう >>188
それはできるプログラマじゃない
ラムダとか関係なくif elseやループでもおそらくネストしまくりだろそいつ >>210
メソッド分割せずに#regionに処理の概要書くんだよ
そうすりゃあっという間に数千行のメソッドのできあがりさ >>189
工数やバグが減って保守性が上がる
メリットだらけじゃねえか
今までバカやってたのと同じ見積もりで受ければ差額は丸儲けだぞ 出来るってのは、出来ないやつの尻拭いが出来ることを指すんだから、
ラムダだのセニカだの言ってねーで、仕事しろよ仕事。 >>193
実態を隠蔽するのがプログラマの仕事だよ
見なくていいものを見ないで済むようにコード整備していくんだ
もし仮に隠蔽しなかったら全部メインルーチンにベタ書きになっちまうじゃないか
それは異常者やることだろ？
正常なプログラマは隠蔽を使いこなす >>216
ラムダなんか書いてねーで関数にしろよカス 全文メインルーチンに書いてあるからぶっ飛ばしたくなってるけど、異常者なのか。
刺されそうで怖いな。 >>217
関数切り出しと処理をラムダで書くかどうかは別次元 >>199
認識に差がありすぎて話が通じねえな
・ラムダが理解できることが異様にハイレベルな特殊技能だと思ってる人達
・ラムダは呼吸とおなじように誰にでもすぐにマスターできる技能と呼ぶのもおこがましいものだと思ってる人達
両者の間でどんなに議論したって結論が一致することは無い
だからプログラマは同じレベルの人間だけで集まって仕事をするべきなんだよ
契約する前に面接や技術試験をしっかり行って配属先を変えたほうがいい
ラムダも理解できないようなカスは物量だけが問題のドカタ案件に放り込む
まともなプログラマは課題解決に知性と技術が必要な案件に招待する
ベテランと新人のセット販売などもってのほか ラムダなんてこんな話題になるようなもんじゃないだろ
何千行とかの入れ子forループ書いたりするアホを斬るほうが重要 >>221
それを解決するための道具の1つとしてラムダが役に立つ 経歴詐称して新人送り込むビジネスって今も通用すんの？
出来るなら最低でも1か月分の金は貰えるから面談でハッタリかましまくって
潜りこむを繰り返すことは可能？ブラックリストとか作られる？ >>223
それを通用させるのが偽装請負という手法なんだな。
特定派遣が廃止され、この偽装請負がさらに増えると見られるわけだが、
営業が見積もりでヘマこいて潰れる会社が増えるんだろうな。 未経験の転職はそういうところから業界に入るしかないのでは
それでなんとかやっていけたら経験者になれる いやそういう意味じゃなくて鋼のメンタルの持ち主なら
現場の空気悪くなろうがどうなろうがほとんど仕事しないで
残業しろって言われても定時で帰ってを繰り返せば仕事的にはすげー楽だよね >>223
セット販売するベテランが居なくなった時点で終わり
首を切れない大量の素人を抱え込んであっという間に会社が破綻する
今は転職が簡単だから優秀な人材は不満を感じたらすぐに居なくなる >>225
自社開発なり誰かと抱き合わせなりして入ればいいんだよ
軽く考えている見たいだけど経歴詐称自体は詐欺なりなんなりの犯罪だからね
受け入れる側も派遣の事前面接やら他にも後ろ暗いことやってるから見逃されて
いるだけであってまっとうなとこだと訴えられないからな 会社側というより送り込まれる本人視点の話
あくまで面談通るぐらいの知識とハッタリをかませる前提で
案件なんて腐るほどあるんだし延々とこれを繰り返すことが可能なのかって話 未経験者でも簡単に入れるこの世界だが、
営業のほうも簡単に入れるもんなのかねぇ？ こういう話題を見ると実感する
ビジネスモラルがないんだよな日本人ってさ
まさにエコノミックアニマル 俺経歴詐称客先常駐で初っぱなから1人で送られたわ
途中から1人は入ったけど
今新しいところはまた1人だは いや周り見てるとさプロパーは当然のことながら派遣でも
居眠り一つせず糞真面目に仕事しとるやん
デスクワーカーの日本人ってある意味で異常な気がしてならないんだよね
海外で派遣システムなんか成立しないだろ 簡単に捨ててくれるからこそ、elseがあるとソース読めないようなバカでも
雇ってもらえるんだもんねぇ。 >>236
正解は、else書きまくるバカでも雇って貰える、でした >>184
前半よかったのに後半ひどくてわろた
CalculateTotal絶対いらん
Pachinkohiがその方法で作れないのわかってんのに
なんで無理やり一般化するし 前にも言ったけど、キーワードは「責任」。
クビになれば済むんだから、そりゃあもう気楽なこと気楽なこと。
ちょっと技術力をつければ、さらにおきらくごくらく。 >>238
パチンコだけ別の処理を書くだけだな
無理やり一般化するというか、キミのほうが一般化すべきコードを無理やりコピペしてる、と言うべきだね interface IDataObj {
int Hiyou { get; }
int DataKubun { get; }
}
int CalculateTotal(int dataKubun) => dataObjList
.Where(d => d.DataKubun == dataKubun)
.Sum(d => Hiyou);
これじゃあかんの？
オブジェクト指向わからない人がいるからダメ？ いま適当に「キーワードは責任」をググレカしてみたら、
かつてアベが口にしたセリフらしいね。 この世界は一般派遣で仕事ゲット出来ないようなのがいっぱいるじゃんか
特派はそういう人の為にあるんだよ
フリーでやってた時、彼らのレベルの低さに驚いたもん
ウェブ系の開発でGoogleマップをカスタマイズしたライブラリーを製作する担当で特派の人がきたんだけど、全然出来なくて何故か自分が泣きつかれて作るはめに。
実は彼は腕利きのフロントエンジニアという触れ込みで現場にきたんだが、前職ではHTMLの運用の仕事しかしてなくて、しかも前前職は理容師見習いだったという。
オブジェクト志向とは何か、から丁寧に教えて一緒に作りましたよ。 ■ このスレッドは過去ログ倉庫に格納されています
