チームでの名前変更、リファクタリング、変更の破棄に関するベストプラクティス

チーム環境でのリファクタリングと名前変更のベストプラクティスは何ですか？いくつかのシナリオを念頭に置いてこれを取り上げます。

1. 一般に参照されるライブラリがリファクタリングされ、それを参照するライブラリまたはプロジェクトに重大な変更が導入された場合。たとえば、メソッドの名前を任意に変更します。

2. プロジェクトの名前が変更され、ソリューションへの参照を更新してソリューションを再構築する必要がある場合。

3. フォルダを導入し、既存のプロジェクトまたはソリューションを新しい場所に移動することにより、プロジェクト構造が「より整理された」ものに変更された場合。

いくつかの追加の考え/質問：

1. この問題のような変化は、結果として生じる痛みが構造が正しくなくなったことを示しているのでしょうか？

2. 重大な変更に関連するエラーを修正する責任は誰にあるべきですか？開発者が重大な変更を行った場合、影響を受けるプロジェクトに参加してそれらを更新する責任があるのか​​、それとも他の開発者に警告して変更を促すべきなのか？

3. これは定期的に実行できるものですか、それともできるだけ頻繁に実行する必要があるものですか。リファクタリングがあまりにも長く延期されると、調整がますます困難になりますが、同時に1日を費やして1時間を費やして、他の場所で起こった変更のためにビルドを修正します。

4. これは正式なコミュニケーションプロセスの問題ですか、それとも有機的なものですか。

リストした各シナリオは、「公開されたAPI /コード」のカテゴリに分類されます。これをリファクタリングするのは難しいので、何かを軽く変更するべきではありません。むしろ、彼は関係するすべての当事者と事前に計画された変更について交渉すべきです。それは少なくとも技術的な問題と同じくらい政治的な問題です。

したがって、Martin Fowlerからのこれに関する最大のアドバイスは、インターフェイス（プロジェクト名と構造）を時期尚早に公開しないことです。

ただし、既に完了していて修正が必要な場合は、他のパーティの混乱を最小限に抑えるために、必要な変更をできるだけ少ない手順で実行することをお勧めします。これは、元のリファクタリングの概念からかなりかけ離れていますが、それには十分な理由があります。

また、可能であれば、既存のメソッドの名前を変更するのではなく、（既存のメソッドを非推奨にしながら）新しいメソッドを追加することを検討してください。これにより、クライアントコードが破損しないことが保証され、最新のAPIに準拠するようにコードを更新する移行期間が提供されます。欠点は、APIが複雑になることです。状態は一時的なものですが、廃止されたAPIメソッド（Javaクラスライブラリの場合は数年）を安全に削除するには、かなりの時間がかかる場合があります。

ほとんどの場合、これらの問題は2つのステップでリファクタリングすることで回避できます。最初のステップでは、新しいコードを導入し、古いコードを非推奨にします。すべてのチームが新しいコードに移行したら、古いコードを削除します。また、この手法を使用して、1つのモジュールを段階的にリファクタリングします。このようにして、テスト実行の間に変更する必要があるコードの量を制限できます。

これは、テストを実行するビルドサーバーがある主な理由の1つであることに注意してください。

特定のプログラムを破壊するようなことが起こった場合、できるだけ早く通知され、原因を突き止めて、詳細がまだ新鮮な間に問題を解決できます。