レガシーな謎のソースコードとの付き合い方

どうも最近、昔のPerlやPython、VBなどのプログラムが持ち込まれる事が多いのです。動かしているハードのリプレイスに伴うものや、連携アプリが対応しなくなったとか、入力側のデータが変ったなど理由は様々ですが、だいたい共通しているのが

  • ドキュメントが無い。「ソース読めば分かるでしょ」問題
  • 謎の独自ライブラリ。元の開発会社等に問い合わせても「担当者は退職しました」という場合が多い。
  • 肝心のソース中にコメントが無い。

こんな感じで、僅かな手掛かりを元に古文書を読み進めていくような作業が必要になります。ツライ。それでも動いているプログラムがあれば、現状の実装仕様は何となく見えてきます。いろいろとデータを食わせては、吐き出されるものをみて処理を類推するわけですね(やっぱりツライ)備忘録がてら、生活の知恵的な事柄を吐き出し手おきます。

なには無くともデバッガー!トレーサー!

デバッグprintを埋め込んで中間処理の状況を出力させるやり方もあり、それなりに理解しているコードであればこれでも良いのですが、やはり作業効率が段違いです。ステップ実行させつつ変数内容の変化を見ていれば、何となく処理概要がみえてきます。トレース機能を持つIDEは欠かせません。

まずはデータ構造の把握から

比較的シンプルな配列などであれば楽ですが、複雑なオブジェクト、構造体などなど、どのようなデータがどのように格納されているかを把握するのは重要です。論理的な構造的な点はもちろん、各値の単位、データの取得頻度、欠測時の扱いなどもメモって行きます。

取りあえずコメントは書きまくる

理解できたこと、疑問点、推測など、とにかく書きまくります。課題や疑問などは “TODO” を冒頭に付けておくと、それを一覧化したりジャンプできるIDEもありますので利用すると良いでしょう。また古いコードだと変数名が”A1″, “A2″のような謎記号で書かれていることも多いでしょう。思わず全置換したくなる衝動にかられますが、意図しない置換処理をしてしまい、後で分からなくなる事も多いので、リファクタリングはコードを十分に理解した後で行う事を強くお勧めします。

また、この手のコードは忘れたころにまたやってきます。記憶を手繰り寄せるヒントはそこらかしこに残しておくべきです。もちろん世の中にはコメント不要論者がいらっしゃるのも存じ上げておりますが、そのような場合には設計もキレイで、変数名や関数名なども意味が分かりやすいものになっていると思いますので、今回対象にしている謎のレガシーコードの場合はなりふり構ってられません。(涙)

オリジナルは読み取り専用で別途に保存

とにもかくにも大量のメモを残しつつコードの意味を理解しようとしますが、誤った処理で意図せぬ副作用が出ることがあります。たとえばPythonであればタブ/インデントが重要な意味を持ちますが、コメントの編集の過程でインデントをずらしてしまうような事があります。私の場合はループ対象の処理がインデントをずらしてしまう事でループから外れてしまい、どうにも出力値がオカシイと調べ始めたことがあります。オリジナルと比較が必要になってきますので、gitなどのリポジトリで管理するもよし、別フォルダにコピーするもよし、参照できるようにしておくことを強くお勧めします。

デバッグプリントを入れる際には一工夫

ある程度、コードの意味が理解出来たら(おそるおそる)書き換えを始めていきます。挙動確認の際にはデバッガーなどの利用が便利と書きましたが、デバッグプリントが便利な場合もあります。この場合にはスイッチで出力がコントロールできるような仕掛けを入れておくとよいでしょう。

例えばロギング用のフレームワーク/モジュールを使って、出力ログレベルをコントロールできるようにしたり、プリプロセッサ―を使う言語であれば

#ifdef DEBUG

のようなコードをいれて、本番用にコンパイルする際にはプリントされなくなるようにするなどです。

未分類

Posted by tomi