「ソースコードが仕様書である」という言葉を最近よく聞きます。

また,Googleのエンジニアなども「説明はいいからとにかくソースコードを見せろ」という話をするなどという噂を聞いた憶えもあります。
そこで,ソースコードは本当に仕様書であると考えれるかお聞きしたいです。

私自身の場合,数百万行あるソースコードの一部を読んだことがありますが,とてもドキュメントなしでは読めませんでした。
勿論1000行くらいのものであればソースコードだけで問題ないかもしれないですし,大規模なソフトウェアでも十分にモジュール化されていて,またコードに詳細なコメントが記述されていれば問題ないかもしれません。
とは言え,関数が関数を呼びそれがまた別の関数を呼ぶというのを繰り返す大規模ソフトウェアを,ドキュメントなしで理解するというのは少々難しいように思います。

これは私自身のスキルの問題で,優秀なエンジニアであればソースコードだけで問題なくすべてを把握できるのでしょうか。

ご意見をお聞かせください。

回答の条件
  • 1人5回まで
  • 登録:2006/03/16 06:29:05
  • 終了:2006/03/17 05:37:31

ベストアンサー

id:Broadway No.9

Broadway回答回数326ベストアンサー獲得回数222006/03/16 14:18:28

ポイント14pt

ちょっと失礼します。

 

 

私のしがない経験から考えてみました。

 

まず、仕様書が何か、辞書で引いてみました。辞書的定義が一般的な意味を表すと思うからです。

-----------------------------------------------------------

しよう-しょ【仕様書】

 →しようがき

しよう-がき【仕様書】

 ①仕様の次第を書きしるした文書。しようしょ。

 ②複雑な設計を要する注文品の内容や図をしるした書類。しようしょ。

し-よう【仕様】

 仕方。方法。「返事の―に困る」

-----------------------------------------------------------

[広辞苑(R) 第5版/岩波書店 (C)1998, 2004新村出記念財団 (R)岩波書店]

 

コンピュータ・ソフトウエアも品物ですので、注文の有無を別にして、「仕様書」と云う場合、「しよう-がき②」

を意味する、と考えます。

御存知の通り、コンピュータ・ソフトウェアのプログラムは、プログラミング言語と呼ばれる言語の一種を使って記述されます。或る程度人間の使う自然言語に似せた論理的表現が行えます。だから、プログラム、つまり、ソース・コードが「読める」訳ですよね。変数名等が或る規約通りに付けられていたり、コメントが入っていたり、等の補足的な部分も手助けになります。

しかし、プログラムに関しての何の予備知識も無しに、ソース・プログラムを読もうとすると、酷く大変な事になります。

或るカスタム・メイドのプログラムのヴァージョン・アップに伴って、ソフトハウスを変更した話なんかを聞いた事が有ると思います。ソース・コードや仕様書が有っても、新規受注したソフトハウスのエンジニアは大変な苦労をして、ソース・コードを読み解きます。仕様書が無い場合は、地獄の沙汰です。

この様に、プログラム言語以外の予備知識が無いと、ソース・コードにいきなり当たっても何も分かりません。

こうなってしまえば、ソース・コードは極々単純に例えれば、恐ろしく難解なパズルと同然だ、と言う事が出来るでしょう。

似た様な事は割と、よく有る話です。

 

「Googleのエンジニアなども『説明はいいからとにかくソースコードを見せろ』と言う」話は、そのエンジニアが特に慣れ親しんだ分野か製品のプログラムだった、と云う事が大前提として有る、と考えるべきです。

人一人の理解出来る範囲は、これだけ複雑で巨大化したコンピュータ・ソフトウエアについては、極々一部に過ぎない、と言う事は既に御存知の事と思います。

仕様書は、複雑な設計を要する製品の概要を示した「地図」と考えれば理解し易いと思います。慣れた場所なら、経験から来る土地勘や、あてずっぽうでも何となく目的地に着きます。何事についても、経験豊富な方が、理解能力は早い場合が多いです。でも、見知らぬ場所だと、そうは行かない。

