まず、最初にコードを開発した人、または少なくとも私より前にコードを保守した人に連絡を取り、コード全般の基本的な理解を得るのに十分な情報を得て、有益なコメントを追加できるようにします。それ。
コードの最も重要な API (署名、戻り値、目的を含む) について誰かに説明してもらうこともできます。グローバル状態が関数によって変更される場合、これも明示的にする必要があります。同様に、関数とプロシージャ、および入力/出力レジスタを区別することから始めます。
この情報が必要であることを雇用主に明確に伝えてください。雇用主があなたを信じない場合は、実際にこの規範の前に座ってもらい、何をすべきか、どのようにすべきかを説明する必要があります。それ（リバースエンジニアリング）。その場合、コンピューティングとプログラミングのバックグラウンドを持つ雇用主を持つことは実際に役立ちます!
あなたの雇用主がそのような技術的背景を持っていない場合は、別のプログラマー/同僚を連れてきてあなたの手順を説明するように依頼してください。あなたの観点から（この「プロジェクト」について知っている同僚がいることを確認してください）。
利用可能で実行可能であれば、このコードの文書化を支援するために、以前の開発者/メンテナ (つまり、彼らがあなたの会社で働いていない場合) と契約する (または少なくとも連絡する) ことは、事前の準備になることも非常に明確にします。 -短期間でコードを現実的に改善し、将来的により簡単に保守できるようにする必要があります。
この全体的な状況は、以前のソフトウェア開発プロセスの欠点によるものであり、これらの手順がコード ベースの改善に役立つことを強調してください。そのため、現在の形式のコード ベースは増大する問題であり、この問題を処理するために現在行われていることは、将来への投資です。
これ自体も、彼らがあなたの状況を評価し、理解するのを助けるために重要です: あなたが今やるべきことをすることは簡単なことではありません.彼らはそれについて知っておくべきです.タスク）。
また、個人的には、十分に理解している部分の単体テストを追加して、コードのリファクタリング/リライトをゆっくりと開始できるようにします。
言い換えれば、優れたドキュメントとソース コード コメントも重要ですが、包括的なテスト スイートを用意することも重要です。
コードが 10K であることを考えると、できればグローバル変数の代わりにアクセス ラッパーと直感的なファイル名を使用して、コンポーネントをより識別しやすくするために、サブルーチンを個別のファイルに分割することも検討します。
さらに、複雑さを軽減することでソース コードの可読性をさらに向上させるための手順を検討します。サブルーチンに複数のエントリ ポイント (および場合によっては異なるパラメーター シグネチャも?) を持たせることは、コードを不必要に難読化する確実な方法のように見えます。
同様に、読みやすさを向上させるために、巨大なサブルーチンを小さなサブルーチンにリファクタリングすることもできます。
したがって、私が最初に検討することの 1 つは、コード ベースを理解するのが非常に複雑になる原因を特定し、それらの部分を作り直すことです。たとえば、複数のエントリ ポイントを持つ巨大なサブ ルーチンを個別の代わりに相互に呼び出すサブルーチン。パフォーマンス上の理由または呼び出しのオーバーヘッドが原因でこれを実行できない場合は、代わりにマクロを使用してください。
さらに、それが実行可能なオプションである場合は、C のサブセットを使用するか、少なくともコードの標準化を支援するためにアセンブリ マクロをかなり過度に使用することにより、より高レベルの言語を使用してコードの一部を段階的に書き直すことを検討します。ベースだけでなく、潜在的なバグのローカライズにも役立ちます。
C でのインクリメンタルな書き換えが実行可能なオプションである場合、開始するための 1 つの可能な方法は、すべての明白な関数を、最初にアセンブリ ファイルからコピー/貼り付けされた本体を持つ C 関数に変換することです。インライン アセンブリが多い関数。
個人的には、シミュレーター/エミュレーターでコードを実行してコードを簡単にステップ実行し、(レジスターとスタックの使用法を調べながら) 最も重要なビルディング ブロックの理解を開始できることを願っています。組み込みデバッガーを備えた優れた 8051 シミュレーターはこれは、主に自分で行う必要がある場合に利用できます。
これは、初期化シーケンスとメイン ループ構造、およびコールグラフを考え出すのにも役立ちます。
おそらく、完全なコールグラフを自動的に提供するように簡単に変更できる優れたオープンソースの 80851 シミュレーターを見つけることもできます。簡単な検索を行うだけでgsim51が見つかりましたが、明らかに他にもいくつかのオプションがあり、さまざまな独自のものもあります。
もし私があなたの立場なら、ツールを変更してこのソースコードの作業を簡素化する作業をアウトソーシングすることも検討します。つまり、多くの sourceforge プロジェクトは寄付を受け入れており、雇用主にそのような変更を後援するように依頼することができます。
経済的でない場合は、それに対応するパッチを提供することでしょうか?
すでにプロプライエタリな製品を使用している場合は、このソフトウェアの製造元と話をして要件を詳しく説明し、この製品をそのように改善する意思があるかどうか、または少なくともインターフェースを公開して許可することができるかどうかを尋ねることもできます。顧客はそのようなカスタマイズを行うことができます (何らかの形式の内部 API または単純なグルー スクリプトでさえ)。
彼らが反応しない場合は、あなたの雇用主がしばらくの間別の製品を使用することを考えていたこと、そしてその特定の製品を使用することを主張したのはあなただけだったことを示してください... ;-)
ソフトウェアが特定の I/O ハードウェアおよびペリフェラルを想定している場合は、対応するハードウェア シミュレーション ループを記述して、エミュレータでソフトウェアを実行することを検討することもできます。
最終的には、コーヒーを何ガロン飲んでも、手動でコードをステップ実行して自分でエミュレーターをプレイするよりも、このようなスパゲッティ コード モンスターを理解するのに役立つ他のソフトウェアをカスタマイズするプロセスを個人的にはるかに楽しむことができるという事実を私は知っています。得る。
オープンソースの 8051 エミュレーターから使用可能なコールグラフを取得するのに、(せいぜい) 週末ほどかかることはありません。これは、ほとんどの場合、CALL オペコードを探してそのアドレス (位置とターゲット) を記録することを意味するためです。後で検査するためにファイルします。
エミュレーターの内部にアクセスすることは、実際には、コードをさらに検査するための優れた方法でもあります。コード ベースのサイズと複雑さをさらに軽減するのに役立ちます。
次のステップは、おそらくスタックとレジスタの使用状況を調べることです。また、使用される関数パラメーターのタイプ/サイズ、およびそれらの値の範囲を決定して、対応する単体テストを考えられるようにします。
dot/graphviz のようなツールを使用して、初期化シーケンスとメイン ループ自体の構造を視覚化することは、これらすべてを手動で行うことに比べて純粋に楽しいものです。
また、実際には、長期的にはより優れたドキュメントの基盤となる有用なデータとドキュメントが得られます。