私は1.3k行のコードを持つストアド・プロシージャを持っています。このストアドプロシージャには、同じパッケージ内の他のプロシージャへの複数のネストされた呼び出しがあります。PL/SQL複合ストアド・プロシージャ
このパッケージのコード行は約13kです。約25の入力パラメータ（カーソルなし）と1つのカーソルを含む3つのパラメータがあります。
また、ストアドプロシージャは、グローバルな一時テーブルをほとんど使用しておらず、動的クエリがいっぱいです。
ストアドプロシージャをデバッグしようとするたびに、私は失われます。これは今まで見た中で最も複雑なコードですが、ストアドプロシージャの正確なロジックを理解しようとしています。このストアドプロシージャを理解するための最善の方法は何ですか？
IPの理由から、ここでコードを共有することはできません。
これがあなたの仕事であれば、私は仕事を変えるでしょう。 ;）
しかし、セリウオスには、このような問題のための良い、迅速なアプローチはありません。あなたが行うことができる唯一の方法は、コードをリファクタリングすることです。プロシージャをより小さなプロシージャに分割し、命名規則に従います（30文字は少数です）、コードの内容をよりよく理解できるようになります。
複製されたコードの断片がある場合は、それらをプロシージャでカプセル化します。クエリが長い場合、それを生成する関数によってクエリを動的に置き換えます。そのようなfuctionsを別々にテストしてください。
一般に、小さなチャンクでコードを分割し、いくつかの単体テストなどで各チャンクをテストします。これは、おそらく数時間の作業を意味します。
この手順の一部を理解してください。ピースを新しいプロシージャに移動して意味のある名前を付け、大きな手順でピースを新しいプロシージャの呼び出しに置き換えます。単体テストがあれば、それを実行して何かを壊していないことを確認してください。あなたの巨大な手順（その時には小さくすべきである）が理解しやすいまで、このプロセスを繰り返します。
これはどの言語にも当てはまると思います。モノリシックでサポートや維持が難しい構造化されていないコードがいくつかあります。 PL/SQL Developerには、「抽出プロシージャ」を含む任意のコード・ブロックに対してリファクタリング・オプションがいくつか用意されていますが、自動的にリファクタリングできるツールはありません。 –
コードを印刷して壁に掲示する。鉛筆を塗り、ポストイットノートでコードベースを分割して分かり始めます。ノートを作成して色を使用します。そこには、何度もやりました。この問題は、同じスコープ内の状態変数が多すぎる可能性が高いです。通常、大きな画像を見始めると、混乱している部分も理解し始めます。 – user272735