私はTDD、リファクタリング、パターンの背後にあるアイデアに完全に同意していますが、これらのアイデアには全体的に大きなギャップがあるように見えます.あなたが取り組んでいると、あちこちでマージの競合が発生し始め、ほとんどの差分/マージ ソフトウェアは、関数を独自のクラスにリファクタリングしたことを認識できません。
チームの全員に大きな頭痛の種を引き起こすことなく、リファクタリングによってコードをクリーンアップするにはどうすればよいでしょうか?
9 に答える
6
小さな変更が頻繁にコミットされます。
あなたの例では、クラスを作成し、その変更をコミットすることから始めます。次に、古い関数と同様の関数をクラスに追加し、その変更をコミットします。次に、古い関数から新しいクラス関数へのすべての参照を変更し、それをコミットします。次に、古い関数を削除し、その変更をコミットします。
もちろん、簡単になるとは誰も言っていません。
于 2008-09-16T01:17:57.527 に答える
2
頻繁なチェックイン。チーム メンバーは、少なくとも1 日に 1 回、変更をチェックインし、サンドボックスを再同期する必要があります。より頻繁にチェックインすると、マージの競合が発生する頻度が減り、発生した場合の管理が容易になります。
于 2008-09-16T01:20:36.020 に答える
2
リファクタリングがソース管理を損なう可能性がある理由を知るために、いくつか質問する必要があると思います。
- 10 人が同時に同じコードを変更しているのはなぜですか?
- リファクタリング/マージを行うときに役立つより良いツールはありますか (おそらく分散バージョン管理)?
最初の質問については、問題が適切に分離されておらず、コードが密結合している可能性があります。または、タスクを割り当てる際に、チーム間のコミュニケーションがうまく取れていない可能性があります。2 番目の質問については、いくつかの優れた dvcs ( git、mercurial、bazaar ) を試して、役立つものがあるかどうかを確認してください。
敬具
于 2008-09-16T01:52:38.067 に答える
1
まあ、実際にはめったに問題にはなりません。通常、さまざまなチーム メンバーがコードのさまざまな領域で作業しているため、競合は発生しません。また、リファクタリングの大部分は、TDD を実行しているときに行われます (これは、コードをチェックインする前である場合もありますが、他の人がコードを使用および変更し始める前であることは間違いありません)。
リファクタリングのために多くの競合が発生している場合は、より頻繁にチェックインするか、同じコードに取り組んでいる可能性のある人に、大きな手直しをしようとしていることを知らせてください。コミュニケーションは常に役に立ちます。
于 2008-09-16T01:16:37.293 に答える
1
あなたのチームはあなたの変更に参加する必要があると思います。大規模なリファクタリングを行っている場合、コードベースとオブジェクト階層に大きな変更を加えている場合は、チームとして変更について話し合う必要があります。
于 2008-09-16T01:27:39.983 に答える
1
リファクタリングをマージするのが難しいと思うときは、次のようにします。
- 変更が近づいていることをチームに警告し、マージが困難な保留中の変更がないかどうかを確認してください。
- すぐに変更できるように、これから行う変更を理解していることを確認してください。必要に応じて、テスト カバレッジを強化します。
- マシンを最新のソースに同期します。
- リファクタリング、テスト、およびコミット。
- チームに通知して、チームが私の変更を同期できるようにします。
機能の変更とは別に、リファクタリングの変更を行っていることに注意してください。
于 2008-09-27T03:48:03.637 に答える
0
ゆっくりと小さく始めなければなりません。コードの一部を取り出して、すべての外部インターフェースを見てください。これらが変わらないことを絶対に確認する必要があります。定義したので、その内部構造を調べ始め、ゆっくりと変更していきます。小さなステップで作業し、頻繁にチェックインして大規模なマージの競合を回避する必要があります。これは、対処しなければならない最大の問題の 1 つです。その規模のチームでは、すべてをチェックアウトして魔法のようにすべてを改善することはできません。何をしようとしているのかを前もって人々に知らせたいと思うかもしれません。（とにかくそれを行う前に、何をするかを常に計画する必要があります）。他の人がそれに取り組んでいる場合は、何が変更されるのか、それがクラスにどのように影響するのかなどを知らせてください。
試し始める前に確認しなければならない最大のことは、人々があなたに同乗しているかどうかです。そうでなければ、それは失われた原因であり、争いを引き起こす可能性があります. この場合、リファクタリングされたコードよりも、悪いコードと混乱をそのまま理解している機能するチームの方が優れている可能性があります。これは直感に反していることは承知していますが、私の以前の職場の上司はこのように言いました。彼は、コードはひどいものだと言いましたが、うまくいきます。ここの開発者は、それがどのように機能するかを知っています。つまり、それを使用する 1000 人が自分の仕事をすることができます。私たちはコードが嫌いで、それを変更したかったのですが、彼は正しかった.
于 2008-09-16T01:25:18.443 に答える
0
私の経験では、アジャイル プロジェクトで小規模および中規模のリファクタリングを行う場合、マージの競合が問題になることはめったにありません。大規模なリファクタリング作業は、マージにいくらかの苦痛をもたらす可能性がありますが、一口サイズのチャンクで行うと、苦痛を大幅に軽減できます。Subversion を SCM として使用すると、SVN が競合しない変更を自動マージするので、マージの手間も軽減できます。
この戦略は、私が参加したチームでうまく機能しており、それらのチームのほとんどは 4 人以上の開発者ペアです。
于 2008-09-16T01:30:10.443 に答える
-1
コミュニケーション。
特定のツールがメールまたは IM クライアントでない限り、ツールはこれを解決できません。
これは、共有プロジェクトで他の大きな変更を行う場合と同じです。同僚/共同作業者に「やあ、数時間手を離してください。FooBar モジュールに大きな変更を加える予定です」と伝えることができる必要があります。の"。
あるいは、他の 10 人の作業と大きなマージ競合が発生する可能性があるほど大きな変更を行う場合は、事前に変更を実行してください。コードレビューを行います。建築に関する情報を求めます。そして、できるだけコンセンサスに近づいたら、必要なリポジトリのセクションで仮想ロックを取得し、変更をチェックインして、オールクリアを送信します。
これは完璧な解決策ではありませんが、できる限り近い解決策です。多くのソース管理システムは、ソース ベースのセクションに対する明示的なロックをサポートしていますが、それらがこれらの領域で良い結果をもたらすのを見たことがありません。これは社会問題であり、一緒に働いている人を信頼できない場合にのみ、技術的な解決策に頼る必要があります。
于 2008-09-16T01:20:03.260 に答える