アカウント名:
パスワード:
ソース自体が設計書（の一部）なんですが。大体、他の物作りでも、自然言語だけでは正確な指示は出来ないので、その仲介として図面などが存在して、それらはとてもじゃないけど、シロート（あえてカタカナ）には書くことどころか、読み取ることも出来ない。（ソースよりは判ったふりはしやすい）
要するに、「セッケーショがぁ」と騒ぐ上司は、他の物作りの場面で図面とか判ったふりをする奴。ポンチ絵でも描いてわたしゃ納得しますって。
＞ソース自体が設計書（の一部）なんですが。
こういうこという奴は「私はバカです」って言ってるのと同じだと思ってる。
要求書とそれを実現する実装方法を抽象化した「設計書」がない限り「実装のミス」はわかりません。
ある値 a と b を合計する値を求めるのが要求と仕様だったとして、実装が a - b になっていた場合、「ソースだけ見ても実装のミスとわかる人はいない。」
ソースを設計書というなら「a - b」が正となり、それしか資料がなくなるのだから。
あなたの理屈で必要なのは要求仕様書であって、設計書ではない。そして要求仕様書は設計者が書くものじゃない。
要求仕様書なんて
「なにがしたい」（ものを買いたい、売りたい。）
レベルで「実現方法（機能仕様、機能設計）」はないでしょうが。
必要なのは「機能と実装の設計」
「コーディング仕様書なんていらない」のは同意できますが「機能実現の為の実装設計書」は必要です。
「どういうDBでどのテーブルはどういう意味を持ち、どのフィールドは何のためで、どういう計算で入るべきか。」
それが「要求仕様書？あほか」
上記がない限り実装でミスってもけっしてわかりません。
＞「機能実現の為の実装設計書」は必要です。
＞「どういうDBでどのテーブルはどういう意味を持ち、どのフィールドは何のためで、＞どういう計算で入るべきか。」
機能を上から下まできっちり詰めることができるのなら、それは即ちそのままソースコードに落とし込めるということで、それなら最初からソースコードにそういうことを書けばいい。
そういう意味で『ソースコードは設計書』なんです。
# それにね、だいたい同じ頭で「機能実現の為の実装設計書」と「ソースコード」を# 書いたところで、両方に同じ間違いをするのが関の山でしょ。
フィールドを計算する関数ごとに「テーブルの意味」「関連する別のフィールド」「別のテーブルの意味」すべてかくんですか？
そもそもシステム全体でDBを複数使用している場合、「システム全体では使用してもそのクラスでは使用しないが値としては関連してくる」
とかいくらでもあるわけで。
だからこそ「コーディング設計書」でなくて「なにをしたいか、何をするべきか、システム全体の中で何を担って、なにを行って、返す値は何で、システム全体でどういう意味を持つか」
の「設計書」が必要なんですよ。後で他の人間がみて、「ここでバカやってる」ってわかるように。
そもそも「何を求められていたか、そこで何するべきだったか」
がわからなくてどうやって「やっていることのミス見つけるの？」
＞「コーディング設計書」でなくて「なにをしたいか、何をするべきか、システム全体の中で何を担って、＞なにを行って、返す値は何で、システム全体でどういう意味を持つか」
もしかして知らないのかもしれないけれど、まともなプログラマならそういうこともソースコード中にある程度ちゃんと書いておくものなのです。
もしかして知らないのかもしれないけれど、まともなプログラマならそういうこともソースコード外のドキュメントにある程度ちゃんと書いておくものなのです。
ソースコードの中に書いておいて自動生成すればその要件は満たせるね。ドキュメントと突き合せずにソースで直接突き合せられるからソースに書くほうが合理的。別に書いてたら整合性を保つ手間も増えるし、同じことを2セット書くとかミス増えるだけじゃん。
にもかかわらずドキュメントで同じことをもう一度書くことの意義はどこにあるんですかね。
○○画面の××ボタンの処理の仕様が知りたいというシチュエーションがあったとしましょう。
ソースコードから自動生成したドキュメントしかない場合、まず○○画面のソースがどれかをドキュメントツリーを掘って探す必要があります。首尾よく○○画面のソースから作られたドキュメントを見つけ××ボタンの処理だというA関数の項を見つけました。しかしA関数のドキュメントを見ても概要は書いてあるが詳細が何も書いていない。さて困った、仕方ないからA関数のソースを探してきて読んでみて謎が解けました。A関数ではB関数を呼んでいて主要な処理はB関数で行っていたのです。B関数のドキュメントを探してみるとそこには少し詳細が書いてありました。それでもまだ全部はわからない。そこでB関数のソースを読んでみると今度はC関数を呼んでいて…
なんてことになります。２度も同じことを書かないんですからB関数の処理内容をA関数のコメントに詳細に書くわけにはいきませんからね。A関数のコメントでB関数を呼んでいると書くのも現実的にはナンセンスです。通常呼ばれる関数は１個や２個じゃきかないんですから。
これが独立した設計書がちゃんとある場合だと○○画面設計書という名前のドキュメントファイルを探して××ボタンの処理と書いてある項目を読めばそれで終わりです。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
Stay hungry, Stay foolish. -- Steven Paul Jobs
ソース自体 (スコア:2)
ソース自体が設計書（の一部）なんですが。
大体、他の物作りでも、自然言語だけでは正確な指示は出来ないので、その仲介として図面などが存在して、それらはとてもじゃないけど、シロート（あえてカタカナ）には書くことどころか、読み取ることも出来ない。（ソースよりは判ったふりはしやすい）
要するに、「セッケーショがぁ」と騒ぐ上司は、他の物作りの場面で図面とか判ったふりをする奴。ポンチ絵でも描いてわたしゃ納得しますって。
Re: (スコア:0, 興味深い)
＞ソース自体が設計書（の一部）なんですが。
こういうこという奴は「私はバカです」
って言ってるのと同じだと思ってる。
要求書とそれを実現する実装方法を抽象化した「設計書」がない限り「実装のミス」はわかりません。
ある値 a と b を合計する値を求めるのが要求と仕様だったとして、
実装が a - b になっていた場合、「ソースだけ見ても実装のミスとわかる人はいない。」
ソースを設計書というなら「a - b」が正となり、それしか資料がなくなるのだから。
Re: (スコア:0)
あなたの理屈で必要なのは要求仕様書であって、設計書ではない。
そして要求仕様書は設計者が書くものじゃない。
Re: (スコア:0)
要求仕様書なんて
「なにがしたい」（ものを買いたい、売りたい。）
レベルで「実現方法（機能仕様、機能設計）」はないでしょうが。
必要なのは「機能と実装の設計」
「コーディング仕様書なんていらない」のは同意できますが「機能実現の為の実装設計書」は必要です。
「どういうDBでどのテーブルはどういう意味を持ち、どのフィールドは何のためで、
どういう計算で入るべきか。」
それが「要求仕様書？あほか」
上記がない限り実装でミスってもけっしてわかりません。
Re: (スコア:0)
＞「機能実現の為の実装設計書」は必要です。
＞「どういうDBでどのテーブルはどういう意味を持ち、どのフィールドは何のためで、
＞どういう計算で入るべきか。」
機能を上から下まできっちり詰めることができるのなら、それは即ちそのまま
ソースコードに落とし込めるということで、それなら最初からソースコードに
そういうことを書けばいい。
そういう意味で『ソースコードは設計書』なんです。
# それにね、だいたい同じ頭で「機能実現の為の実装設計書」と「ソースコード」を
# 書いたところで、両方に同じ間違いをするのが関の山でしょ。
Re: (スコア:0)
フィールドを計算する関数ごとに「テーブルの意味」「関連する別のフィールド」「別のテーブルの意味」
すべてかくんですか？
そもそもシステム全体でDBを複数使用している場合、
「システム全体では使用してもそのクラスでは使用しない
が値としては関連してくる」
とかいくらでもあるわけで。
# それにね、だいたい同じ頭で「機能実現の為の実装設計書」と「ソースコード」を
# 書いたところで、両方に同じ間違いをするのが関の山でしょ。
だからこそ
「コーディング設計書」でなくて「なにをしたいか、何をするべきか、システム全体の中で何を担って、
なにを行って、返す値は何で、システム全体でどういう意味を持つか」
の「設計書」が必要なんですよ。
後で他の人間がみて、「ここでバカやってる」ってわかるように。
そもそも「何を求められていたか、そこで何するべきだったか」
がわからなくてどうやって「やっていることのミス見つけるの？」
Re: (スコア:0)
＞「コーディング設計書」でなくて「なにをしたいか、何をするべきか、システム全体の中で何を担って、
＞なにを行って、返す値は何で、システム全体でどういう意味を持つか」
もしかして知らないのかもしれないけれど、まともなプログラマならそういうこともソースコード中に
ある程度ちゃんと書いておくものなのです。
Re: (スコア:-1)
もしかして知らないのかもしれないけれど、まともなプログラマならそういうこともソースコード外の
ドキュメントにある程度ちゃんと書いておくものなのです。
Re: (スコア:0)
ソースコードの中に書いておいて自動生成すればその要件は満たせるね。
ドキュメントと突き合せずにソースで直接突き合せられるからソースに書くほうが合理的。
別に書いてたら整合性を保つ手間も増えるし、同じことを2セット書くとかミス増えるだけじゃん。
にもかかわらずドキュメントで同じことをもう一度書くことの意義はどこにあるんですかね。
Re:ソース自体 (スコア:0)
○○画面の××ボタンの処理の仕様が知りたいというシチュエーションがあったとしましょう。
ソースコードから自動生成したドキュメントしかない場合、
まず○○画面のソースがどれかをドキュメントツリーを掘って探す必要があります。
首尾よく○○画面のソースから作られたドキュメントを見つけ××ボタンの処理だというA関数の項を見つけました。
しかしA関数のドキュメントを見ても概要は書いてあるが詳細が何も書いていない。
さて困った、仕方ないからA関数のソースを探してきて読んでみて謎が解けました。
A関数ではB関数を呼んでいて主要な処理はB関数で行っていたのです。
B関数のドキュメントを探してみるとそこには少し詳細が書いてありました。
それでもまだ全部はわからない。そこでB関数のソースを読んでみると今度はC関数を呼んでいて…
なんてことになります。
２度も同じことを書かないんですからB関数の処理内容をA関数のコメントに詳細に書くわけにはいきませんからね。
A関数のコメントでB関数を呼んでいると書くのも現実的にはナンセンスです。
通常呼ばれる関数は１個や２個じゃきかないんですから。
これが独立した設計書がちゃんとある場合だと
○○画面設計書という名前のドキュメントファイルを探して××ボタンの処理と書いてある項目を読めばそれで終わりです。