プログラマの雑談部屋 ★34
■ このスレッドは過去ログ倉庫に格納されています
>>690
そういうの当てられたとき
今日は〜を試した→駄目だった
今日は〜を試した→駄目だった
今日は〜を試した→駄目だった
・
・
・
っていうネットでググった方法を
毎日記述するだけで定時で帰ってたよ
もちろん実際はやってもいない だいたい出来ないって泣きついて
「じゃあ前倒しで余裕のある〇〇さん代わりに引き継いで！」
って言われた〇〇さんは物凄い殺意抱くからね
いつも他人に頼るのが当たり前の無能には理解できないだろうけど >>692
途中参加なんて気が楽だろ
次のタスクねーし >>692
出来る人はもう慣れてるから絶対に前倒ししないようにコントロールする
前倒ししちゃってるようじゃまだまだ半人前 途中参加？
尻拭いさせられるのはほぼ同じプロジェクトのメンバーで
当然タスクも尻拭いさせられる分が余計に増えてるのがほとんどだよアホ
アホ一人のために他から人員を持ってくるってことは
丸々一人分のリソース食い潰すってことだからまず無理 >>692
アホ
空いてる人に溢れを振るのはマネジメントとして当然だろうが
それとも空いてる人は遊ばせておくのか？ ？？？ｗ前倒しは空いてるって言わないよｗ
途中参加といい、ちょくちょく全く仕事したことない馬鹿がレス返してくるね
全部同じ奴か？ｗなんでここ見てんだ？ｗとりあえずレスつけるのやめてROMってろ プログラマ志望のガキが話に参加したくて一生懸命横やり入れてんのかねｗ
悪いことは言わんから他人に尻拭いの依頼するような役立たずのゴミの居場所はないからやめとけ 出来ないやつを首にしても出来ないやつに任せていた仕事がなくなるわけではない。
首にしてすぐに増員して入ってきたのが華麗に解決してくれるなら簡単に首を切れる
環境の方がいいが、現実はそんなうまく回らないわけで。
無能なんて首を切ればいいよなんて言う奴は上みたいな誰でも思いつくような
簡単なことすら想像できない無能な奴だったりする。 なんというかITに人がｶﾞﾝｶﾞﾝ流れてきてた時代の認識で止まってるのがたまにわくな
少子化で絶対数が減ってるし、ブラック認識が広まって人が来なくなっているというのに できないやつ放置すると後々面倒くさいことになる
出来てると思ってた共通処理が未実装だったり できないのをずっと黙って抱えてられても困る
他の人がやることになるとしても早くわかったほうがいいし >>705
よく考えると無能は仕事を増やしてるんだよ
わかりやすい例で言うと「誰でもわかるように基本的な言語機能以外は使うな」ってやつとかさ
ようするに無能に足並み合わせて有能は縛りプレイしようぜってことな
無能がいなくなってこういう馬鹿馬鹿しい制限がなくなれば生産性がいっきに向上する 初めて開発案件入ったんだがWebアプリなんだが設計書渡されたけど画面にデータベースからデータ取って表示する処理でデータベースのどの列からselectするとか書いてないんだがどうすればいい？これって普通なん？ 実装担当しない大手の人間なんて何人増えても意味ないんですけど >>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
そのうち日本人も分かるだろう
在日がどれだけ良質な移民だったかを
イスラム土人や南米土人が押し寄せたとき
過去に在日を虐めたのを後悔する時がやってくる ■ このスレッドは過去ログ倉庫に格納されています
