X



ソースコードを日本語訳したレベルの詳細設計書ってどう? [無断転載禁止]©2ch.net
■ このスレッドは過去ログ倉庫に格納されています
0541仕様書無しさん
垢版 |
2017/10/17(火) 22:55:53.66
ちょっと聞かせてもらいたいのだけど、商用製品で仕様書や設計書無しで他人に製品評価させるってありなのか?
遅れているじゃ無くて作る予定が無い
0542538
垢版 |
2017/10/17(火) 22:57:14.62
>>540
わかりにくくなってるじゃんw
0543540
垢版 |
2017/10/17(火) 23:48:17.35
>>542
分かりづらいだろ?
更にソースに連番で@〜Fまで処理別に書くんやで

// @ 合計値(ry
int total;

// A @で宣言(ry
total = 0;
以降続く・・・

半年後、大炎上した
0545仕様書無しさん
垢版 |
2017/10/17(火) 23:53:02.74
インターフェースって設計書に書くと拒否されるから別の言い回しないかな
0549KAC
垢版 |
2017/10/18(水) 00:40:25.31
>>538
それは設計書じゃない。
設計書ってのは、「設計した」結果が記載されるものだ。
0551仕様書無しさん
垢版 |
2017/10/18(水) 07:55:46.69
設計書は標準的なコーダーが施工すれば同じコードが仕上がるようになっていなければならない。
したがって>>1以外の設計書はありえない。
0553KAC
垢版 |
2017/10/18(水) 12:50:50.21
>>550
そうなら、「設計ができていない」と判断するしか無い。
0554仕様書無しさん
垢版 |
2017/10/18(水) 19:11:48.14
「やろうと思えば機械的にソースコードに変換可能」が設計書の定義だろうね
機械的にソースコードに変換できないということは曖昧さが残っているということだ
曖昧な設計は設計ではなくただの妄想
0556仕様書無しさん
垢版 |
2017/10/18(水) 19:32:03.08
つまりスレタイみたいな詳細設計書は無駄ということたな
0557仕様書無しさん
垢版 |
2017/10/18(水) 19:37:20.06
設計書自体は無駄でもそれを書かされてるお前らの苦労を見る事が上流の人達の娯楽になり
結果上流の人達のパフォーマンス向上に貢献する事になる
やっぱりソースコードを日本語訳したレベルの詳細設計書は必要悪なんだよ
0558仕様書無しさん
垢版 |
2017/10/18(水) 19:46:58.40
抜け毛が増えてきた
いやだ
ハゲたくない
だれか助けてくれ
0559仕様書無しさん
垢版 |
2017/10/18(水) 20:20:39.17
>>557
設計書は生成してるんだなぁ
工数なしで費用だけ頂いてすいやせんね
0560仕様書無しさん
垢版 |
2017/10/18(水) 20:21:08.73
そうやっていつも他力本願だからハゲるんだよ
0562仕様書無しさん
垢版 |
2017/10/18(水) 20:33:14.70
切っても剃ってもハゲはハゲ
0563仕様書無しさん
垢版 |
2017/10/18(水) 21:03:09.78
ハゲないためにDNAというソースコードを修正せねばなるまい
0565仕様書無しさん
垢版 |
2017/10/18(水) 21:19:09.87
DNAにどれだけ無数の欠陥があろうともハゲだけは受け入れる事はできない
0567仕様書無しさん
垢版 |
2017/10/18(水) 22:09:53.46
>>558
ハゲはどうせ帰っても抜け毛を数えるぐらいしかやることないだろうから、毎日終電までサビ残して経済に貢献しろ
0568仕様書無しさん
垢版 |
2017/10/18(水) 22:15:06.16
ハゲだが帰宅したら楽しいクッキングタイムだ
抜け毛を数えてる暇はない
0573仕様書無しさん
垢版 |
2017/10/19(木) 07:17:31.60
ソースと対の詳細設計書はもちろんソースコード一行一行にもコメント書くんやで
0574仕様書無しさん
垢版 |
2017/10/19(木) 07:46:09.81
シェルスクリプトを書けるようにならないといけなくなって、本を一冊買った
サンプルコードの一行一行に、これはなにをしているというのがコメントで書かれていた
ありがたかった
0575仕様書無しさん
垢版 |
2017/10/19(木) 07:52:27.42
>>573
メソッドドキュメントコメントにも詳細な処理内容を書かなきゃ
0576仕様書無しさん
垢版 |
2017/10/19(木) 22:29:58.97
>>574
マジレスすると、それはコードの意味がわからない人に
一行一行「説明してくれる」のがありがたいのであって
一行一行「コメントしてくれる」のがありがたいわけじゃない

