2

現在、複数の Maven プロジェクトにわたってリファクタリングを実行するための適切なワークフローを見つけようとしていますが、満足のいく解決策が見つかりません。

3 つのプロジェクトがあるとします。1 つのプロジェクトはcommonと呼ばれ、2 つの依存プロジェクトはapp1とapp2と呼ばれます。それぞれ別の Git リポジトリにあります。

ここで、StringUtils.trim() という一般的なメソッドの名前を StringUtils.getTrimed() に変更するとします。このメソッドはapp1とapp2で使用されるため、これらのプロジェクトも調整する必要があります。

ここで問題は、この変更を開発チームに提供するための正しいワークフローは何かということです。この状況を考えると: アーティファクトをホストするための中央 SCM サーバーと中央 Maven リポジトリ サーバーを持つ約 10 人の開発者のチーム。

可能なワークフロー:

  1. 変更を SCM にコミットするだけです (3 つのプロジェクトすべてに対して) --> 問題:たとえば、 app1で作業している開発者は、プロジェクトコモンをチェックアウトしていない可能性がありますが、中央のアーティファクト サーバーからバイナリを使用しています。SCM からapp1の最新バージョンをフェッチすると、ビルドが壊れます。悪い！

  2. 1 に加えて、 app1の依存関係を変更して、 commonの SNAPSHOT バージョンを指すようにします。--> 問題: app1で作業している開発者が SCM から最新バージョンをフェッチするとき、更新ポリシーがDAILY (デフォルト) に設定されている場合、おそらくcommonの最新の SNAPSHOT を取得できません。悪い！

  3. 2 に加えて、SNAPSHOTS の更新ポリシーをALWAYSに変更します。--> 問題: これで、app1の開発者はcommonの最新の SNAPSHOT を取得し、すべて問題ありませんが、 app1への変更をコミットする前に SNAPSHOT が Artifact サーバーにデプロイされている場合のみです! さらに、アーティファクト サーバーへの共通プロジェクトのデプロイと、SCM へのapp1のコミットの間には、一定の期間があります。開発者がcommonの最新の SNAPSHOT を取得した場合、app1への変更をまだコミットしていないため、SCMのapp1の現在のバージョンと互換性がなくなります。悪い！

私が思い付くことができる唯一の実行可能な解決策は、SNAPSHOT メカニズムをスキップしてバージョンを操作することです。ワークフローは次のとおりです。

  • 私のマシンで 3 つのプロジェクトをローカルに変更した後 (コミット前)、 commonのバージョンを1.0 から 1.1に上げます。
  • SCM に共通にコミットし、アーティファクト サーバーにデプロイします。
  • デプロイが完了した後でのみ、app1とapp2の依存関係を変更して、共通の新しいバージョンを指すようにし、app1とapp2をコミットします。

このアプローチの問題点: バージョン管理を行う必要があるため、これはチーム全体で調整し、すべての依存プロジェクトを考慮して行う必要があります。さらに、変更をapp1およびapp2にコミットする前に、共通プロジェクトが成果物サーバーにデプロイされるのを待つ必要があります。

そのようなリファクタリングを実行する方法、簡単で柔軟なメカニズムはありませんか? 誰かが私を助けてくれることを願っています。多分私の側にもいくつかの誤解があります。

4

4 に答える 4

0

Sonar（sonarsource.org）のようなOpenSourceツールをお勧めします

于 2012-09-14T12:16:36.167 に答える
0

例で提案したタイプのリファクタリングを使用する簡単な方法はないと思います。基本的にここにあるのは、アプリ1と2から共通へのサードパーティの依存関係です。また、お気づきかもしれませんが、サードパーティの依存関係によってインターフェイスメソッドの名前が頻繁に変更されることはありません。これには、正当な理由があります。最新バージョンに更新しようとする人にとっては、地獄です。

インターフェイスメソッドの名前をできるだけ高く保つことをお勧めします。名前を変更するには、名前にひどく間違っている必要があります（名前は、そうでないことを実行することを示しています。その逆も同様です。 ）。「trim（）」を「getTrimmed（）」に変更したいのは、そうするのに十分な理由ではありません。

だから、私の提案はこれでしょう：

commonの内部部分で必要なすべてのリファクタリングを実行し、インターフェイスをそのままにします。本当に名前を変更する必要がある場合は、問題のメソッドを新しい名前で複製し、古いメソッドを非推奨としてマークし、全員が使用を開始したと想定するのが妥当になるまで、両方を一定期間存続させます。新しいもの、そして古いものの使用をやめました。

于 2012-09-14T12:06:05.647 に答える
0

古いメソッド名を減価償却し、新しいメソッド名への呼び出しを参照してください。次に、両方で作業する時間枠があります。次に、X ごとに減価償却されたメソッドをチェックするように開発チームに依頼し、一定時間後に、将来のリリースで減価償却されたメソッドを削除します。

于 2013-01-24T16:34:30.910 に答える