これは、経験豊富な「優秀なエンジニア」であっても、同じ事なのです。

「これは私自身のスキルの問題で,優秀なエンジニアであればソースコードだけで問題なくすべてを把握できるのでしょうか」。

これについては「返事の仕様に困る」事は有りません。

全てプログラムにはバグが内包されている可能性が有る事は論理的に証明されていると言います。問題無く、全てを把握出来る人は、居ません。

「出来る」と云う人は、単なる法螺吹きか、傲慢なだけ、と解すべきでしょう。

だから、どうぞ御心配無く!

 

 

まずは私見まで。御役に立てれば幸いです。

id:tono5652

なるほど。ご丁寧にありがとうございます。

たしかにある程度感が働く場所ならソースコードがすぐに頭に入ってくるかもしれないですね。

OS規模のプログラミングであっても,たとえばスケジューラが専門のプログラマであれば,他のOSでもスケジューラ部分についてはソースを読んだ方が早い。しかし例えばデバイスドライバについてはやはり仕様書が必要だった。

このようなことがあるかもしれないですね。

2006/03/16 22:11:51

その他の回答(13件)

id:kn1967 No.1

kn1967回答回数2915ベストアンサー獲得回数3012006/03/16 06:49:07

ポイント14pt

仕様書にどこまで書く必要があるかは様々ですが、開発規模の大小に関わらず、何らかの仕様書が必要になるということを避けては通れないです。

「既に概要を知っているから肝心の中身を見せろ」あるいは「短いプログラムだったら見たほうが早いから中身を見せろ」という状況で無ければ、おっしゃるように関数が関数を呼ぶような状況に対応できるはずもありませんよね?

「説明はいいからとにかくソースコードを見せろ」といった短文をそのままに読み取るのではなくて、どういった状況で「ソースを見せろ」と言ったのかを上記のように補足する必要があると思われます。

「ソースが仕様書である」という言葉も「仕様書に縛られていない項目はソース内で独自に設定されているのでソースを見ない事には本当の仕様を明かす事はできない」といった意味で捕らえるとよろしいかと思います。

id:tono5652

なるほど。ありがとうございます。

2006/03/16 22:01:56
id:hshin No.2

hshin回答回数2ベストアンサー獲得回数02006/03/16 07:24:54

ポイント14pt

100万行もあるソースが、仕様書だと言える人は恐らくいない(ほとんどいない)とだろう思います。

ですが、何かのフレームワークなどで、制限がかけられている場合、そのフレームワークを熟知していれば、ソースの可読性は上がります。

例えば、Webアプリがあるフレームワークを使っている場合は、その構造はだいたいどれも同じようになります。となれば、質問にも書かれています通り、モジュール化がある程度適切に行われていれば、ソースの上っ面を見るだけで、中身がわかったつもりにはなれます。

また、ソースを仕様書と呼ぶ人は、そのソースに対して、いくつか知ってることがあるのではないでしょうか。

  • そのソースの目的、目標は何か。
  • どのようなフレームワークで作られているか。
  • ラフなクラス図
  • 似たようなシステムを以前に作った経験がある
  • 一般的もしくは、組織的に共有されているライブラリ仕様

「ソースコードを見せて,と創業者のラリー...にも書かれてますが、プロジェクトデータベースにこれらのことが書かれているのだと思います。なので、この前提知識のもと、ソースを見れば、だいたいのことがわかるのだと思います。

大規模システムのアプリや組み込みアプリと比べるとWebアプリは状態も少なく(連携する画面も、数枚)、簡潔に書けるのもソースが仕様書と言えるポイントかもしれません。各言語のライブラリ(Perl,Python,PHP,etc)もライブラリが豊富で、Webの場合は、ロジックの細かいところまで書かなくてもだいたいのことはライブラリがやってくれます。

