プログラマの雑談部屋 ★38
レス数が900を超えています。1000を超えると表示できなくなるよ。
プログラマは
こちらで雑談してください。
ユーザ、ＳＥが馬鹿過ぎる、
上司がバカだからもう辞めたい、
もう少し簡単な仕事に転職したい、
彼女が欲しい、
などなど愚痴、妬み、妄想などなんでもどうぞ。
※前スレ
プログラマの雑談部屋 ★36
https://medaka.5ch.net/test/read.cgi/prog/1529287662/
プログラマの雑談部屋 ★37
http://medaka.5ch.net/test/read.cgi/prog/1530182616/ >>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
お前いままでなにを見てきたんだ
俺はそもそも画面項目とカラムなんてマッピングしねー派だよｗ
ViewModelのプロパティとマッピングつってんだろ
これでも命名を揃えられないなら素人のお遊び確定だよ 相手が過去の自分の書き込みと自分のポリシーを熟知してるのが
あたりまえだと思ってるやつがかく設計書…
匿名掲示板で >>867
うーん現場抜けるの交渉大変そうだなあでも考えてみるよ
>>868は「ユーザコード表示欄」て書いてるから「getUserCode」ってメソッド？で取得するって感じなんだろうけど
自分のとこは「△△△表示欄」てあからさまなに書いてるわけでもないし「△△△」も簡単に判別出来そうな名前でもないしDBにもそれっぽいのは簡単に見つからないんよ
あっても似たような名前で影分身してることも多い ちゃんと最初に網羅してれば
項目名称がログインユーザーコードと顧客ユーザーコードになってただろうに
もう破綻してるふふん >>889
網羅しきったことを証明できないと永遠に仕事が始まらないぞ >>885
顧客が現状理解してるなら残って期間多めで受けれるようにする(隠れて整理する)
お前しか残ってない(≒出来ない)なら顧客評価は上がる
前提条件ありでこう考えるのもあり
請負でもゴミ処理で金稼ぐ会社は結構あるっぽいよ オブジェクト指向の考え方自体は理解できるんだが、実際のコードに落とせない
参考になる書籍やサイト教えてくれませんか オブジェクト指向で作ると逆説的に
なんやかんやで障害が出たときに
追いかけて直すのがたいへんになるから
５千行あるような関数が並んでるコードの方がマシだよ。
きれいでエレガントですばらしいコードは
趣味でだけ書いてくれ オブジェクト指向の最大の特徴は継承と隠蔽だ。
だがよく考えてみると、継承は独立性と矛盾するし、
隠蔽は可読性と対峙してしまうことがある。
常にそうなるのではないが
慣れてない人が組むとどつぼにはまる。
そして慣れてない奴ばかりが現場に放り込まれて
デスマになる。
人手はない.
よってプログラミング初心者でも
わかりやすく組める関数型言語のほうが良い。 >>895
わかるわ
スコープが狭いだけでグローバル変数使ってるのと大差ないの多いし
関数に下手に同じ名前つけれるから参照さがすとき検索結果が大量に出てきて読んでてうんざりする 関数型なんて背伸びしてるんじゃねえよ
一生トランザクションスクリプト書いてろ オブジェクト指向できないクズは転職してくれ
ほんと迷惑 作りたいもんが作れりゃ概念なんてどうでもいいんだよ >>894
それは理解できてないから
>>895
巣に帰れ えーとつまり
オブジェクト指向を理解してない新人さんあるいはおじいちゃんが
5000行のモンスターメソッドを幾つも作り込んで
わけわからなくなってにっちもさっちも行かなくなって
藁にもすがる思いで設計書がー設計書がー
とわめいていたわけだ
そりゃこんなクソコード書く連中にコードが設計書なんて言っても通じないか
前提となるスキルに差がありすぎて話にならないってわけだ >>883
堀内孝雄「みなさんよくお間違えになりますが、百万じゃなくて一万ボルトなんですよ」 ここに居る連中の職場は
単体テストとか結合テストとか書かない所ばかりなの？
単体テスト書こうと思ったらゴッドオブジェクトとか作らないはず 超巨大ゴッドオブジェクト作るやつって
他人と会話する気がないコミュ症でしょ
コミュ強者は責務が分離された
適切なコメントの付いているコードを書く オブジェクト指向覚える嫌
Cで手続き型でこのままやっていきたいわ 5千行の関数書くようなおじいちゃんが、その会社ではコミュ強者だったりするんだよなあ >>907
俺が今、必ず単体テスト書くように啓蒙活動始めたところ。 フレームワークやJAVAのライブラリくらい責任が明確化されたオブジェクト指向ならまだしもオブジェクト化する構想を頭の中で作った場当たり的なものは勘弁 5000行のクソコード書くおじいちゃんがコミュ強者になってクソ設計書を周りに強要する、ということか >>912
それを非オブジェクト指向で作ったらさらにカオスになる
大雑把でも枠ができてればリファクタリング可能 設計書を周りに強要するって考えがまず間違いで設計書が作成されてないプロジェクトはゴミでそんな状況で作られたシステムはスタート時点から死にゆくのみ 開発工程でなにをやるんでもいいんだけどさ、
それって、出来るやつにしか出来ないことなんじゃねーの？ 誰にでもわかりやすいコードは必ずしも良いコードじゃないんだよな
素人プログラマは両者を混同してオブジェクト指向はわかりにくい、悪いコードだなどと言い出すけど、それは典型的な勘違いでしかない
例えば初心者は、複雑な処理を関数分けして引数を渡して回るよりも、
1つの関数に全部つめ込んだり、関数分けはするけどグローバルなレジストリで状態を共有するほうが理解しやすいらしい
しかしその構造が良いコードかというとそんなことはまったくないわけで 単純なクラスを組み合わせる代わりに巨大switch文を作り
単体テストは無理と言って書かない可能性がある >>913
5000行のクソコードの設計書なんか書かんだろうから逆にソースが正ってなるんじゃないか >>915
そうか？
もっといろんな現場見たほうがいいぞ 設計書ってのは、書いた人が辞めた後に必要になるモンなんだ。
顧客というのはソースは見なくても設計書は見てくれるからねぇ。
とりあえず設計書のとーーーりに作っておけば、設計書の不備ってときには
時間を稼ぐことぐらいはできるだろう。 >>918
>>919
あるある
そしてその元になった設計書は全く意味不明で矛盾と不足だらけのゴミなんだよなぁ
こういうバカなコードを書く現場って、設計書を書くという工程を伝統的に受け継いできたから、
しかたなくやってるだけで、実質的に「設計」はしてないんだよ
見切り発車でコードを直書きするのと全く同じ感覚で、見切り発車で設計書という名のゴミを書き始める
こんな状況になるぐらいなら、しっかり設計したうえで綺麗なOOPのコードを書いて設計書は省略としたほうがマシ
それにOOPユーザーなら仮に設計書を書かなくても、XMLコメントやAPI仕様書、開発者ガイドみたいな後付ドキュメントはしっかり書く習慣があるからメンテナも安心 5000行クソコード書くやつっていうのは、スコープの概念が無いんだろうな。
だから、全部記憶力だけでなんとかしてる。
努力と根性だけで現代を生きてる原始人だな。 >>921
そそ、だから設計書作らないってのはブラックボックス作ってるっことでスタート時点で死んじゃうんだよね
まぁコミュ障パンチャーらしくはあるけど >>923
記憶力もないからクソコードと似たようなクソ設計書を書いて必死に読み比べて補ってるんだろ
すべての元凶は設計そのものが汚いスパゲティ設計書＆コードなんだよ
そんなものを作ってるからコードだけじゃわからんので設計書が必要などと言い出す
OOPのコードほど綺麗に設計情報を反映した文書は存在しないというのにね >>924
きったねえスパゲティ設計書のほうがよっぽどブラックボックスだよ
綺麗なコードが手元にあればそれが完全なホワイトボックスだろが オープンソース開発は設計書がなくても高品質な製品を量産できてるよね 糞コードやドキュメントが不足しているOSSは
誰も見向きせず淘汰されるので
結果的にある程度品質が高い物しか生き残らない でもコードだけだと動作仕様はわかるけど、その仕様の意図まではわからんよな さっきも言ったべ、辞めた後の話だって。
設計書があれば少なくとも顧客に言い訳ができるんだな。
あくまでも管理職のための資料。 ソースにしても設計書にしても、出来るやつにしか書けないんだから
そこで金をケチった時点で、そのプロジェクトはもう・・・ 会社のコードはOSSの場合とは違い
仕事を受注さえすれば社内にコード品質の競争相手が居ないので
糞コードが淘汰されず生き残る
ある意味ガラパゴス化
既存のクソースを保守する仕事も同じ会社がやる事になって
他の会社に仕事を取られる事もない
そんなクソース他の会社は機会があっても引き継ぎたくないだろう レス数が900を超えています。1000を超えると表示できなくなるよ。
