プログラマの雑談部屋 ★38
■ このスレッドは過去ログ倉庫に格納されています
プログラマは
こちらで雑談してください。
ユーザ、SEが馬鹿過ぎる、
上司がバカだからもう辞めたい、
もう少し簡単な仕事に転職したい、
彼女が欲しい、
などなど愚痴、妬み、妄想などなんでもどうぞ。
※前スレ
プログラマの雑談部屋 ★36
https://medaka.5ch.net/test/read.cgi/prog/1529287662/
プログラマの雑談部屋 ★37
http://medaka.5ch.net/test/read.cgi/prog/1530182616/ >>766
在庫管理に特殊な権限管理が必要なら在庫管理のコンテキストに組み込むか在庫権限管理など新しいコンテキストを作るかな
いずれにせよ一般的なログイン管理と在庫管理を同時に考えることはないよ 「在庫権限管理」
ほら言葉がでてきただろ
俺がシステムの実情を伝える前にコードは設計とばかりに書き下してたら
後からどうなってたことやら >>710
多分、若い人はそういう考えなんだろうと思う。
Webを中心としたシステム構成が増えてきて、
すぐに仕様変更できてしまうから、いちいちドキュメントを
直すなんてほうが無駄に時間がかかるしね。
仕事によって作成するドキュメントの種類や内容を変える必要があるのに、
内部設計書を書いたことのないWebプログラマなどが大規模業務系には参加して、
「なにこれメンドクセ!」とか言って重要なドキュメントを書かなくなったのだろう。 >>781
今の会話セッションは「設計」プロセスな
設計中に新しい用語が出てくるのは当然のこと
プログラミングはこれから始まるんだよ
さらに言うとログイン処理の命名を決めようというときには結局、在庫管理も在庫権限管理も関係がない
ログイン処理関連の命名は在庫管理のことなど気にせず決めていいし、在庫管理も逆に同じこと
新しく出てきた在庫権限管理もログイン処理とは独立して考えられるが、在庫管理とは上流下流の関係にありそうだから、在庫管理と在庫権限管理は多少関わり合った方がいいかもね
こうして物事を分けて個別に考えられるのは分割して統治するという基本ができてるから
君にも早く身につけてほしい概念だ 日商PC検定試験のデータ活用1級って持ってるとなんか意味ある? >>782
重要、と一言で言うけど、状況によると思う
それこそシステムを作るだけなら内部設計なんていらないし、重要なことなんて何もない
システムにメンテナンスが入ったらコードと設計書を二重に直す労力は半端ではないから、重要どころかむしろ邪魔にすらなりうる
でも、客が設計書を成果物として欲しがっていて、それが金になる、という意味では非常に重要と言える 数学はともかく計算機科学はくわしいよ
くわしいはず
はず >>786
ほとんど何もしらない素人ですよ
プログラマと名乗ってるだけです
どうせセット販売されるので、自分はプログラマです、と言い切れるだけでも働けるんですね 東京大学理学部情報科学科卒
東京大学大学院情報理工学系研究科コンピュータ科学専攻修士課程修了
東京大学大学院情報理工学系研究科コンピュータ科学専攻博士課程修了
こういう学歴のプログラマーっている? あー、東京を自分の思いのままに都市計画してみたいなぁ・・・・・。
超巨大なビルとかいっぱい建てたい。
やっぱり首相にならないと無理なのかな? >>783
その「設計」と称するものを他人も理解できるように
設計書にして確認したり、一覧にして整理してみようって気はないのか
多大な工数をかけてコードにする前に コピペ改変した設計が間違ってたとかで横展開でエクセル修正してくれって指示がくると目の前が真っ暗になる
え?それどこにあんの…何個あんの…直した影響調査ってどうやんの…えっえっ?作業指示って横展開ヨロシクだけ?ってかなんでリファクタリングしてクラス化しなかったの?誰か助けて…もうやだ…
みたいな感じ >>794
コードをみれば誰でも設計内容を確認できるし
パッケージ、名前空間、クラス、メソッドで見やすく一覧化されるのでわざわざ資料にする意味はない >>791-793
全の値段は幾らぐらいでしょうか? >>804
C++11 or lator をやっている >>808
>>810
全の値段は幾らぐらいでしょうか? >>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じゃねえかあああああ
ってわかるだろ?ちったあ常識で考えろよ ■ このスレッドは過去ログ倉庫に格納されています