プログラマの雑談部屋 ★38
レス数が1000を超えています。これ以上書き込みはできません。
プログラマは
こちらで雑談してください。
ユーザ、SEが馬鹿過ぎる、
上司がバカだからもう辞めたい、
もう少し簡単な仕事に転職したい、
彼女が欲しい、
などなど愚痴、妬み、妄想などなんでもどうぞ。
※前スレ
プログラマの雑談部屋 ★36
https://medaka.5ch.net/test/read.cgi/prog/1529287662/
プログラマの雑談部屋 ★37
http://medaka.5ch.net/test/read.cgi/prog/1530182616/ ブオー!ブオー!非常に危険なプロジェクトが進行中です!
命を守ることを最優先に開発してください!
ブオー!ブオー!非常に危険なプロジェクトが進行中です!
命を守ることを最優先に開発してください! 👀
Rock54: Caution(BBR-MD5:1341adc37120578f18dba9451e6c8c3b) > elseが不要だと思う本物のプログラマは
> こちらで雑談してください。
己も論理的elseを多用してるくせに、
どんだけ馬鹿なんだと思ってたら
プログラマじゃなかったんだな。
二度とくるなクズ! if/elseそのものは悪くない
だが分岐した後にだらだら処理を続けるバカは悪だ
分岐した中に更新系処理を書く奴も悪だ elseの問題点は考える事を放棄したようなコードが連続して産まれてしまう部分 > だが分岐した後にだらだら処理を続けるバカは悪だ
分岐に関係なくだらだら書くのはダメだろう?
なぜ「分岐した後に」がつくんだ?
プログラム作ったことあるのか?
相当な馬鹿だな >>6
分岐した後のコードをメンテナンスしたりテストする工数がそのまま倍になんだよハゲ foreach(DataRow dataRow in dataRows) {
int dataKubun = dataRow["データ区分"];
string pachinkoKubin = dataRow["パチンコ区分"];
int data = dataRow["データ値"];
if (dataKubun == 0) {
gamen.Syokuhi += data;
}
else if (dataKubun == 1) {
gamen.Kounetsuhi += data;
}
else if (dataKubum == 2) {
if (pachinkoKubun == "W") {
gamen.Pachinkohi -= data;
}
else {
gamen.Pachinkohi += data;
}
if (gamen.Pachinkohi < 0) {
gamen.PachinkoCss = "gold";
else {
gamen.PachinkoCss = "black";
}
}
else if (dataKunun == 3) {
...
昨日、うちの新人が書いてたコードの真似
これが100個ぐらいだらだらと続く典型的なelserコード
バグや項目追加があるたびにテストやり直しさせたら泣きそうになってやんの どう考えても、処理内容とデータ構造を把握する事を教えて無い。
お前が悪いだろう。 elseは馬鹿の製造装置
だいたい私大文系なんだけどな そういうのを早いうちに体験させて「これ、ダメじゃん」と分からせるのは
実に親切なことだ。
それをやっておかないと今年の始めくらいからずっと
else爺とか、書いてないだけでやってること同じだろ、とか、
寝言を一生言い続ける木偶が出来上がってしまう。 >>8
別にいいと思うけどな
っていうか
見積りすでに終わってるから動けばいいよ >>12
何年、十何年も前に動けばいいよと言ってメンテナンス性を犠牲にしていた企業が、今頃になってこのままじゃビジネスの変化スピードに耐えられない、と気が付き出してる
これからの開発では、動けばいい、エビデンスだけ綺麗に作れ、は通じない
それじゃもう客を誤魔化せない >>14
え?
単価50万だし
こちらの瑕疵で無ければ
お金出るから気にせんでええよ まともに働いた事ないから分からん。
税金払って、うまい棒 どれだけカエルの? 遊園地ってさ、なんで最近、35歳スレから外出してきてるん? >>15
単価50で開発してはいさようならならそういう書き方になるのはしょうがないよなあ。
メンテナンス性も拡張性も高いものを安い使い捨ての要員にやらせようってのが
間違えって分かってない肉屋のブタみたいな意識高い系が多いのが問題だな。 安いドカタを使うとelse地獄になってメンテナンスできなくなるということだな もうネタとしても飽きられてるのに1人で必死になにやってんだ >>20
そもそも所属会社の資産でも無いのに汎用性なんか気にしてる奴バカ何じゃないの? ヨソの会社のドナドナーが何やらかそうと
知ったこっちゃねーやな。 >>8ぐらいのソースさえマトモに読めない時点でもう・・・ >>7
ダラダラ書くのはどこで書くのもダメだっていうのと、
elseがダメだっていうのは違う話だろうが馬鹿!!! elseがダメならそういうソース見せてみろよクズ!
いいと思うソースも見せてみろクズ!
いちども見せてないだろうがクズ!!
さっさと死ねクズ! ビジネスという観点においては、プログラムは
バカでも出来るようにしていかなきゃいけないんだから、
elseはそのために必要な機能だったんだな。 プロジェクトが終わったら
さようならなのに、
高給取りの正社員様のために
メンテナンスしやすいソースなんて
書くわけないじゃん。
むしろ自分しかメンテできないように仕込んで
次に高単価で呼ばれるようにするのが
俺みたいな低賃金非正規の処世術。 >>31
でも、そんなプロジェクトにまた戻りたいか? >>8
そんなクズのレベルの話をしてんのか?
それはelseがダメというのとは違う次元の話だな。
ああ、わかった。
クズしかしらないクズが吠えてるだけだったわけね。
なるほど。
お前がクズだということはよーくわかった。
お前の周りもクズばっか。
プログラマじゃねーわ。おめーらは。
さっさと死ねよクズ! >>27
ああいうソースを見るともう少しましな書き方で書き直すとかはあるな。
ただ入門書やらwebだとそういう書き方なんて学べる機会なんてほとんどないから
コードレビューなりなんなりしてきちんと学ぶ機会を与えないと無理だよ。
教えたらマシになるなら教えるべきで5chで愚痴って他人に承認してもらおうなんて
考えて行動する方はどうしようもないクズだけどね。 >>27
これが何百行も続いてしかもおなじようなコードがあっちこっちにある
実際には命名も適当だからどこになにがあるのかを探すだけでも無駄に時間を食う
それが可読性が低いコードということ
局所的にピックアップしたコードがなにをしているかなどキミでも読めるだろうね
確かに読めるが綺麗に書かれたコードよりも読むのに時間がかかるのも事実
それが可読性が低いコードということ このスレはプログラマーじゃない部外者も多いからねぇ。
将棋にたとえれば「龍王」「龍馬」の駒の裏側を
ワザワザ見てる奴クソ、とか言うぐらいのレベル。 >>32
自分に跳ね返ってくるならそういう書き方になるだけだとは思うが
それに拡張性やメンテナンス性なんて意識して書いても無駄だったと思うような
場面自体少なくないからなあ、そういう経験すらないの? >>33
おやおや
Elserの本性が見えてきたね
e
ELSEを使うとモラルやマナーまで失ってしまうのかな >>30
if & elseならバカでもできるってのは量が少ない時だけの話だよ
量が増えれば増えるほど組み合わせ数が爆発的に増えて単純に仕様を追いきれなくなる
これはバカでも賢い人でも同じで最終的には物量に勝てなくなる
知能が高くても追いきれる限界が多少増えるだけで限界はすぐに訪れる
ビジネスを長く続けて会社とシステムを成長させる気が本気であるなら
バカでもできるelseを積極的に使おうなどと言っていてはいけない
それは規模の小さい保守しないシステムで満足できる志の低い企業の戯れ言だ elseを積極的に使おうなんて言ってねーぜ。
elseがあるだけでソースがロクに読めない程度のバカを
バカにしてるだけであって。 ホント、企業の情シスってのはかわいそうだな。
こんな無責任なドナドナーどもにすき放題elseとかで
プログラムをメチャクチャにイジくり回された挙句のクソースの
責任取らされるんだもんねぇ。 契約が終わったらバイバイって人は残念だけどたぶん客に評価してもらえなかったんだろうね
俺みたいに優秀な人材になるとシステム更新の案件があった時にまた契約してもらえるんだよ
さらに「Sさんはこのサブシステムのノウハウあるから任せるよ。そのほうが効率的だ」って自分が組んだ機能をまた任されるんだな
なのでelseの無い美しく保守性の高いコードを書いておいて本当によかったと何度も過去の自分に感謝したね がんばってスパゲッティコード量産したら
彼がいないとシステムがわかる人いないって契約更新してもらえたよ!
過去の自分に感謝したね それは、手離れの悪いソースっていうんだぞ。
かつての会社に戻るのはまだいいけど、かつてのプロジェクトにまで
また戻されるなんてねぇ。
お前が書いたソースなんだから、お前がちゃんと責任とれ、みたいな。 そうだ、パスタゆでて食べようと思ってたんだ。
ソースは何にしようかねぇ、レトルトカレーかな。 データ構造と数式をちょっと書き込めば解決する様な事なのに、
小学生みたいに四則演算で揉めてんのか?
クラス設計の在り方で揉めるなら仕方ないけど、暇なんだな。 仕様の達成が難しいことがわかったとき
自分が決めた仕様だからとぶん投げていいものだろうか?
いやシステム上実際はどっちでも大してかわりゃしないんだが かわりゃしないがこんなシステムなくたってかわりゃしないし
こんな会社なくたってかわりゃしない
生きてる意味がない
でもやると工数が >>4
俺みたいに優秀な人材
俺みたいに優秀な人材
俺みたいに優秀な人材
此処が笑い所なのか? >>44
違うんだなあ
自分の領分が落ち着いたら別人が書いた機能も新規機能も任されるからね
ほんとにダメなやつならまかせんだろうな しってる
本当に優秀だと、コード書くよりべつのことをさせようとするんだ
箱物行政でみんなに配分するタスクを一人で食い荒らされちゃかなわんからな
箸にも棒にもかからないとさすがに切られるから
今まで通り仕事があるってことは
今までどおり中ぐらいの評価なのでは タスク食い荒らすと困るって暇そうでいいなあ
営業の腕が良いんだろうね 結局なまじっかなベーススペックより
職場にあった人間がのこるもよう
状況によって生産性激変するから優秀さとか一概にわからんほんとに 雇用率も政権の成果だからな
退屈な作業を自動化すると怒られるのなんて日本ぐらいだろう キーワードは「責任」。
elseがあってもなくてもいいから、金がほしいなら
自分が書いたソースに責任もてよ責任。 >>56
だれもが暇を享受すればいいというのに
ちょっと自分より生産性わるかったり、知識で差があると
役立たずだの無能だの言って排除しようとするから
不毛な仕事がみんなに行きわたる羽目になる
おまいら 1日,2日で直されて何食わぬ顔で通常業務してる奴も居るは ついに奴隷から解放されることが決定しました
ここに来ることももうないと思うけど
お前らも元気でな 待って、生きていれば少しは楽しいこともあるかもしれないよ >>57
昔から正社員様の旗印だったが
これほど漠然とした感覚だけで中身のない言葉もないな
具体的にはなにがちがうん? 責任の名の下に人間を奴隷にするジャップ資本主義
飼いならされた奴らはモンキー メンテナンスしやすいコードってどんなコードなんすかね?
リテラシーの高い人にしか通用しないコードじゃ嫌ですよ?
再帰とかインスタンス化とか、誰でも分かるわけじゃないですからね?
結局、適度にコメントするとか仕様書でフォローするとかしかないんじゃないですか? どういうわけか突然ひらめいた
オブジェクト指向のいう「責任」ように
内部に仕事を抱え込んで外部に必要な成果のみ提供することで
居場所が確保できる
いわば権力をもつことでもある
ホウレンソウとかって成果と関係ないようなことまでねちねち聞いてくるのは
むしろ仕事を円滑に進めるというより、奴隷にそうさせないための算段なのではなかろうか / ̄ ̄ ̄ ̄ ̄ ̄ \
/⌒ヽ / '''''' '''''' ヽ
| / | (●), 、(●) |
| | | ,,ノ(、_, )ヽ、,, |
| | | `-=ニ=- ' |
| | ! `ニニ´ .! たたりじゃーーー!!
| / \ _______ / 安倍晋三の悪政に
| | ////W\ヽヽヽヽ\ 天.がお怒りなのじゃ
| | ////WWWヽヽヽヽヽヽヽ
| | ////WWWWヽヽヽヽヽヽヽ たたりじゃーーー!!
E⊂////WWWWWヽヽヽヽヽヽヽ
E//// ヽヽヽヽヽヽヽ
| | //WWWWWWWヽヽヽヽヽヽヽ プログラム組むの本当楽しいんだけど待遇考えるなぁ
管理職の殆どより会社に貢献している自信はあるけど 「責任」の概念がわからないから奴隷のままなんだよ。
で、技術者やってる分には、そのほうが楽に儲かるんだな。 上はたぶんおまいの貢献分は0として見積もってるよ
プログラマの貢献分はつねに0
なんぼ優秀でも優秀な部品は金で買えるし だからまあ、責任なんてので会社なんぞに固執せず、
どこにでもドナって残業代だけガッツリもらってりゃいいわけだ。 派遣が残業代もらってて自分はもらえてないことに気が付いて発狂した正社員の方ですか それとも今までサビ残やらせまくって後から残業代請求された経営者? >>77
俺さまにわかるわからんみたいな感覚論じゃなくて機械的に測定できるものを指標にするのが一般的だね
循環的複雑度が高いと減点
重複コードが多いと減点
メソッドが長すぎたら減点
などなど
もしラムダをつかって測定した点数が上がったならそれはメンテナンス性が上がったということ
俺さまはラムダがわからんのだから可読性が低いんだなどという幼稚な意見はスルー >>78
人間はオブジェクトと違って間違えまくる
そしてバカは間違えても気が付かないし叱られるのを恐れて報告しない
例外を握りつぶすようなものだ
だから実装にまで踏み込んで管理してやらなきゃならない たまにはプライベートの事でも書いてくれよ
こういうことやってて楽しんでるとか
これやって仕事に活かせたとかさ そういうくだんねー話はツイッターかインスタでやってくれや >>92
お前らの仕事の愚痴の方がくらだねえから
まずはお前のプライベートから語ってくれよ たしかに「雑談」とか銘打ってるくせに雑談になってねえよな
ずっと仕事に取り憑かれてる社畜のスレって感じ >>89
機械的に測定できるんなら機械にその修正をまかせれば良さそうだけどね
プログラミング言語はそもそも人間様が理解しやすいように作られるもんなんだから、ラムダが分からんを幼稚と断ずるのはちょっとなあ 搾取されてるエンジニアが団結して労働者の権利を主張しないからこうなる
弱者のくせにネトウヨにだまされて資本家の走狗となり共産主義を悪魔のように排撃してきた報い
貧困に陥った屑どもがマイノリティ排斥に走って鬱憤を晴らす
低脳ジャップの行動は悉く斜め上
労働者はマイノリティを大事にして協力してこの腐った島国文化を上書き更新して別物に作り変えていかなければいけないのに そうだ俺らはプログラマーなんだ社畜じゃない
仕事とかかわりなく
楽しくゲーム作ったりソフト作ったりしてるはずなんだ
なんでこんなことに >>96
分岐が多いので減点となった時に分岐を勝手に消す判断までは機械にはできない
理解しやすいはどこまでいっても感覚でしかない
同じコードが理解しやすい人もいれば理解しにくい人もいる
だから感覚によるブレは捨てて機械的に数字で判断をする
ラムダがわからんのならわかるように努力する
チーム作業で俺がわからんから全体で禁止しろなんて意見は幼稚としかいいようがない >>87 >>88
残業代が飛ぶことに気づかれたもんだから、ロクに残業を
させてもらえなくなった派遣技術者さ。 >>91
スマホで電卓アプリ作ったことあるとか言っても、
誰も反応しないからねぇ。 >>99
なるほどね
そういう定量的な分析をして判断は人間に任せるみたいなアプリってあったりすんのかな
減点する作業がそもそも辛そうだけど >>103
自分で調べたら色々見つかったわ
まずlintをよく知らなかった
初心者ですまん >>8がダメって言ってるやつらどんなコード書いてんの
そもそも違うデータをひとつの画面に出そうとしてるんだし
入ってくるデータもKBN持ってんだし
多態とかしたら余計わからんくなるだろ
テスト毎回全部やり直させてんのは新人じゃなくて職場の問題じゃん >>106
IT業界をブラック、社畜と卑下してるのは当のIT従事者だからな ここ半年で6人中3人辞める異常事態のチームにいるんですが
このままここにいた方がいいですか? プログラマの癖にたまにこういう曖昧な質問する奴はただの荒らしなんだろうな 川が決壊してるのに
明日は、クソコード書きに
会社にいかないといけないのか? >>91
な、なんの反応もねーだろ?
ここの連中のプライベートや楽しみは、せいぜい
ここにバカ書く程度のことなのさ。 巨大タンカーの船長とプログラマーはどっちの方が頭を使いますか? >>107
elseどうこうの前にドカタの皆さんにはViewとModelの分離を覚えて欲しいね
DataList data = searchDataService.SearchDataList(/* 検索条件 */);
gamen.Syokuhi = data.TotalSyokuhi;
gamen.Konetsuhi = data.TotalKonetsuhi;
gamen.Pachinkohi = data.TotalPachinkohi;
gamen.PachinkoCss = gamen.Pachinkohi < 0 ? "gold" : "black"; YouTubeを超える動画共有サイトを自分一人で作りたい。 >>118
世の中にはバインディングというものがあってだな レンタルサーバーとかISPの事業に少し興味がある。 >>118
でもSearchDataListの中はエルス王国なんでしょ? ネトウヨ「LINE俺らの個人情報を盗んでる!恐ろしい!((((;゚Д゚))))」
ネトウヨ「俺らの個人情報なんてゴミだよ!グーグルさん、遠慮なく盗んでね!」
↑個人情報に敏感になったり疎くなったりコロッコロ変わるのは何故?(´・ω・`)
ご都合主義のヴァカネトウヨ >>134
数論幾何学ってどれくらい難しいのでしょうか?
凡人には到底理解できないですか? せめて
せめてラムダ
なんで俺の職場はいつまでたっても
Java7とかなのか >>138
Java のラムダは、ラムダとは名ばかりの劣化物であり、シンタックスシュガーに過ぎない。
ホンモノのラムダとは、それで Y コンビネータを記述できるものだ 1
for(int i=0;i<items.length();i++)
{
result += items[i].Val;
}
2
foreach(var item in items)
{
result += item.Val;
}
3
resullt = items.Sum(n=>n.Val);
3がエレガントだが1がなんか好きな人もいるだろ
ただ2が好きな奴は変人 >>135
俺は>>134じゃないけど、難しいですよ。
数学の勉強は始めましたか?
いま数Tか数Uあたりですか? プログラマーは脳疲労が半端ないな
最近は休日身体が動かんし、平日もエフェドリン系の風邪薬飲まないと朝布団から出られない
10時間ぶっ続けで集中して難解なコード書き続けてると知恵熱出てくる
頭はいくら使ってもいいというが、やはりモノには限度があるんだな >>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の運用の仕事しかしてなくて、しかも前前職は理容師見習いだったという。
オブジェクト志向とは何か、から丁寧に教えて一緒に作りましたよ。 >>243
>いま適当に「キーワードは責任」をググレカしてみたら、
>かつてアベが口にしたセリフらしいね。
その通り。
プログラマーの意識が低すぎるから、アベを糾弾する為に話をふってみたのさ。
まだ続けてやるから、ネトウヨ悔しいのぉ。 iPod touchの第7世代っていつごろ発売されるのでしょうか? >>244
ジャップからは搾取したもんが勝ち。
元請けが搾取してるんだから別にいいんだよ。
この国は上はアベから竹中から搾取の構造で成り立っている。 本来なら、会社の看板掲げてる分、特派のほうが
レベルが高くなきゃいけないんだが、会社の看板で
能無しをゴリ押ししてるのが現状だもんねぇ。
それこそが、まさにキーワードは「責任」。
大事なのは能力よりも責任の押し付け先。 iPod touch 第7世代早く発売してほしい。 いや、非正規に責任なんてないから。
だから非正規を楽しんでる。
責任ないのに高い給料。
非正規の特権だよ。 一般派遣は、仕事選べるから、高い給料+後に続く経験が蓄積されるけど、
特定派遣は、「高く売れる」ところに放り込まれるだけ
それでも、肩書が、正社員なので、人並みの人生が送りたいなら、特定派遣を勧める。 でも9月で特定派遣終了っしょ?
偽装請負に切り替わるだけ? どっちでもいいよ
末端は定時までだらだらするだけで変わりない キーワードは責任ww
こんな島国に対してやなこった アベ自らが責任とってないのに
末端の非正規に、キーワードは責任wwww 責任というからネガティブなかんじがするんだ
権力といおう 外国じゃ責任ってのは誰が状況をどうにかできるか、何をするべきか決めるものだ
日本じゃことが起こった後でだれを吊るせばいいか決めるときに使う >>265
安心しろ
海外だってそうだろ
そうでなかったらギロチンなんてできやしねーよ 今の現場設計書に書いてある条件とかどこのデータ(データベースとかファイルとか)からとってくるとか書いてないんだけどこういうのってみんなプロパーや常駐先のリーダーっぽい人から聞いてるの?
自分はちょびちょび聞いてるんだけど箇所が多すぎて一々席立つのしんどかったり鬱陶しく思われそうで作業止まること多いんだ
まだ1年目でよく判断がわからない まさに責任
おまえがどこまで背負ってどういう立ち位置に立とうとするか観察されている くれぐれも責務だけおわされないように
決定権も自分がもたないと身が持たん 詳細設計にどこから持ってくるか書いてないなら不備
その現場はすぐ逃げた方がいい >>271
詳細設計書が無い部分なんだ
機能によってあったり無かったり
なんで無いのかはなんか聞きたくない
>>272
嫌な予感しかしないんだが設計書に書いてあったんで好きにコーディングしましたよって言える度胸必要なんかな
仕事行きたくねえ… わかんなかったらExcelシートに取得元がこんだけわかりませんって書いてぶん投げちゃえ 日本の場合、
設計書の不備は指摘しなかったり確認しなかった
プログラマの責任だからな。
とんでもないバカげた風習だよな。 日本のITがこんななのも自民党政権のせいなんだよな >>268
リポジトリの設計を見ればいいよ
ただリポジトリの設計はほとんど自明だから省略する場合もあるが >>268
同じチームの人は似たような設計書を扱ってるのに出来てるんだろ?
なら自分以外の人がなぜ出来てるのかを突き詰めて考えるんだよ
考えて分からなきゃ頭を下げて教えてもらう
5chなんかに愚痴ってないでまずはやるべきことをやろうぜ 設計書に項目一個、処理一行まで書いてあげないと製造してくれない子ってすごく困る
コードを自分で書くより設計書を書く手間の方が大きくなってしまう
コードを書いてテストするだけなら1機能1日
10機能なら10日で終わる
設計書を書くとエクセルだからすごく書きにくくて1機能2日かかる
10機能なら20日
そこから10人に実装とテストを任せると追加1日
合計で21日かかる
忖度を期待して設計書を省略すれば1日2機能ぐらい作れるけど
忖度が苦手で隅々まで書いてくれないとわからないって言う子が必ず現れる
この問題みんなどうやって解決してるんだろう 人を使わないことで解決させてる。
キーワードは「責任」。 >>280
普通そんな問題発生しないけどな
要件と仕様の忖度と設計はプログラマの仕事範疇だし
設計と実装を別の人がやるというのがありえない
それに処理一行まで記載って日本語で実装してるようなもんじゃん、そんなんエクセルコンパイルしますわ >>283
って言うけどさ
実際には設計と実装は別人がやるし
処理1行までかかないと仕様漏れだこれでは実装できないって鬼の首を取ったような勢いで責め立ててくるよ 関数型プログラムもUML使うの?
まだOOなもんで 曖昧な設計書から仕様を読み取る勘なんてのも能力のうち。 書いてないことがプログラマーの裁量になるならともかく
思ってたのと違ってたら実装バグに倒してきよるからな
設計ミスだっつーの 前にも言ったと思うが、下流に行くほど高い能力が要求される。
素人には、コーディングよりも設計書を書かせるのをやらせるんだな。 >>289
一番難しいから丸投げの対象になるしコスト競争で薄給になるよな そうだな。
この際、出来ないやつほど上流というのを徹底して
入社したらまず営業をやらせるぐらいがいいのだろう。 >>288
仕様の論理的矛盾を解決するのはプログラマの仕事
一番下っ端どころか客先常駐の奴隷だから押し付けやすい >>291
客の要望を理解するという意味では良いかもね
何したいか知ってればモチベーション違うでしょ 客の要望なんてのもそうだし、社長の要望なんてのもそうだし
なにより、お金の流れを知るってのが重要なんだよね。 設計書をFixしないと実装できない現場ってクソだと思ってたけど
そうでもないな
何も確証の無いまま実装工程行くとカオスになる
勝手に自分クラスを大量にこさえる奴の抑制は必要 プログラムの能力なんてのは、そのまんま設計の能力だからな。 日本語名でクラス作れたらその程度のことで目くじらたてんでよかったろうに
なぜかどこも許してくれない お前がさっきゴチャゴチャ言った内容をWordに書けばいいんだよ 君の書いたクラスを俺の書いたクラスで呼び出さなきゃいけないんだけど
設計書にあるクラスで動かないじゃん?
どういう風に書いたらいいの?
なんか1ヶ月ぐらい返信無かったw >>295
そのとおり
だから1行1行までピタリとコードに一致する設計書が必要なんだ 設計も出来ないやつにプログラム書かせるなんて時点でもう・・・
人売り業ならではの出来事だな。 細かすぎる詳細設計書の必要性ネタで荒らそうとするのはやめろ! 人を使うから人のことで悩むハメになるんだよ。
人に使われる立場を死守して悩みの加害者になるぐらいでないと。 元請けから要件定義を見せてもらわないと忖度なんてできない
マージンとる理由付けのために元請けは要件定義を見せない
見せたら丸投げになるから
でも仕様不備で問題発生したらこちらが悪いことになる 外人はさ、
設計書に書いたカラム名を母国語になおす必要ないんだぜ
すげーハンディキャップ >>307
そういう時は派遣で契約すればいいんだよ。 >>307
縛りプレイしてるんなら
しょうがないな >>308
外人が皆英語を母国語としているわけではないやろ いついつまでにシステム改修してと言われたけどPCセッティングとか雑用を積まれるからなかなか進まない
客先常駐の悲哀だわ >>308
英語ネイティヴならそうだろうな
そしてプログラミング言語ペラペラなら設計書からプログラムに翻訳しなくていい 【搾取】年収1,000万円以下はパートでやれ【対策】
☆不利益で迷惑だから料金増やすか生産減らせ☆
相場下がって迷惑だから年収1,000万円以下はパートでやれよ!
アメリカのSEは多重派遣なしで1,000万円以上の高収入
日本のSEは多重派遣ありで1,000万円以下の低収入
【アメリカ】
スーパープログラマ
時給10万円だったり、ストックオプションで数億〜数十億円稼ぎだす
Javaフレームワーク
〜3600万円
PHP
〜2400万円
COBOL
〜1700万円
技術サポート
〜1200万円
年収中央値:1175万円(アメリカ労働統計局調査、サンプルは111万人)
70歳でも仕事があり、年収は下がらない
数年単位で転職する(一つの会社に長くいるのは危険)
管理系の職種は雇用が不安定で、報酬も高くない
【日本】
平均年収:430万円(情報処理推進機構調査)
Web/ゲーム業界(昔ほど報酬は高くない)以外は人月単位のため、報酬には上限あり
年功賃金を採用する企業では20代後半までの給料は一部の例外を除き低い
間接雇用が基本(大手のSIerでも客先常駐派遣が少なくない)
40歳以降になるとリストラ候補となり、一旦リストラされると低賃金職か、長期間無職となる
大企業の場合は管理職トラックに進むためコーディングはしなくなり、
プログラミング経験が昔あっても35歳以降の転職は難しい
転職回数が3回超えるだけで大手には書類で落とす。
アメリカは多重派遣搾取しない
http://getlife.hateblo.jp/entry/2014/06/19/034109 >>308
var rieki
dim uriage
const kosuto
でOK >>316
ワシは外人向けのAPIのテストコードで変数名を天津飯や悟空にした事あったな 2バイト文字は流石にキツイ
英単語だと日付の月をmoonとか書くのが現れる
ゆえにローマ字表記がベストという事でよろしいですか 客先常駐で俺以外が書くコードなんて興味無いと放置してたら皆辞めちゃって地獄見てる
まあ俺も特派終了で終わりだけど、あと二ヶ月逃げ続けないといけない >>319
みんな辞めても地獄が続いてるってことはお前が元凶だったのか? 「全」は神がプログラミングしたのでしょうか?
神は誰がプログラミングして作ったのでしょうか?
また、神をプログラミングした存在は、誰がプログラミングしたのでしょうか?
また・・・・ >>320
作り方もシンタクスもフレームワークも好き放題だったから今地獄なんだよ
もう何が何だか解らん それは設計書のせいだな
ユーザーインターフェイスを1単位として設計書を書くだろ
それをコーダーに並列で投げるとその手の統一感のないシステムがすぐに出来上がる なんやかんやで
優秀なヤツに1機能とか1画面を作らせて、
それをバラまいてコピペして作らすやり方が
一番うまくいく。 .*tuki.*と.*tsuki.*が混在して、しかも「間違ってもう一方の綴りの方にしちゃってた」なんてバグまで出るんだろ >>327
それだ
それか一番優秀な奴の書く
社内プロジェクトdobon.netしか
役に立ったことがない
クラスでパックするとどうにも
機能を追加したくなったときに
それができるのか?できないのか?
さっぱりわからん
ピンポイントでdobon.netをやってくれてる方が百倍役に立つ ゆうしゅうなひとがにげた
それほどじゃないひともにげた
できないひとがかいしゃこない
どうしよう >>334
やめて
コピペされると全体をくまなく見ないと追加できるかどうかわからなくなる
クラス化して責務が集中してればそこだけ見ればわかる ドメインモデル
レポジトリ
ドメインサービス
アプリケーションサービス
ユーザーインターフェイス
にわかには信じがたいが、どうもこの程度の基本もわからない人が沢山いるらしい
Javaなら常識だよねって何気なくオブジェクト指向プログラミングすると
プロパティをプライベートにしたら不便だの
クラスが多くて理解できないだの
インターフェースってなんだよだの
プロとして恥ずかしい発言があちこちから飛び出てくる おまいさんの言葉の使い方がズレてんじゃないの
Javaにプロパティてあったっけ >>339
プロパティはあるけど、意味が全然違う。普通はKey-Valueペアの事を指す。
>>338はフィールドをプロパティと勘違いしてるんだろ。 プロパティって何のためにあるんだ
public int Value {get;set;}
の代わりに
public int Value;
つかったらどんな問題があるのだろうか VB界隈はドボンコピペで作り逃げが王道
そのせいかVB改修には人が集まらずC♯案件と騙してドナドナかけるのがモダンスタイル 俺は底辺web開発の少人数チームリーダーだけど画面ごとじゃなくフロントエンドとバックエンドに分けて開発してる
で、バックエンドは知識ごとのクラスで作る人分けてる
こういう作り方も何かアンチパターンに触れてるかな アンチパターンかどうかはわからんけど、
出来るやつが下にいないと成り立たないやり方だな。 >>354
クラス設計やインターフェイス実装は俺がやってるから中身だけを作って貰ってる
どうしても駄目ならそのクラスは俺がやるつもり
幸い壮大なクエリ書いたお姉ちゃん以外にトラブルはない クエリいいじゃないか
ロジックが目立たないからテスト工数へる DBスペシャリスト持ちの派遣お姉ちゃんが来てスゲーと一機能頼んだらほぼSQLで実装してくれた
そういうストアドメインの職場もあるんだろうなと世間を学んだ テストはDaoとして取得ロジックが切り出されてるからむしろやりやすい
改修はお察し >>353
まあ悪くないよ
バックエンドにも複数のレイヤーがあること
知識で分けた上で責務で更に分けるということ
この2つを意識して クエリの仕様がはっきりしてればテストしやすいだろうけどスパゲティクエリが許される現場でそんなことまずないだろ
SQLもどきに罫線つけただけのクソ設計書じゃテストケース作れねえよ 【搾取】年収1,000万円以下はパートでやれ【対策】
☆不利益で迷惑だから料金増やすか生産減らせ☆
相場下がって迷惑だから年収1,000万円以下はパートでやれよ!
アメリカのSEは多重派遣なしで1,000万円以上の高収入
日本のSEは多重派遣ありで1,000万円以下の低収入
【アメリカ】
スーパープログラマ
時給10万円だったり、ストックオプションで数億〜数十億円稼ぎだす
Javaフレームワーク
〜3600万円
PHP
〜2400万円
COBOL
〜1700万円
技術サポート
〜1200万円
年収中央値:1175万円(アメリカ労働統計局調査、サンプルは111万人)
70歳でも仕事があり、年収は下がらない
数年単位で転職する(一つの会社に長くいるのは危険)
管理系の職種は雇用が不安定で、報酬も高くない
【日本】
平均年収:430万円(情報処理推進機構調査)
Web/ゲーム業界(昔ほど報酬は高くない)以外は人月単位のため、報酬には上限あり
年功賃金を採用する企業では20代後半までの給料は一部の例外を除き低い
間接雇用が基本(大手のSIerでも客先常駐派遣が少なくない)
40歳以降になるとリストラ候補となり、一旦リストラされると低賃金職か、長期間無職となる
大企業の場合は管理職トラックに進むためコーディングはしなくなり、
プログラミング経験が昔あっても35歳以降の転職は難しい
転職回数が3回超えるだけで大手には書類で落とす。
アメリカは多重派遣搾取しない
http://getlife.hateblo.jp/entry/2014/06/19/034109 >>219
ラムダって一行書くためにしか使わないやつを書くって感じ? 何も難しいことはないけど、最近勉強する意欲がなさすぎて調べる気が起こらない。
やばい
新人のときみたいな意欲が出ない 本屋とかでPythonがめっちゃ多いけど、ほんとにこれ仕事で使われてるの?
どんな業務で使われてるん?JavaやPHPより有用なの? >>369
なぜか知らんけど会社の業務系システムまで
pythonにするという企業が出てきたから仕事増えてる
10年経ったら動かなくなると思うけど、
そしたらまた仕事が増えるから
プログラマとしては大歓迎だね!
今よりずっと人手が足らなくなって
単価はどんどん上がると思う 【社会 詐欺 フィリピン人】主要駅に出没する、フィリピン募金に気をつけよう
※断ると罵倒されるそうです
--------------------------------------------------
外国人世帯の生活保護の割合
在日コリア:6世帯に1世帯
フィリピン:10世帯に1世帯 まーた次のプロジェクトもハイテクだよ
諦めて勉強するわ
おまえらみたいなハイテクマウント取りにDisられないようにせいぜい精進させていただきますわ
構成管理グループはカッコいいね嫌いじゃないよ スキルを求める無ければ首と脅かされて入った現場が総称型禁止だった
理由はよく解らないから 霊界に値段を付けるとしたら幾らぐらいになるのでしょうか?
神界はどうでしょうか? 【死刑ブーメランが安倍に刺さる】 オウム麻原彰晃 <刑死←2018→復活?> 世界教師 マ1トレーヤ
http://rosie.5ch.net/test/read.cgi/liveplus/1531186354/l50
世界演説『大宣言』の日には、テレパシーとヒーリングで、難病も瞬時に治るよ! genericは職人芸
理解してる日本人は滅多にいない
禁止して当然だろう 何で共通部品に業務ロジック書いてるの
何で業務ロジックで継承ダウンキャストリフレクション使ってるの
凡人にはツラすぎる >>381
リフレクション使うこと自体が反対だ
変わったことしなくていいから普通に組め、と強くいいたい! 絶望的に調べる意欲が出ない経験してるんだろ、イケメンベテランスーパーエンジニアのお前らなら、そんな時どういうメンタルで乗り越えた? 僕はダウンキャストとアップキャストが曖昧になる呪いにかかった >>380
お前が理解できないことを正当化したいんだね >>380
俺の教え子は大体3ヶ月で理解してるとこやぞ 馬鹿でもメンテできるように作るのが基本じゃねーの?
これからどんどん人材が少なくなるんだから。 >>385
ベテランの人頼むぜ、俺に力が湧く言葉をくれ >>388
どこまで深入りして教えたら3か月かかるんだよ genericとかいうゴミなんていいからベテランさんのアドバイスくれよ
やる気ないときどうしてた >>395
genericをゴミと仰るほどの技術者さんに俺らみたいなのからアドバイスはできないよ
レベルが違いすぎる >>397
ごめん知らなかったんだ許してください
そしてアドバイスプリーズ えGenericsのことじゃないよな?w
秒でわかるわ もし仮にGenericsがわからないやつがいたらそいつは新卒レベル >>387,388
ちがうよ
実際にGenericをよく知ってる日本人は滅多にいないんだ
使うことはギリギリできるが書ける人は本当にいない
悲しいことだけどいろんな会社を渡り歩いた経験上確かなことだよこれは
だからそんなマイナーな知識を業務で使われちゃたまらないんだよ
素直にシンプルに考えてObjectとキャストを使いなさいな ジェネリクスの単数系見たことないな
なんだジェネリックって 馬鹿でもわかるように言語機能を縛ってプログラミングしよう
大事なことは技術をひけらかすことではない
他者への思いやりが何より大事なんだ
しかし出来上がった物は馬鹿どころか達人ですら裸足で逃げ出すほどの超難関スパゲティプログラムだった 前にライプラリー教えてもらったけどパラレル世界の用語かしら メソッドにList<Hoge>とか渡すとき、読み込みしかしないのに
ジェネリクスの指定がHogeのサブクラスになってるとだめな書き方してあること多いよな
昔C++でメソッドの引数型にconstついてないせいで悩んだのを思い出す
またきっと時間が解決してくれる なぁできるベテランはなんでこのスレで発狂しねぇんだ教えてくれよなぁww >>407
初歩だろw
新人の頃思い出すわ
まさかそのレベルが達人とか言わないよな >>409
めんどくさいじゃん
使うあてもないサブクラスのListのためにいちいちGenericsの範囲定義するとか >>404
昔twitterで話題になっていた時にMSはドキュメントの記述ルールで複数形じゃなくて単数形で
表記されるみたいなことがあったから、C#の人なんじゃね? >>407
イコールズがサブクラス受け付けてないじゃなくて? はー・・・
今の現場の開発スタイルが糞過ぎて泣きたくなる
2か月契約だけど1週間で逃げたくて仕方ない・・
コーディングするのに詳細設計ないってなんだよ・・
何がわからないことは聞けだよ・・
そんな次元じゃねーよ・・
そら遅延もするし残業もするわ >>415
HOGEクラスのイコールズがサブクラスを受け付けてないってこと >>413
時と場合によるかな
集約ルートのコードと他のリポジトリのサンプル渡されてその集約ルート用のリポジトリ実装してって言われたら出来なきゃプログラマの過失
なんのドメイン知識もないのに集約ルート作ってって言われたら新参プログラマにはどうしようもない >>413
何こいつ話割ってくんなよ
おまえらが新卒レベルだって証明されたな >>417
Javaの話な
一時気にして凝ってたが不毛だったんでやめた
ぐぐって思い出したが行けるかどうかわからん
Result calcHogeHage(List<? extends HogeHage> hogeHage) {
...
} 新卒と変わらないのかJavaを知らないのか
ジェネリック医薬品と勘違いしてるのか
ジェネリクスは悪くないのに勘違いしてたかどっちかだな >>421
ごめんよくわかんない、レビューのときに言われなければいいんじゃね ジェネリックスはC#が賢いよな
というかJavaがC#に勝ってるところなんてないけど 2か月の契約を1か月にこっちからすることって出来る? >>421
違うなcalcHOGEHOGEメソッドの定義でジェネリクス使うだろ
あと引数newしろ >>423
こうやって書いとくとList<HogeHage>だけじゃなくて、
HigeHugaがHogeHage継承してたらメソッドにList<HigeHuga>とか渡せる
C#はEnumerator<HogeHage>で引数渡したら特に何もかかなくてもそれができる
できたはず
たぶん
だからJavaもきっといつかできるできて >>426
ぱっと見でメソッド定義だとわかってくれないあなたは一年生 あれ?ってジェネリクスじゃね
Resultは何
え何書きたいんだ
Java8の文法じゃないよな
めんどい!
Javaやめたら ここでジェネリクスとかデリゲートとかの話はやめて下さい
わからない人もいるんですよ! そう、ちょうど>>429みたいなかんじで
すこぶる不評だった… >>428
public static void sub(){
メソッド定義例な
private とかつけてくんないからわかんなかったよ1年生
javaやめろ >>432>>433
つけなくてもめそっど定義できるよ
お前がわかっていないと文句を言ってるわけじゃない
実際見返して、たいして便利じゃないうえに非常に目にうるさくて鬱陶しい
あんまり見ない記述で読む人がびっくりして読むの遅くなる なーんか、ジェネリックスの記述方法って、キモいんだよなぁ…。
代案があるわけじゃないけど、キモいんだよなぁ…。 >>401
知ってる日本人たくさんいるね
ジェネリクス使ったほうが便利だよ 結合テストで大量に出てるバグを
機能作った担当とは別の人間に直させて
さらにデグレードさせててワロタ >>430
いるわけねーだろw
みんなアホのフリしてるだけだぞ >>438
工数が増えれば動く金も増える
日本のITはエンジニアリングじゃなくてビジネスなんだぜ >>438
リグレッションテストをしない深い理由でもあるの? >>442
ビジネスで品質担保出来るといいなぁ
俺はもうどうでもいいけど
>>444
さあPMとPLにテスト方針を聞いてほしい
方針なんてないけど
あるいは直したって言い張る修正担当に聞いてほしい >>425
> 2か月の契約を1か月にこっちからすることって出来る?
契約は当事者間の合意に基づいて締結するものだから、
一方的な変更は、普通はできません。
どういう状況ですか?
詳しく。 >>447
JUnitで間に合う範囲はそうしてる
UIテストの自動化ツールってだいたい有料じゃないか… >>450
seleniumは無料って知らなかったのか このスレ退勤中の社畜が延々JavaとC#の話しててきもちわるい 2chの主層の氷河期の平均年齢が40ぐらい社畜まっさかり Javaが有料になったら
使う理由がなくなっちゃう >>454
ワッチョイでも導入したら全部同じ奴だったりしてな 昔めちゃめちゃ凄腕のエンジニアの先輩がいたんだけどさ、板違うけどネラーだったんだ
このスレにももしかしたらいると思う
気が知れねぇよ 仕様がカッチリ決まっててあとはコーディングするだけっていう案件が多い言語を教えてください
その言語を今から勉強します
もうJavaの案件はろくに仕様決まってないか
エビデンス100枚越えになる鬼のようなコーディングさせられるゴミ現場しかないので嫌です 嘘だろあんたはこんなスレで何を求めてるんだ
ぱいせええええん 嘘だよ
だれもいるわけがない
適当に誰にでも当てはまることを
みんなが面白がって適当にほのめかしている
だれもいないんだ レス分析した結果
ボット 5
おっさん 2
新人 1
ごりら 2 オレオレフレームワークはなぜ生産性がマイナスになるのか メジャーなフレームワーク使ってても生産性がマイナスになるのがジャップクオリティだよ? 下請けイジメの鉄板ネタ
自社フレームワーク強制
自社規約強制
エクセル&ファイル共有で管理強制 メジャーなフレームワークにロクなものがないのが出発点なので、
それ以下の脳力の奴が作っても良いものができるはずがないという、
救いようのない世界。 貸与品であるパソコン、VPN接続用トークン、モバイルルーターセットで無くした人が出た
うちの会社じゃないことを祈るわ
>>468
> エクセル&ファイル共有で管理強制
ほんとコレきついわ
管理ツールのありがたみを感じながら仕事してます。
ええ、キックオフ時点でなく、「1週間以内には入るよ」
といわれ早1ヶ月 >>469
PHPerは仕方ない気がする
FWほんとクソしかない プロパー社員が「自社作業」とやらに1日費やして全然仕事してくれないのなんなの
そのくせ頭数には入ってるせいで他のメンバーの負荷が上がるし意味わからない プロパー様は色んな仕事を同時に抱えてるから1つのプロジェクトにつきっきりにはなれない
相手の立場になって考えよう >>140
3が多いですわ
LINQは便利すぎますな
ただ、たまにVC++で普通のコード書くときに不便さで泣きます 巷のフレームワークは出来が悪い
俺が作った奴は最高とまではいかないが
最良に近い >>476
Golangを知ると目からウロコだぞ
不便が便利な不思議な世界 >>477
PHPerのは巷のは出来が悪い
オレオレはもっと出来が悪い
だからね・・・ 【搾取】年収1,000万円以下はパートでやれ【対策】
☆不利益で迷惑だから料金増やすか生産減らせ☆
相場下がって迷惑だから年収1,000万円以下はパートでやれよ!
アメリカのSEは多重派遣なしで1,000万円以上の高収入
日本のSEは多重派遣ありで1,000万円以下の低収入
【アメリカ】
スーパープログラマ
時給10万円だったり、ストックオプションで数億〜数十億円稼ぎだす
Javaフレームワーク
〜3600万円
PHP
〜2400万円
COBOL
〜1700万円
技術サポート
〜1200万円
年収中央値:1175万円(アメリカ労働統計局調査、サンプルは111万人)
70歳でも仕事があり、年収は下がらない
数年単位で転職する(一つの会社に長くいるのは危険)
管理系の職種は雇用が不安定で、報酬も高くない
【日本】
平均年収:430万円(情報処理推進機構調査)
Web/ゲーム業界(昔ほど報酬は高くない)以外は人月単位のため、報酬には上限あり
年功賃金を採用する企業では20代後半までの給料は一部の例外を除き低い
間接雇用が基本(大手のSIerでも客先常駐派遣が少なくない)
40歳以降になるとリストラ候補となり、一旦リストラされると低賃金職か、長期間無職となる
大企業の場合は管理職トラックに進むためコーディングはしなくなり、
プログラミング経験が昔あっても35歳以降の転職は難しい
転職回数が3回超えるだけで大手には書類で落とす。
アメリカは多重派遣搾取しない
http://getlife.hateblo.jp/entry/2014/06/19/034109 人生って飽きないか?
自殺して無になってもう二度と有になりたくねえわ。 内製開発で本来1つのシステムを俺も含めた派遣3人雇って3つの大機能ごとに割り振ったら3つのシステムになっちゃった
機能要件非機能要件でクラスやメソッド重複しまくり
正社員リーダーは年長の俺に指揮を取って欲しかったらしいけど華麗に無視して自分のシステムに専念した結果大変な事に おれは海外の仕事いくつかやったよ。
旅費出してくれるし、通訳つけてくれるし、
バカンス気分でやりましたw
とっても楽しかったでーす! C言語での債権取引のシステムでサンノゼに行きました。
これは人月70万でしたけど、
インドネシアの発電所のシステムはC言語で月25万でした。
アジアの仕事は一杯ありますけど安いですね。
語学できなくてもOKという仕事もいっぱいありますけど、
とにかく安いです。
旅行のつもりでいくならいいと思います。 >>486
下手くそやなぁ
設計書はいらんが、コンテキストマップぐらいは作ってからコード書けよ >>491
派遣の俺が俯瞰するの?
まあ残業規制された他の派遣と違って残業いっぱいして良いよと破格の待遇だったけどさ
基本給は横並びだぜ できる奴ができないクズどもを介護する
それがIT業界の常識なんだよね
技術を持っててもクズに合わせて使用禁止
仕事が早けりゃクズの遅延を引き受ける
クズにできない難しい問題も全部代わりに解いてやる
有能は無能に忠実な従者となって無能の面倒をみなきゃいけない
でも時間当たりの給与は同じ
給与が違ったら不平等で良くないからな https://www.youtube.com/watch?v=UE0PvmVfGR8
この動画の女の子を見ないで
ノートPCの画面を見ていた俺は
おかしいのだろうか?
オカマじゃないぞ!
プログラマなら画面に惹かれるだろ? 海外なんて東京の劣化版だろ?
東京に勝てる都市なんてないんだからさ。
バカンスならホタルナに乗って浅草行けば十分さ。 >>495
電線まみれ
景観ばらばら
景観法を強化しよう >>486
インターフェースがあってりゃ何の問題もないだろ 東京に来た観光客は落胆するらしいね
文化的な価値は無いし、かといって大都会の華やかさみたいなものも、ニューヨークなど各国の代表的な都市に比べると遥かに劣る
単にそこそこデカくて汚い都市といったところ >>474だけど愚痴りたいから追記
若手プロパー社員がPG要員として数えられてるのに実際には現場作業あまりしなくて、
WBS上若手に割り振られてた作業が他メンバーにのしかかってくるのが納得いかない
最初から0.5人月とかで計算してくれればいいのに >>500
まあまあ面倒を見てあげなよ
ボランティアって素晴らしいだろう?
心が洗われるよ 景観がバラバラなのが都会なのさ。
整備なんてされてたら、それだけ人が少ないことの証拠なんだし。
整備できちゃう程度の規模だから仕事がないんだよ。 >>500
時間で作業した分だけ金をもらう契約で働いてるのじゃないのか?
なら、プロパーのせいで作業が遅れようが
プロジェクトが火を噴いて失敗しようが関係ないわな。
まさか関係あってしまう偽装派遣?
いまどきそんなことはないだろうけど・・・ 一般派遣、特定派遣、偽装請負
実は良くわかってない僕 天と地ほどちがうが
あえてわからないようにして誤魔化すのが政府の政策だからしょうがない でも一般派遣の場合、派遣先はもう決まってるわけだから
その派遣先と顧客の間は、基本的に請負なわけだ。 偽装請負ってのがわからん
請け負ったフリして請け負ってないのか こきつかうだけこき使って
いざとなったら製品の未完成を理由に金払わない 請負の場合、本来なら顧客の社員が業者さんの末端の人に
直接指示しちゃいけないんだとさ。 顧客が会社に金を払わなくても、社員は会社から
給料がもらえるから問題ないらしいのだが・・・ 顧客のほうから「定時後に会議やります」ってのも違法なんだっけ? 時間指定や場所指定はNG
いわゆる偽装フリーランスはその辺で引っかかる ヒュー・エヴェレット3世と菩提達磨はどっちの方が賢いですか? 5人がかりでドキュメントの修正に取り掛かっていたが
今週中に終わりそうに無い・・と泣きつかれて俺+2人追加(定時後)
マジでアホくさい作業で死にそうになるわ
もうやめよう、神エクセル・・・マジで プログラマじゃないんだけど気になる疑問があるから教えてほしい
独学で学んでて、分からないがあったらネットで調べて理解してコード書くけど職業プログラマもそういうことはやるの?
勝手なイメージでは公式のドキュメント的なのは見るけど個人サイトの解説みたいのは見ない、またはそもそも設計書?的なのに具体的な実装法が書いてるからそんなに分からないーてなる事が少ないのかなて想像してるんだけども >>524
なるべく公式などの信頼できるソースで調べるようにしてるけど、欲しい情報が見つからなかったり、新しく取り組む分野でまずは取っ掛かりとして広く浅く把握したいときとかは、個人サイトも役立つね。
業務で使用する際にはなるべく他のサイトも調べたり自分でテストしたりして裏をとる必要があるけど。 >>524
仕事によって違うかな。
でも、職業プログラマは速度と効率優先だから、
検索しまくって、なるべく速く作ろうとしますよ。
品質と速度はトレードオフ的なところもあるけど、
それを高次元でバランスとるのがプロ。
アマチュアだったら、ゆっくり悩みながら作ればいいんでないかな?
そのほうが勉強になるよ。 >>524
> 独学で学んでて、分からないがあったらネットで調べて理解してコード書くけど職業プログラマもそういうことはやるの?
個人的にはその学習法お勧めできない
A、B、Cをひとつずつ順に理解・・・
ってやるより、各論について「ほーん、こんなものもあるんだ」程度にとどめておいても良いと思う
ありがちなんだけど、ABCを順に理解するより、AB知ってCを知ったらABCが全部繋がって
どーんと一気に、順にやるより深く、時間効率よく理解できたりする >>524
分からないことは公式ドキュメントも見るし個人サイトも見るよ
職場によるけど普通は設計書作るのももプログラマの仕事なので実装方法なんて書いてあるドキュメントはない
下手すると要件や仕様すら怪しいことも多々ある 本やサイトから情報を探すより、今のシステムの内部にある
既存のソースから探すほうが先らしいぞ。 >>524
VB開発はドボンというサイトからのコピペで実装はほぼ完了する プログラマ不要のノンプログラミングBIツール使ってるけどプログラマの俺に使えと言うんだよ
いやいやユーザーに作らせろよ意味解らん 先生! JP1は
プログラマ不要のノンプログラミングBIツールに入りますか? 請負で設計やらせて難癖つけて設計書だけ奪って踏み倒す
これ王道だよね ノンプログラミングツールでも結局アルゴリズムは組まんといかん
GUIで全部組むとか情報無い分コードより難しくないか
小さいサンプルは別にして >>534
そうだな。
だから競争入札なんて素直に降りろって言ってるわけだ。
あれ、別のスレだったかな? マイナーなノンプログラミングツールとか使いづらいし覚えても潰し効かんという >>524
まずはネットの質問サイトに投げる
回答を待っている間に同僚に聞く
同僚が回答に詰まったら、即逃げる。※知らないのに教えようとする人が多い業界なので注意
過去の案件で同様の事をしていないか探す
つまり、社内資料や同僚(場合によっては知人など)まずはリアルの知り合いに直接か電話、チャットなどで確認
次に公式サポートに投げる。即答が必要なら電話(レスポンス速度重視の場合)。そうでなければネット問い合わせ(スループット重視)
サポートからの回答が文書で貰えるほうが不具合時のエビデンス、情報の蓄積・共有、再問合せ時の根拠、間違いのなさなどから便利
あとは公式ドキュメント、MSDNなどの公的なもの、公式掲示板を巡る
次は企業がやっている解説サイト
そしてググって出てきた個人運営のサイトを見る
ネットの資料に関してはコピペして動けばそのまま使う。エラー処理はプロジェクトごとに定型処理があるから修正する場合もあり
コピペ用のサイトは大抵誰もがお気に入りのサイトを持っている
ここまで調べて最後にネットの質問サイトについた回答と答え合わせをする
質問サイトの回答は質はバラバラだけど気づきのある気の利いた回答が得られる場合もあって有益なことが多い
ここまで完走してまだわからなければ上記の繰り返し
ちなみにネットショップ業界ね。多少のバグがあっても許されるけど即対応必要 >>533
細かい制御しようと思ったらJP1スクリプトやWindowsバッチファイルと連動が必要
例えばバックアップみたいに長時間かかる上に成否判定が必要な処理、
フェイルオーバーのように影響範囲が多いものなど少し慣れがないと失敗しやすい処理も多い
本来は情シスや社内SEが使うものだろうけど素直に専門家にまかせたほうがいいのではないか 専門家に任せる場合、そいつにサーバーの各種情報・権限を
与えないといけなくなるから、後々の情報漏えいが怖いらしいぞ。 >>539
ほぼ完成してこれから本格運用って時に
「実は日本だけじゃなく中国の工場でも使うソフトなんだよね」って言われて
ネットワーク屋が青ざめるとかよくあるわ
最終的に中国ネットワーク事情を考慮しつつDBとの接続頻度を減らして、WAN経路、AWSとさらに中国工場内のLANまで含めた見直し
マスタに登録する内容も中国語っていうのを本番運用後に聞かされ祈るしかない状況だった
ただ、中国の人は不具合に寛容というか興味ないんだよね
回避策あればそれで充分
そのせいかあまり熱心にテストしてくれない
依頼した事は即対応してくれるから日本人相手よりはやりやすいけどね
日本人だと細かいとこまで(例えば罫線の太さが気に入らないとか)かなり要望くれて完成するまで長時間にわたるんだけど
中国人の場合はテスト用に配布した場合ですら「あ、もう本番で使ってます」ってぐらいスピード感違いすぎて笑う
ITの世界は中国人的な気質のほうが合ってる気がするよ >>542
それ単に時代遅れなだけ。
日本にもそんな時代があったのさ。 気質の問題じゃない
目的の達成に何が必須でなにがそうでないか理解していない
単に視野が狭いんだ >>535
アイコンを線で繋いでフローチャート書くとその通り動く開発ツールをお客様都合で使ってる
苦しい ユーザーが使えないのであればノンプロである意味がないよね
ただの縛りプレイ 【搾取】年収1,000万円以下はパートでやれ【対策】
☆不利益で迷惑だから料金増やすか生産減らせ☆
相場下がって迷惑だから年収1,000万円以下はパートでやれよ!
アメリカのSEは多重派遣なしで1,000万円以上の高収入
日本のSEは多重派遣ありで1,000万円以下の低収入
【アメリカ】
スーパープログラマ
時給10万円だったり、ストックオプションで数億〜数十億円稼ぎだす
Javaフレームワーク
〜3600万円
PHP
〜2400万円
COBOL
〜1700万円
技術サポート
〜1200万円
年収中央値:1175万円(アメリカ労働統計局調査、サンプルは111万人)
70歳でも仕事があり、年収は下がらない
数年単位で転職する(一つの会社に長くいるのは危険)
管理系の職種は雇用が不安定で、報酬も高くない
【日本】
平均年収:430万円(情報処理推進機構調査)
Web/ゲーム業界(昔ほど報酬は高くない)以外は人月単位のため、報酬には上限あり
年功賃金を採用する企業では20代後半までの給料は一部の例外を除き低い
間接雇用が基本(大手のSIerでも客先常駐派遣が少なくない)
40歳以降になるとリストラ候補となり、一旦リストラされると低賃金職か、長期間無職となる
大企業の場合は管理職トラックに進むためコーディングはしなくなり、
プログラミング経験が昔あっても35歳以降の転職は難しい
転職回数が3回超えるだけで大手には書類で落とす。
アメリカは多重派遣搾取しない
http://getlife.hateblo.jp/entry/2014/06/19/034109 JP1って名前聞いたことあるがなんなんだあれ
バックグラウンドジョブ管理? >>546
営業「独自の強力な生産性ツールを使ってるので安く早く高品質に開発できます」
これを言うためだけに導入してるので意味はある
実際には生産性が上がるどころか、慣れてないと逆に負担が増えるんだけど、末端の派遣PGに全ての負担を押し付けるだけだから市民階級には問題なし linuxのシステムをansibleで管理するのはノンプログラミングといえますか ニンテンドースイッチを買おうと思うけど、周辺機器とかいろいろ買わなければならないものが多すぎて嫌になってきた・・・。 オレオレフレーム大規模プロジェクト
コメント見てコーディングして机上デバッグしてコーディング完了とする
逝かれた現場から逃げ出す方法を教えてください 答えてくれた人ありがとう
そういう部分では特別大きな差はないのね >>560
>>562
数学者と神学者はどっちの方が凄いですか? >>554
好きだよ好きがとまらない、その6000行の6重forループが好き、8段ifが好き、グローバル変数が好き、その意味のない連番のついた関数名や変数が好き、条件式に副作が有りすぎてどう分岐されるかわからないコードが好き、好き 日本人で特定派遣やりづらくなってきたからって
今度は外国人使った中抜きが増えてきたな 名札に単価も書いてほしいわ
自分が低単価って確証が得られればなんの罪悪感もなく手を抜いて定時で帰れるのに >>566
自分が時給800円とか低賃金でも
安い単価とは限らないからね。
そこが大問題だよな。 高い給料欲しければ
皆が欲しがる人材になればいいだけ。
プログラマにとっては簡単なことだろ? この板で人がほしいなんて言ってる奴がどれほどいた? 金が欲しいわけじゃない
薄給でこき使われるのがむかっ腹立つだけ
薄給でもいいけど薄給なら仕事は最低限でさっさと帰りたい 金は自由をくれる
金というか、金を得られる状況や能力が 奴隷がせっせとお金を運んでくれるからね
自由でいいね お前らほんとに俺のこと好きだよなあww
モテすぎてつれー >>564
そんだけ書き下して実際動いてるんだったら嫌う理由がないな
リファクタなぞ別の暇なやつにやらせればよろしい >>577
私はそんなソース書いてないよっ
私と仕事どっちが大事なの?
って言われたらどうするテンプレですまんけど 社員が私にくれたもの、矛盾だらけの設計書♪
社員が私にくれたもの、定時間際の改仕様♪
社員が私にくれたもの、土日出社の重労働♪
大手だったけど〜、ブラックだーなんて♪
大手だったけど〜、最後の後始末♪
バイバイ マイ スイート ワーキング
放棄してあげるわ 山の手線の危険ドラッグの広告で
女性が断るコツとして
きっぱりと断る、その場から離れるってやってて
最後に腕組みして「私は、やらない」っていうんだけど
なんの断り方なんですかねこれ
職場のねーちゃんが隣にやたらと「暇で体空いてる」っていう言い方して周りが妙な顔してる
なんか対比ですごく気になった 汚いコードを分析すると必ず細かすぎる設計書とif elseの乱用が該当する 人手不足からの賃上げ圧力が正常な経済成長に必要なのに安い外国人奴隷入れて
賃上げは絶対しない構えだからなあ絶望しかないわ。
今の生活は奴隷がいなければ成り立たないから奴隷を入れるのは正しいとか
本当に21世紀なのって思うよ。 予算ケチられて人手不足になってるんだから、
納期に遅れたってある意味しょうがねーんだな。
どうせ遅れる前提なんだから、それだったら残業の際に
残業代をキッチリもらえる立場だけは守るしかねーやな。 細かすぎる設計書か
かいてないと設計瑕疵にたおしてたが
あかんのか 安い外人入れて成果が出るならまだいいんだよ。
でも外人は、不法入国などで逮捕されたり強制送還されたり・・・
安さを追求すれば、挙句にはそういう人を雇うことになるわけだからねぇ。 神界に値段をつけるとしたら幾らぐらいになるのでしょうか? >>589
だから予算ケチられたら蹴って別の仕事を取ってくればいいんだよ。
人手不足で仕事不足なんてどんなバグだよありえないだろ。 昔はアメリカでもプログラマーの価格破壊があった。
特にCOBOLやCのプログラマーなどは、給与がバイトレベルになって食えなくなって辞める人が続出。
プログラミングの世界が複雑化したのは、上位レイヤーのエンジニア達が自らの業界に付加価値を付けるためワザと複雑な形を作ったのだと言われている。
こう無駄な複雑化でアメリカのIT業界は超高学歴化が進んで、価格破壊が収まり給与水準は凄まじく上昇したそうだ。
ただしコーダーレベルの奴は、今でもアメリカではバイトレベルの給与だ。 関わっちゃダメな案件
発注元または1次受けがN〇T
1次受けまたは設計がI〇M
銀行の金融系全般
特にI〇Mの毎回生産性あげるため〜とか謳った設計のオレオレフレームワークはホント何なんだ
キチガイか >>596
>発注元または1次受けがN〇T
>銀行の金融系全般
下が合ってて上も文字合えばビンゴかもしれん そして人集めと開発がF通
…どこだったらまともなんだよおい
携帯系はシステムより組織体質がシャレになってないって聞くし >>596
誰から見た何の生産性なのかと言う話やね
I○M的には生産性が高いんだろ ビンボーだからMacもiPhoneも買えないYO! >>595
進んだのは高度化じゃない
明らかに無駄なものは普及せんでしょ >>594
でも、どこも予算ケチってくるよ。
もっと安い人売りがいくらでもいるんだもん。
まあ、スケジュール遅れて金が飛んでくのは
安請合いした人売りの勝手だから、あとはまあ、
その金が飛んでく先が自分であればいいわけだ。 人手不足と思っているのは、あくまでも現場の作業員の感覚であって
顧客のほうは人手不足などとは思ってないからねぇ。
なにしろ顧客は、人と人売りの区別なんてつかないから。
むしろ顧客が関わるのは人売りのほうだもんねぇ。 改修機能追加常駐としては開発ペースめちゃくちゃ遅いけどエクセル設計書のある現場で助かる
仕事が人に依存しないし調べようと思えば調べられるってのは大事 >>602
諸悪の根源はマウスを発明したパロアルト研究所なのかもしれない なんでやねんw
極論言ったら、ノイマンが悪いとかになるやんw いや完全に遡ったら狩猟の道具を考えたヤツだろ
人間が楽したがる文化はそこから始まってると思う >>605
そのエクセル設計書を書く工数はコーディングの工数よりも遥かに高いってことは知っておかなければならないな
10分で書けるコードの設計書を1時間かけて作るということ
まあでも、そのおかげで底辺のプログラマにも仕事が行き渡る
生産性はともかく雇用統計には大幅プラスだね ひーひー言いながら仕様書の機能実装してよしオッケー→使いにくいからここ変更して
ってのを延々繰り返している。残業してもいいから……みたいな発言までいよいよ飛び出した
これがIT業界の洗礼なのかなって今泣いてる >>611
俺はドヤ顔で残業代出るから沢山仕事して良いよと言われた
こんな業界で一生働けるのかな >>611
慣れるまで。
ここでいう慣れるというのは、どんな変更が来るか先読みできるようになる事と、どんな変更が来てもさほど改変なく(残業無くw)できるような設計をベースとして作れるようになる、まで。 打ち合わせに参加していると、
だいたいどういう変更がありそうかわかるけど、
プログラマごときは出席しないでよい、などという思いあがった
ユーザ―の場合、「忖度した設計」することができないから、
後ですごく困ったことになる。
プログラマは打ち合わせに出席すべき。
だって、出席した奴が馬鹿だったら、
その馬鹿からの説明の範囲しか知ることができないから、
その馬鹿のレベルを超えるシステムは作れなくなってしまう。
で、だいたい上司にゴマすってる馬鹿がリーダー格に
なって打ち合わせに出席したりするから困ったもの。 >>612
境界値テストしたらそんな操作しないからいいって・・・ >>610
もちろんその通りで今の現場は大変優良だと思う
ただ本来どこもそうあるべきだわ
打つだけで設計書残さないのはその後の機能追加の難易度を大幅に上げるし土方側も期間短くておいしくないし何もいいことがない ファーストサーバのZenlogicってなんで全然復旧しなかったの? >>617
難易度が高いのはコードでも設計書でも変わらんよ
特に誰でもコードが書けるように詳細まで書いた設計書はコードと同じかそれ以上にメンテナンスが難しい
なぜなら設計書はプログラムと比べてシステマチックに管理されておらず(フリーフォーマット)、
静的解析によるサポートもリファクタリングツールもユニットテストもUIテストも存在しないから
変更のリスクが恐ろしく高い
この事実から目をそらす人が多すぎるようだね >>614
設計は元請け正社員様なのが定石
その正社員様が瞬間湯沸かし器で論理矛盾をどうするか聞くとお前で考えろと発狂するのも良くあること
で、こっちで考えたものをお披露目すると、なんでこんな仕様にしたと激怒して派遣元にクレームという流れも経験済み >>620
>>特に誰でもコードが書けるように詳細まで書いた設計書
コレはゴミですわ そんなエクセル作ってる間にコーディングしろよって話だな >>623
そう
まさにゴミなんだけど
外注の派遣さんを使うと詳細すぎる設計書がないと全く働いてくれないから作るしかない 偽装請負や二重派遣とかって誰が罰金払ってるんだろう?
顧客なのかねぇ? 汚いコードの元になった設計書って同じぐらい汚いんだよね
そもそも論理的な設計が狂ってるから、それを文書としてアウトプットしたってろくなものにはならない
設計が綺麗ならダイレクトにコードにアウトプットしても問題なく読める
むしろ自然言語より読みやすい >>629
ツォンカパとオックスフォード大学の数学教授はどっちの方が賢いですか? >>630
お届けするには、今から13 時間 22 分以内にお急ぎ便を選択して注文を確定してください(Amazonプライム会員は無料) 裏口入学かぁいいなあ
青春犠牲にして第二志望だよオレ
日本の権力者はほんとやりたい放題だね
国民はさもっと怒らないとだめだよ
こんな国は民主主義じゃない やっぱりあのPMは進捗報告の数字しか見てなかった
アラート挙げても全部無視 >>635
でも末端のPGより給与も評価も高いよ? だからなんだ
アラートがPMに無視されたんだ
俺が困ってるんだひとの給料の話なんかしてない >>637
ID無い板だとお前みたいに成りすまして
わざと叩かれるレス書き込む奴いて虫唾が走るわ 美味しいとこは吸い上げてミスはPGに押し付ける
あとは怒鳴り散らしながら進捗を眺めるだけ
イージーすぎて笑えてくるわ >>634
日本神話と北欧神話はどっちの方が崇高ですか? 本当にそれはミスだったのか?
相手はお前の理解力のなさにげんなりしているかもしれない 「わかる人と話がしたい」という台詞が
管理者はスゲーむかつくらしいぞ。 件名:【アラート】緊急報告【重要】
やばいです仕様矛盾どうにもなりません時間もたりません(略
件名:Re:【アラート】緊急報告【重要】
スケジュールに間に合うよう仕様通り実装してください。 アラートなんて言われたって管理職になにが出来るわけでもなく・・・
せいぜい代わりに怒られることぐらいだな。 誰でもわかるような設計書まではいかなくともDBからどのテーブルのどのカラムから取ってくるくらいは書いてほしい… >>649
最低でもテーブル名とカラム名は必須だな。
いまどきは設計なんかしなくても下請けや派遣の常駐プログラマが
忖度しながら仕事してくれるから
SEは何もしなくてもいい、と思ってるような感じはするな。 残業代が1.5出る派遣会社いたときは基本給20万でももりもりお金が貯まっていったな
休日出勤すると2.0だった 結局自分のしたことを人が都合よくとってくれるかどうか
能力によって期待値も上下するから怒られ度は一緒
不条理だ デリヘルにもNGプレイというのが認められているが、ワイらにもNG現場認めてくれ
ワイは気になる木にはもう二度と行きたくない
逆によかったのは、ゼロ戦のメータ屋だな、あそこは良かった、なんか緩いし >>649
逆にソレがなくてどうして設計書として成立するのかわからんぞ
「なんかいい感じにデータ抽出してください」
「こうなったらいいなぁ・・って思いません?」
なんて書いてあるわけじゃぁ・・(過去の記憶がフラッシュバック) >>656
具体的にどこからどの値を取ってきて
どう計算したら良いですか?
って聞くと、なぜか怒り出す設計者様っているよな。 >>657
大丈夫だ
俺は具体的にどこからどの値を取ってきて
どう計算したら良いか指定されると
キレるプログラマだからだ
わかってんならテメーで作れよ!
( ‘д‘⊂彡☆))Д´) パーン 大昔の課題管理表やら
未公開の要件定義やら
誰も見ないような規約持ち出して
ねちねちいじめてやる >>657
家の設計図に、家の大きさ、ドアの大きさ、窓の大きさだのが書いてなかったら
大工さん文句言っても当然のことだと思うが、それがこと設計書になると抜けててもOK的な風潮あるよね >>660
大工さんは怒るけど、お前ら怒らないじゃん。
自業自得だよ。 ここに書いてある!っつって窓枠のカタログとモデルハウスの例と設計規約をもちだしてきて
ここから類推できなかった土方のせいにする
それがIT業界 >>661
切れたら、契約切られて営業が切れるだろうに。 いいなあ質問バカはヒマそうで。。。
うらやましくてウンコがでるよ。。。 マピオンのサイトに
フィッシングサイトが仕掛けられてるから注意な。
いきなりgoogleの何かの当選です!という
表示がされてびっくりした。
ソースをちょっとみたらコメントにgaqダミー入れとくとか
書いてあるけどそこかなあ?
めんどいから詳しく見る気はしないけど、
マピオンは使わないほうがいいな。
つかマピオンは中国の下請け企業にでも
作らせてるんだろう >>649
そんなわかりきったことを書く意味はない
ドメイン層のエンティティとデータベース層のスキーマの対応はほとんど自動で決まるのだから
設計書にはコンテキストマップやドメインモデルなどもっと重要な情報を書いてくれ 些末なことを特定するのにどれほど労力がかかると思ってるのか おれが作ったスマホとかのアプリは全く売れないけど
おれ自身はよく売れる。 計算機が相手という論理矛盾に最もシビアな世界なのに求められるスキルは忖度 尊宅ってどっからでてきた言葉なんだ
40年ぐらい生きてきてまじで最近はじめて聞いたんだけど
日本建国時にいろいろ文化的に言葉に仕込みをした連中がいるらしいので気になってる
中国語で変な意味だったりしないだろうな そりゃあ、能無しなんだから忖度で勝負するしかねーやな。
ゴマすりとか酒づきあいとか。 >>684
あ、あと隣のグループの議事録も
「メールCCでこの会議連絡あったよね?」
「議事録を置く場所知ってるよね?」
「知ってるのになんで見てないの?」 アジャイルだからと言って計画を立てずにひたすら突き進むマネージャー
プロジェクトがコケたらマネージャーだけ残って私達は切られるんだろうなぁ アジャイルを何も決めずに見切り発車で開発する手法と勘違いするアホがいる そりゃあ、成果だけなら中国やベトナムで十分なんだから
忖度で勝負するしかねーやな。
ゴマすりとか酒づきあいとか。 >>691
私は下っ端だから何も言えない
なんかもう嫌だ >>680
設計に労力がかかるのは当たり前
・設計
・設計書作成
この2つのプロセスを分けて考えられん?
じっくり時間と労力をかけて細かいことを決めるのが設計
設計したことを何らかの形でアウトプットするのが設計書作成
アウトプットの形式ってのは
専用の設計書作成ツールで作る
エクセルで作る
紙やホワイトボードに書く(パシャる)
など様々で決まったやり方というのはない
そんな多様なアウトプットの形式の1つとしてコードがある
つまりコードは設計書ってことだ
設計と設計書作成の区別がついてないバカは設計をおろそかにして見切り発車で設計書作成を始めてしまう
だからおぞましい悪夢のようなスパゲティ設計書(殆どの場合エクセル)が生産される
この手の設計書は体裁だけ整えたゴミなので背後にある設計が全く見えてこない
逆に設計をよく練る人は即コーディングをしても美しいコードを作る
コードから設計がよく見えて保守もしやすい >>268
こういうのも実は設計する段階ではキッチリと決まっている
設計→エクセル設計書作成→エクセル設計書からコードへコピー
この3段階の無駄なプロセスでプロジェクトを回す前提だったのに
エクセル設計書作成の工程に漏れが有ったということなんだろう
設計したことをさっさとコードとして書いてしまえば>>268が悩むこともなかっただろう >>699
エクセルなんぞで遊んでないでテストコードを書く
社会人の常識でしょう >>679
慣れたらエスパーみたいなもんでわかるものなのか?
どのテーブルのどのカラムから取ればいいのか >>703
慣れとかじゃなくて機械的にマップするんだよ >>704
機械的にマップするってどうやるんだ?
どれ取ってこればいいかわからないのに? イベントソーシングとかCQRSって誰も使ってない?
CRUDの従来型システムには無い様々なメリットがあるんだが
・実証可能な監査証跡を残せる
・履歴データに基づいたクエリモデルを作れる
・(コマンドの)副作用を気にせずに済む
・トラブルシューティングやデバッグの助けになる
CQRSとイベントソーシングの使用法、または「CRUDに何か問題でも?」
https://postd.cc/using-cqrs-with-event-sourcing/ おれの世代だと、
1.外部設計 (現在の要件定義+基本設計)
2.内部設計 (現在なくなってる!?)
3.詳細設計 プログラムの設計書
となっていた。
だが経験の豊かなプログラマが作成していた内部設計書というものが、
90年代中ごろから無くなってしまった。
なじぇ? >>707
自分は設計書にどのテーブルのどのカラムからデータ取ってこればいいか書かれてなくて困ってて
>>679だとそれが自動で決まるってあるからなにか見分けつける方法あるのかな?って思ったんよ
今の現場の画面設計書だと同じ表記で違うカラムから取ってくるってことがあったから >>708
JavaやC#やHTMLの表現力も生産性もBasicやCobolにくらべてはんぱないから
あんまりいらなくなったのもある
おれが思うに、詳細設計書を詳細に書きすぎると
製造と設計を別人が行うとき、
作業者が満足度を著しく下げる上に
作業者が考えて判断するということをしなくなってしまう
細かくかくなら達成すべきことを
内部の設計がかわってもいいように細かくかいておくべきだ >>706
ここにいるのは多分ほとんど業務系の土方だろう
普通に考えて使ってるわけがないと思うが?
イベントソースやDDDはおろかそもそもオブジェクト指向すら理解してない奴らが多数派でしょ
イベントソースなんて百年早いわ
そもそも業務系システムはリアルタイム性と正確性を重要視するから
仮にスキルが十分でもイベントソースは採用しにくいだろうね >>708
エコシステムの進化が原因
便利な入力支援もなくチェックもテストもできないエクセルで設計を練るより
快適なIDEでコードを書いてテストしながらリファクタリングする方が簡単だと気が付いた
昔はパンチカードでプログラミングしたり
コンパイルに一晩もかかったり
自動テストがまったく普及してなかったり
そもそもIDEが重くてまともに動かなかったり
なんてことがあったからじっくり設計書を練りこんでコーディングは最小限にしようって判断が正しかった
でも今はまったく状況が違うから設計書なんて要らなくなった 設計書を書いとかないといっぺん決めたことを忘れてしまう
細かいところで整合性がとれずにソフトがぐちゃぐちゃになる いらないなんて言ってるやつはものすごく小さい範囲の末端だけちぎって投げられてる土方にちがいない >>709
なんだか話がおかしくなってきたぞ
なんで画面設計書にデータベースが出てくるんだ?
設計をちゃんとしてから設計書を書いたのか?
見切り発車で適当な設計書を書いたせいで画面設計書にデータベース処理仕様を混ぜ込んでしまったんじゃないのか? >>713
頭の中に置いとけと言ってるわけじゃない
決まったことをコードとして完結明快に保存するんだ >>715
自分は実装担当で現場に入ったんだそれで作られた設計書見て作ってねと言われて設計書見たら画面のここはこのデータを表示してってのがデータベースの値を取ってくるんだろうけどあまり詳細に書かれてないんだ
データベースのテーブルから推測したりして探してみたりしたけど似たようなテーブル名やカラム名が多くて判別つかないんよ
最近はPM?の人に聞いて教えてくれるけどなら最初から設計書に書いてほしいかなーって 三層アーキテクチャも知らない素人が設計書を書くとか冗談じゃないよね
画面にデータベースをマッピングだって?
そんな設計書に付き合わされるプログラマはたまったもんじゃない
ようするにさ
設計書をありがたがる人ほど設計なんてしてないんだよ
設計書というなのスパゲティを書いて設計 し た つ も り になってんの >>717
モジュール、名前空間、クラス名、メソッド名
これでどこに何があるかわからんなら
そもそも設計やプログラム構造がめちゃくちゃなんだろうな
このへん手抜きせずに決めればかなり検索性が高くなるぞ
つかファイルシステムとエクセルの組み合わせの方がはるかに探しにくいわな それを整理してどれにどんな名前を付ければいいか判断するには
最初に一覧を作らなきゃむりだろ!
脳内で何千件も処理できるもんか
そしたらそれをメモ書きして捨てるか設計書に残すかってなる
捨てるのはもったいないからちょっとばかり労力を払って内部設計としておいとくことになる
設計書いるじゃねーか 場当たり的にコード改修して整頓された見通しのよさが保てるわけがない
設計したことない連中が主張の都合のいいところだけつまみ食いして
バラ色の未来を提示してる いや設計はしてるんだっていってるけど
設計したんだったら設計書かくのにそれほど苦労しないはずだろ!
なんでなにもないんだ >>722
なんで最初から全部リストアップする必要がある
受注管理の命名をするときに顧客管理の命名をリストアップする必要があるか?
分割して統治せよって新人研修で教わらなかったのか?
そんなことも教えてくれないなんて同業者として憐れみを感じるよ >>723
場当たり的に書いて整理すらしなかったものがエクセル設計書だよ
>>718などは完全にその被害者だろ
設計書は作ったけど設計はしてないとこうなるんだ
逆に良く設計してればコードがドキュメントになるので設計書はいらん >>725
机上の空論破綻はアリの穴から
どこに何をどういうルールで置くか、その分割を適切にできるかどうかは
最初にどれだけ網羅できるかにかかってる
名前はものを区別するためにあるんだ ここにいる人はどんな資格を持ってる?
VBAエキスパートは今更遅いかな 設計書を書くツールがエクセルからIDEに変わって
設計書の出力形式がエクセルからテキストファイルに変わって
設計記述のルールが厳密にチェックされるようになった
それだけのことじゃん?
コードで整理できないって人がエクセルで急に整理できるようになるとは思えんけど 一覧管理のために生まれたExcel様のパワーなめるな >>727
ログイン処理の機構を考えているときに在庫管理のことを考えるか?しないね
全てをまとめて網羅する必要などどこにもないんだよ
分割して統治せよ
君が真っ先に理解すべき概念だ
来週の業務が始まるまでに理解しておいてくれ >>733
在庫管理システムだけプラットフォーム別になってて
ログインユーザーの権限が連動してる必要あるんですけど >>737-738
全の値段は幾らぐらいでしょうか? >>735
それこそ権限管理のコンテキストで解決する問題
在庫管理のコンテキストを巻き込んではいけない
分割して統治しておいて良かったねと締めくくられメデタシメデタシだな >>711
CQRS/ESでは結果整合性を使うから、
複数のリードモデルがあると一部の反映が遅れる場合があるって弱点はあるが
僅かな期間の表示のズレも許容出来ないようなアプリケーションばかりかって言うと
そうでもないのでは? >>741
>>743
全の値段は幾らぐらいでしょうか? >>749−750
全の値段は幾らぐらいでしょうか? >>749-750
全の値段は幾らぐらいでしょうか? >>763-764
全の値段は幾らぐらいでしょうか? >>740
お前がどんな絵をかいてるのか設計書がないから見えない伝わらない
そのシステムユーザーに在庫の製品種別ごとの権限ついててログイン管理してるんですが >>766
在庫管理に特殊な権限管理が必要なら在庫管理のコンテキストに組み込むか在庫権限管理など新しいコンテキストを作るかな
いずれにせよ一般的なログイン管理と在庫管理を同時に考えることはないよ 「在庫権限管理」
ほら言葉がでてきただろ
俺がシステムの実情を伝える前にコードは設計とばかりに書き下してたら
後からどうなってたことやら >>710
多分、若い人はそういう考えなんだろうと思う。
Webを中心としたシステム構成が増えてきて、
すぐに仕様変更できてしまうから、いちいちドキュメントを
直すなんてほうが無駄に時間がかかるしね。
仕事によって作成するドキュメントの種類や内容を変える必要があるのに、
内部設計書を書いたことのないWebプログラマなどが大規模業務系には参加して、
「なにこれメンドクセ!」とか言って重要なドキュメントを書かなくなったのだろう。 >>781
今の会話セッションは「設計」プロセスな
設計中に新しい用語が出てくるのは当然のこと
プログラミングはこれから始まるんだよ
さらに言うとログイン処理の命名を決めようというときには結局、在庫管理も在庫権限管理も関係がない
ログイン処理関連の命名は在庫管理のことなど気にせず決めていいし、在庫管理も逆に同じこと
新しく出てきた在庫権限管理もログイン処理とは独立して考えられるが、在庫管理とは上流下流の関係にありそうだから、在庫管理と在庫権限管理は多少関わり合った方がいいかもね
こうして物事を分けて個別に考えられるのは分割して統治するという基本ができてるから
君にも早く身につけてほしい概念だ 日商PC検定試験のデータ活用1級って持ってるとなんか意味ある? >>782
重要、と一言で言うけど、状況によると思う
それこそシステムを作るだけなら内部設計なんていらないし、重要なことなんて何もない
システムにメンテナンスが入ったらコードと設計書を二重に直す労力は半端ではないから、重要どころかむしろ邪魔にすらなりうる
でも、客が設計書を成果物として欲しがっていて、それが金になる、という意味では非常に重要と言える 数学はともかく計算機科学はくわしいよ
くわしいはず
はず >>786
ほとんど何もしらない素人ですよ
プログラマと名乗ってるだけです
どうせセット販売されるので、自分はプログラマです、と言い切れるだけでも働けるんですね 東京大学理学部情報科学科卒
東京大学大学院情報理工学系研究科コンピュータ科学専攻修士課程修了
東京大学大学院情報理工学系研究科コンピュータ科学専攻博士課程修了
こういう学歴のプログラマーっている? あー、東京を自分の思いのままに都市計画してみたいなぁ・・・・・。
超巨大なビルとかいっぱい建てたい。
やっぱり首相にならないと無理なのかな? >>783
その「設計」と称するものを他人も理解できるように
設計書にして確認したり、一覧にして整理してみようって気はないのか
多大な工数をかけてコードにする前に コピペ改変した設計が間違ってたとかで横展開でエクセル修正してくれって指示がくると目の前が真っ暗になる
え?それどこにあんの…何個あんの…直した影響調査ってどうやんの…えっえっ?作業指示って横展開ヨロシクだけ?ってかなんでリファクタリングしてクラス化しなかったの?誰か助けて…もうやだ…
みたいな感じ >>794
コードをみれば誰でも設計内容を確認できるし
パッケージ、名前空間、クラス、メソッドで見やすく一覧化されるのでわざわざ資料にする意味はない >>791-793
全の値段は幾らぐらいでしょうか? >>804
C++11 or lator をやっている >>808
>>810
全の値段は幾らぐらいでしょうか? >>813-814
全の値段は幾らぐらいでしょうか? >>719
三層アーキテクチャって久しぶりに聞いたな >設計書をありがたがる人ほど設計なんてしてないんだよ
>設計書というなのスパゲティを書いて設計 し た つ も り になってんの
コーディング前に設計したんだと主張しつつ何のドキュメントも残せないやつが言ってることに
背筋が凍るものをかんじる
そう言い切る根拠が「画面にデータベースがマッピングしてある」ことだからなおさら
設計の負荷は無駄に高くなるが、コーダーは打ち込みゃ終わるから楽だろうに
困った状況とかなんにもいわないし
自分のスキルがあまりにも低くて指示が細かいと従うことすらできないのを
なんかよくわからない高邁な理念を持ち出して
責任を相手になすりつけてるような >>820
はいはい
高尚な理念()がわからんアホは永遠に2層アーキテクチャの出来損ない作って炎上し続ければいいよ >>821
具体的に、どんなとき困ったの
それがききたい >>823-824
全の値段は幾らぐらいでしょうか? そういや、イタリアの通貨が昔は「リラ」じゃなかったっけ? >>822
ビューとデータアクセスが結合して押しつぶされたアプリケーション、ドメインが行き場を失い
SQLやビューなど、あちこちに分散したり、逆に関係ないものが一箇所に集中したり、類似のコードが大量にコピペされるなど
可読性最悪のコードが書かれて、誰にもメンテナンスできなくなる
ぐちゃぐちゃに絡み合ったスパゲティコードはそう簡単にはテストができないので
テストがおざなりになり、潜在バグが大量に含まれた状態で出荷される
客の検収テストでバグだらけと発覚して何百、何千件ものissueが発行される
スパゲティと化したプログラムの修正は苦難の連続だ
そして相次ぐプログラムの修正に、変更しにくい設計書の正確な修正が追いつくはずもなく、コードと設計書の乖離は手の施しようがなくなる
この頃になると、どさくさ紛れにバグに仕様改変を差し込む愉快犯まで現れてくる
もはや何がなんだか誰にもわからなくなり、終わりの見えないバグの山と戦いつづける、悪夢の連続徹夜デスマーチが確定する
画面設計書にデータベース処理仕様を書くだけでこうなるんだ
おそろしいね 最後に勇者が一人で魔王に立ち向かっていくところは燃えた >>831
ほんとにいるんだよな
ただのグループ化なのにとんでもない構成作り出す奴が・・・ >>831
そういう聞きかじりじゃなくてお前が困ったこと具体的に聞きたいんだけど >>620
欲しいのは詳細設計じゃなくて外部設計やER図、マスタ設計だからそこまでメンテ大変じゃないはず
それが残ってない何やるにもソース読めDB見ろなんてのは論外で、
プログラム打ってテストしてとりあえず動くものは超短期で作れるけど一人で一生保守できるものでない限りそんなのはプロの仕事じゃないと思うな >>777
アホすぎクッソワロタ
客にコード見ればわかるよ
って言うんかwww
設計書はじめ人に伝えるためのドキュメント書けないやつは中途半端に役職つく前に頼むから転職してくれ >>831
管理や要件のスコープが悪いだけで設計書何も悪くなくてワロタw おれの予想
トランザクションスクリプトで書かれた設計書渡されて
世間で売ってる本ががトランザクションスクリプトを馬鹿にしてるもんだから
ひとに笑われるのがいやさに
無理やりオブジェクト指向に翻訳しようとしてめちゃくちゃな共通化を行い
設計書との対応もとれないオブジェクト指向ともいえない超絶スパゲッティつくってたと思われ >>851
言葉は知ってるがお前と同じ認識をしてるかどうかはわからん スパゲッティも1000行ぐらいならとくに問題はない
どこになんの処理が書いてあるのかわからないのが困る ここってThe Google File Systemとかを自ら作ったり、読んで理解して自分で作れる
プログラマーっているの?、いないだろうなあ。 オブジェクト指向→共通化って脊髄反射連想がもうおじいちゃん的で笑える >>853
1000行もあったらどこになんの処理が書いてあるかわからないのでは? 本で勉強してDRY万歳コピペプギャーみたいな価値観を吹き込まれたてのやつは
共通化もやってるにちがいないんだ >>856
お前がプログラマじゃないことは分かった >>858
お前がプログラマじゃないことは分かった 一番困るのは、コード組んでる時の神懸かりw
が、別日に直すとわけわからんw
複雑=高度ではないという事に気付こうな俺, >>860
書いているときに持っている記憶が抜けてしまうと、まるで他人の成果物と同様になってしまうのが困るのです 自分はまだ1年目だからわからんのだけど設計書にデータ取得について詳しく(DBのテーブルやファイルとか)書かれてない時どう対処するんだ?
自分はPMっぽい人に聞いてるわ 絶対効かないとわからないことをあらかじめ文書としておこさずに
属人化の行き当たりばったりの開発スタイルでコミュニケーションがーって言う馬鹿ゴミプロジェクトは
ガチで隕石でも落ちて全員死んで欲しいね >>861
そら合計ならそんなもんでしょ
でも1関数1000行はちょっと狂ってるよね >>863
>>864
の言ってる通りプロジェクト自体がクソなので諦める
設計書に必須な情報はシステムの立ち上げから必ず記録されてる必要があって、今からお前だけが書くようになっても意味なし(自分のためにやらないよりはマシだが設計書の工数が込まれてないので無理)
客も金使って意味のわからん改修不能で機能追加したらバクだらけなものが出来るだけ
会社に文句言ってとっとと次の現場行くのが正解 >>863
名前をみりゃわかるでしょう
ユーザーコード表示欄にホームラン本数を表示する人は居ない
ユーザーコード表示欄には常識的に考えてユーザーコードを表示するものだ
htmlの項目idをみたらuser_codeとか書いてあるだろ
だとしたらそこにはViewModelのgetUserCodeをバインドするんだよ
他の項目も全部同じ
こんなわかりきったことをわざわざ設計書に書くわけなかろう >>868
カラム10個ぐらいしかないお遊びやってる人はちょっと黙っててもらっていいですか? 誰がてめーのユーザーコード表示しろっつったよ
顧客のユーザーコードに決まってるだろうが
え?書いてない?なんで聞かなかったんだよ
お前のユーザーコード表示する場所そんなこと聞かなきゃわかんねーのかよ自分で考えろよ >>869
アホほどカラム数増やす人こそお遊びでしょうよ >>870
URL見ればわかるだろうが
/users/112233
ってURLだったらこのページに表示するのは識別番号が112233のuserなんだな
その中でuser_codeつったら識別番号が112233のuserのgetUserCodeってそりゃ112233じゃねえかあああああ
ってわかるだろ?ちったあ常識で考えろよ >>872
カラム名と変数名が必ずリンクすると思っちゃうくらいの規模しかないって意味ね
その結びつきが絶対と思えるほどの規模しかない規模
規模が小さいから暗黙の規約を盲信してドキュメント不要論唱える
笑えるくらいお遊びかと >>875
お前いままでなにを見てきたんだ
俺はそもそも画面項目とカラムなんてマッピングしねー派だよw
ViewModelのプロパティとマッピングつってんだろ
これでも命名を揃えられないなら素人のお遊び確定だよ 相手が過去の自分の書き込みと自分のポリシーを熟知してるのが
あたりまえだと思ってるやつがかく設計書…
匿名掲示板で >>867
うーん現場抜けるの交渉大変そうだなあでも考えてみるよ
>>868は「ユーザコード表示欄」て書いてるから「getUserCode」ってメソッド?で取得するって感じなんだろうけど
自分のとこは「△△△表示欄」てあからさまなに書いてるわけでもないし「△△△」も簡単に判別出来そうな名前でもないしDBにもそれっぽいのは簡単に見つからないんよ
あっても似たような名前で影分身してることも多い ちゃんと最初に網羅してれば
項目名称がログインユーザーコードと顧客ユーザーコードになってただろうに
もう破綻してるふふん >>889
網羅しきったことを証明できないと永遠に仕事が始まらないぞ >>885
顧客が現状理解してるなら残って期間多めで受けれるようにする(隠れて整理する)
お前しか残ってない(≒出来ない)なら顧客評価は上がる
前提条件ありでこう考えるのもあり
請負でもゴミ処理で金稼ぐ会社は結構あるっぽいよ オブジェクト指向の考え方自体は理解できるんだが、実際のコードに落とせない
参考になる書籍やサイト教えてくれませんか オブジェクト指向で作ると逆説的に
なんやかんやで障害が出たときに
追いかけて直すのがたいへんになるから
5千行あるような関数が並んでるコードの方がマシだよ。
きれいでエレガントですばらしいコードは
趣味でだけ書いてくれ オブジェクト指向の最大の特徴は継承と隠蔽だ。
だがよく考えてみると、継承は独立性と矛盾するし、
隠蔽は可読性と対峙してしまうことがある。
常にそうなるのではないが
慣れてない人が組むとどつぼにはまる。
そして慣れてない奴ばかりが現場に放り込まれて
デスマになる。
人手はない.
よってプログラミング初心者でも
わかりやすく組める関数型言語のほうが良い。 >>895
わかるわ
スコープが狭いだけでグローバル変数使ってるのと大差ないの多いし
関数に下手に同じ名前つけれるから参照さがすとき検索結果が大量に出てきて読んでてうんざりする 関数型なんて背伸びしてるんじゃねえよ
一生トランザクションスクリプト書いてろ オブジェクト指向できないクズは転職してくれ
ほんと迷惑 作りたいもんが作れりゃ概念なんてどうでもいいんだよ >>894
それは理解できてないから
>>895
巣に帰れ えーとつまり
オブジェクト指向を理解してない新人さんあるいはおじいちゃんが
5000行のモンスターメソッドを幾つも作り込んで
わけわからなくなってにっちもさっちも行かなくなって
藁にもすがる思いで設計書がー設計書がー
とわめいていたわけだ
そりゃこんなクソコード書く連中にコードが設計書なんて言っても通じないか
前提となるスキルに差がありすぎて話にならないってわけだ >>883
堀内孝雄「みなさんよくお間違えになりますが、百万じゃなくて一万ボルトなんですよ」 ここに居る連中の職場は
単体テストとか結合テストとか書かない所ばかりなの?
単体テスト書こうと思ったらゴッドオブジェクトとか作らないはず 超巨大ゴッドオブジェクト作るやつって
他人と会話する気がないコミュ症でしょ
コミュ強者は責務が分離された
適切なコメントの付いているコードを書く オブジェクト指向覚える嫌
Cで手続き型でこのままやっていきたいわ 5千行の関数書くようなおじいちゃんが、その会社ではコミュ強者だったりするんだよなあ >>907
俺が今、必ず単体テスト書くように啓蒙活動始めたところ。 フレームワークやJAVAのライブラリくらい責任が明確化されたオブジェクト指向ならまだしもオブジェクト化する構想を頭の中で作った場当たり的なものは勘弁 5000行のクソコード書くおじいちゃんがコミュ強者になってクソ設計書を周りに強要する、ということか >>912
それを非オブジェクト指向で作ったらさらにカオスになる
大雑把でも枠ができてればリファクタリング可能 設計書を周りに強要するって考えがまず間違いで設計書が作成されてないプロジェクトはゴミでそんな状況で作られたシステムはスタート時点から死にゆくのみ 開発工程でなにをやるんでもいいんだけどさ、
それって、出来るやつにしか出来ないことなんじゃねーの? 誰にでもわかりやすいコードは必ずしも良いコードじゃないんだよな
素人プログラマは両者を混同してオブジェクト指向はわかりにくい、悪いコードだなどと言い出すけど、それは典型的な勘違いでしかない
例えば初心者は、複雑な処理を関数分けして引数を渡して回るよりも、
1つの関数に全部つめ込んだり、関数分けはするけどグローバルなレジストリで状態を共有するほうが理解しやすいらしい
しかしその構造が良いコードかというとそんなことはまったくないわけで 単純なクラスを組み合わせる代わりに巨大switch文を作り
単体テストは無理と言って書かない可能性がある >>913
5000行のクソコードの設計書なんか書かんだろうから逆にソースが正ってなるんじゃないか >>915
そうか?
もっといろんな現場見たほうがいいぞ 設計書ってのは、書いた人が辞めた後に必要になるモンなんだ。
顧客というのはソースは見なくても設計書は見てくれるからねぇ。
とりあえず設計書のとーーーりに作っておけば、設計書の不備ってときには
時間を稼ぐことぐらいはできるだろう。 >>918
>>919
あるある
そしてその元になった設計書は全く意味不明で矛盾と不足だらけのゴミなんだよなぁ
こういうバカなコードを書く現場って、設計書を書くという工程を伝統的に受け継いできたから、
しかたなくやってるだけで、実質的に「設計」はしてないんだよ
見切り発車でコードを直書きするのと全く同じ感覚で、見切り発車で設計書という名のゴミを書き始める
こんな状況になるぐらいなら、しっかり設計したうえで綺麗なOOPのコードを書いて設計書は省略としたほうがマシ
それにOOPユーザーなら仮に設計書を書かなくても、XMLコメントやAPI仕様書、開発者ガイドみたいな後付ドキュメントはしっかり書く習慣があるからメンテナも安心 5000行クソコード書くやつっていうのは、スコープの概念が無いんだろうな。
だから、全部記憶力だけでなんとかしてる。
努力と根性だけで現代を生きてる原始人だな。 >>921
そそ、だから設計書作らないってのはブラックボックス作ってるっことでスタート時点で死んじゃうんだよね
まぁコミュ障パンチャーらしくはあるけど >>923
記憶力もないからクソコードと似たようなクソ設計書を書いて必死に読み比べて補ってるんだろ
すべての元凶は設計そのものが汚いスパゲティ設計書&コードなんだよ
そんなものを作ってるからコードだけじゃわからんので設計書が必要などと言い出す
OOPのコードほど綺麗に設計情報を反映した文書は存在しないというのにね >>924
きったねえスパゲティ設計書のほうがよっぽどブラックボックスだよ
綺麗なコードが手元にあればそれが完全なホワイトボックスだろが オープンソース開発は設計書がなくても高品質な製品を量産できてるよね 糞コードやドキュメントが不足しているOSSは
誰も見向きせず淘汰されるので
結果的にある程度品質が高い物しか生き残らない でもコードだけだと動作仕様はわかるけど、その仕様の意図まではわからんよな さっきも言ったべ、辞めた後の話だって。
設計書があれば少なくとも顧客に言い訳ができるんだな。
あくまでも管理職のための資料。 ソースにしても設計書にしても、出来るやつにしか書けないんだから
そこで金をケチった時点で、そのプロジェクトはもう・・・ 会社のコードはOSSの場合とは違い
仕事を受注さえすれば社内にコード品質の競争相手が居ないので
糞コードが淘汰されず生き残る
ある意味ガラパゴス化
既存のクソースを保守する仕事も同じ会社がやる事になって
他の会社に仕事を取られる事もない
そんなクソース他の会社は機会があっても引き継ぎたくないだろう IT土方の大半が技術力ないんだから
OOPなんて難しい概念使わせたら訳のわからんものが出来上がるだろ OSSでも物によってはフツーに会社がプログラマーを雇って業務の一環として書かせていたり
自社製品でそのように作ったOSSのコンポーネントを使っている場合がある
ドッグフーディングってやつ?
最初は開発チームがテストするだろうが
次第にそのOSSのユーザーもバグ報告等を行ってくれるようになる 全員が優秀であることを前提に
スケジュール組んだり設計したりプログラムの作り方を決めたりするから
デスマになるのだぜ。
仕事で集団で作る以上、その大前提が間違ってるからな。 上流の仕様がころころ変わるけど、納期が変わらないからデスマになったよ まあ、デスマなど、どうせ末端のおれらの責任じゃないんだから、
せいぜい書き入れ時ってことで、残業代をガッツリ稼げばいいのさ。 休出しても代休も残業代もなかった思ひ出
裁量労働の恐ろしさを知った ソノヘンは昭和のやつらも、ちゃんと知ってたんだよね。
だから企業も派遣という契約形態にこだわっていた。
それが特定派遣。
でも味を占めて能無しを送り込む奴らが増えたもんだから、
顧客のほうが派遣ならイラン受託にしろ、と言い出して
偽装請負という形になったわけだ。 >>938
少なくとも日本に関しては無能を大量雇用しすぎたことが諸悪の根源だろう
どこの現場に行ってもこのチームは無能の集団である、からスタートしなきゃならないPMが哀れ だからまあ、自分だけでも優秀になる努力ぐらいはしないと。 優秀でも給料は変わらないよ。
そんで仕事だけ多く押しつけられる。
それがIT業界の体質。
本当に優秀なヤツは、自分の立場が守れる程度に出来ない振りして
優秀さを隠してるのだぜ。 派遣してたけど残業もさせてくれないし、いついなくなってもいいような単純作業ばっかりで飽きた >>946
残業代定額制のおかげだな
派遣がおもわず残業やサビ残しちゃわないように
かつ企業も残業させたくなくなるように設定してある 糞コードの混入を阻むコードの番人(レビュアー)が居ないので
やがて糞コードが支配的になってしまう 給料は上がらなくてもクビにはされにくくはなるからねぇ。
せいぜいメリットはその程度。
でもクビになっても簡単にホカへ行けちゃうもんだから、
それすら大したメリットじゃないんだな。 >>948
それが、本来あるべき派遣の姿だからな。
そもそも、小泉のアホがやった技術職への派遣の拡大が間違いだっただけだ。 でもまあ、優秀なら選択肢は増えてくれる。
一般派遣でもやれるし、正社員にもいつでもなれるし、
勤務地も近いところや逆方向のを選ぶことも出来るし。 >>950
真面目で優秀なレビュアーは配置しないほうがいい
酷いコードだらけで読む価値なしとしてrejectされまくった結果コード0行の状態で納期が来てしまう
レビュアーはレビューしたフリしてOKサインを出す係
日本ではこれが精一杯 >>911
TDDはデスマ作りやすいから気を付けてな テスト書かないで納品なんて
極端な話、あなたの依頼したシステムのテストはみんな本番環境でやりますって言ってる様なものだ
人力テストは効率悪過ぎて
バグが無いかすべて人力で確認するため、リリースが非常に遅くなる
その為頻繁なリリースは出来ず、まとめて沢山の変更を一度に行ってバグのリスクが増加
面倒だから、テストしなくても大丈夫だろうとタカをくくった結果、バグが発生
など様々なリスクがある >>956
>テスト書かないで納品なんて
ん? それは発注側がテストコードを成果物に含めなかったのが悪いんだから
発注したやつが悪いんじゃね?
そんなアホの事はしらんよ。 テスト常に書く側としても。 テスト書かないで納品というのは、いまどきはゲームがそうらしいぞ。
テスト要員は一般プレイヤー。
バグを見つけてチートに成功すれば、RMTで金が稼げてそれが給料。 ユーザーにテストをやらせて何が悪いのか
仕様がないのでテストなんて作れない 休日の何もする気が出ない感ぱねえ
平日の睡眠が足りてねのかな
24時就寝5時起床はキツイのか しょうがないよね!
って言おうとして駄洒落でもなんでもないことに気が付いた >>962
24時就寝にしてどんどん後ろにずれてて寝起きも体調も悪いみたいな生活してたが
癌になって手術して休職して22時にベッドに入る生活になったら
5時くらいに勝手に目が覚めるようになってスッキリするようになったわ 【東京都】帰宅女性の背後から侵入し携帯奪う、指名手配の韓国人の男を逮捕 【!注意!】ウィルスの仕組まれているサイトと思われるURLが送られてきた。
見てみたい気もするが、ウィルス対策のソフトを入れておらず、
Windows defenderしか入ってないので、誰かセキュリティに自信のある人は、
以下のサイトがどれほど強力な脅威なのか教えてくれ!
よろしく!
くれぐれも冗談でアクセスしないように!
http://bretzel-franchising.ru/wp-content/plugins/wp-db-ajax-made/ 巡回スレでこういうことする馬鹿いるとホントイラッとするね
とりあえず通報しといたから安心してタイーホされろ >>970
ロシアの殺し屋、おそロシアー
というのをデトロイト・メタル・シティで
クラウザーが言ってた。 みずほいい加減潰れればいいのにね
こんな状態でもまだ金預けてる一般人いるのかな お給料貰ってるとはいえ朝9時厳守、最速でも17時ごろまで拘束、しかも毎日ってちょっとした人権侵害だと思うの
昼までに出社、ノルマこなしたらいつでも帰宅OKじゃいかんのか?
健康で文化的な最低限度の生活を保障してくれないと困るぜ自民さんよー 奴隷に人権はないと平気で言うんだw
人手不足になる訳だ >>977
そうしたいならそういう契約すればいいだけじゃね >>977
外資系投資銀行にてシステム開発したことあるけど、まさにそれ。
仕事が終わればいつ帰ってよい。
自宅勤務も充実してて、会社のPCにリモートデスクトップで
接続して作業してもOK.
仕事さえできれば何やってもOKという雰囲気だった。
上司が日本人だったから英語は少し話せればいいだけだったし、
俺にとってはすごく楽しくて、やりやすい職場だった。
だから外資に行けばいいよ。 で、なんでそんな良い職場を辞めたわけ?
使えないからクビ? 派遣で行く分には、ブラックで知られる会社でも
その被害をあまり受けずに済むもんねぇ。 ブラックならともかく普通の仕事時間にすら耐えられないってダメ人間でないの、、 >>719
開発って数か月ぐらいかかるだろ?
逆に設計は数日じゃん
だったら設計を可視化してチェックすれば開発の工数見積もりできるわけ
工数がわかれば金額がわかる
どんなものに対していくら払うかっていうのがわかれば
金払う価値があるかどうかわかる
だから設計は大事 >>987
派遣って大声で怒鳴られたり殴られたりするやつだろ?
実際に手を出すのは大手だとNぐらいだわ >>991
それは設計してるふりだから早いだけか
設計書のアウトプットだけを設計と言ってるだけ
実際には設計には長い時間がかかりアウトプットは短い 先を見通す能力が低いと設計も雑になるから逆に早く終わる
その状況と能力で時間かけたってそれ以上質が上がるわけじゃないから
それはそれでいい気がする
やってみんことには そんな工数使っていったい設計書に何書いてんだ?
詳細すぎる設計書にはデメリットしかないぞ 日本語の本だと設計書の書き方的な参考書いっぱい出てるけど
ガイジンの本でそういうの見たことねーな
ガイジンって設計書を書いてんのか? 長いこと騙されてたけど
そもそもあのボケどもに設計って
無理なんじゃね?
オブジェクト指向もメリット皆無だし
設計手法回りの技術はとにかく怪しい
適用しない方が開発効率が高いものが多い
新技術が出たら必ずメリットとデメリットを書き出して
明確に工数削減と品質向上に数字が出せないなら導入を見送るべきだ このスレッドは1000を超えました。
新しいスレッドを立ててください。
life time: 8日 10時間 24分 10秒 5ちゃんねるの運営はプレミアム会員の皆さまに支えられています。
運営にご協力お願いいたします。
───────────────────
《プレミアム会員の主な特典》
★ 5ちゃんねる専用ブラウザからの広告除去
★ 5ちゃんねるの過去ログを取得
★ 書き込み規制の緩和
───────────────────
会員登録には個人情報は一切必要ありません。
月300円から匿名でご購入いただけます。
▼ プレミアム会員登録はこちら ▼
https://premium.5ch.net/
▼ 浪人ログインはこちら ▼
https://login.5ch.net/login.php レス数が1000を超えています。これ以上書き込みはできません。