自分がいつもやっているソース解析の方法
この記事作成時点の自分のソース解析のために普段行っている手法を記録しておきます。
前提
ソース解析の目的は主に以下のもの
- 不具合原因調査
- ソースレビュー
- 仕様変更(追加)に伴う変更箇所調査
解析手法をどう選択するか
主に目的によって以下のように分けられますが、さほど厳密ではなくだいたいフィーリングでやっています。
仕様調査、変更箇所調査の場合。
ソースがオブジェクト指向に則ったクラス設計が概ねできているという前提で トップダウン*1で追っていきます。 具体的にはUMLのシーケンス図（とそれに伴うクラス図）を書き込みながら解析します。
レビューや不具合でエラーログから対象箇所が詳細に分かっている場合
ボトムアップでクラス図や仕様をメモしながら解析します。
上記のやり方で対処できない場合
今までソースの解析はだいたいUMLのクラス図とシーケンス図書けば分かると思っていました。
でも、クラスの責任は適当（っていうか画面で全てをやっている。）、メソッドも名称が意味無し（time1_Tickとか）
という実例にぶち当たった際にクラス図とシーケンス図はまったく無力。
- 1000行くらいのメソッド
- if文のパターン多すぎる
- デバッガで意図した通りに通ったら他のところは気にしなくて良いんじゃない？
- 50のif文とか見たことあるよ！
- 新記録！
そういう場合に力を発揮するのがフローチャートなんだな…。
さらにソースコードの解析が困難で、例え時間をかけてもそれに見合った成果が得られなさそうな場合もたまにあって、そういう場合は最終的な動きから判断する。*2
こんな感じでソース解析しています。 ソース解析はもうちょっと生産性をあげる余地がありそうなんで、今後なにか改善したらまた記録しておこう。
