プログラマの雑談部屋 ★11 [無断転載禁止]©2ch.net
レス数が950を超えています。1000を超えると書き込みができなくなります。
>>819
まあ確かに日本でしか働いてないけど無駄な工数多いわ >>825
何のために何をしたいのか
どういう方式でやるのか
IO
くらいは文書ほしい派だなあ
人が入れ替わってなんのつもりでこのコード書いたの？ってわからなくなるのしんどい >>852
なんのためかわからないコードってそれはコーディングが下手なだけ
クラスのもつ責務が1つで明快な名前が付いてれば、なんのため？などという疑問はありえない
コーディングに時間をかけてこなかったなんちゃってエンジニアが上流に行くとコーディングが下手なのを誤魔化してドキュメントで補おうとするんだね >>854
日本で働いてる人で中国人、韓国人、インド人が多い気がする
俺が働いてる職場だけなのか気になって質問した 仕様を設計どおり作れないのはレベル低いだけだし、設計時に仕様不具合が見抜けないのも、指摘して提案できないのも結局自分のレベルが低いと言ってるのと同じで、しかも自分に返ってくる。 中国人が少しいる程度
その辺は人事のコネ次第じゃないだろうか
優秀な人は取り合い激しい >>857
つまり上流不要ってことだな
何でもかんでも下流が面倒みなきゃならん
上流は自分が作ったものに責任を持って下流に投げなきゃ コーディングのことまで考えて設計しないといけないもんなの？
プロのプログラマに投げるんでしょ？初心者育成ならともかく給料払ってる相手にそりゃないでしょ コーディングまで口を出すなら最初から設計にコーディングまで盛り込むのが常識
逆にそうでなければコーディングには口出ししてはいけない プログラマー上がりの上流ならコーディング視点で設計書けるでしょ
まともなSIerならプログラマー経験の無い上流がいてもPLにマー上がりの人を補助で付けたりしてカバーしているよ
ただしITでなく巷のアホ企業の案件受けちまうと悲惨だけどな バカ「ソバを作って」
蕎麦屋「ほい」
バカ「このソバはニセモノだ。食べられないよ」
蕎麦屋「は？」
バカ「あの素材とあの工程が間違ってるんだ。厨房を貸してくれ。本物のソバを作ってやる」
蕎麦屋「お帰りはあちらになりま〜す」
まあこれが常識的な対応だわな 最近はどの会社も、足元見れる相手には昇給してくれない
転職するんだ 仕様の曖昧なところを確認すると「ほとんどないと思う」と意味ないこと言うアホ上流はどうしたらいいだろう？ エース級なら転職しようとすると引き止められる
もし簡単に辞めさせてくれるならその程度の人材だったということ 話は変わるけど会社が違法派遣をしているので労基署に通報してやった
みんなで通報してこの世界をよくしていこうぜ
みんなでやれば怖くない！ >>867
そんなやつ見たことない
むしろ引き留められるのは会社がブラックで気の弱い土方の場合 マジで足下見てるよな
対社外のＳＥばっか給料たかくてマジむかつくわ
この前机にＳＥ女年齢２９？ぐらいの給与明細の封筒あったら
こっそり隙間から見てみたら手取り38万とかで吹いたわ >>855
いやでも下手な奴がコーディングしたソースしかなかったらもうお手上げだし >>829
自動生成プログラムやってたけど、並列で流せるし帰り際に流して朝来て終わってない
やることなければ無理にすることないと思うけど
できることはいくらでもある >>868
うちも通報したいわ
取り合ってくれるもん？
業界の慣習だから…ってならない？
そういやちゃんと派遣してるとこは来年から同じ職場は3年以内になるらしいね >>873
下手くそは解雇するんだよ
それが正常な世界だろ 明らかな違法行為とかなら気兼ねなく通報するんだが
うちは単純に無能しかいないせいでブラックなんだよな
みんな死ぬほど頑張ってるからなんも言えない
一人だけ定時で帰ってすいません >>875
来年から特定派遣禁止だから動くはず
しかしこの業界のシステム本当にやべーわ
A社→B社→C社→D社って来てるのに
「所属はC社扱いで頼みますわ〜」とか普通に言われるし
いやいやアカンだろって >>868
その手の通報はみんなやってるから今さら意味ないよ
おまえは思い切って通報したつもりかもしれんが、日常的に通報するのが趣味のやつもいる
で、労基署は実名通報で具体例があってやっと話を聞く程度
基本的には企業の味方だからな
>>870
自分の下に何人ついてるかで給料は決まる
もしくは複数企業を相手にしてるとかね
質よりも範囲が重要 >>829
いまどきクラウドでワンクリックしたら大抵のアプリは構築までやってくれるよ >>859
どこが悪い、というのを言うつもりはないよ。
ただ、少なくとも、自分が受けた仕事、プログラマなら仕様不具合があれば作る前に指摘するべきだと。
プログラマだって不具合だすだろ、出すやつは不要とはならないだろ。 >>882
１つ２つならまあ構わんよ親切に指摘してあげる
でもさ現実の設計書でそれやってたらキリがないんだよハッキリ言ってね
仕様書の不備を調査報告する工程を別に設けてそのぶん金をもらわなきゃやってられない程度
それぐらいバカ上流の設計書ってのは酷い 設計書をテストしないからトラブルが発生する
最初からコードで書けばトラブルとは無縁なのになぁ >>882
やっかいなのはコード書いたことのない整理魔がUMLカジって書いた概念クラス図および概念シーケンス図
それを英語風に直して「設計は完了した、コードに書き下せば出来る」という人かなぁ
分類する行為そのものが好きで、実際に動かせるかどうかは興味がないんだろう >>887
水道直したり電子機器直したり壁直したり屋根直したりアンテナ張ったりできるよ
趣味は読書だが、最近読んだ本は？ と聞かれた時の俺の回答はいつもおかしいらしい
「漢方医学」と「コンバットバイブル」と「なぜペニスはそんな形なのか」くらい普通だよな？ >>889
「俺ってひととは違ったセンス持ってますよ」感がひしひし伝わってきますね
地獄のミサワまでもう少しです
がんばって「俺ってひととは違ったセンス持ってますよ」感を磨いて下さい コンパイル・・・までは行かずに、
パースして仕様の整合性とか不備とかをチェックできるUMLみたいなものを時々夢想する。
それを使って仕様を書くんだ。
システムの全てを表現できなくても良い。文章に勝るものは無いから。
チェックも完璧でなくてもいいんだ、大体チェックできれば良い。仕様の質を高めるのに役立てばいいんだ。
完璧なものを目指すとUMLみたいにクソ複雑な言語になる。
ソースを出力するとかも要らない。ソースは人間の頭で組めば良い。 >>890
じゃあ次はもっとおかしな本を……いやちゃんと理由があるんだよ、漢方医学（大塚敬節）だけは
たまに飲んでる「荊芥連翹湯」はナニモノってのを調べたかったんだが書いてなかった orz
コンバットバイブルとなぜ（略）は本屋の棚で見て衝動買いしただけだ >>891
あるっちゃあるで
www.fujitsu.com/jp/solutions/industry/financial/services/mcbg/solutions/purpose/interdevelop-designer/#FUNCTION
https://www.genexus.com/japan/genexus-japan?ja
機能的にAccessレベルというか「データ指向」というか、データの記録・保全重視で操作性泣いてもらう系ならば、だけど
UXメインというか「ユーザーがどれだけ楽に仕事できるか」を重視する場合死ねる 何ぞ波長の合いそうな奴がいるな
次の本は謝明徳のタオ性科学をお勧めしておこう >>849
手帳の 機会があれば＠読む本 にメモった
……訓練法とかAmazonに書いてたが、慢性前立腺炎に効くやつあるんかね 下半身を鍛える方法はいろいろ載ってるが、前立腺炎に効くかはわからんな
というか前立腺炎は細菌感染が怖すぎるし病院行こうぜ
あるいはアネロスとかエネマグラでも入れてマッサージでもしとけ
しかし俺は医者じゃないし責任は取らんぞ >>825
上の文章と下のコードの情報量は全く違うわけだが >>896
病院は行ってる
バクタとレボフロキサシン飲んでダメ、漢方何発かやってダメだった、今は牛車腎気丸
セルフで前立腺マッサージ試みたこともある、マッサージわりと効くわ
四つん這いになって指に手マン用指サックをハメてローション塗って、ケツに指突っ込んでそれっぽいところ押すだけ
いろいろ死にたくなるけど、恥ずかしいとかじゃなくてすげぇ痛い
あと手マン用指サック持ってる理由は俺にも分からん、クンニ用ゴムシートとかもある……
調べたら骨盤底筋群にトリガーポイント（コリ）ができる場合もあるとかで
多分何らかの体操が必要なのだろうと ← イマココ >>893
有難う。
富士通のはデータ指向って感じのようだ、確かに。
GeneXusはもっと内容調べてみないとよく分かんないや。
そうだなー、幾つかカテゴリがあるんだよね、仕様で書くべきものは。
そのうち機械的にパースできそうなものは何だろう？
1
まずデータの仕様。富士通のやつはRDBを念頭に置いているだろう。
他にもクラスとして表現するような色々なデータ構造がある。
2
アクターからの見え方、操作体系。
どんなUIを用意して何がしたい時にどう操作するのか？UIはどうなるのか？エラーをどう扱うか？
UIではなく他システムやコンポーネントとのインターフェースも考えたい。
3
もっと細かい論理の積み重ね。
こういう時場合はこうなる、ああいう場合はああなる、というのが多次元に組み合わさる仕様について、
漏れなく仕様を決めているかチェックしたり、
逆にこういう条件も考えなきゃいけないよね、とか警告したり。
漠然としているな。これでは議論が難しい。まあチラシの裏だ。そういうスレだし問題は無いはずだ。 >>825
焼き芋焼く程度にしか使えない「要件定義書」や「概要設計書」だったとしても、それっぽい見栄えであるかどうかだけが重要
そういう書面をお客さんに提出してOK貰わないと次の工程に入れない（とされている）ってこと
契約的な意味で
問題は、客はたぶん設計書の内容を完全に把握してるわけないってこと
というか客自身、「ああいい忘れてたんで電話したんですけど」とか「後日xx部から要望がありまして」とかもザラで
自身の会社の要望も完全に把握してるわけじゃないので
なんというか仕様書駆動開発とでもいえばいいか？
オカミもそうあるべきだということで「工事進行基準がデフォルト」としたが
誰一人として「最終的かつ完璧で一切の漏れ・重複がない要件一覧」を把握してるわけじゃないので厄介 まぁ内容がやや過激かもしれんが、皮肉入りってことで（焼き芋用仕様書ならその案件蹴る） >>900
＞骨盤底筋群にトリガーポイント（コリ）ができる
それならヨガのほうが良いかもしれんな
骨盤底筋群を鍛えるにはムーラバンダ（ケーゲル体操）だ。ヨガのポーズは健康にも良いぞ
膣トレとかで調べて出てくる女性用のトレーニングでも良い >>904
ヨガか……ちょっと試してみる、ジュンク堂に参考書が何かあるだろうし
サンクス ケーゲル体操でググったら出た orz
本屋行かなくてもよさそうだな、すまん >>879
ちゃんと派遣業してるとこはね
そもそも偽装請負だとどうなんだろ
20年以上同じ客先にいて何でも知ってるというかその人以外が知らないこと多すぎな人知ってるからあの現場がどうなるか楽しみ >>887
若者よマルクスを読もうという本を読んだ
ジャップランドで差別主義が蔓延するのは資本主義のせいだと確信した
この島国では上からの民主主義が必要なんだ市民解放のためには
民度の低い国では民主集中制でなければならない >>907
大抵は主要スタッフ丸ごと抜けたって何とかなるもんだよ 結局、山岡は素材や技法が正しいかや美味しく出来上がるかに興味はあるんだけど
企画を成功させたり、会社の利益に貢献しようっていう動きは見せないんだよね
誰でも一定の品質で作れて利益もちゃんと出るっていうのが大前提
おそらく単価が高いであろう設計者の負担を増やすのは
利益を削る行為に他ならない
それならプログラマに足りない部分を補わせるほうがトータルコストで有利
設計に不満であれば勉強して設計する立場にあがってこればよい
ITというのは職位があがれば自分の手法をある程度押し付けられる寛容さは持ち合わせている
自分の技術が正しいというならそれを行うだけの立場にあがってこればよい 【貧困生活】派遣残業は結婚障害【家事困難】
偽装請負多重派遣搾取業界SEと離婚
両親や親戚に反対されましたが、低収入なのに時間外労働違反するSEと結婚してしまい生活困難で中絶と離婚をしました。現在は高稼働低収入でない共働き可能な相手と結婚して将来不安から救われました。
・モラルがない
・モテない
・キモい
・ファッションセンスがない
・コミュニケーションが苦手
・コンピューターが趣味
・プログラムの料金以上の不利益生産
・プログラムの巨額利益を客先に提供
・プログラムの巨額報酬を人売に提供
・プログラムの知的財産を人売に提供
・ITスキルが高いのに安売り低収入
・高度情報技術者なのに安売り低収入
・高生産なのに安売り低収入
・高利益なのに安売り低収入
・高需要なのに安売り低収入
・学習多いのに安売り低収入
・人員不足なのに安売り低収入
・会社員なのに早期退職
・PC使用過多で不健康
・運動不足で不健康
・高稼働で不健康
・高稼働で家事困難
・低収入で生活困難
・低収入なのに鬱病多発
・低収入なのに早死多発
・偽装請負の多重派遣損害あるのに稼働
・裁判官が技術判定不能だから賠償困難
【IT業界】独身が多い職業の象徴として「ITエンジニア」が取り上げられる
http://itpro.nikkeibp.co.jp/atcl/watcher/14/334361/110200713/?ST=spleaf 最低限、静的解析とリファクタリングツールが実装されないと(Office)設計書がコードより優れた設計ツールになることはないぞ
(Office)仕様書の最大の問題は機械的に検証できないことと変更しにくいことだ
最初から人間の頭だけで完璧でミスのない設計書を書ける前提がないと(Office)設計書は成立しないんだよ
そんな完璧人間はいないんだから機械的に検証できて編集も簡単なコードで設計書を書くべきなんだよ それでも機械的に埋められる程度の項目ぐらいは設計書で埋めてもらわないと困る
これはそんな高度なチェック機能なんか必要ない
誰でも見ればわかるレベルの話
現状はそれすらできてない >>915
チェック機能は要らないとか言いつつ間違えるんだよな
バリデーションルールをエクセルでリストアップなんてことは仕様書ではよくあるパターンだ
機械的でつまらない作業だけどこの程度ですら完璧な仕様書を書いてよこす会社は未だに存在しない
必ずどこかが間違っている 安い人間を使って自動化したほうが
高価なソフトウェアを使うようりも効率がいい
で、安い人間でも機械的に正確な動きをしてもらうためには
もっとエクセルを上手に作る方法があるんじゃないかという議論は
まだまだ余地があると思う
日本語と機械語の仕様を通じた通訳っていうのはコストに合わない可能性が高いんじゃないかな
単純なジェネレーターならまだしも、修正まで対応できるかっていうとね
既存言語での自由度を捨てて独自の中間ファイルを持つっていうならまだ何らかの成果はでそう 検証はエクセルで管理するよりViewModelの属性で管理したほうがいいよ
宣言的プログラミングはドキュメントとしても優れている >>917
ソフトフェアなら特定の範囲内で完全なチェックは出来るけど、人間だと絶対不可能です。
安ければ安いほど完全性は失われます。 特に人間は1時間程度でも同じことをミスする
ことなく続けるのは困難です。 例えば検算を全くの休みなしに1時間続けさせてミスを
1つも出さない人はいない。 そういうコンピューターと人間の特性の違いを全く理解せずに
人間の方が安いからというだけで効率的と考えるのが間違いです。
適材適所が理解できない人ほど物事を破綻させていきます。 分業ってのは適材適所の
最たるものなのにね。 コードで成果物管理するとか幻想
アルファベット順に並べなおしたり日本語から逆引きもできないし
工数や見積と突き合わせることもできない まあその辺りはエレガントなコードを書けるやつと書けないやつで永遠に意見が会うことはないだろう
書けない奴はどう説明したってコードで管理なんてできるわけないって考えを払拭することはできない
書ける奴は(全てとは言わないが)ドキュメントなんてコードとの重複作業でしかないのにそれに高い金出すのは馬鹿馬鹿しいなとしか思わない >>917
Excelをうｐったら（なんらかのシステムが空気読んでコードスニペットを組み合わせてくれて）
コードがゲロされる、以外の手法があるようには思えないな……
強いて言うならコードスニペットの適切な組み合わせを考える機械学習系のなんかか？
もちろん日本語が揺れてたら揺れそのものが問題になるから単なる機械学習じゃダメでディープラーニングになるかも、くらい 自動化とか表記揺れの削減とか考えるとさ
まず最初に設計書記述のプロジェクト規約みたいなものを作り出すだろ
それがうまくいけば社内規約などに昇格する
次の段階になると
新人教育のカリキュラムに社内規約の習得を追加しよう
社内Wikiで規約をメンテナンスして浸透させよう
といった活動が始まる
いつか誰かがチェックツールがあると便利だなということに気がつく
そしてチェックツールに通すためには機械可読な文法が必要だということにも気がつく
ここで◯◯社内設計書記述言語という新しいDSLが誕生する
DSLが出来ればチェックだけでなくコード生成も簡単だ
ここまでくれば我々はプログラミングから解放されて設計書に専念することができる
しかし誰かが気付いてしまった
我々はこの新しいDSLでプログラミングをしているだけなのではないか
既存の言語でプログラミングしたほうが汎用性もメンテナンス性も高かったのではないか 上流のバカどもがエクセルを指定して来るから仕方がないんだ >>927
最近それ実感するわ
まわりのみんなが日本人的であり続ける限り
何時迄もこの愚かさから脱出できない
日本的価値観なんて決して良いものではない
目が覚めてない奴が多くて日本最高とか
もうバカかと叫びたくなる
日本はネトウヨ濃度が高いんだよ 日本人率50%切ってる職場だけど
その国のトップレベルの大学から呼び寄せたって
日本人と大差ないよ
手心加えずに言われたことそのまま満たそうとするから
指示するほうは気をつかう ヘタに空気読んで相手の要望を忖度して違うってなったら被害こうむるのこっちだしなあ
「思っている通り」じゃなくて「書いてる通り」でないとまずい場面はよくある 書いてる通りに作るのが当たり前。
書いてあるのが間違いでは？となったら指摘するのが良い。
指摘しなくてもいいが結果、自分にツケが回ってくる。 気を利かせて明らかに間違ってるとこ直すとそれが結果的に正しくても怒られるからね
かといって問い合わせて1日2日浪費するのも馬鹿馬鹿しい
外注ってのが致命的にミスマッチしてるんだろうなこの業界 >>931
人によるなあ
「ちょっと見直してみます → すみません直しました最新送ります」
みたいな人だったら言いやすいけど
「はぁ？ 俺のに間違いなんてねーよお前の頭がバグってんだろ」
だったら多分何も言わないで相手にケツ拭いてもらう…… 設計書に書いてある通りにコードを書く
設計書に書いてあることが曖昧なら何が起こっても仕方がない
それでバグってもビルドできなくても仕様通りだから製造に瑕疵はない
設計書を主として開発するってのはそういうこと
ガキじゃあるまいし都合のいいところばかり取ろうとするな >>933
俺の対会社でそんな奴見たことないけど、そんな奴はまぁそうなるわなw
それはそいつの自業自得だね。 >>934
曖昧なのに作るって優秀かバカのどちらか。問題が起きなきゃ優秀。多分に起きるからアンタバカ。 >>936
ん〜
問題が起こりえない設計で問題が起きたならプログラマがバカだけど
問題が起こりうる設計で問題が起きたならそれは設計者がバカってこと
ちなみにこんな簡単なこともわからないあなたは間違いなくバカの世界チャンピオンでしょうね >>937
＞問題が起こりうる設計で問題が起きたならそれは設計者がバカってこと
はぁ〜
曖昧で問題が起こりうる事が分かってて作るのはバカ
と言ってるのに…
こんな簡単なこともわからないあなたは間違いなくバカの世界チャンピオンでしょうね そうそう！
ぐちゃぐちゃの設計書が届いたら
こんな設計じゃ作れないと言ってあげるのが当然のこと。
ただし、その為の資料がぐちゃぐちゃの設計書しか
ない場合がほとんどだから、
こんなんじゃ何がわからないのかもわからない、
と言って突き返すべし。
つか、今どきいくらでも仕事があるのに
バカSEのバカ設計書など断固として受け取るべきではない。
勿論、バカ設計書の評価にはバカSEより情報が
圧倒的に少ない状況で判断しなければならないので
バカSEの設計期間の2倍から3倍の期間を評価期間としてもらうべき。
急ぎで、と言われたら全て断るべき。
今は仕事がいくらでもあるから
業界から馬鹿SEを追放する絶好の機会！ >>938
プログラマがものを考えてはいけない
プログラマはコード生成スクリプトの代わりでしかない
曖昧なら曖昧なままコードを書け 無償で設計書を添削してほしいなんてムシのいい話はね
設計者のお母さんや学校の先生ならともかく常識的なサラリーマン相手には通じないぞ
設計書の分析と添削が必要ならまず金を出せよ >>939
「ふーん、○○さんはできないんだー。で き な い んだねー」
「社長ー○○さんはこの仕事難しくてできないそーでーす」
クソ担当はこんな感じで煽るわ社内評価下げに来るぞ 他に振る人がいないから言えないよ
工数圧迫の原因がそのクソ設計だからな 関わった人間が仕事できないとなると評価にかかわるから
どんな糞な人間とかかわったとしても無難に終わらせようと動くよ
それができない奴が一生底辺コーダーのまま
技術力は関係ない
人格の問題 >>940
そうだよ、それは言ってる。
ただ結果自分に返ってくるのが分かってるなら手を打てよと。
返ってくるのが嬉しいなら何もすることはないか。
嫌なら返せ。ただではやらないとか意味不明。やり直しで工数稼ぐとか生活残業と変わらんアホ。 なんていうか本当にパーツレベルの仕事ばっかしてるんだな >>942
お前が論理的に指摘できない無能だったらそうだろうな WEB系の零細に入ったんだがフレームワーク使うのが普通なん?
SQLとかDB周りがめちゃくちゃ作りにくいし分からん
使えない人扱いになってクビになりそう(´；ω；｀)ﾌﾞﾜｯ >>948
フレームワーク使うのは当たり前
今までどうしてたんだ？
RoRなら素直に死にもの狂いで覚えるしかない
PHPの各種フレームワークなら会社のバージョン管理システムでもみて変更箇所チェックして勘所を探れ
CodeIgniterならまだマシだからちょっと勘をつかむにはちょうどいい レス数が950を超えています。1000を超えると書き込みができなくなります。