コードが読める人=例えば英語が読める人
に対して、一単語ずつ意味を説明されてもうざいだけ
0578仕様書無しさん
垢版 |
2017/10/19(木) 22:59:47.22
>>576
お前のようなできるプログラマでも、そんなダサいコメントだらけのコードに関わることがあるのか?
0579仕様書無しさん
垢版 |
2017/10/19(木) 23:10:30.51
>>578
そりゃあるだろ?
一人でプログラミングしてるわけじゃないんだ。
十数年前の学生の頃に、そんなコード書いていたやつがいたんだよ
0580仕様書無しさん
垢版 |
2017/10/19(木) 23:22:58.36
すべての行にコメントがついてるアセンブラコードとかあったな
0583KAC
垢版 |
2017/10/19(木) 23:53:57.26
詳細設計書がしっかりしてるならコメントは不要。
少なくとも、このスレでコメント云々語るのはすれ違い。
0586仕様書無しさん
垢版 |
2017/10/20(金) 12:25:31.97
だがしっかりしたコードはこの世に存在しないので詳細設計書は必要
0589仕様書無しさん
垢版 |
2017/10/21(土) 00:56:33.91
詳細設計って何を指しているんだろう?
機能仕様の下位に位置するドキュメントかな?
どんなにコードがしっかりしていても、プログラム全体を把握するドキュメントは必要と思う。
ブロック図、シーケンス図、状態遷移図等。
0590KAC
垢版 |
2017/10/21(土) 02:25:10.36
>>589
詳細設計という概念が考えられた時代を考慮に入れるとおのずと解る
0591仕様書無しさん
垢版 |
2017/10/21(土) 06:33:38.80
ビルドコストランコストが高すぎたんだ
だから設計書を書くしかなかった
つまり現代では不要
0592仕様書無しさん
垢版 |
2017/10/21(土) 06:41:36.35
>>589
殆どのシステムはコンテキストマップがあればあとはコードとドキュメントコメントで十分
概念が複雑なものはUMLに頼らずそれを表現する的確なモデルを作る
例えば剛体シミュレータを作るのにUMLは最適解じゃないだろ
まず必要なものは物理数学モデルだ
0594仕様書無しさん
垢版 |
2017/10/22(日) 23:03:17.29
訳のわからない言い訳ばかり言ってないで設計書書け底辺共
0595仕様書無しさん
垢版 |
2017/10/22(日) 23:22:59.85
今時になって設計書なんか書いてる底辺がなんか言ってる
0596仕様書無しさん
垢版 |
2017/10/22(日) 23:44:41.58
>>593
じゃあ今まではValueObjectを使ってなかったがために設計書が必要になってたのか

意味わからんなw
どういう設計書を書いてたんだよw
0597仕様書無しさん
垢版 |
2017/10/22(日) 23:54:55.54
>>596
そうだよ
ValueObjectを使っていなかったから基本的な型のロジックがあちこちに分散して制御不能になってた
それを設計書でどうにかして誤魔化そうとしていた
0598仕様書無しさん
垢版 |
2017/10/23(月) 02:32:58.82
Value Objectって言いたかっただけだろ。
はやくフローチャートを書く仕事に戻れよw
0599仕様書無しさん
垢版 |
2017/10/23(月) 18:51:21.76
誰も読まない設計書をサビ残で仕上げてこそ底辺プログラマ

