ソースコードを日本語訳したレベルの詳細設計書ってどう? [無断転載禁止]©2ch.net
■ このスレッドは過去ログ倉庫に格納されています
sum = sum + 1;
これををパースして
assign(
var("sum"),
add(
var("sum"),
const(1)
)
)
こんな構文木を作る
辞書に{ "sum": "合計" }を登録する
構文木を文字列に変換する
const(1) -> 「1」
var("sum") -> 「合計」
add(a, b) -> 「aとbの和」
assign(a, b) -> 「aにbを代入する。」
つまり
「「合計」に「「合計」と「1」の和」を代入する。」
という文字列に変換する
同じ考え方で変換規則を作り込んで行けばソースから日本語の仕様書を生成することができる
誰か作ってくれ エクセル設計書って大量の小さいクラスと相性悪いよなぁ
クラスをシートで分けるとシート数大杉だし
ファイルで分けると開くのめんどくさすぎ >>517
Excelかどうかじゃなくて、大量の小さいクラスをいちいち設計書に起こしてるのがバカすぎw >>518
設計書とコードが同期してないとレビューで袋叩きのズタボロにされる 大量の小さいクラスに向いた設計の表現方法はないの? もちろんですとも現作業終了後ただちに直します
(テストさえ通ってしまえばこっちのもの) レビュアーがマージするからレビュー指摘クリアしないといつまでたっても終わらんぞ >>526
ソースコードレビュー完了より先にテストっておかしくないかい? >>525
わかりました。レビュアーを修正します。 >>524
バカが読めないコードはダメって規約ができるのかよw >>534
バカが読めないコードが全部使用禁止になるのか 規約とはトレードオフでどちらかに割れるようなお題を片方に寄せるためのものだと思ってた
でも現実には誰もがその判断は間違ってると思っていても逆らえないただの足枷になってしまっている 半年間くらいずっとExcelとWordで似たようなコピペ設計書を作る日々を繰り返したことがあるが、
結局その設計書が使われることは無かったな
基本クラスの仕様が少し変わる度に数千あるファイル全て手直ししないといけなくなったので シート[受注]
継承元: 無し
状態変数:
受注番号(文字列(20))
受注日(年月日)
明細(受注明細のリスト)
処理:
受注額取得:
入力:無し
出力:受注額(金額)
処理内容:
明細から(単価*数量)を選択して合計して返す
設計書ってこんな感じでいいんじゃないかな?
みんなどう書いてるの? >>538
1行を10行にするつもりで書いてたわ
おっさん連中は文字が沢山あると嬉しいらしいです
処理内容:
@ 合計値を格納する変数totalを宣言する
A @で宣言した変数totalに0を代入する
B 明細リストをループする処理に入る
C 明細から単価と数量を乗算し、@で宣言した変数totalに加算する
D B明細リストのループが終了
E 変数totalを戻り値に代入する
F 関数を終了する ちょっと聞かせてもらいたいのだけど、商用製品で仕様書や設計書無しで他人に製品評価させるってありなのか?
遅れているじゃ無くて作る予定が無い >>542
分かりづらいだろ?
更にソースに連番で@〜Fまで処理別に書くんやで
// @ 合計値(ry
int total;
// A @で宣言(ry
total = 0;
以降続く・・・
半年後、大炎上した インターフェースって設計書に書くと拒否されるから別の言い回しないかな >>538
それは設計書じゃない。
設計書ってのは、「設計した」結果が記載されるものだ。 設計書は標準的なコーダーが施工すれば同じコードが仕上がるようになっていなければならない。
したがって>>1以外の設計書はありえない。 >>550
そうなら、「設計ができていない」と判断するしか無い。 「やろうと思えば機械的にソースコードに変換可能」が設計書の定義だろうね
機械的にソースコードに変換できないということは曖昧さが残っているということだ
曖昧な設計は設計ではなくただの妄想 つまりスレタイみたいな詳細設計書は無駄ということたな 設計書自体は無駄でもそれを書かされてるお前らの苦労を見る事が上流の人達の娯楽になり
結果上流の人達のパフォーマンス向上に貢献する事になる
やっぱりソースコードを日本語訳したレベルの詳細設計書は必要悪なんだよ 抜け毛が増えてきた
いやだ
ハゲたくない
だれか助けてくれ >>557
設計書は生成してるんだなぁ
工数なしで費用だけ頂いてすいやせんね ハゲないためにDNAというソースコードを修正せねばなるまい DNAにどれだけ無数の欠陥があろうともハゲだけは受け入れる事はできない >>558
ハゲはどうせ帰っても抜け毛を数えるぐらいしかやることないだろうから、毎日終電までサビ残して経済に貢献しろ ハゲだが帰宅したら楽しいクッキングタイムだ
抜け毛を数えてる暇はない ソースと対の詳細設計書はもちろんソースコード一行一行にもコメント書くんやで シェルスクリプトを書けるようにならないといけなくなって、本を一冊買った
サンプルコードの一行一行に、これはなにをしているというのがコメントで書かれていた
ありがたかった >>573
メソッドドキュメントコメントにも詳細な処理内容を書かなきゃ >>574
マジレスすると、それはコードの意味がわからない人に
一行一行「説明してくれる」のがありがたいのであって
一行一行「コメントしてくれる」のがありがたいわけじゃない
コードが読める人=例えば英語が読める人
に対して、一単語ずつ意味を説明されてもうざいだけ >>576
お前のようなできるプログラマでも、そんなダサいコメントだらけのコードに関わることがあるのか? >>578
そりゃあるだろ?
一人でプログラミングしてるわけじゃないんだ。
十数年前の学生の頃に、そんなコード書いていたやつがいたんだよ すべての行にコメントがついてるアセンブラコードとかあったな >>579
十数年前のことをよくもまぁ飽きずに何度も語れるもんだw 詳細設計書がしっかりしてるならコメントは不要。
少なくとも、このスレでコメント云々語るのはすれ違い。 >>581
一回しか語ってないが、何度も語ると、何か問題が有るの? だがしっかりしたコードはこの世に存在しないので詳細設計書は必要 詳細設計って何を指しているんだろう?
機能仕様の下位に位置するドキュメントかな?
どんなにコードがしっかりしていても、プログラム全体を把握するドキュメントは必要と思う。
ブロック図、シーケンス図、状態遷移図等。 >>589
詳細設計という概念が考えられた時代を考慮に入れるとおのずと解る ビルドコストランコストが高すぎたんだ
だから設計書を書くしかなかった
つまり現代では不要 >>589
殆どのシステムはコンテキストマップがあればあとはコードとドキュメントコメントで十分
概念が複雑なものはUMLに頼らずそれを表現する的確なモデルを作る
例えば剛体シミュレータを作るのにUMLは最適解じゃないだろ
まず必要なものは物理数学モデルだ ValueObjectを使うようになると設計書は要らなくなるな
というか同期するの大変だからむしろ設計書が邪魔になる 訳のわからない言い訳ばかり言ってないで設計書書け底辺共 今時になって設計書なんか書いてる底辺がなんか言ってる >>593
じゃあ今まではValueObjectを使ってなかったがために設計書が必要になってたのか
意味わからんなw
どういう設計書を書いてたんだよw >>596
そうだよ
ValueObjectを使っていなかったから基本的な型のロジックがあちこちに分散して制御不能になってた
それを設計書でどうにかして誤魔化そうとしていた Value Objectって言いたかっただけだろ。
はやくフローチャートを書く仕事に戻れよw 誰も読まない設計書をサビ残で仕上げてこそ底辺プログラマ
苦痛を与えることに意味がある 詳細設計書は誤字脱字なく書け
コード一行にコメントを書け
メソッドドキュメントコメントには処理フローを書け
だから、みなし残業60時間用意しとるんやからな >>600
自動生成できるものに数倍の工数を使えて嬉しいね
楽して稼げるから下請けとしては助かりますわ
え?手書き?またまたご冗談を… 自動生成遅っwwww
ゼンマイ式コンピューターでも使ってんのか>>601の会社はw 機械的にソースコードに変換可能
か
ならばそれをコンパイルすれば?
と笑ってしまうww 某社の製品でエクセル設計書をプログラムに変換可能とか宣伝してたから文書読んだら
形式固定の表データからコード生成&ビルドするだけで笑わせてもらった
エクセルVBAと大差ない >>606
笑うというか苦笑したってところかな
君に対してね 笑うポイントがおかしい自覚がある人にアンカされとるwキモw 「神掛かりのパフォーマンスを出すモノを見た」が
「どうやってそれを実現したのか私にはわからない」から
「形式を模倣」することに徹する
に陥るのはこの世の常じゃあないのか?
で、最終的には見た目バンザイと 個人的にコードジェネレータを勧めたいひとは
「ぶっちゃけあなた同じ事やってるんでしょ」かつ
「それでメシ食えてるから今後もずっとそれをやっていきたいんでしょ」のうえ
「相手がいうことは正しいか間違ってるかを知りたいんじゃなくて、個人的にキモチイイ見え方かどうかだけが価値判断基準の人」かなぁ
つまり、プログラミングとか好きじゃないのね、でも立場上ブログラマとかSEの類なんス
そういう条件そろってる人割と多いからコードジェネレータ勧めることよくある 設計書の通りにプログラムを書けと言って上流から渡される細かすぎる(その割に誤算だらけの)設計書に対する皮肉として
設計書の通りで本当に動くならコードジェネレーターでも作ればいいんじゃね?と皮肉で返したのが始まり
本当に設計書からコードを生成しようとは別に誰も考えていない そもそも設計書の通りにコード書けるならコード要らなくね?
設計書からマシン語作れば解決 コードを読めない人の為に設計書を書く
なら解らんでもない 設計には業務知識だけでなくプログラミングの領域の要素も入ってこざるを得ない
プログラミングの素人がリポジトリとかサービスとかインターフェースとかパッケージとかイベントとかインフラストラクチャーとかコントローラーとかビューとか言われたとして果たして正しく理解できるだろうか
プログラムを読めない人は設計書も正しく読めない
そんな人は最初から相手にするだけ時間の無駄だ バカ上司「プログラムをそのまま日本語したものが設計書だ。
お客様はプログラムは読めないが日本語化したものなら読める」
僕「識別子を日本語化してキーワードをマクロで日本語化すれば素人でも読めるってこと?」
バカ上司「うるさい。設計書は納品物なんだから文句言わず作れ」 ■ このスレッドは過去ログ倉庫に格納されています