私は、組み込みアプリの開発をやってますが、100万行のソースに対して、ソースがあるから仕様書はいらないという人は今まで見たことがありません。

逆に、Webアプリのソースなんかを見てると、状態が少ないので、ソースがあれば、仕様書なんかいらないと思ったりします。

id:tono5652

Case By Caseということですね。

ありがとうございます。

2006/03/16 22:02:21
id:karla No.3

karla回答回数130ベストアンサー獲得回数42006/03/16 08:23:52

ポイント14pt

ソースコードの品質と見方によってかなと思います。

しっかりとモジュール化されていれば知りたいポイントを

A→B→C

といった感じで追いつつ、さらにモジュールAの細かい処理を

A1→A2→A3

と追っていく感じになると思います。

これらをツールなど使ってモジュール構成図みたいのを作成し、局所的に見ていけば大規模でもさほど苦労はないかと。

さすがに全てを把握しようというのは少し厳しい話です。

・ソースコードの品質が一定以上

・コメントがしっかり記載されている

・ハードウェアや特定環境に依存しない

この辺がしっかりしてないと現実的には難しい気がしますね。

グローバル変数などモジュール間で影響があるものを多様されると可読性に欠け辛かった記憶があります。

ドキュメントも正確ではないケースがありますので、ソースが見れる状況だと両方を見るようにしています。

ドキュメントで概要を、ソースで実装をとった切り分けです。

id:tono5652

やはりドキュメントはある程度必要であるという意見が多いようですね。

2006/03/16 22:02:44
id:ske3 No.4

ske3回答回数15ベストアンサー獲得回数02006/03/16 08:29:39

ポイント14pt

確実なドキュメントがあれば,ソースコードなど見なくてもいいかもしれません。しかし(自分の周りだけかもしれませんが...),まともなドキュメントが存在していること自体が少ないということもあります。最初はきっちりとしたドキュメントだったりするのですが,いろいろと修正が進むにつれてドキュメントとの整合性が取れなくなってくる...ということが多くあります。

極端なことを言えば,ドキュメントには嘘が書いてあるので信用出来ない,ソースコードが確実...ということもあるのではないでしょうか。さらにソースコード中のコメントだって嘘が書いてあるかもしれません(コンパイルエラーにならないし)。

このような場合,誰が読んでも理解出来るような綺麗なソースコードを書く必要があるわけで,とりあえず動けばいいといったコードが許されない環境になっているのでは...と,つたない頭で考えました。

id:tono5652

ドキュメントに嘘が書いてあるからバグがあるという考えかたもあると思います。しかし,そのソフトウェアがもたらすそもそもを理解するにはドキュメントで十分という考え方もできると思います。

2006/03/16 22:03:31
id:practicalscheme No.5

practicalscheme回答回数157ベストアンサー獲得回数422006/03/16 08:41:12

ポイント14pt

「ソースが仕様書」とか「ソースを見ればいい」というのは一種の省略記法で、その裏には何層もの意味があると思います。

額面通りに取れば、プログラムはソースに書かれていることしか実行しない (バグも含めて) という意味で、ソースがプログラムの動作を完全に記述しているものであることは間違いありません。

しかし純粋にソースだけでは、「こう動作するべきと意図して書かれた箇所」と「いくつか方法があり、どれでも良いのだがとりあえずこの方法で書かれた箇所」の区別がつきません。入力に対する暗黙の制約であるとか、全体のアーキテクチャをそう設計した理由、といったこともソースの上には出てきづらいものです(how,whatは書かれているがwhyは書かれない)。ソースは実際に動くものとして具体的であらねばならないので、意図とか方針とかいった抽象的なレイヤを表現しにくいのです。この意味では、ソースだけではプログラムの全貌は見えない、と言えると思います (より抽象的なプログラミング言語を使うことでこのギャップを減らすことはできます)。

