それは、3 つの引数がどこから来るかに大きく依存します。デフォルト値を設定できず、追加パラメーターの共通パターンを作成できない場合は、50 回の呼び出しのそれぞれをグループで攻撃する以外に選択肢がない可能性があります。この場合、元の呼び出しを保持し、わずかに異なる名前で直接コピーを作成します。次に、徐々に移動して、最終的にすべての呼び出しが追加のパラメーターを使用して新しい関数を呼び出すようにします。その後、古いものを廃止できます。
一方、デフォルトで開始するか、少なくとも呼び出し元のコードから独立させることができる場合は、次の計画が適している可能性があります。心に留めておくべきことは、大きな変更として、何か問題が発生した場合の潜在的な影響を制御するために、これはおそらく段階的に実行する必要があるということです.
まず、関数の名前を から に変更しますxxxx
。xxxx_<tag>
は<tag>
変更のハンドルです。おそらく、欠陥トラッカーまたは変更管理システムからのバグ # です。次に、すべてを再コンパイルするxxxx
だけの新しい関数を作成します。xxxx_<tag>
ここまでは順調ですね:
void xxxx_tag(int p1, int p2)
{
// ....
}
void xxxx(int p1, int p2)
{
xxxx_tag(p1, p2);
}
次に、 の署名を変更してxxxx_<tag>
、余分な 3 つのパラメーターと呼び出しを追加します。今、私は再び再構築します:
void xxxx_tag(int p1, int p2, int p3, int p4, int p5)
{
// ....
}
void xxxx(int p1, int p2)
{
// XXX, YYY, and ZZZ and constants or at least can be derived at this point.
xxxx_tag(p1, p2, XXX, YYY, ZZZ);
}
ここでの重要なポイントは、将来のメンテナーのために、このラッパーが存在する理由を説明するコメントを追加することです。残念ながら、これはこれらの変更の一部に関する限りであるため、コードが取り残され、その目的はすぐにはわかりません。
次に、元の呼び出しを新しい呼び出しに変更できるように、たとえば 5 つまたは 10 のグループで 50 の変更を段階的に行うことを計画します。
xxxx(p1, p2);
になります:
xxxx_tag(p1, p2, p3, p4, p5);
呼び出しコードの各セクションは個別にテストできるので、(a) いつものように動作し (完全な下位互換性)、(b) 問題が修正されます。
最後に、これがすべて完了したら、単一の変更を行って新しい関数を削除し、xxxx()
名前xxxx_<tag>
を に変更xxxx
できます。もう一度、完全に再構築してテストする必要があります。
結論
どちらの方法をお勧めします:
- 段階的に行う - これにより、問題が発生するリスクが最小限に抑えられます。
- テスト、テスト、そして再度テスト - 繰り返しになりますが、これにより問題にさらされる可能性が減ります。