最近、リファクタリング全般の処理方法に関する議論に参加しました(それ自体が興味深いトピックです)。最終的に、次の質問が提起されました。
他の誰かが同じコードの機能に取り組んでいる間に誰かがコードの一部をリファクタリングしたために発生したマージ競合をどのように処理しますか?
基本的に、効率的な方法でこれに対処する方法がわかりません。これに関して従うべきベストプラクティスはありますか?レガシーコードが大量にあるシステムでこれを処理する方法に違いはありますか?
最近、リファクタリング全般の処理方法に関する議論に参加しました(それ自体が興味深いトピックです)。最終的に、次の質問が提起されました。
他の誰かが同じコードの機能に取り組んでいる間に誰かがコードの一部をリファクタリングしたために発生したマージ競合をどのように処理しますか?
基本的に、効率的な方法でこれに対処する方法がわかりません。これに関して従うべきベストプラクティスはありますか?レガシーコードが大量にあるシステムでこれを処理する方法に違いはありますか?
回答:
良い質問。私が考えることができる最高の戦略は次のとおりです。
継続的インテグレーションと小さなリファクタリングを頻繁に(頻繁にリファクタリングする代わりに)組み合わせることで、こうした競合のコストと頻度を最小限に抑えることができます。
私はあなたの質問に答えると思います。まず、なぜ対立が起こるのか、そして合併の本当の意味とプロセスは何かを見なければなりませんか?
競合が発生するのは、2人以上の開発者が同じファイルを同時に操作していて、両方がチェックインしようとした場合のみです。もちろん、最初の開発者は競合を取得しません。ただし、2番目(3番目、4番目など)は競合します。理由は、サーバー上の既存のコードと部分的または完全に異なるコードがあるためです。
これは本質的に、2番目の開発者が最初の開発者とは異なる考えを持っていることを意味します。この違いは、言及したレベルまでではnew UserManager().GetUserName()
なく使用するなど、スタイリングとは異なる可能性がありますUserManager userManager = new UserManager(); userManager.GetUserName();
。つまり、両方の開発者は、コードをリファクタリングして改善する方法について異なるアイデアを持っていました。
一方、マージは、開発者が競合を考慮せずにコードをチェックインできることを意味しません。それらは、それらの対立に対処するべきであり、そうしなければなりません。競合が重要でない場合は、チェックインして以前のコードを上書きする可能性があります。しかし、まったく違うものを見つけた場合は、前の開発者に電話して話をする必要があります。そうすれば、両者が連携して最適なソリューションをチェックインできます。
たとえば、2人の開発者にオンライン支払いライブラリの改善を依頼し、それらの作業が重複している場合、少なくともいくつかの場所では2つの異なるソリューションがあることを意味します。したがって、これらのソリューションの1つについて話し合い、受け入れて、チェックインすることを、より良いソリューションとして検討する必要があります。
私たちは理論的よりも現実的である傾向があるため、これらの状況を防ぐことに同意しません。時には、CSSが得意な人もいれば、ASP.NETマークアップが得意な人もいます。ただし、ログインページで作業して両方を機能させる必要がある場合、作業が競合する可能性があります。つまり、現実(理想的ではない)と考えると、この現象(競合)が何度も発生していることがわかります。
言及したいもう1つのポイントは、チェックインプロセスを支援するツールを使用することです。これらのツールは通常、サーバーコードと開発者コードの違いを視覚化し、どの部分をチェックインするかを決定するのに役立ちます。
タスクのアクティブな管理がない場合、競合が発生します。
ただし、毎日のスタンドアップミーティングまたはマネージャーがいる場合は、この問題は発生しません。
(毎日のスタンドアップを介して)話すか、マネージャーと話します。
これは話すことによって簡単に防ぐことができます。
マージができるだけ単純であることを確認してください。リファクタリングは通常、多くの既存の行を変更するかなり機械的なプロセスです。変数宣言の移動、空白の変更、書式設定、操作のシーケンス。フィーチャーの作成は通常、はるかに創造的なベンチャーであり、多くの場合、新しいコードに加えて既存のコードにいくつかのマイナーな微調整をもたらします。これで、リファクタリングを行う開発者がステップを(たとえば正規表現として)記録する場合、これらのステップを他の方法よりも追加機能でコードに適用する方がはるかに簡単になります。これに基づいて、一般的なルールとして、最も複雑な変更を最初に適用し、次に徐々に単純な変更を適用する必要があると思います。