だからと言って「やっぱりソースだけでは不完全じゃないか」という結論に飛びつくのも早計です。うまい書き手によるソースは、読み手のことを考えて書かれているものです。上手な構成と適切に置かれたコメントは、別に用意された仕様書よりもずっと明解にプログラムを語ることがあります。

さらにその裏があります。文章に書き手の個性が出るのと同様、ソースにも書き手の人となりが色濃く反映されます(誰が書いても同じになるようなtrivialなプログラムは除きます)。複数の人間が関わった中規模以上のソフトウェアを読んでいて、誰がどこのモジュールを書いたか思い浮かぶ、という経験はありませんか。あるエンジニアをよく知るには、技術上のトピックについて雑談するよりも、ソースを見せてもらうほうが良いでしょう。

これらの裏の意味を捨象して、「ソースは仕様書か」を議論するのは不毛だと思います。そのせりふは、裏の意味をわかっている者同士が使うjargonみたいなものです。

id:tono5652

なるほど。勉強になります。

たしかにプログラミングの上手い下手は表れますよね。

2006/03/16 22:04:15
id:Kumappus No.6

くまっぷす回答回数3784ベストアンサー獲得回数1852006/03/16 09:06:55

ポイント14pt

ちょっとぐぐったんですが、ここにいいこと書いてありますね。

「ソースコードが仕様書だ」といういい方はある意味正しくてある意味間違っています。

まず、仕様書での表現には限界(あいまいさ、文章で書くと長くなり読みにくい、コピペのかたまりみたいになって読んでいてわけがわからなくなる(…はソースでもありますが)など)があり、細かい実装についてはソースを見てくださいというのは正しい。

ただし、それも限度があって、質問者さんのように数百万行もあるソースを何の仕様書もなしに読むというのは不可能です。

仕様書は全体の構造を把握するためには必須だと思います。今ならUMLによる記述もあるし。逆に昔よくあった全ての関数に数ページのコピペみたいな仕様書〜「関数名:なんとか 入力:なんとか(ほげ型、範囲はほげほげ…)…、出力:ほげ型… 関数の内容のステップごとな記述」〜は特に高級言語を使う場合は全く無駄で、むしろプログラマーの仕事量の枚数稼ぎではないかと思います(いまだにプリント枚数が多いと納得するクライアント多いし)。

また、GoogleなどのWebアプリについていえば、Web Service APIについてはある程度しっかりした仕様書があります。最初からなくてもひとつAPIができたら、それを参照する形でどんどん追加されていく感じになるはずです。

で、アプリ本体はそのAPIを順番に叩いていくだけの割と短いものが多く、APIの使いかたやデータベースの使いかたの「お作法」もある程度決まりきっている(もちろん、それについてもプログラマがいちいち参照しているかどうかはともかく個別に仕様書がある)ので、たいした仕様書がなくてもまさにソース見た方が早い、ということになります。

これはWebアプリだけでなく例えばJavaのように既存クラスを使ってそれを拡張することが前提になっている場合も似たようなものだと思います(なのでJavaDocがあると)。

まとめると、

・仕様書は必要、ただし全体の構造把握に役立つものが望ましい

・Webアプリみたいなものだとアプリ自体の仕様はimplicitに他の仕様書を参照しているようなものになるのでごく短いものか場合によってはソースコード(及び埋め込まれたコメント、ドキュメント)で十分

というところです。

id:tono5652

まとめありがとうございます。

今までの方々と共通した意見ですね。

2006/03/16 22:04:54
id:ToMmY No.7

ToMmY回答回数656ベストアンサー獲得回数192006/03/16 09:47:05

ポイント14pt

一般的にプロのプログラマーでもソースコードの長さは最高1000行程度といわれています。それ以上長いコードを書き綴るのはへたくそバロメーターとなっているようです。(タイトルは忘れてしまいましたが、そのような長すぎるコードを集めた本にそのような記述がありました。)

長いコードを解読するのはプロでも大変でしょうし、Cで言えばヘッダなどにコメントつきで関数や構造体の一覧が書かれていたら十分通用する仕様書ではないでしょうか。

