2

安定したコードにアクセスできるが、バグを簡単に導入できるほどきれいなコードがない大規模なチームを処理する最良の方法は何ですか?

ファイルをロックするSVNの行に沿って何かを探しています。

4

10 に答える 10

13

単体テストがまだない場合は、単体テストを記述します。次に、リファクタリングを開始し、コミットごとに回帰テストを続けます。

于 2008-09-19T04:01:01.773 に答える
4

放っておくように伝えてください。

それはうまくいきます、それをきれいにする以外にそれを変更する利点は何ですか（そして潜在的なコストは高いです）、コスト/利益分析を説明するだけです。

あなたの開発者がこれを理解するのに十分賢いことを願っています.

于 2008-09-19T04:05:32.573 に答える
3

Svn には同時アクセスを防止するためにファイルをロックする設定がありますが (ソース セーフと同様)、自動化された単体テストと恐ろしいコードの統合テストを作成することをお勧めします。うまくいけば、セーフティ ネットとしてもしっかりした QA グループができます。

于 2008-09-19T04:00:41.993 に答える
3

  1. 自動化された単体テストを作成します。維持しているコードをテストするテストがある場合は、変更によってコードが壊れていないことを確認できます。JUnitなどのテスト フレームワークが役立ちます。

  2. Martin Fowler の古典的な本Refactoringを入手して読んでください。コードの匂いの概念に特に注意してください。これにより、状況に役立つ特定のリファクタリングが示されます。

  3. リファクタリングのサポートが組み込まれている優れた IDE を入手してください。IDE は本書のすべてのリファクタリングをサポートしているわけではありませんが、それらの多くには多数のリファクタリングがあります。Java の世界のEclipseとNetBeansは無料で、リファクタリングをうまくサポートしています。

  4. テストが失敗しているかどうかを追跡するには、Hudsonのような継続的インテグレーション サーバーを検討してください。

于 2008-09-19T04:11:44.290 に答える
2

ええ、より保守しやすい代替品を書くことができるまでロックしてください。

レガシー コードに関する Michael Feathers の本は、そのチームにとって良い読み物になるでしょう。もちろん、言うは易く行うは難しですが、長期的には特定のコードがソフトウェアの設計上の負債になる可能性があります。

于 2008-09-19T04:00:39.107 に答える
1

ライブラリでブラックボックス化して、いじられないようにします。インターフェイスを十分に文書化します。

于 2008-09-19T04:00:43.647 に答える
1

完全な単体テストを作成して、変更が必要な場合でも機能することを確認します。

于 2008-09-19T04:01:33.287 に答える
1

Subversion を使用している場合、コードがほんの数ファイルでない限り、ファイルをロックすることはそれほど難しくありません。Subversion では、サブディレクトリをロックすることはできず、個々のファイルのみをロックできます。さらに、ロックが壊れる可能性があります。

おそらく必要なのは、pre-commit フック スクリプトです。ほとんど何でもできますが、特定のサブディレクトリへのアクセスを特定の人 (ブランチ、SQL スクリプト) に制限するために使用しました。また、サーバーにアクセスできない限り、pre-commit フックを壊すことはできません。

リポジトリ フックの実装に関するSubversion によるバージョン管理の本を参照してください。Subversion ディストリビューションには、まさにこれを行う方法の良い例が含まれているはずです。

于 2008-09-19T04:12:33.900 に答える
0

私はリファクタリングのように考えています。コードが扱いにくい場合はやり直す必要があります。時間がかかる場合がありますが、多くの問題を引き起こさないため、長期的には改善される可能性があります。

于 2008-09-19T03:59:18.360 に答える
0

自動化されたビルドと単体テストをセットアップします。変更を追跡するあらゆる種類のリポジトリは優れていますが、バグを防ぐことはできません。

また、すぐに実行できる変更のみを加えてください。早期にリリースするというアジャイル手法は、ここで役立つことがよくあります。そうすれば、コードを深く理解するにつれて、コードの理解を深めることができます。

基本的に、可能であれば、機能を変更しないリファクタリングから始めます。次に、リファクタリングされたコードの上に新しい機能を導入します。小さく意図的な変更を加えながら、ゆっくりと行ってください。

変更が行われている間にソースをロックすることは、おそらく何がどこで変更されているかを伝えるほどには役に立ちません。最善のアプローチは、オープンなコミュニケーション チャネルを作ることです。Slashcode のようなものを使用して、オープンに議論したり、質問したり、記録を残したりできるフォーラムを設定します。

于 2008-09-19T04:47:06.310 に答える