プログラマの雑談部屋 ★34
■ このスレッドは過去ログ倉庫に格納されています
実装担当しない大手の人間なんて何人増えても意味ないんですけど >>714
そんな屏風の中の世界のこと言われましても >>715
普通は画面の設計書にDBの事なんて書かないよ
新人研修で三層アーキテクチャとかドメインモデルとかMVCとか、そういうの教わらなかったの？ 仕事出来ない奴ずっと残しといてそいつは何するわけ？ｗん？
そいつの給料はどこから出てくるわけ？ｗん？ 書いたコードレビューされる環境の方がめずらしいのかね >>717
えーまじかよ意味汲み取るしかないんか
>>719
MVCは勉強したけどもう忘れちまったよ
他の単語も聞いたことがあるくらいしか知らんし 仕事を出来ないやつを出来ないままで放置しかできない無能集団 そもそもエリートプログラマーさんしかいないような会社なんて
ソースレビューの必要なんてないもんね 画面に表示する項目がデータベースのどこにあるかって殆ど自明だと思う
例えばだけど、注文入力・参照画面だったら表示したいエンティティは普通に考えて注文エンティティだろ
注文エンティティはどっから取ってくるかっていうとそりゃまあ注文テーブルじゃん(ヘッダと明細にテーブル分かれてるかも)
で、どの注文エンティティを表示したいかを知りたければ、URLからリソースid見るだけだよね
あとは、画面の入出力項目と注文エンティティの属性のマッピングはプロパティ名から明らかでしょ
注文エンティティ以外だって同じだよね
悩むところ有るか？ >>725
逆だよ。 出来る人ほどそういう転ばぬ先の杖みたいな作業をやってる。 ぼく仕事できませーん！助けてくれない上司は無能！！（ｷﾘｯ！！！ﾄﾞﾔｧ！！
初めて〇〇やりました〜どうすればいいですかー！（ｷﾘｯ！！
なんでこのスレってこんな人もどきのチンパンが沸いてきてレスつけてんだ？
相応の初心者スレにでも逝けよ あと項目を自分の推測で決めろとか言ってるアホどももヤバすぎるｗ
逝ってよし やる気ない系プログラマーの一番の理想は
良く出来てるシステムのメンテ・改造担当になることだよな >>725
Githubがエリートにウケた理由は超快適にコードレビューできるからだぞ
エリートほどレビューするし逆に底辺は全くレビューしない プログラマーに限らずやる気が増減しないみたいな思考の奴がヤバイな
やる気を出させるのは基本無理ゲーでやる気なんて簡単に減るもんなのに
報酬もらってるんだからやる気なんて関係なく報酬に見合った成果が出せなきゃだめだろ >>734
改行しなければいいんですよねわかります 典型的なwebアプリならドメインモデルとDBを適切に設計してれば大して長いクエリにはならないはず
一方でBIツールにデータ流す時とかはスパゲッティクエリになりがちでつらい >>731
実用的なデータ量突っ込むと普通に1000行超えるわ
でもエクセルで1000行あっても驚く量じゃないしね
むしろ400行程度で嫌になっちゃう構造が不味い やっと気づいたんだが、この業界たぶん効率化が一番遅れてる気がする insert into UNK_99_脱糞履歴 (
-- ここに1000行のカラム名
) values (
-- ここに1000行のデータ
) コードレビューして何指摘するん
どうせ聞かないしけんかになる >>744
でも同じデータばっかじゃねーし
普通に量が増えれば列も増える >>745
何指摘するも何もコードレビューに関することはあれこれ公開されてるのに
そういうのに目を通してない時点で手遅れだよ >>745
そもそもどっちが正しいのかどうやって決めるのかよくわからん
同僚に汎用性だの拡張性だのやたらエクスカリバーを振り回す奴がいるが
ぶっちゃけ実際いくらも金になってないと思うんだよね 正規化してても10は普通に超えるだろ
10超えたらおかしいというならそれ目的と手段逆転して効率と可読性犠牲にして列数減らしてるだけじゃないか 今時のフレームワークだとORM使ってるのがほとんどだからモデルクラス見れば
DB直接覗かなくてもある程度はどうにかなるだろ >>747
1000超え余裕なのに10列ｘ100個のテーブル作っても
今度は切り離す意味のない同期が必要な100個のテーブルができるだけ 1000越え余裕とか言ってる奴と同じプロジェクトにならなくてよかった・・・ >>747
何考えてこの設計なんだというテーブルとして、
列数が2600あったテーブル
なんとか解読したときは
「・・・・あーなるほど・・そうなのね・・」って納得した気がするが（もう覚えていない）
どう考えてもおかしいわ >>726
なんか似たような単語とか多くてよくわからないんだよ
自分がシステム自体の業務用語に慣れてないのもあるな
システム開発って難しいんだな 2600カラムってネタですらそこまで盛らないってレベルじゃね >>749
くそこーど放置はすると技術的負債になる→改修時の工数が増える→時間と金にダメージ >>750
ビジネスロジックに殆ど影響しないノートプロパティで列を水増しすることは出来る
なので正しく正規化しても10を超えることはそりゃあるよ
でもそれは本当に必要なのかってのは考えた方がいいよ >>752
兆候を見逃すとこうなる
つーかここまでくると見逃すってかわざとシステム破壊しにきたライバル企業のエージェントかなんかか？って気もするが たとえ主キーが一緒でも関心ごとにちゃんとテーブル切らないとなあ >>757
逆に聞くけど
そんな4KB程度で収まる程度の設定データで動くアプリやハードなんて今どきあんの？ >>759
トランザクション系かマスタ系かで違うし人事、顧客、会計だとか業界でも扱う情報量全然違うし一概に10だ15だいうのには違和感
まぁ目安を持っておくのは新人とかに教える上で有用だし異論無い 検索キーで使わないカラムはJSON型にして押し込むって手もある 全部1つのカラムにカンマ区切りでまとめれば解決するんじゃないか？ ある販売会社の契約管理システムで同一の主キーでいくつものテーブルに分割してるシステムあったな
細かい属性ごとに分けてテーブルあたりのカラム数は少なかったけどありゃゴミだ >>765
あくまで兆候だからな
正規化したのにやたら列数が多いテーブルはたぶん境界付けられたコンテキストを跨いでテーブル共有しちゃってる
認証認可コンテキストのユーザーはIdとパスワードを持つが届け先住所は要らないだろう
入金コンテキストだとユーザーに紐つく支払い方法とかクレカ番号が欲しいけどパスワードは要らない
発送コンテキストだとユーザーの届け先住所とかが欲しいけどクレカ番号もパスワードも要らない
同じエンティティでも場面場面で求められる情報ってのは違ってくる
そういうのを同じユーザーだからってんで安易に同じテーブルにくっつけていくと最終的に破滅的な巨大テーブルが出来上がる
大量のカラムが一体なんのためにあるのか、カラム間の整合性を保つにはどうすればいいのか、誰にもわからなくなる DBに関わる人はSQLアンチパターンが必読書といっても過言ではないと思う
変化しづらい分野だし >>770
こうやって細かく一対一の分割しまくった結果、数年間の運用で項目増えて問題出てるケースを前に見た
当初は全く無関係だったテーブルで共通の項目が出てきて、同じ項目を複数に持たせるのは良くないからテーブル追加してみたいな
どっちもデメリットはあるんだよな >>772
それってDBよりアプリに問題があるんじゃないかな？
DDDでドメインモデルがDBに依存しないように設計してれば、
参照系でテーブル結合、更新系は同一トランザクションで操作すれば簡単に変更できると思う
Railsのアクティブレコードパターン使ってる場合は地獄だろうけど >>770
テーブル間の同期が取れなくなった地獄に比べればまだ傷は浅い
1レコードである限り列同士のデータの同期は取れている 同期を取らなきゃいけないような分け方をするから問題になる
認証認可コンテキストと発送コンテキストの同期は別に必要ないよね
異なるコンテキストにあるパスワードと届け先住所が異なるトランザクションで更新されてもなんの不都合もない
逆に同じコンテキストにある郵便番号と住所は一緒に更新した方がいいかもね >>775
は？
もともと1レコードのもんを意味もなく分けたんだからそうなるに決まってんじゃん 実装しないで仕様書だけ見てダメ出しする立場にならないと定年35歳まで奴隷 >>776
意味もなく分けると同期を取るなど面倒なことになる
なので境界付けられたコンテキストを見極めて分ける必要がある
とりあえずプログラマの教養としてDDDは読んでおいた方がいい >>773
そりゃ簡単に対応できるけど当初思想から異なるテーブル構成になって本来不要な対応が増える時点でDB設計の問題でしょ
かといって完璧に先を見通すのは無理だからね
細かく分けるのはその場限りの開発者目線だと良くても運用目線ならデメリットがある 想定外を減らすためにコンテキストでDBのスコープを限定する
ゴッドクラスを責務ごとに分離するのと同じ
エンティティが同じだからといって異なる責務を一緒くたにしてはいけない
販売管理と配送管理では商品は同じ商品でも別の責務があるということ マイクロサービスでの開発した事ある人居る？
Webサービスの内容が増えてきて
モノリス型での開発はもう限界か、とも思えては来たが
モノリスもまともに開発出来ない開発陣なのでカオスになる未来しか見えない 【悲報】日本は、すでに移民大国だった。
移民流入で世界４位(2015年度時点)
#今後は更に増加へ >>783
そのうち日本人も分かるだろう
在日がどれだけ良質な移民だったかを
イスラム土人や南米土人が押し寄せたとき
過去に在日を虐めたのを後悔する時がやってくる >>779
正しいと思う
要求に対してDB設計から変更して対応できる事が少ないのが問題だと思う >>789
期待しすぎだろ
あんな根暗どもに要求すんな 無能だからテスターやってんだろ
他人を当てにするな テスター必要なプロジェクトにいるやつ全員無能なのでは 世の中は徐々にモノリスからマイクロへ向かってるのに
ゴッドオブジェクト作って案件を炎上させる者は後を絶たない
何故彼らは小さく作って組み合わせると言う事を学習しないのか ユーザー系
↓
独立A（特定派遣）
↓
独立B（特定派遣）
俺は独立Bに居るんだけど、先輩がいつも独立Aのリーダーに怒られまくって、ついには罵声、陰口や俺の陰口まで言うようになってきたんだけど、これって当たり前なのか？ >>797
罵声以降おかしい
ただうちにも妙に怒られる人はいる 底辺職だから
高卒の頭悪いヤツが立場だけ
えらくなってイバってる世界。
怒鳴り合いなんて挨拶みたいなものだ。 >>797
よくあるような話だが
罵声や陰口は人間として糞なやつに当たったとしか言いようがない >>797
当たり前だけど普通じゃない
前に似たような状況になった事あるけど、その人ノイローゼなんじゃない？
その人は前のプロジェクトで大赤字を出してて会社から「次は無い」って言われて余裕無くなってたみたいで、人前で怒鳴り散らしたりしてたね
とりあえず自社の上司か営業に「仕事がやりにくいからなんとかしてくれ」って言うしかないだろうね PGが一番楽なのにねぇ
PGの需要あるならずっとPGでええやんって感じ 10年以上前に3重派遣ぐらいでNＴＴの大規模案件でいろんな派遣会社が
一つのフロアに詰め込まれてる場所に飛ばされたときに他社の社員が部下の社員に
周りがドン引きするぐらい怒鳴り散らしてたのは見たなぁ
あーいう羞恥心０の奴って他の人間の存在が物か何かとしか思ってないのかね
キチガイすぎてて理解不能人種 何次かも解らん派遣に売られて、誰が支持者なのかも解らんから同じっぽいグループの人に何やるか訪ねたら
お前の作業なんて知らんが
と突き放された
コミュ障にはキツイなIT土方 標準語喋ったら虐められた現場がある
小学校のような事務所だった
堺市 >>805
コミュ障ってか普通に技術者に対するパワハラ多いからなぁ
訳わからん線引いた奴が怒鳴る謎構図 労働者不足になっていくらかマシになったね
みんなが嫌がる担当者の仕事は請けない 人間はコミュ障に厳しいからなー
コミュ障を患うぐらいなら手足がもげるほうが遥かにイージー
コミュ障は社会生活に支障がある障害者なのだから国が保護すべき 無能になると群れて気弱そうな奴をリンチするしか勝つ方法がないんですわ
自社や協力会社さんをよぉく観察すれば見えてくる
有能ほどなぜか人当たりも良い傾向が強い >>811
そんなことはない
技術力もあるガチのキチガイもいる (・∀・)一日3000行ペースで組めば土日も出れば来週には終わるよね？
Σ(´∀｀；)あ、四則演算できたんですね？ｗ
物理演算の代わりに捨てて来たのかと思ってました 話を聞かない奴多い
話を聞いてしまうと仕事が増えるからだろうか ■ このスレッドは過去ログ倉庫に格納されています