さらに巨大プロジェクトになればなるほどDLLなどを多用しますので、ソースコードをいきなりわたしてもらったほうが時間がかからないのかもしれません

id:tono5652

ソースコードが仕様書になる派のご意見ですね。

しかし実際にはOSともなると数百万行レベルなのでやはりドキュメントが必要ではないかと思います。

DLLが仕様できる場合もあれば出来ない場合もあると思いますし。

2006/03/16 22:06:34
id:hissssa No.8

hissssa回答回数427ベストアンサー獲得回数1292006/03/16 13:54:13

ポイント14pt

この業界に昔からある格言で、「プログラムはプログラマーの思ったとおりには動かないが、プログラマーの書いたとおりには動く」というのがあります。

しかし、仕様書てものは所詮「プログラマーの思うところ」を記述するものです。実際に書かれたコードが仕様を反映し切れているとは限りませんし、仕様書の方に記述ミスがあることもあります。仕様書が作成されたあとにバグフィックス等でソースコードが改変され、それが仕様書に反映されていないということもよくあります。

その辺で痛い目をみた経験のある優秀なプログラマーほど、仕様書はあまり信用せずソースコードの方を重視するようになっていくわけですね。結局、「ソースコードは全てを語ってくれる」のです。

id:tono5652

これまたソースコードを仕様書とする派のご意見ですね。

確かに卓越したプログラマならもしかしてソースを読んだ方が早くて正しい理解ができるのではないかという考えについて,僕自身否定できないからこそこういう質問をしました。

それではそういったプログラマになるにはどうしたらいいのでしょうかね。

あるいはそういったプログラマはOSレベルのソースコードでもドキュメントなしに読めちゃうんでしょうか。

2006/03/16 22:08:44
id:Broadway No.9

Broadway回答回数326ベストアンサー獲得回数222006/03/16 14:18:28ここでベストアンサー

ポイント14pt

ちょっと失礼します。

 

 

私のしがない経験から考えてみました。

 

まず、仕様書が何か、辞書で引いてみました。辞書的定義が一般的な意味を表すと思うからです。

-----------------------------------------------------------

しよう-しょ【仕様書】

 →しようがき

しよう-がき【仕様書】

 ①仕様の次第を書きしるした文書。しようしょ。

 ②複雑な設計を要する注文品の内容や図をしるした書類。しようしょ。

し-よう【仕様】

 仕方。方法。「返事の―に困る」

-----------------------------------------------------------

[広辞苑(R) 第5版/岩波書店 (C)1998, 2004新村出記念財団 (R)岩波書店]

 

コンピュータ・ソフトウエアも品物ですので、注文の有無を別にして、「仕様書」と云う場合、「しよう-がき②」

を意味する、と考えます。

御存知の通り、コンピュータ・ソフトウェアのプログラムは、プログラミング言語と呼ばれる言語の一種を使って記述されます。或る程度人間の使う自然言語に似せた論理的表現が行えます。だから、プログラム、つまり、ソース・コードが「読める」訳ですよね。変数名等が或る規約通りに付けられていたり、コメントが入っていたり、等の補足的な部分も手助けになります。

しかし、プログラムに関しての何の予備知識も無しに、ソース・プログラムを読もうとすると、酷く大変な事になります。

或るカスタム・メイドのプログラムのヴァージョン・アップに伴って、ソフトハウスを変更した話なんかを聞いた事が有ると思います。ソース・コードや仕様書が有っても、新規受注したソフトハウスのエンジニアは大変な苦労をして、ソース・コードを読み解きます。仕様書が無い場合は、地獄の沙汰です。

この様に、プログラム言語以外の予備知識が無いと、ソース・コードにいきなり当たっても何も分かりません。

こうなってしまえば、ソース・コードは極々単純に例えれば、恐ろしく難解なパズルと同然だ、と言う事が出来るでしょう。

