アカウント名:
パスワード:
ソース自体が設計書(の一部)なんですが。大体、他の物作りでも、自然言語だけでは正確な指示は出来ないので、その仲介として図面などが存在して、それらはとてもじゃないけど、シロート(あえてカタカナ)には書くことどころか、読み取ることも出来ない。(ソースよりは判ったふりはしやすい)
要するに、「セッケーショがぁ」と騒ぐ上司は、他の物作りの場面で図面とか判ったふりをする奴。ポンチ絵でも描いてわたしゃ納得しますって。
>ソース自体が設計書(の一部)なんですが。
こういうこという奴は「私はバカです」って言ってるのと同じだと思ってる。
要求書とそれを実現する実装方法を抽象化した「設計書」がない限り「実装のミス」はわかりません。
ある値 a と b を合計する値を求めるのが要求と仕様だったとして、実装が a - b になっていた場合、「ソースだけ見ても実装のミスとわかる人はいない。」
ソースを設計書というなら「a - b」が正となり、それしか資料がなくなるのだから。
それは「よ、う、き、ゅ、う、し、よ、う、し、ょ」例えば、車は「エンジンが付いてて、タイヤがあって、流線型で」とか。当然そんなものでは、いきなり物が作れるはずがない。
「自然言語」は「設計書」として不完全なツールに過ぎない。
もちろん要求仕様書は非常に重要で、ある状況に対して最終的な結果はすべてそこにあるので、首っ引きで参照しながらソースを書きます。しかし、それは設計書ではない。
設計書は作る側に渡すもので、提供される側が必要とすべきものではない。(その次に別の製作者に渡すために、保管ということでは必要だが)
図面だとそれが理解出きるのに、ソフトウエアだとなぜ理解されないんだろう。
ウォーターフォールモデルと上流/下流工程の考え方に汚染されたSIer脳では、基本/詳細設計で行うことのみが設計でありその成果物が設計書で、開発(プログラミング)とは前工程の設計書のとおりに作るものなんですよ。
間違いが2点。基本/詳細設計の成果物には、開発工程に対する要求仕様書という側面があるということ。粒度が違うだけでプログラミングもまた設計だということ。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
コンピュータは旧約聖書の神に似ている、規則は多く、慈悲は無い -- Joseph Campbell
ソース自体 (スコア:2)
ソース自体が設計書(の一部)なんですが。
大体、他の物作りでも、自然言語だけでは正確な指示は出来ないので、その仲介として図面などが存在して、それらはとてもじゃないけど、シロート(あえてカタカナ)には書くことどころか、読み取ることも出来ない。(ソースよりは判ったふりはしやすい)
要するに、「セッケーショがぁ」と騒ぐ上司は、他の物作りの場面で図面とか判ったふりをする奴。ポンチ絵でも描いてわたしゃ納得しますって。
Re: (スコア:0, 興味深い)
>ソース自体が設計書(の一部)なんですが。
こういうこという奴は「私はバカです」
って言ってるのと同じだと思ってる。
要求書とそれを実現する実装方法を抽象化した「設計書」がない限り「実装のミス」はわかりません。
ある値 a と b を合計する値を求めるのが要求と仕様だったとして、
実装が a - b になっていた場合、「ソースだけ見ても実装のミスとわかる人はいない。」
ソースを設計書というなら「a - b」が正となり、それしか資料がなくなるのだから。
Re: (スコア:2)
それは「よ、う、き、ゅ、う、し、よ、う、し、ょ」
例えば、車は「エンジンが付いてて、タイヤがあって、流線型で」とか。当然そんなものでは、いきなり物が作れるはずがない。
「自然言語」は「設計書」として不完全なツールに過ぎない。
もちろん要求仕様書は非常に重要で、ある状況に対して最終的な結果はすべてそこにあるので、首っ引きで参照しながらソースを書きます。しかし、それは設計書ではない。
設計書は作る側に渡すもので、提供される側が必要とすべきものではない。(その次に別の製作者に渡すために、保管ということでは必要だが)
図面だとそれが理解出きるのに、ソフトウエアだとなぜ理解されないんだろう。
Re:ソース自体 (スコア:0)
ウォーターフォールモデルと上流/下流工程の考え方に汚染されたSIer脳では、基本/詳細設計で行うことのみが設計でありその成果物が設計書で、開発(プログラミング)とは前工程の設計書のとおりに作るものなんですよ。
間違いが2点。
基本/詳細設計の成果物には、開発工程に対する要求仕様書という側面があるということ。
粒度が違うだけでプログラミングもまた設計だということ。