プログラマの雑談部屋 ★38
レス数が900を超えています。1000を超えると表示できなくなるよ。
プログラマは
こちらで雑談してください。
ユーザ、SEが馬鹿過ぎる、
上司がバカだからもう辞めたい、
もう少し簡単な仕事に転職したい、
彼女が欲しい、
などなど愚痴、妬み、妄想などなんでもどうぞ。
※前スレ
プログラマの雑談部屋 ★36
https://medaka.5ch.net/test/read.cgi/prog/1529287662/
プログラマの雑談部屋 ★37
http://medaka.5ch.net/test/read.cgi/prog/1530182616/ >>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行のクソコード書くおじいちゃんがコミュ強者になってクソ設計書を周りに強要する、ということか レス数が900を超えています。1000を超えると表示できなくなるよ。