似た様な事は割と、よく有る話です。

 

「Googleのエンジニアなども『説明はいいからとにかくソースコードを見せろ』と言う」話は、そのエンジニアが特に慣れ親しんだ分野か製品のプログラムだった、と云う事が大前提として有る、と考えるべきです。

人一人の理解出来る範囲は、これだけ複雑で巨大化したコンピュータ・ソフトウエアについては、極々一部に過ぎない、と言う事は既に御存知の事と思います。

仕様書は、複雑な設計を要する製品の概要を示した「地図」と考えれば理解し易いと思います。慣れた場所なら、経験から来る土地勘や、あてずっぽうでも何となく目的地に着きます。何事についても、経験豊富な方が、理解能力は早い場合が多いです。でも、見知らぬ場所だと、そうは行かない。

これは、経験豊富な「優秀なエンジニア」であっても、同じ事なのです。

「これは私自身のスキルの問題で,優秀なエンジニアであればソースコードだけで問題なくすべてを把握できるのでしょうか」。

これについては「返事の仕様に困る」事は有りません。

全てプログラムにはバグが内包されている可能性が有る事は論理的に証明されていると言います。問題無く、全てを把握出来る人は、居ません。

「出来る」と云う人は、単なる法螺吹きか、傲慢なだけ、と解すべきでしょう。

だから、どうぞ御心配無く!

 

 

まずは私見まで。御役に立てれば幸いです。

id:tono5652

なるほど。ご丁寧にありがとうございます。

たしかにある程度感が働く場所ならソースコードがすぐに頭に入ってくるかもしれないですね。

OS規模のプログラミングであっても,たとえばスケジューラが専門のプログラマであれば,他のOSでもスケジューラ部分についてはソースを読んだ方が早い。しかし例えばデバイスドライバについてはやはり仕様書が必要だった。

このようなことがあるかもしれないですね。

2006/03/16 22:11:51
id:izayoimizuki No.10

izayoimizuki回答回数302ベストアンサー獲得回数02006/03/16 15:04:42

ポイント13pt

私の経験からしてソースは仕様書にはなりえないです。

また逆に仕様書だけではそのソフトウェアを知る事が出来ません。

ソースは実際の動作を記述したものであり

仕様書とはAPIやUIなどのインターフェースを

一覧化したものに近いと考えています。


そのソフトウェアにどれだけのレベルで関わるか

によっても意味が違ってきます。

たくさんのAPIを使用して連携して動作をするのであれば

内部の構造が分からなければなりません。

そのため仕様書は何の意味も成しません。

APIは必ず自分の書いた物からの指定にあわせて適切な値が帰ってくるとして

そのライブラリなどを利用するためだけならば仕様書で十分です。


「説明はいいからとにかくソースコードを見せろ」は共感できます。

説明されても何を言っているか分からないです。

どんな言葉を使っても「あ~そうですか。」といった感じで・・・

最後には眠くなってきて・・・ご破談ですね。

id:tono5652

ははは。なるほどそういう経験もあるというわけですね。

ドキュメントも必要だが,結局動作自体はソースを読んで確認するしかないという解釈でよろしいでしょうか。

2006/03/16 22:13:45
id:martclasher No.11

N@なんとやら回答回数4ベストアンサー獲得回数02006/03/16 16:42:32

ポイント13pt

元へたれプログラマーです。

スキルのない人間からの率直な感想を。

「まずソースをみせろ」嗚呼なんて素晴らしい言葉!

そんな事をさらっといえる人間になれたら転職せずにすんd…失礼、話がそれかけました。

本題に戻ると、大規模なシステムであれば、仕様書はほぼ確実に必要だろうというのは他の方と同じくです。

中小規模のシステムの場合だと、もし完璧ではなくてもある程度適切なコメントと、ある程度一定規則にしたがって名づけられたファンクション・マクロ・変数と、ある程度用途ごとにまとめられたコードで構築されたシステムであれば、やはり仕様書は不要だと思います。


