プログラマの雑談部屋 ★38
レス数が1000を超えています。これ以上書き込みはできません。
関わっちゃダメな案件
発注元または1次受けがN〇T
1次受けまたは設計がI〇M
銀行の金融系全般
特にI〇Mの毎回生産性あげるため〜とか謳った設計のオレオレフレームワークはホント何なんだ
キチガイか >>596
>発注元または1次受けがN〇T
>銀行の金融系全般
下が合ってて上も文字合えばビンゴかもしれん そして人集めと開発がF通
…どこだったらまともなんだよおい
携帯系はシステムより組織体質がシャレになってないって聞くし >>596
誰から見た何の生産性なのかと言う話やね
I○M的には生産性が高いんだろ ビンボーだからMacもiPhoneも買えないYO! >>595
進んだのは高度化じゃない
明らかに無駄なものは普及せんでしょ >>594
でも、どこも予算ケチってくるよ。
もっと安い人売りがいくらでもいるんだもん。
まあ、スケジュール遅れて金が飛んでくのは
安請合いした人売りの勝手だから、あとはまあ、
その金が飛んでく先が自分であればいいわけだ。 人手不足と思っているのは、あくまでも現場の作業員の感覚であって
顧客のほうは人手不足などとは思ってないからねぇ。
なにしろ顧客は、人と人売りの区別なんてつかないから。
むしろ顧客が関わるのは人売りのほうだもんねぇ。 改修機能追加常駐としては開発ペースめちゃくちゃ遅いけどエクセル設計書のある現場で助かる
仕事が人に依存しないし調べようと思えば調べられるってのは大事 >>602
諸悪の根源はマウスを発明したパロアルト研究所なのかもしれない なんでやねんw
極論言ったら、ノイマンが悪いとかになるやんw いや完全に遡ったら狩猟の道具を考えたヤツだろ
人間が楽したがる文化はそこから始まってると思う >>605
そのエクセル設計書を書く工数はコーディングの工数よりも遥かに高いってことは知っておかなければならないな
10分で書けるコードの設計書を1時間かけて作るということ
まあでも、そのおかげで底辺のプログラマにも仕事が行き渡る
生産性はともかく雇用統計には大幅プラスだね ひーひー言いながら仕様書の機能実装してよしオッケー→使いにくいからここ変更して
ってのを延々繰り返している。残業してもいいから……みたいな発言までいよいよ飛び出した
これがIT業界の洗礼なのかなって今泣いてる >>611
俺はドヤ顔で残業代出るから沢山仕事して良いよと言われた
こんな業界で一生働けるのかな >>611
慣れるまで。
ここでいう慣れるというのは、どんな変更が来るか先読みできるようになる事と、どんな変更が来てもさほど改変なく(残業無くw)できるような設計をベースとして作れるようになる、まで。 打ち合わせに参加していると、
だいたいどういう変更がありそうかわかるけど、
プログラマごときは出席しないでよい、などという思いあがった
ユーザ―の場合、「忖度した設計」することができないから、
後ですごく困ったことになる。
プログラマは打ち合わせに出席すべき。
だって、出席した奴が馬鹿だったら、
その馬鹿からの説明の範囲しか知ることができないから、
その馬鹿のレベルを超えるシステムは作れなくなってしまう。
で、だいたい上司にゴマすってる馬鹿がリーダー格に
なって打ち合わせに出席したりするから困ったもの。 >>612
境界値テストしたらそんな操作しないからいいって・・・ >>610
もちろんその通りで今の現場は大変優良だと思う
ただ本来どこもそうあるべきだわ
打つだけで設計書残さないのはその後の機能追加の難易度を大幅に上げるし土方側も期間短くておいしくないし何もいいことがない ファーストサーバのZenlogicってなんで全然復旧しなかったの? >>617
難易度が高いのはコードでも設計書でも変わらんよ
特に誰でもコードが書けるように詳細まで書いた設計書はコードと同じかそれ以上にメンテナンスが難しい
なぜなら設計書はプログラムと比べてシステマチックに管理されておらず(フリーフォーマット)、
静的解析によるサポートもリファクタリングツールもユニットテストもUIテストも存在しないから
変更のリスクが恐ろしく高い
この事実から目をそらす人が多すぎるようだね >>614
設計は元請け正社員様なのが定石
その正社員様が瞬間湯沸かし器で論理矛盾をどうするか聞くとお前で考えろと発狂するのも良くあること
で、こっちで考えたものをお披露目すると、なんでこんな仕様にしたと激怒して派遣元にクレームという流れも経験済み >>620
>>特に誰でもコードが書けるように詳細まで書いた設計書
コレはゴミですわ そんなエクセル作ってる間にコーディングしろよって話だな >>623
そう
まさにゴミなんだけど
外注の派遣さんを使うと詳細すぎる設計書がないと全く働いてくれないから作るしかない 偽装請負や二重派遣とかって誰が罰金払ってるんだろう?
顧客なのかねぇ? 汚いコードの元になった設計書って同じぐらい汚いんだよね
そもそも論理的な設計が狂ってるから、それを文書としてアウトプットしたってろくなものにはならない
設計が綺麗ならダイレクトにコードにアウトプットしても問題なく読める
むしろ自然言語より読みやすい >>629
ツォンカパとオックスフォード大学の数学教授はどっちの方が賢いですか? >>630
お届けするには、今から13 時間 22 分以内にお急ぎ便を選択して注文を確定してください(Amazonプライム会員は無料) 裏口入学かぁいいなあ
青春犠牲にして第二志望だよオレ
日本の権力者はほんとやりたい放題だね
国民はさもっと怒らないとだめだよ
こんな国は民主主義じゃない やっぱりあのPMは進捗報告の数字しか見てなかった
アラート挙げても全部無視 >>635
でも末端のPGより給与も評価も高いよ? だからなんだ
アラートがPMに無視されたんだ
俺が困ってるんだひとの給料の話なんかしてない >>637
ID無い板だとお前みたいに成りすまして
わざと叩かれるレス書き込む奴いて虫唾が走るわ 美味しいとこは吸い上げてミスはPGに押し付ける
あとは怒鳴り散らしながら進捗を眺めるだけ
イージーすぎて笑えてくるわ >>634
日本神話と北欧神話はどっちの方が崇高ですか? 本当にそれはミスだったのか?
相手はお前の理解力のなさにげんなりしているかもしれない 「わかる人と話がしたい」という台詞が
管理者はスゲーむかつくらしいぞ。 件名:【アラート】緊急報告【重要】
やばいです仕様矛盾どうにもなりません時間もたりません(略
件名:Re:【アラート】緊急報告【重要】
スケジュールに間に合うよう仕様通り実装してください。 アラートなんて言われたって管理職になにが出来るわけでもなく・・・
せいぜい代わりに怒られることぐらいだな。 誰でもわかるような設計書まではいかなくともDBからどのテーブルのどのカラムから取ってくるくらいは書いてほしい… >>649
最低でもテーブル名とカラム名は必須だな。
いまどきは設計なんかしなくても下請けや派遣の常駐プログラマが
忖度しながら仕事してくれるから
SEは何もしなくてもいい、と思ってるような感じはするな。 残業代が1.5出る派遣会社いたときは基本給20万でももりもりお金が貯まっていったな
休日出勤すると2.0だった 結局自分のしたことを人が都合よくとってくれるかどうか
能力によって期待値も上下するから怒られ度は一緒
不条理だ デリヘルにもNGプレイというのが認められているが、ワイらにもNG現場認めてくれ
ワイは気になる木にはもう二度と行きたくない
逆によかったのは、ゼロ戦のメータ屋だな、あそこは良かった、なんか緩いし >>649
逆にソレがなくてどうして設計書として成立するのかわからんぞ
「なんかいい感じにデータ抽出してください」
「こうなったらいいなぁ・・って思いません?」
なんて書いてあるわけじゃぁ・・(過去の記憶がフラッシュバック) >>656
具体的にどこからどの値を取ってきて
どう計算したら良いですか?
って聞くと、なぜか怒り出す設計者様っているよな。 >>657
大丈夫だ
俺は具体的にどこからどの値を取ってきて
どう計算したら良いか指定されると
キレるプログラマだからだ
わかってんならテメーで作れよ!
( ‘д‘⊂彡☆))Д´) パーン 大昔の課題管理表やら
未公開の要件定義やら
誰も見ないような規約持ち出して
ねちねちいじめてやる >>657
家の設計図に、家の大きさ、ドアの大きさ、窓の大きさだのが書いてなかったら
大工さん文句言っても当然のことだと思うが、それがこと設計書になると抜けててもOK的な風潮あるよね >>660
大工さんは怒るけど、お前ら怒らないじゃん。
自業自得だよ。 ここに書いてある!っつって窓枠のカタログとモデルハウスの例と設計規約をもちだしてきて
ここから類推できなかった土方のせいにする
それがIT業界 >>661
切れたら、契約切られて営業が切れるだろうに。 いいなあ質問バカはヒマそうで。。。
うらやましくてウンコがでるよ。。。 マピオンのサイトに
フィッシングサイトが仕掛けられてるから注意な。
いきなりgoogleの何かの当選です!という
表示がされてびっくりした。
ソースをちょっとみたらコメントにgaqダミー入れとくとか
書いてあるけどそこかなあ?
めんどいから詳しく見る気はしないけど、
マピオンは使わないほうがいいな。
つかマピオンは中国の下請け企業にでも
作らせてるんだろう >>649
そんなわかりきったことを書く意味はない
ドメイン層のエンティティとデータベース層のスキーマの対応はほとんど自動で決まるのだから
設計書にはコンテキストマップやドメインモデルなどもっと重要な情報を書いてくれ 些末なことを特定するのにどれほど労力がかかると思ってるのか おれが作ったスマホとかのアプリは全く売れないけど
おれ自身はよく売れる。 計算機が相手という論理矛盾に最もシビアな世界なのに求められるスキルは忖度 尊宅ってどっからでてきた言葉なんだ
40年ぐらい生きてきてまじで最近はじめて聞いたんだけど
日本建国時にいろいろ文化的に言葉に仕込みをした連中がいるらしいので気になってる
中国語で変な意味だったりしないだろうな そりゃあ、能無しなんだから忖度で勝負するしかねーやな。
ゴマすりとか酒づきあいとか。 >>684
あ、あと隣のグループの議事録も
「メールCCでこの会議連絡あったよね?」
「議事録を置く場所知ってるよね?」
「知ってるのになんで見てないの?」 アジャイルだからと言って計画を立てずにひたすら突き進むマネージャー
プロジェクトがコケたらマネージャーだけ残って私達は切られるんだろうなぁ アジャイルを何も決めずに見切り発車で開発する手法と勘違いするアホがいる そりゃあ、成果だけなら中国やベトナムで十分なんだから
忖度で勝負するしかねーやな。
ゴマすりとか酒づきあいとか。 >>691
私は下っ端だから何も言えない
なんかもう嫌だ >>680
設計に労力がかかるのは当たり前
・設計
・設計書作成
この2つのプロセスを分けて考えられん?
じっくり時間と労力をかけて細かいことを決めるのが設計
設計したことを何らかの形でアウトプットするのが設計書作成
アウトプットの形式ってのは
専用の設計書作成ツールで作る
エクセルで作る
紙やホワイトボードに書く(パシャる)
など様々で決まったやり方というのはない
そんな多様なアウトプットの形式の1つとしてコードがある
つまりコードは設計書ってことだ
設計と設計書作成の区別がついてないバカは設計をおろそかにして見切り発車で設計書作成を始めてしまう
だからおぞましい悪夢のようなスパゲティ設計書(殆どの場合エクセル)が生産される
この手の設計書は体裁だけ整えたゴミなので背後にある設計が全く見えてこない
逆に設計をよく練る人は即コーディングをしても美しいコードを作る
コードから設計がよく見えて保守もしやすい >>268
こういうのも実は設計する段階ではキッチリと決まっている
設計→エクセル設計書作成→エクセル設計書からコードへコピー
この3段階の無駄なプロセスでプロジェクトを回す前提だったのに
エクセル設計書作成の工程に漏れが有ったということなんだろう
設計したことをさっさとコードとして書いてしまえば>>268が悩むこともなかっただろう >>699
エクセルなんぞで遊んでないでテストコードを書く
社会人の常識でしょう >>679
慣れたらエスパーみたいなもんでわかるものなのか?
どのテーブルのどのカラムから取ればいいのか >>703
慣れとかじゃなくて機械的にマップするんだよ >>704
機械的にマップするってどうやるんだ?
どれ取ってこればいいかわからないのに? イベントソーシングとかCQRSって誰も使ってない?
CRUDの従来型システムには無い様々なメリットがあるんだが
・実証可能な監査証跡を残せる
・履歴データに基づいたクエリモデルを作れる
・(コマンドの)副作用を気にせずに済む
・トラブルシューティングやデバッグの助けになる
CQRSとイベントソーシングの使用法、または「CRUDに何か問題でも?」
https://postd.cc/using-cqrs-with-event-sourcing/ おれの世代だと、
1.外部設計 (現在の要件定義+基本設計)
2.内部設計 (現在なくなってる!?)
3.詳細設計 プログラムの設計書
となっていた。
だが経験の豊かなプログラマが作成していた内部設計書というものが、
90年代中ごろから無くなってしまった。
なじぇ? >>707
自分は設計書にどのテーブルのどのカラムからデータ取ってこればいいか書かれてなくて困ってて
>>679だとそれが自動で決まるってあるからなにか見分けつける方法あるのかな?って思ったんよ
今の現場の画面設計書だと同じ表記で違うカラムから取ってくるってことがあったから >>708
JavaやC#やHTMLの表現力も生産性もBasicやCobolにくらべてはんぱないから
あんまりいらなくなったのもある
おれが思うに、詳細設計書を詳細に書きすぎると
製造と設計を別人が行うとき、
作業者が満足度を著しく下げる上に
作業者が考えて判断するということをしなくなってしまう
細かくかくなら達成すべきことを
内部の設計がかわってもいいように細かくかいておくべきだ >>706
ここにいるのは多分ほとんど業務系の土方だろう
普通に考えて使ってるわけがないと思うが?
イベントソースやDDDはおろかそもそもオブジェクト指向すら理解してない奴らが多数派でしょ
イベントソースなんて百年早いわ
そもそも業務系システムはリアルタイム性と正確性を重要視するから
仮にスキルが十分でもイベントソースは採用しにくいだろうね >>708
エコシステムの進化が原因
便利な入力支援もなくチェックもテストもできないエクセルで設計を練るより
快適なIDEでコードを書いてテストしながらリファクタリングする方が簡単だと気が付いた
昔はパンチカードでプログラミングしたり
コンパイルに一晩もかかったり
自動テストがまったく普及してなかったり
そもそもIDEが重くてまともに動かなかったり
なんてことがあったからじっくり設計書を練りこんでコーディングは最小限にしようって判断が正しかった
でも今はまったく状況が違うから設計書なんて要らなくなった 設計書を書いとかないといっぺん決めたことを忘れてしまう
細かいところで整合性がとれずにソフトがぐちゃぐちゃになる いらないなんて言ってるやつはものすごく小さい範囲の末端だけちぎって投げられてる土方にちがいない >>709
なんだか話がおかしくなってきたぞ
なんで画面設計書にデータベースが出てくるんだ?
設計をちゃんとしてから設計書を書いたのか?
見切り発車で適当な設計書を書いたせいで画面設計書にデータベース処理仕様を混ぜ込んでしまったんじゃないのか? >>713
頭の中に置いとけと言ってるわけじゃない
決まったことをコードとして完結明快に保存するんだ >>715
自分は実装担当で現場に入ったんだそれで作られた設計書見て作ってねと言われて設計書見たら画面のここはこのデータを表示してってのがデータベースの値を取ってくるんだろうけどあまり詳細に書かれてないんだ
データベースのテーブルから推測したりして探してみたりしたけど似たようなテーブル名やカラム名が多くて判別つかないんよ
最近はPM?の人に聞いて教えてくれるけどなら最初から設計書に書いてほしいかなーって 三層アーキテクチャも知らない素人が設計書を書くとか冗談じゃないよね
画面にデータベースをマッピングだって?
そんな設計書に付き合わされるプログラマはたまったもんじゃない
ようするにさ
設計書をありがたがる人ほど設計なんてしてないんだよ
設計書というなのスパゲティを書いて設計 し た つ も り になってんの >>717
モジュール、名前空間、クラス名、メソッド名
これでどこに何があるかわからんなら
そもそも設計やプログラム構造がめちゃくちゃなんだろうな
このへん手抜きせずに決めればかなり検索性が高くなるぞ
つかファイルシステムとエクセルの組み合わせの方がはるかに探しにくいわな それを整理してどれにどんな名前を付ければいいか判断するには
最初に一覧を作らなきゃむりだろ!
脳内で何千件も処理できるもんか
そしたらそれをメモ書きして捨てるか設計書に残すかってなる
捨てるのはもったいないからちょっとばかり労力を払って内部設計としておいとくことになる
設計書いるじゃねーか 場当たり的にコード改修して整頓された見通しのよさが保てるわけがない
設計したことない連中が主張の都合のいいところだけつまみ食いして
バラ色の未来を提示してる いや設計はしてるんだっていってるけど
設計したんだったら設計書かくのにそれほど苦労しないはずだろ!
なんでなにもないんだ >>722
なんで最初から全部リストアップする必要がある
受注管理の命名をするときに顧客管理の命名をリストアップする必要があるか?
分割して統治せよって新人研修で教わらなかったのか?
そんなことも教えてくれないなんて同業者として憐れみを感じるよ >>723
場当たり的に書いて整理すらしなかったものがエクセル設計書だよ
>>718などは完全にその被害者だろ
設計書は作ったけど設計はしてないとこうなるんだ
逆に良く設計してればコードがドキュメントになるので設計書はいらん >>725
机上の空論破綻はアリの穴から
どこに何をどういうルールで置くか、その分割を適切にできるかどうかは
最初にどれだけ網羅できるかにかかってる
名前はものを区別するためにあるんだ ここにいる人はどんな資格を持ってる?
VBAエキスパートは今更遅いかな 設計書を書くツールがエクセルからIDEに変わって
設計書の出力形式がエクセルからテキストファイルに変わって
設計記述のルールが厳密にチェックされるようになった
それだけのことじゃん?
コードで整理できないって人がエクセルで急に整理できるようになるとは思えんけど 一覧管理のために生まれたExcel様のパワーなめるな >>727
ログイン処理の機構を考えているときに在庫管理のことを考えるか?しないね
全てをまとめて網羅する必要などどこにもないんだよ
分割して統治せよ
君が真っ先に理解すべき概念だ
来週の業務が始まるまでに理解しておいてくれ >>733
在庫管理システムだけプラットフォーム別になってて
ログインユーザーの権限が連動してる必要あるんですけど >>737-738
全の値段は幾らぐらいでしょうか? >>735
それこそ権限管理のコンテキストで解決する問題
在庫管理のコンテキストを巻き込んではいけない
分割して統治しておいて良かったねと締めくくられメデタシメデタシだな >>711
CQRS/ESでは結果整合性を使うから、
複数のリードモデルがあると一部の反映が遅れる場合があるって弱点はあるが
僅かな期間の表示のズレも許容出来ないようなアプリケーションばかりかって言うと
そうでもないのでは? >>741
>>743
全の値段は幾らぐらいでしょうか? >>749−750
全の値段は幾らぐらいでしょうか? >>749-750
全の値段は幾らぐらいでしょうか? >>763-764
全の値段は幾らぐらいでしょうか? >>740
お前がどんな絵をかいてるのか設計書がないから見えない伝わらない
そのシステムユーザーに在庫の製品種別ごとの権限ついててログイン管理してるんですが >>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じゃねえかあああああ
ってわかるだろ?ちったあ常識で考えろよ >>872
カラム名と変数名が必ずリンクすると思っちゃうくらいの規模しかないって意味ね
その結びつきが絶対と思えるほどの規模しかない規模
規模が小さいから暗黙の規約を盲信してドキュメント不要論唱える
笑えるくらいお遊びかと >>875
お前いままでなにを見てきたんだ
俺はそもそも画面項目とカラムなんてマッピングしねー派だよw
ViewModelのプロパティとマッピングつってんだろ
これでも命名を揃えられないなら素人のお遊び確定だよ 相手が過去の自分の書き込みと自分のポリシーを熟知してるのが
あたりまえだと思ってるやつがかく設計書…
匿名掲示板で >>867
うーん現場抜けるの交渉大変そうだなあでも考えてみるよ
>>868は「ユーザコード表示欄」て書いてるから「getUserCode」ってメソッド?で取得するって感じなんだろうけど
自分のとこは「△△△表示欄」てあからさまなに書いてるわけでもないし「△△△」も簡単に判別出来そうな名前でもないしDBにもそれっぽいのは簡単に見つからないんよ
あっても似たような名前で影分身してることも多い ちゃんと最初に網羅してれば
項目名称がログインユーザーコードと顧客ユーザーコードになってただろうに
もう破綻してるふふん >>889
網羅しきったことを証明できないと永遠に仕事が始まらないぞ >>885
顧客が現状理解してるなら残って期間多めで受けれるようにする(隠れて整理する)
お前しか残ってない(≒出来ない)なら顧客評価は上がる
前提条件ありでこう考えるのもあり
請負でもゴミ処理で金稼ぐ会社は結構あるっぽいよ オブジェクト指向の考え方自体は理解できるんだが、実際のコードに落とせない
参考になる書籍やサイト教えてくれませんか オブジェクト指向で作ると逆説的に
なんやかんやで障害が出たときに
追いかけて直すのがたいへんになるから
5千行あるような関数が並んでるコードの方がマシだよ。
きれいでエレガントですばらしいコードは
趣味でだけ書いてくれ オブジェクト指向の最大の特徴は継承と隠蔽だ。
だがよく考えてみると、継承は独立性と矛盾するし、
隠蔽は可読性と対峙してしまうことがある。
常にそうなるのではないが
慣れてない人が組むとどつぼにはまる。
そして慣れてない奴ばかりが現場に放り込まれて
デスマになる。
人手はない.
よってプログラミング初心者でも
わかりやすく組める関数型言語のほうが良い。 >>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の場合とは違い
仕事を受注さえすれば社内にコード品質の競争相手が居ないので
糞コードが淘汰されず生き残る
ある意味ガラパゴス化
既存のクソースを保守する仕事も同じ会社がやる事になって
他の会社に仕事を取られる事もない
そんなクソース他の会社は機会があっても引き継ぎたくないだろう IT土方の大半が技術力ないんだから
OOPなんて難しい概念使わせたら訳のわからんものが出来上がるだろ OSSでも物によってはフツーに会社がプログラマーを雇って業務の一環として書かせていたり
自社製品でそのように作ったOSSのコンポーネントを使っている場合がある
ドッグフーディングってやつ?
最初は開発チームがテストするだろうが
次第にそのOSSのユーザーもバグ報告等を行ってくれるようになる 全員が優秀であることを前提に
スケジュール組んだり設計したりプログラムの作り方を決めたりするから
デスマになるのだぜ。
仕事で集団で作る以上、その大前提が間違ってるからな。 上流の仕様がころころ変わるけど、納期が変わらないからデスマになったよ まあ、デスマなど、どうせ末端のおれらの責任じゃないんだから、
せいぜい書き入れ時ってことで、残業代をガッツリ稼げばいいのさ。 休出しても代休も残業代もなかった思ひ出
裁量労働の恐ろしさを知った ソノヘンは昭和のやつらも、ちゃんと知ってたんだよね。
だから企業も派遣という契約形態にこだわっていた。
それが特定派遣。
でも味を占めて能無しを送り込む奴らが増えたもんだから、
顧客のほうが派遣ならイラン受託にしろ、と言い出して
偽装請負という形になったわけだ。 >>938
少なくとも日本に関しては無能を大量雇用しすぎたことが諸悪の根源だろう
どこの現場に行ってもこのチームは無能の集団である、からスタートしなきゃならないPMが哀れ だからまあ、自分だけでも優秀になる努力ぐらいはしないと。 優秀でも給料は変わらないよ。
そんで仕事だけ多く押しつけられる。
それがIT業界の体質。
本当に優秀なヤツは、自分の立場が守れる程度に出来ない振りして
優秀さを隠してるのだぜ。 派遣してたけど残業もさせてくれないし、いついなくなってもいいような単純作業ばっかりで飽きた >>946
残業代定額制のおかげだな
派遣がおもわず残業やサビ残しちゃわないように
かつ企業も残業させたくなくなるように設定してある 糞コードの混入を阻むコードの番人(レビュアー)が居ないので
やがて糞コードが支配的になってしまう 給料は上がらなくてもクビにはされにくくはなるからねぇ。
せいぜいメリットはその程度。
でもクビになっても簡単にホカへ行けちゃうもんだから、
それすら大したメリットじゃないんだな。 >>948
それが、本来あるべき派遣の姿だからな。
そもそも、小泉のアホがやった技術職への派遣の拡大が間違いだっただけだ。 でもまあ、優秀なら選択肢は増えてくれる。
一般派遣でもやれるし、正社員にもいつでもなれるし、
勤務地も近いところや逆方向のを選ぶことも出来るし。 >>950
真面目で優秀なレビュアーは配置しないほうがいい
酷いコードだらけで読む価値なしとしてrejectされまくった結果コード0行の状態で納期が来てしまう
レビュアーはレビューしたフリしてOKサインを出す係
日本ではこれが精一杯 >>911
TDDはデスマ作りやすいから気を付けてな テスト書かないで納品なんて
極端な話、あなたの依頼したシステムのテストはみんな本番環境でやりますって言ってる様なものだ
人力テストは効率悪過ぎて
バグが無いかすべて人力で確認するため、リリースが非常に遅くなる
その為頻繁なリリースは出来ず、まとめて沢山の変更を一度に行ってバグのリスクが増加
面倒だから、テストしなくても大丈夫だろうとタカをくくった結果、バグが発生
など様々なリスクがある >>956
>テスト書かないで納品なんて
ん? それは発注側がテストコードを成果物に含めなかったのが悪いんだから
発注したやつが悪いんじゃね?
そんなアホの事はしらんよ。 テスト常に書く側としても。 テスト書かないで納品というのは、いまどきはゲームがそうらしいぞ。
テスト要員は一般プレイヤー。
バグを見つけてチートに成功すれば、RMTで金が稼げてそれが給料。 ユーザーにテストをやらせて何が悪いのか
仕様がないのでテストなんて作れない 休日の何もする気が出ない感ぱねえ
平日の睡眠が足りてねのかな
24時就寝5時起床はキツイのか しょうがないよね!
って言おうとして駄洒落でもなんでもないことに気が付いた >>962
24時就寝にしてどんどん後ろにずれてて寝起きも体調も悪いみたいな生活してたが
癌になって手術して休職して22時にベッドに入る生活になったら
5時くらいに勝手に目が覚めるようになってスッキリするようになったわ 【東京都】帰宅女性の背後から侵入し携帯奪う、指名手配の韓国人の男を逮捕 【!注意!】ウィルスの仕組まれているサイトと思われるURLが送られてきた。
見てみたい気もするが、ウィルス対策のソフトを入れておらず、
Windows defenderしか入ってないので、誰かセキュリティに自信のある人は、
以下のサイトがどれほど強力な脅威なのか教えてくれ!
よろしく!
くれぐれも冗談でアクセスしないように!
http://bretzel-franchising.ru/wp-content/plugins/wp-db-ajax-made/ 巡回スレでこういうことする馬鹿いるとホントイラッとするね
とりあえず通報しといたから安心してタイーホされろ >>970
ロシアの殺し屋、おそロシアー
というのをデトロイト・メタル・シティで
クラウザーが言ってた。 みずほいい加減潰れればいいのにね
こんな状態でもまだ金預けてる一般人いるのかな お給料貰ってるとはいえ朝9時厳守、最速でも17時ごろまで拘束、しかも毎日ってちょっとした人権侵害だと思うの
昼までに出社、ノルマこなしたらいつでも帰宅OKじゃいかんのか?
健康で文化的な最低限度の生活を保障してくれないと困るぜ自民さんよー 奴隷に人権はないと平気で言うんだw
人手不足になる訳だ >>977
そうしたいならそういう契約すればいいだけじゃね >>977
外資系投資銀行にてシステム開発したことあるけど、まさにそれ。
仕事が終わればいつ帰ってよい。
自宅勤務も充実してて、会社のPCにリモートデスクトップで
接続して作業してもOK.
仕事さえできれば何やってもOKという雰囲気だった。
上司が日本人だったから英語は少し話せればいいだけだったし、
俺にとってはすごく楽しくて、やりやすい職場だった。
だから外資に行けばいいよ。 で、なんでそんな良い職場を辞めたわけ?
使えないからクビ? 派遣で行く分には、ブラックで知られる会社でも
その被害をあまり受けずに済むもんねぇ。 ブラックならともかく普通の仕事時間にすら耐えられないってダメ人間でないの、、 >>719
開発って数か月ぐらいかかるだろ?
逆に設計は数日じゃん
だったら設計を可視化してチェックすれば開発の工数見積もりできるわけ
工数がわかれば金額がわかる
どんなものに対していくら払うかっていうのがわかれば
金払う価値があるかどうかわかる
だから設計は大事 >>987
派遣って大声で怒鳴られたり殴られたりするやつだろ?
実際に手を出すのは大手だとNぐらいだわ >>991
それは設計してるふりだから早いだけか
設計書のアウトプットだけを設計と言ってるだけ
実際には設計には長い時間がかかりアウトプットは短い 先を見通す能力が低いと設計も雑になるから逆に早く終わる
その状況と能力で時間かけたってそれ以上質が上がるわけじゃないから
それはそれでいい気がする
やってみんことには そんな工数使っていったい設計書に何書いてんだ?
詳細すぎる設計書にはデメリットしかないぞ 日本語の本だと設計書の書き方的な参考書いっぱい出てるけど
ガイジンの本でそういうの見たことねーな
ガイジンって設計書を書いてんのか? 長いこと騙されてたけど
そもそもあのボケどもに設計って
無理なんじゃね?
オブジェクト指向もメリット皆無だし
設計手法回りの技術はとにかく怪しい
適用しない方が開発効率が高いものが多い
新技術が出たら必ずメリットとデメリットを書き出して
明確に工数削減と品質向上に数字が出せないなら導入を見送るべきだ このスレッドは1000を超えました。
新しいスレッドを立ててください。
life time: 8日 10時間 24分 10秒 5ちゃんねるの運営はプレミアム会員の皆さまに支えられています。
運営にご協力お願いいたします。
───────────────────
《プレミアム会員の主な特典》
★ 5ちゃんねる専用ブラウザからの広告除去
★ 5ちゃんねるの過去ログを取得
★ 書き込み規制の緩和
───────────────────
会員登録には個人情報は一切必要ありません。
月300円から匿名でご購入いただけます。
▼ プレミアム会員登録はこちら ▼
https://premium.5ch.net/
▼ 浪人ログインはこちら ▼
https://login.5ch.net/login.php レス数が1000を超えています。これ以上書き込みはできません。