苦痛を与えることに意味がある
0600仕様書無しさん
垢版 |
2017/10/23(月) 18:56:13.87
詳細設計書は誤字脱字なく書け

コード一行にコメントを書け

メソッドドキュメントコメントには処理フローを書け

だから、みなし残業60時間用意しとるんやからな
0601仕様書無しさん
垢版 |
2017/10/23(月) 19:34:04.93
>>600
自動生成できるものに数倍の工数を使えて嬉しいね
楽して稼げるから下請けとしては助かりますわ
え?手書き?またまたご冗談を…
0602仕様書無しさん
垢版 |
2017/10/23(月) 19:37:42.65
自動生成遅っwwww
ゼンマイ式コンピューターでも使ってんのか>>601の会社はw
0604仕様書無しさん
垢版 |
2017/10/28(土) 15:27:16.31
機械的にソースコードに変換可能


ならばそれをコンパイルすれば?
と笑ってしまうww
0605仕様書無しさん
垢版 |
2017/10/28(土) 15:56:25.70
某社の製品でエクセル設計書をプログラムに変換可能とか宣伝してたから文書読んだら
形式固定の表データからコード生成&ビルドするだけで笑わせてもらった
エクセルVBAと大差ない
0606仕様書無しさん
垢版 |
2017/10/28(土) 16:09:33.89
笑うポイントがおかしい人ってキモいよねw
0608仕様書無しさん
垢版 |
2017/10/28(土) 19:01:43.26
笑うポイントがおかしい自覚がある人にアンカされとるwキモw
0610仕様書無しさん
垢版 |
2017/10/29(日) 01:43:34.94
「神掛かりのパフォーマンスを出すモノを見た」が
「どうやってそれを実現したのか私にはわからない」から
「形式を模倣」することに徹する

に陥るのはこの世の常じゃあないのか?
で、最終的には見た目バンザイと
0611仕様書無しさん
垢版 |
2017/10/29(日) 01:47:57.16
個人的にコードジェネレータを勧めたいひとは

「ぶっちゃけあなた同じ事やってるんでしょ」かつ
「それでメシ食えてるから今後もずっとそれをやっていきたいんでしょ」のうえ
「相手がいうことは正しいか間違ってるかを知りたいんじゃなくて、個人的にキモチイイ見え方かどうかだけが価値判断基準の人」かなぁ

つまり、プログラミングとか好きじゃないのね、でも立場上ブログラマとかSEの類なんス
そういう条件そろってる人割と多いからコードジェネレータ勧めることよくある
0612仕様書無しさん
垢版 |
2017/10/29(日) 08:47:24.23
設計書の通りにプログラムを書けと言って上流から渡される細かすぎる(その割に誤算だらけの)設計書に対する皮肉として
設計書の通りで本当に動くならコードジェネレーターでも作ればいいんじゃね?と皮肉で返したのが始まり
本当に設計書からコードを生成しようとは別に誰も考えていない
0613仕様書無しさん
垢版 |
2017/10/29(日) 08:52:34.70
そもそも設計書の通りにコード書けるならコード要らなくね?
設計書からマシン語作れば解決
0614仕様書無しさん
垢版 |
2017/10/29(日) 08:54:41.76
コードを読めない人の為に設計書を書く
なら解らんでもない
0615仕様書無しさん
垢版 |
2017/10/29(日) 09:01:24.46
設計には業務知識だけでなくプログラミングの領域の要素も入ってこざるを得ない
プログラミングの素人がリポジトリとかサービスとかインターフェースとかパッケージとかイベントとかインフラストラクチャーとかコントローラーとかビューとか言われたとして果たして正しく理解できるだろうか
プログラムを読めない人は設計書も正しく読めない
そんな人は最初から相手にするだけ時間の無駄だ
0616仕様書無しさん
垢版 |
2017/10/29(日) 09:07:17.81
バカ上司「プログラムをそのまま日本語したものが設計書だ。
お客様はプログラムは読めないが日本語化したものなら読める」