ただし当方の経験では、大規模だろうが小規模だろうが納期ギリギリで無茶と無理と無謀があわさり、コメントを入れる余裕も機能ごとにファンクションをまとめる余裕もまったくなく、結果的にもんじゃ焼きソースになってしまう場合が多いです。

そうなってしまうと、ソースを見ても意味不明で「何で仕様書ないのよーーーー!!」と絶叫する羽目になったり。

で、担当さんに泣きついてようやく仕様書もらえたとおもったら、いかにも「3徹でつくりましたー」みたいなひどいものだったりしてまた絶叫する羽目になったりして……。


結論:仕様書になりえるようなソースコードを作れるのが理想。

id:tono5652

可読性の高いソースコードはドキュメントにもなるということですね。ありがとうございます。

2006/03/16 22:14:44
id:Seacolor No.12

Seacolor回答回数34ベストアンサー獲得回数12006/03/16 20:29:20

ポイント13pt

tono5652さんの仰るとおり、難しいですね。

 プログラムではソースコードの1行が「1ステップ」と呼ばれ、「ステップ数=プログラムの規模」と考える人がいますがこれは「1行=1命令」となる旧世代の考えです。

 現在ではコードの省略形は可視性を落とすという事で多くの現場で禁止とされていますし、可視性を高める目的でコメントもふんだんに追加されています。 

また、コードの再利用性や保守性を高める為、オブジェクト指向設計によるソースコードの分割やデザインパターンの導入も常識となっています。

その為、最適化やファイルの分割によりステップ数は飛躍的に増大します。

それらのファイル全てに目を通して目で処理を追う事は可能ではありますし、できる自信があります……が、少なくとも自分はやりません。 あまりにも非効率的なので。

id:tono5652

効率ということを考えるとまた別の話となるわけですね。

なるほど。有用なご意見ありがとうございます。

2006/03/16 22:15:45
id:kubira711 No.13

kubira711回答回数132ベストアンサー獲得回数02006/03/16 23:32:48

ポイント13pt

私の予想ではプログラム言語の XML SCHEMA というものが

定義され、プログラム仕様書も XML で記述される時代が

すぐそこまで来ていると思います。

そうなった時、このXMLから自動的に実行可能なEXEまで落とす

コンパイラーも出現するでしょう。

そうなった時XML自体がソースコードとなりXSLTのスタイルシート

がこのソースから仕様書を出力するようになると思います。

そうなった時、ソース自体が仕様書だと言えるわけで、現状で、

ソースが仕様書だと言っているのはとどのつまりは仕様書なんか

最終的には頼りにならないと言っているのと同じ様な意味です。

プログラムのバグを見つけるためには実際仕様書はあまり役立たないものです。

ソースのどの辺りにバグが存在しそうか当たりをつけるぐらいしか。

id:tarchan No.14

たーちゃん回答回数200ベストアンサー獲得回数22006/03/17 01:14:09

ポイント13pt

http://www.biwa.ne.jp/~mmura/SoftwareDevelopment/WhatIsSoftw...

ソースコードは最も詳細な設計書です。

一口に設計書と言っても基本設計書、詳細設計書などのように何段階かに分けて設計書が存在しているのではないでしょうか。ソースコードだけを読むより詳細設計書を参照しながらのほうが理解しやすいのは当然で、詳細設計書も基本設計書を参照しながらのほうが理解しやすいのではないでしょうか。

ソースコードは設計書のひとつです。

id:tono5652

ありがとうございます。

2006/03/17 05:34:51

コメントはまだありません

この質問への反応(ブックマークコメント)

「あの人に答えてほしい」「この質問はあの人が答えられそう」というときに、回答リクエストを送ってみてましょう。

これ以上回答リクエストを送信することはできません。制限について

絞り込み :
はてなココの「ともだち」を表示します。
回答リクエストを送信したユーザーはいません