プログラマの雑談部屋 ★20
■ このスレッドは過去ログ倉庫に格納されています
プログラマは こちらで雑談してください。 ユーザ、SEが馬鹿過ぎる、 上司が陰険だからもう辞めたい、 もう少しまともな仕事に転職したい、 彼女が欲しい、 などなど愚痴、妬み、妄想などなんでもどうぞ。 ※else禁止ガイジは出入書込禁止 ※前スレ プログラマの雑談部屋 ★18 http://medaka.5ch.net/test/read.cgi/prog/1509054617/ プログラマの雑談部屋 ★19 http://medaka.5ch.net/test/read.cgi/prog/1509711456/ 質問です。普通のプログラマーとゲームプログラマーってどっちがおすすめできますか? 給料無くてもプログラム作りたいならゲームやればいいだろ? 給料は欲しいしプログラムは仕事と割り切れるなら普通のマで。 ゲームはヤバイ 生きていけない可能性がある 求人の給料は嘘っぱち >>6 嘘の記載というのは許されるのでしょうか?残業代が出ないとかそういうことでしょうか? >>7 残業代なんて絶対出ないよ 裁量労働制とか書いてあったら出ないよ この世は嘘ばっかり過ぎて誰も騒がなくなった >>8 >>10 ゲームプログラマーはやめとこうかな... >>10 何年前の記事なんだろ? 裁量労働制でみなし時間でそれ以上払わないみたいなことが 書いてあるけど、訴えられると確実に負けるからよっぽど度胸のある所じゃないと払うのが 普通なのだが。 みなし込みでも十分安かったりするけどね。 ただゲーム関連はゲームを遊ぶのが好きな人は選ばない方がいいところだな。 遊ぶのと作るのでは全く違うものが要求されるから。 派遣でゲーム会社モドキのゴミみたいなところ行ったことあるけど 新卒で手取り15,6万、雰囲気残業強制、ゲーム作る力もほとんどない 高い金払って専門学校とか卒業した頭の弱そうな子が こういうなんちゃってゲーム会社に就職するのが一番かわいそうだと思った 【貧困生活】派遣残業は結婚障害【家事困難】 両親や親戚に反対されましたが、低収入なのに時間外労働違反業界のSEと結婚してしまい生活困難で中絶と離婚をしました。現在は低稼働高収入で共働き可能な相手と結婚して数億円損失を防げました。 ・モラルがない ・モテない ・キモい ・ファッションセンスがない ・コミュニケーションが苦手 ・コンピューターが趣味 ・プログラムの料金以上の不利益生産 ・プログラムの巨額利益を客先に提供 ・プログラムの巨額報酬を人売に提供 ・プログラムの知的財産を人売に提供 ・ITスキルが高いのに低収入 ・高度情報処理技術者なのに低収入 ・高利益なのに低収入 ・高生産なのに低料金 ・高需要なのに低料金 ・学習多いのに低料金 ・人員不足なのに早期退職 ・会社員なのに早期退職 ・PC使用過多で不健康 ・運動不足で不健康 ・高稼働で不健康 ・高稼働で家事困難 ・低収入で生活困難 ・低収入なのに鬱病多発 ・低収入なのに早死多発 ・不利益なのに断らない ・偽装請負の多重派遣損害あるのに稼働 ・裁判官が技術判定不能だから賠償困難 【IT業界】独身が多い職業の象徴として「ITエンジニア」が取り上げられる http://itpro.nikkeibp.co.jp/atcl/watcher/14/334361/110200713/?ST=spleaf 最近のゲームの酷さ見てるとゲームプログラマの将来が不安だ 面白さそっちのけでいかにガチャ回させるか 品質もバグだらけでユーザが無料テスタ、アプデで対応 ソシャゲの影響か 資本主義だから仕方がないね お前が面白いと思うゲームを作らせたいならお前が出資するのが筋だよ ドッカンバトルがやらかして、ソースコード公開してたけど 違うキャラクターのデータを取得したことにより ピックアップキャラが一人しか表示されないことになる意味が分からない >>17 おれは、お前が何を言ってるのか分からない。もっと真面目に人生やれ。 ソースコード読んでない人には何だか分からないだろうね >>15 ソシャゲみたいな継続するものだと毎月の売り上げがきちんとなきゃいけなくて 最低ラインの人数の運営でも月数百万が必要なわけで。 最低ラインはほんとにほとんど何も追加もなくイベントも同じのがループする みたいな運営になるからな、それでも継続しようとすると月数百万なわけだ。 全く人を介在させないとか残業代を全く払わないとかだとぐっと減らせるが。 薄く広くで取るとしても数百万/課金人数で最低課金額がいくらになるか計算 したらほとんど変化のないゲームに金額or人数があり得ないとわかると思う。 ガチャ以外の課金要素に月数千数万を突っ込むのが大量にいるなら別だけど、 そんなにいないよね、数百円ですら課金したくない人が大半だし。 確かバンナムだかのドラゴンボールのゲームだっけか、ドッカンバトル 強力なキャラを手に入れるのに、課金して回すガチャがあるんだけど そのガチャではピックアップ、つまり目玉となるキャラが設定されてて、 そいつが排出される確率がユーザーごとに違ってて、更にたちの悪い事に ピックアップされているキャラの排出率が0%だったユーザーがいて 過去のガチャもそうじゃないのかって話とコレ法に触れてるよねっていう話 SELECT * FROM t WHERE id IN (123, 456) の結果セットの1行目を id = 123、2行目を id = 456 だと決め打ちしてしまった奴か こんなくだらないミスで株価がストップ安になるとかトラウマもの 条件を満たさなきゃ取れないアイテムがある その条件を知恵を絞って探し出すのもゲームの醍醐味だろ 全てのユーザーが0%で何やっても変動しないなら詐欺だろうけど そうでなければそれもゲーム性の一つでしかないわな ドッカンバトルの件だと正しいゲーマーならまず分布を測定することから始める 仲間やネットを通じて分布に偏りがあることに気がつく いい分布を得るためにアカウントを変えるなどの対策をとる 与えられたものにしか興味がない 困難を乗り越えることに喜びを見出せない そんなゆとりゲーマーばかりになってしまったのは悲しいことだね やり込みゲーマーはひょっとするともう絶滅しちゃったんじゃないか リファクタリングするならきちんとしろよw バージョン3.8.0では新イベント「極限Zバトル」の機能追加にあたって、キャラクターデータ読み込み処理を極限Z覚醒データに対応させました。 キャラクターデータ読み込み処理は、プログラム上で複数箇所に散らばっていた為、コードの共通化を実施する必要がございました。 このコード共通化の影響により「出現キャラ一覧」及び「出現キャラ提供割合」において一部想定していない挙動が発生しておりました。 動けばいいでコピペしちゃったんだね 低品質SEPGを雇うからそうなる 共通化は悪であるとまた証明された やはりコピペ改変が最善手ということだろう コピペ改変の原則とでも名付けて布教すべき 共通化って結果論だからなぁ やってよかったも やらなくてよかったも その後の改修および不具合内容次第 部品の共通化は、ときどきコストダウンをもたらす でも驚くべきことに 最終的な成果物の品質に一切寄与しない ほんとに一切寄与しないんだよ… ただコストを下げる「ことがある」だけ 金と時間があったら別に作ったほうがいいらしい 共通化するとトラブルの元になる それにステップ数も減るから儲けが減る リファクタリングって、元々それが出来るコードが書いてあっての話だからな。 ゴミしかなかったなら、マジ、作り直した方が早い。 だから、最初にゴミ作っちゃった時点で、もう、後は何やっても無駄。 コピペ民一人入れただけで崩壊するんだよプロジェクトって、 ジワジワと人知れず侵食していって、気付いたら菌糸張りまくってるから腐海の森そのもの だから、最初にゴミ作っちゃった時点で、もう、後は何やっても無駄。 コピペ民一人入れただけで崩壊するんだよプロジェクトって、 ジワジワと人知れず侵食していって、気付いたら菌糸張りまくってるから腐海の森そのもの テストもコードじゃなく、当然人力のチェックリストだろうしな へ? いや、君がやってもコピペでやっても報酬は変わらないよ 頭悪いん? 共通化して何かをやった気になるのは厳禁だね 現プロジェクトには一切利益をもたらさないことを認識するべき 同様に次のプロジェクトでもその次のプロジェクトでも大した利益にはならない 人数を増やすより足手まといを的確に切り捨てるほうが生産性あがる 人事部たのむからちゃんと仕事してくれ >>39 変更しやすくなる 拡張しやすくなる テストしやすくなる わかりやすくなる メリットたくさん 責務を切り分けて共通化しよう >>40 そんなの設計が不出来だから必要なんでしょ? で客からお金出ないよね? 周りが凄い勢いでゴミを量産してるとマトモなプログラマのやる気も無くなる 実力のあるレビュアーが冷酷無慈悲にクソコードにNGを出してくれればいいんだけどな ゴミの排出量が多すぎてレビュアーも手が回らん スキルない人は本当に迷惑だから退職してほしい >>42 >変更しやすくなる それって仕様変更? 誰のメリットなのか明確にして >拡張しやすくなる それも仕様変更? 誰のメリットなのか明確にして >テストしやすくなる どうして? >わかりやすくなる 誰が? >メリットたくさん 寝ぼけてんじゃねーよ >>42 ×変更しやすくなる コーディング段階での共通化は 変更時に影響範囲を精査しなければならなくなり、変更のコストは増大する ×拡張しやすくなる 機能でカバーできない拡張が入るとあっという間に破綻する △テストしやすくなる 楽になるのは単体テストまで。 どうせ後には機能単位の結合テストが待っており、その工数は削減できない ×わかりやすくなる わかりやすくなるのは言語の共有ライブラリのように、機能についての知識が共有されているときだけ その使用を義務付けるとコミュニケーションコストが増大する 必要なのは責務を切り分けだ 場当たり的な共通化ではない >>45 変更や拡張の理由は様々だよ 仕様変更かもしれないしバグ対応かもしれないし パフォーマンスチューニングかもしれないしリファクタリングかもしれない 何にせよ責務が明確に切り分けられた共通部品を使えばありとあらゆる場面で作業効率があがる 責務が明確に切り分けられた共通部品はやってることがハッキリしてるからテスト仕様を導出しやすい 依存関係が持ち込まれないからテストコードを書くのも簡単 色んな責務を一緒くたに行う部品よりただ一つの責務に集中した部品のほうがわかりやすい 人間の脳は考えなければならないことが少ないほど処理しやすい なので責務を明確に切り分けて共通化したほうがわかりやすい 誰がと聞かれれば人類全員に当てはまる事実と言うほかない 寝ぼけてるのは誰だろうね 鏡を見ながらよく考えてごらん ふと思ったが、>>45 が居なくなれば一つゴミが減ってみんな幸せになれる。 >>49 それだけ長いレスしてるのに俺の質問には何も答えられないんだね ドッカン案件で始めてここ来たけど怖い。 そもそも単体テストとかやったことない。 責務を明確に切り分けて共通化すると変更の影響調査も簡単になる まずどこに該当する処理があるかを探すところから始まる 責務を明確に切り分けて共通化していないと手がかりがほとんどないので膨大な調査時間がかかる 共通化していればシンボルを起点にしてコード解析すればあっという間に終わる そのあとにその処理に依存する機能を調べなければならない 共通化されていないとどこからどこまでがその機能の範囲なのかつまりスコープが不明瞭になる そしてそのスコープの不明瞭さはその機能に依存する機能も同様である可能性が高く再帰的に爆発的に影響範囲が広まっていく 責務を明確に切り分けて共通化していればスコープが明確なのでそのようなことにはならない ほぼ機械的に最小の手間で影響範囲を特定できる さらに言えば影響の範囲調査だけでなく実際の影響を観測する時にも差が出る 責務を明確に切り分けて共通化した部品はテストしやすい つまり変更の影響を簡単に観測することができる 責務を明確に切り分けて共通化していなければ変更の影響を確かめる方法は結合テストより上位のテストを行うしかなくそれには膨大なコストがかかる 良くここで話題に出る「テスト」て一体何なのか解んないんだが 詳しく説明してもらえるとありがたい >>56 あ、いえ、普通は設計書書くんで別にいいです そういうセブンセンシズは >>58 最初から完全な設計書を書くことは人間には不可能 なので設計書は必ず編集を繰り返し整理整頓しなければならない ようは設計書のリファクタリングが必須であるということだ しかし設計書はテスト不能であるという致命的な問題がある テスト不能ということは安全にリファクタリングもできない 設計書は不完全かつ修正困難である したがって設計書にはメモ書き程度以上の価値はない ドキュメンテーションは設計書ではなくドキュメントコメントを含むプロダクトコードとテストコードとユーザーマニュアルで行う ユーザーマニュアルは実際に出来上がった製品から導出される文書でなければならない ふと思ったが、>>58 が居なくなれば一つゴミが減ってみんな幸せになれる。 プロジェクト東京ドールズってゲームが キャラも可愛くて戦闘も面白いぞ 設計書からコードを自動生成するのは失敗したが コードから設計書を自動生成なら出来るんじゃね? 今の客がWebサイトの全画面の設計書寄越せってうるさい 画面の設計書なんて客が何に使うんだ JavaScriptで超スパゲッティでも書いたんか ここで言ってる画面の設計書って、画面毎に操作される処理の設計書であって フロントエンドの設計書って意味じゃねーでしょ >>66 とりあえずソースコードがあるなら フローチャート作成ツールでも動かしてペタペタ貼ったモノでも出してみたらどうか? 設計書と言うか操作説明書みたいのを最初に作ってから 作り始めるスタイルをやってる それくらいなら最初に作っても良いんじゃね? >>73 なんでそれしか作らないでGoがかかるのか狂気だな >>61 馬鹿じゃね 設計書間違ってても誰も指摘しないヌルい環境でしか仕事したことねーだけだろ >>78 Aボタンでジャンプ 長押しでスライディング bootstrapとかあるとは言っても htmlのレイアウトを手動で書くの('A`)マンドクセ マウス操作でデザイン出来ないのこれ? twitter bootstrapなんか使ったら、後で死ぬ事になるぞ 半年かけて進めてた計画、延々協力拒否してた同期に乗っ取られた上に 手柄持ってかれて責任と後始末だけおっかぶせられたんだけど死にたい そういうアホって会社に これからこれをやります 成功した暁にはこれこれ こういう評価を下さい! って言わねぇんだよな やってんだかやってねぇんだかわからねぇから上も 何も考えず配置転換しちゃうんだよ (*゚∀゚)バカバカバーカ ハードウェア基盤としてこういうの用意するからって言われてて その前提で開発してたら突然 やっぱできませんソフトでなんとかしてくださいって 話が違いすぎる しかもできないんじゃなくて製品を検証する手間がないからって 意味が分からん過ぎる 俺らが作ったもんが製品以上の信頼性になるわけないだろ こっちに面倒押し付けようとしてるだけじゃねーか! >>86 ハードと同時進行で開発する時にはよくあること。 慌てずにコストと納期と制限事項の調整しろよ? 内製にしないと誰も幸せにならない プログラムを外注するってのがまず間違いなんだよ 下請け禁止しろ >>86 ちゃんとそれを言葉にしないと 人手増やすなり、徹夜でもして間に合わせればいいじゃないですか? って言えよ >>82 あいつさんざん大法螺吹いたあげくににっちもさっちもいかなくなって 俺に泣きついてきたんだぜ おれが一瞬で収束させてやったよ せめて後始末ぐらいやってもらおうと思ったんだけど それでも恨みがましく不満言ってやがる いやぁ、ダメ社員が同僚にいるのと苦労するなあ! 楽しそうで何よりだな 俺はit業界入ってから手柄なんて 案件に当たったことがない 報酬はいつも単価いくらで 予め決まっていて いくら頑張ってもそれがもらえるだけだ ずっと新規でシステム開発し続けるユーザなんていないからなあ >>94 だからAmazonにコテンパンに負けまくってるのよねー >>95 ちゃうねんて。オレはおまえら水呑みとちがって自由だから、休日とか平日とか関係ないねん。 お前らが働いてる時に酒のんで寝てることもあれば、 お前らが屁をしながら27時間テレビ見てる時に仕事してることもあんねん。 時間というのは万人に共通じゃないねん。 だから、お前らは今日はゆっくり休め。 >>98 無職はいつも休めて自由だよね。 仕事してるとか嘘でしょ? >>98 自宅警備員ならもう少し緊張感を持った方がいい ■ このスレッドは過去ログ倉庫に格納されています
read.cgi ver 07.4.7 2024/03/31 Walang Kapalit ★ | Donguri System Team 5ちゃんねる