僕「識別子を日本語化してキーワードをマクロで日本語化すれば素人でも読めるってこと?」

バカ上司「うるさい。設計書は納品物なんだから文句言わず作れ」
0617仕様書無しさん
垢版 |
2017/10/29(日) 12:13:22.80
なんだ、ただの「上司に意見しちゃう俺」アピールじゃん
0618仕様書無しさん
垢版 |
2017/10/29(日) 18:53:08.50
>>616
おまえの意見は正しい
問題はこのあたり

・プログラム言語固有の識別子や型宣言、演算子
・複雑な末端アルゴリズム
・ローカル変数

このへんをクリアすれば本当に読めるはず
0619KAC
垢版 |
2017/10/29(日) 20:26:44.28
>>616
それはお前が詳細設計書というものを全く理解できていないだけ。
0620仕様書無しさん
垢版 |
2017/10/29(日) 20:33:14.49
>>619
詳細設計書はゴミ
こんなゴミをありがたがる連中はプログラミングを理解してない
0621仕様書無しさん
垢版 |
2017/10/29(日) 20:48:28.20
詳細設計なら
変数の型を端折れるし
XXを取得するってかいたらローカル変数とGetXXで二回XXを書かないでもすむし
定数の名前とか逆に具体値とかその場で決める必要ないし
先に詳細設計書いたほうが楽じゃないの?
0623仕様書無しさん
垢版 |
2017/10/29(日) 21:12:47.66
名前と動詞を統一しとけばそんなに破綻しないよ
経験上だけど

破綻はおもに必要な情報の不足から起こる
設計書はXXを作成するとかって結果から書いていって順々に中と必要な情報詰めていくかんじ
コード上だと最初から必要な情報洗い出されたうえで引数決めて書く必要があるから
下位でこれたりねーってなったら、上位メソッドまで全部変えなきゃいけなくなる

破綻を見つける能力はコードに劣るけど破綻を回復する能力は詳細設計のほうが全然上だ
0624仕様書無しさん
垢版 |
2017/10/29(日) 21:14:12.39
おまえら簡単に破綻しすぎw
0626仕様書無しさん
垢版 |
2017/10/29(日) 21:37:02.89
何が面倒って名詞に英語の名前つけるのが一番面倒
アルゴリズム考えながら全体見通して無理のない統一された英名考えるとか
俺には無理だ
外人はこんな苦労しなんだろうな
0627仕様書無しさん
垢版 |
2017/10/29(日) 21:51:33.31
>>623
ほらな
やっぱりわかってない
OOPはボトムアップだよ
必要なものがなければその場で作ればいいだけ
疎結合だから他への影響も心配ない
トップダウンで機能分割していく手続き型じゃこうはいかない
一個破綻したら全部持っていかれる
そして世の中の殆どの設計書は手続き型の方法論を踏襲して書かれるものだ
だから簡単に破綻する
ゴミなんだよ
0628仕様書無しさん
垢版 |
2017/10/29(日) 21:55:06.47
必要な情報が欠けてても開発を進められるのがオブジェクト指向の最大の利点
いわゆる決定の遅延って奴だな
これがあるからアジャイルが成立する

全部決めてから着手なんて頭の悪いやり方はオブジェクト指向ではやらない
そういうのはCOBOLとかでやればいい

設計書も同じこと
そういうのはCOBOLでやってくれ
0629仕様書無しさん
垢版 |
2017/10/29(日) 21:55:39.82
>>627
OOPがインターフェースの情報不足をどう解決してくれるのかさっぱり見当がつかない
そもそもボトムアップでコード作れるのは先にトップダウンで設計書き下してるからこそじゃないの?
0630仕様書無しさん
垢版 |
2017/10/29(日) 22:04:31.71
>>629
インターフェースが変わるなら修正すればいい
なんのためにリファクタリングツールが発展したと思ってるんだ
一度書いたら直さないなんて腐った発想が全てを台無しにする
そんなのは一筆書き戻りなしの制約をつけて巨大迷路をクリアするようなものだ

