人力検索はてな
モバイル版を表示しています。PC版はこちら
i-mobile

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

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

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

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

●質問者: tono5652
●カテゴリ:コンピュータ
✍キーワード:Google エンジニア コメント コード スキル
○ 状態 :終了
└ 回答数 : 14/14件

▽最新の回答へ

1 ● kn1967
●14ポイント

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

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

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

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

◎質問者からの返答

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


2 ● hshin
●14ポイント

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

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

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

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

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

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

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

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

◎質問者からの返答

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

ありがとうございます。


3 ● karla
●14ポイント

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

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

A→B→C

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

A1→A2→A3

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

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

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

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

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

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

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

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

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

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

◎質問者からの返答

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


4 ● ske3
●14ポイント

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

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

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

◎質問者からの返答

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


5 ● practicalscheme
●14ポイント

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

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

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

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

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

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

◎質問者からの返答

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

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


1-5件表示/14件
4.前の5件|次5件6.
関連質問


●質問をもっと探す●



0.人力検索はてなトップ
8.このページを友達に紹介
9.このページの先頭へ
対応機種一覧
お問い合わせ
ヘルプ/お知らせ
ログイン
無料ユーザー登録
はてなトップ