リバースエンジニアリング(RE)という考古学について書き留めておきます。
こんなものは作り直せばいいんですよ
と、やっつけることができるのは、規模が小さい場合のみです。
自転車で行ける程度と言っておきましょうか。
リグレッションテスト項目が10万も20万もあるようなシステムで作り直しを提案するのは、余程の野心家か、無責任な楽天家だけです。
そこではすでに、バグが仕様となっているのですから。
正しく作り直すこと
自体が不具合を生むのです。おわかりでしょうか。
さて、改修や改造をおこなうには、洞察力と人手さえあればなんとかなります。
とにもかくにもクロスリファレンスを作ってください。
たとえば、グローバル変数と関数・モジュールのクロス。グローバルではないが、ほぼ永続的に存在するオブジェクトのクロス。レジストリの参照。ソースとヘッダのクロス。外部ファイルの参照箇所のクロス。
忘れていけないのは、R/Wの種別も可能な限り調べて記述すること！
これで各リソースの責任者が明確になります。
例：誰がそのファイルを書き出すのか。誰がその変数を書き換えるのか。
真新しい2次元の表は、行・列ともに巨大で、かつ疎な行列になっていると思います。
正確には疎な部分と密な部分がまだらになっていると思います。
手作業で行や列を入れ替えて、"見た目で"見やすい感じにします。
疎な部分はその参照はそもそもなくてもいいかもしれません。
密な部分はバグの温床です。
ソースを見て、バグの温床がどこかを言える人は多いですが、モジュール間の関連まで含めていえる人は少ないです。
だから楽天家が温床と気づかずに手を入れて、大炎上するわけです。
不慣れなみなさんは変数のクロスすら手作業で作成するのに何百時間もかかることでしょう。
それはソースを読む能力が全然足りていないことを示します。
そんな人は詳細かつ正確な実装仕様書が残っていても、見事にバグを作りこみます。
まずは、資料、記録、仕様書、メモ、議事録のクロスリファレンスを作ることをオススメします。
コメント