業務が理解できるソースコードの読み方

約１年程前からシステムエンジニアの仕事に就きました。
一番不思議なのは、ベテランSEの人たちは、ソースコードを見て仕様がわかるということです。

例えば私なら、配属されたばかりの部署でソースコードを読んでみて、書いてあるソースを文法的にであればわかるのですが、それが業務としてどうなっているのか、言葉で説明しろと言われたらしどろもどろになってしまいます。
しかし、ベテランSEの人たちは皆、それをやってのけます。
新しい業務に携わるようになって２，３日目ぐらいで、全ての業務がわかったかのようなしゃべり方をするし、実際にそれなりにわかっています。
そういう人に何を見ているのかきくと、ソースコードを読む、という人がほどんどです。
しかし私は、文法はわかっても、仕様書も無いのに、ソースコードから業務まではわかりません。

SEのベテランの皆さん、業務が理解できるソースコードの読み方を教えて頂けないでしょうか。
よろしくお願い致します。

No.2 ベストアンサー 回答者： Wr5 回答日時： 2009/07/02 00:55

#1さんの書かれているとおり、蓄積してきた経験…というモノではないかと。

さすがに、私は２～３日では無理ですね。
２週間くらい欲しいところです。

私の場合、解析は下記の要領で。
まず、一通り目を通す。
その際に関数名などをチェック。呼び出し元などの関係も軽く見ておく。
一通り見たらメインループを探す。メインループ見つけたら、そこより前に動いているハズの初期化処理を探して必要な初期化処理の内容を把握する。
後はメインループから状態を見ながら分岐処理している部分を追いかける。
テキストエディタなどの行マーク(関数コール追いかけるとき)とか、調べた内容をメモしたり…とか。
重要そうな処理を見つけると、ポイントとしてメモに追加してみたり。
デバッガで追うことができる場合は適当にブレークポイントで止めてみたり、変数の内容やコールスタック見てみたり…
場所によってはステップ実行してみたり。
ログ出力があればログから動作を追いかけてみたり……
そんな感じで７～８割のコードが確認できればおおよそ理解できたかな…と。
あとは必要に応じて同じ手順で調べていきます。
# 大半は解析済みですから残りを調べるのはそれほど手間ではありません。
関数コールとか追いかける際にgrepなど多用するのでテキストエディタが20とか開かれていたりして、だんだんカオスに……。
# 上記の解析中に動作不明なロジックとか見つけたら、とりあえず質問用に書き出しておきます。
# たまにバグではないか？というモノ見つけたりしますけど。
## 問題ないのか？と思って後で調べると制御の行かない死にコードだった…なんてこともよくありますが。

エラー処理なんかがあった場合は局所的に対処内容を確認してメモに追加。とか……

この回答へのお礼

色々と参考になるアドバイス、ありがとうございます。

一通り目を通す、というのは重要そうですね。
一通り見ても記号にしか見えなくてすぐ細部を見てしまうのですが、これがまず、いけない気がしました。

明日からアドバイス頂いた手順で早速やってみたいと思います。

お礼日時：2009/07/02 23:41

No.1 回答者： super-dog 回答日時： 2009/07/02 00:02

本人たちに聞けば良いことだと思いますけど。

。。
普通は類似業務を知っているから、ソースだけで推測できるのだと思いますよ

この回答へのお礼

ありがとうございます。
本人たちは、ソースをよーく見る、と言います。
経験がものを言うというのはあるんでしょうね。
結構特殊な業務なので、今回直接的に類似業務は無いはずなのですが、何かに類似させて理解しているんでしょうね。

お礼日時：2009/07/02 23:34