>>629
OOPでも全体を俯瞰するときにはトップダウンで考える
例えばそれはコンテキストの境界を考える場合だ
しかし手続き型のアホどものようにコード全てをトップダウンで解析するようなバカな真似はしない
0631仕様書無しさん
垢版 |
2017/10/29(日) 22:13:59.08
インターフェースのリファクタって
一番自動でできないとこじゃんかー!

嫌だやっぱ先に詳細設計かく
0632仕様書無しさん
垢版 |
2017/10/29(日) 22:18:01.99
>>631
アホか
お前の使ってる開発環境は静的解析もできない欠陥品かよ
0633仕様書無しさん
垢版 |
2017/10/29(日) 22:24:13.57
インターフェースは実装と切り離されてるからむしろリファクタリングは非常にやりやすい
これからレガシーシステムのリファクタリングやりますってなったらまず真っ先にインターフェースで実装の結合を分離して手を出せる状態を作り出す
リファクタリングとインターフェースはサイモンとガーファンクルのデュエットのように相性バツグンなんだよ
やったことない奴には一生わからんかもしれんがそういう奴らは一生スパゲティCOBOLでも啜ってればいい
0634仕様書無しさん
垢版 |
2017/10/29(日) 22:25:53.80
インターフェースの中身を挿げ替えるのはそりゃ簡単ですよ
0635仕様書無しさん
垢版 |
2017/10/29(日) 22:30:09.23
>>634
インターフェースは責務が明確で余裕があるからコントラクトを変えるのも簡単
コントラクトを変えなくてもアダプティブに変更できる場合も多い
インターフェースを使わないと中身の変更も大変だし
コントラクトと中身が結合してしまうからコントラクトを変えることも難しくなる
0636仕様書無しさん
垢版 |
2017/10/29(日) 22:46:58.15
コントラクトってなに

OOPに幻想もちすぎじゃないの
責務の範囲を区切ったって結局実装するメソッドは手続きの中で考えないと
責務を全うするためにいらんメソッドまでいっぱい実装する羽目になって余計工数かかるし

インターフェース自体を変えなきゃいけないってなったら影響範囲半端ないし
作り終わったあとのリファクタはやりやすいかもしれんが、
作りながら破綻がみつかりしだい改修とか作る片手間にやれるこっちゃない

OOPだと余計詳細設計重要なイメージしかないんですが
0637仕様書無しさん
垢版 |
2017/10/29(日) 22:55:29.29
>>636
要するに君が下手くそなんだよ
実装が手続き汚染されるのは手続き脳から離れられないから(頭が硬い)
責務を全うするのにいらんメソッドなんかない
インターフェースがあるから影響範囲を最小化できる
ダメージが軽微なうちから修正しながら進めるから修正コストが最小化される
OOPに必要なドキュメントは詳細設計書ではなくストーリー
0638仕様書無しさん
垢版 |
2017/10/29(日) 22:57:41.13
要らないメソッドってむしろ手続き型の方が多いだろ
トップダウンで分析するから細部まで手が回らず似たようなメソッドを何度も何度も作る

あっそうか手続き型の連中はメソッド書くんじゃなくてコピペするのか
そりゃメソッドが増えないわけだよ
0639仕様書無しさん
垢版 |
2017/10/29(日) 23:05:23.45
全てを結合するまで破綻していたことに気が付かない
それがトップダウン手続き型の開発手法だ
ノコギリで素材を直感に頼り切り分けてそのまま雑にくっつけて家具を作るようなものだ

しっかりしたもの作るならそうじゃない
ヤスリがけなどで加工して寸法チェック強度チェックなど部品単体としての欠陥がないか確かめながら無理のないように組み上げるだろ
それがOOPによるコーディング設計術の心得な
0640仕様書無しさん
垢版 |
2017/10/29(日) 23:05:28.05
なんか掛け声は威勢いいけど
言ってることに具体性なさすぎて何言ってんかわからん
■ このスレッドは過去ログ倉庫に格納されています

ニューススポーツなんでも実況