まさにこれ。 > ある値 a と b を合計する値を求めるのが要求と仕様だったとして、 > 実装が a - b になっていた場合、「ソースだけ見ても実装のミスとわかる人はいない。」 って言ってるけど、そもそも設計書の段階で間違われてたらどうすんだと。 更にソースでは要求仕様をきちんと満たしてたりすると、余計に混乱するわけです。 プログラミングでは、重複を避けろと言われますが、同じ内容を別の言語で重複して書くのは愚行です。 *BSD や Linux にすら設計書がないのに、明らかにそれら以下の規模や複雑さのソフトに設計書が必要である明確な根拠があるとは思えないです。
ソース自体 (スコア:2)
ソース自体が設計書（の一部）なんですが。
大体、他の物作りでも、自然言語だけでは正確な指示は出来ないので、その仲介として図面などが存在して、それらはとてもじゃないけど、シロート（あえてカタカナ）には書くことどころか、読み取ることも出来ない。（ソースよりは判ったふりはしやすい）
要するに、「セッケーショがぁ」と騒ぐ上司は、他の物作りの場面で図面とか判ったふりをする奴。ポンチ絵でも描いてわたしゃ納得しますって。
Re: (スコア:0, 興味深い)
＞ソース自体が設計書（の一部）なんですが。
こういうこという奴は「私はバカです」
って言ってるのと同じだと思ってる。
要求書とそれを実現する実装方法を抽象化した「設計書」がない限り「実装のミス」はわかりません。
ある値 a と b を合計する値を求めるのが要求と仕様だったとして、
実装が a - b になっていた場合、「ソースだけ見ても実装のミスとわかる人はいない。」
ソースを設計書というなら「a - b」が正となり、それしか資料がなくなるのだから。
Re: (スコア:0)
あなたの理屈で必要なのは要求仕様書であって、設計書ではない。
そして要求仕様書は設計者が書くものじゃない。
Re: (スコア:0)
要求仕様書なんて
「なにがしたい」（ものを買いたい、売りたい。）
レベルで「実現方法（機能仕様、機能設計）」はないでしょうが。
必要なのは「機能と実装の設計」
「コーディング仕様書なんていらない」のは同意できますが「機能実現の為の実装設計書」は必要です。
「どういうDBでどのテーブルはどういう意味を持ち、どのフィールドは何のためで、
どういう計算で入るべきか。」
それが「要求仕様書？あほか」
上記がない限り実装でミスってもけっしてわかりません。
Re: (スコア:0)
＞「機能実現の為の実装設計書」は必要です。
＞「どういうDBでどのテーブルはどういう意味を持ち、どのフィールドは何のためで、
＞どういう計算で入るべきか。」
機能を上から下まできっちり詰めることができるのなら、それは即ちそのまま
ソースコードに落とし込めるということで、それなら最初からソースコードに
そういうことを書けばいい。
そういう意味で『ソースコードは設計書』なんです。
# それにね、だいたい同じ頭で「機能実現の為の実装設計書」と「ソースコード」を
# 書いたところで、両方に同じ間違いをするのが関の山でしょ。
Re: (スコア:0)
まさにこれ。
> ある値 a と b を合計する値を求めるのが要求と仕様だったとして、
> 実装が a - b になっていた場合、「ソースだけ見ても実装のミスとわかる人はいない。」
って言ってるけど、そもそも設計書の段階で間違われてたらどうすんだと。
更にソースでは要求仕様をきちんと満たしてたりすると、余計に混乱するわけです。
プログラミングでは、重複を避けろと言われますが、同じ内容を別の言語で重複して書くのは愚行です。
*BSD や Linux にすら設計書がないのに、明らかにそれら以下の規模や複雑さのソフトに設計書が必要である明確な根拠があるとは思えないです。
Re:ソース自体 (スコア:1)
それだと誰も設計レビューしてないみたいだ。
*BSD や Linux にすら設計書がないのに、
IRC や ML のログが暗黙の設計書だったりする。
ときにはアスキーアートまで駆使して説明することもあるよ。
Re:ソース自体 (スコア:1)