20

C# 2.0 で記述された大規模な (500k 以上の LOC) WinForms アプリを開発および保守しています。これはマルチユーザーで、現在約 15 台のマシンに展開されています。システムの開発は進行中であり (永続的なベータと見なすことができます)、毎週のビルドで導入される可能性のある潜在的な新しいバグからユーザーを保護するために行われたことはほとんどありません。

このため、とりわけ、デバッガーのエディット コンティニュに大きく依存するようになりました。バグハンティングやバグ修正だけでなく、場合によっては進行中の開発にも役立ちます。実行中のアプリケーションのコンテキスト内から新しく記述されたコードを実行できることは非常に価値があると思います。再コンパイルして、新しいコードに特定のエントリ ポイントを追加する必要はありません (ダミーのメニュー オプション、ボタンなどを追加する必要はありません)。アプリを削除し、次の本番ビルドの前にそれらを削除することを忘れないでください) - プロセスを停止することなく、すべてをリアルタイムで試行およびテストできます。

私はエディット コンティニュを非常に重視しており、エディット コンティニュと完全に互換性のあるコードを積極的に書いています。たとえば、私は避けます：

  • 匿名メソッドとインライン デリゲート (書き換えが完全に不可能でない限り)
  • ジェネリック メソッド (安定した不変のユーティリティ コードを除く)
  • 「任意の CPU」でプロジェクトをターゲットにする (つまり、64 ビットで実行しない)
  • 宣言時のフィールドの初期化 (初期化はコンストラクターに移されます)
  • を使用する列挙子ブロックの作成yield(ユーティリティ コードを除く)

現在、C# 3 および 4 の新しい言語機能は、エディット コンティニュ (ラムダ式、LINQ など) とほとんど互換性がないことを十分に認識しています。これが、プロジェクトを新しいバージョンのフレームワークに移行することに抵抗した理由の 1 つです。

私の質問は、デバッグが非常に簡単なコードを優先して、これらのより高度な構造の使用を避けるのが良い方法であるかどうかです。この種の開発に正当性はありますか、それとも無駄ですか？また、重要なことに、これらの構成要素 (ラムダ式、匿名メソッドなど) のいずれかが、適切に記述されたエディット コンティニュ対応のコードで回避できるパフォーマンス/メモリ オーバーヘッドを引き起こしますか? ...または、C# コンパイラの内部動作により、このような高度な構造は、手動で記述された「展開された」コードよりも高速に実行されますか?

4

10 に答える 10

21

陳腐に聞こえないように - Edit-Continue に依存するのではなく、ユニット/統合テストを作成することをお勧めします。

そうすれば、努力を 1 回費やすだけで、2 回目以降は「無料」になります...

ここで、すべてのコードに対してレトロスペクティブにユニットを作成することをお勧めしているわけではありません。むしろ、バグを修正する必要があるたびに、修正を証明するテスト (より一般的には複数のテスト) を作成することから始めます。

@Dave Swersky がコメントで言及しているように、Mchael Feathers の本、レガシー コードを効果的に使用することは優れたリソースです (書いてから 5 分後にはレガシーですよね?)

はい、編集と継続を可能にするために新しい C# 構造を避けるのは間違いだと思います。しかし、新しい構造をそのためだけに採用するのは間違いだと思います。特に、それがコードの理解を難しくする場合はなおさらです。

于 2010-10-05T16:00:44.313 に答える
6

「エディット コンティニュ」が大好きです。これはインタラクティブな開発/デバッグを可能にする大きなツールであり、機能しない場合は非常に煩わしいと思います。

「エディット コンティニュ」が開発方法論に役立つ場合は、放棄するものの価値を念頭に置いて、必ずそれを促進するための選択を行ってください。

私の不満の 1 つは、関数内でラムダ式を使用して何かを編集すると、「エディット コンティニュ」が機能しなくなることです。十分につまずいたら、ラムダ式を書き出すかもしれません。私はラムダ式でフェンスにいます。それらを使用すると、いくつかのことをより迅速に行うことができますが、後で書き出すことになってしまうと、時間を節約できません。

私の場合、必要のないときはラムダ式を使用しないようにしています。それらが邪魔になる場合は、関数でラップして、それらを使用するコードを「編集して続行」できるようにすることができます。それらが不当である場合、私はそれらを書き出すかもしれません。

アプローチは白黒である必要はありません。

于 2012-06-06T14:51:49.690 に答える
4

これらのことを少し明確にしたかった

デバッグが非常に簡単なコードを優先して、これらのより高度な構造の使用を避けることは良い習慣ですか?

エディット コンティニュは実際にはデバッグではなく、開発中です。C# の新しい機能は非常にデバッグしやすいため、このように区別しています。言語の各バージョンは、新しい言語機能のデバッグ サポートを追加して、デバッグをできるだけ簡単にします。

プロセスを停止することなく、すべてをリアルタイムで試行およびテストできます。

このステートメントは誤解を招くものです。エディット コンティニュを使用すると、変更によって特定の問題が修正されることを確認できます。変更が正しく、他の多くの問題を壊していないことを確認するのははるかに困難です。つまり、エディット コンティニュではディスク上のバイナリが変更されないため、単体テストなどの項目が許可されないためです。

全体的にはそうですが、編集して続行できるようにするために、新しい C# 構造を避けるのは間違いだと思います。エディット コンティニュは優れた機能です (C++ 時代に初めて出会ったとき、本当に気に入りました)。しかし、運用サーバーのヘルパーは、新しい C# 機能の IMHO による生産性の向上を補うものではないため、価値があります。

于 2010-10-05T16:05:15.977 に答える
4

私の質問は、デバッグが非常に簡単なコードを優先して、これらのより高度な構造の使用を避けることが良い習慣であるかどうかです。

次のようなコードを書くことを余儀なくされているときはいつでも、私は主張します：

  1. 表現力が低い
  2. より長いです
  3. 繰り返される (ジェネリック メソッドの回避による)
  4. 移植性がない (64 ビットをデバッグおよびテストしないでください??!?!?)

デバッガーの「エディット コンティニュ」機能が失われるよりも、全体的なメンテナンス コストが大幅に増加します。

IDE の機能を動作させるコードではなく、可能な限り最高のコードを作成します。

于 2010-10-05T16:07:14.297 に答える
2

あなたのアプローチに本質的な問題はありませんが、IDE が理解できる表現力の量に制限されます。コードは、言語ではなくその機能を反映したものになり、開発の世界での全体的な価値が低下します。これは、他の生産性向上手法の学習を控えているためです。エディット コンティニュを優先して LINQ を回避することは、個人的には大きな機会損失のように感じますが、そのように感じる前にある程度の経験を積まなければならないというパラドックスがあります。

また、他の回答で述べたように、コードを単体テストすると、アプリケーション全体を常に実行する必要がなくなり、ジレンマが別の方法で解決されます。IDE で右クリックして、必要な 3 行のコードだけをテストできない場合は、開発中に既に多くの作業を行っています。

于 2010-10-05T16:16:31.717 に答える
1

ソフトウェアを展開する前にバグを見つけて排除するのに役立つ、継続的な統合を本当に導入する必要があります。特に大きなプロジェクト (500k はかなり大きいと思います) には、何らかの検証が必要です。

http://www.codinghorror.com/blog/2006/02/revisiting-edit-and-continue.html

特定の質問について：これらの構成を避けたり、狂ったデバッグスキルに頼ったりしないでください-（展開されたソフトウェアで）バグをまったく回避するようにしてください。代わりに単体テストを作成します。

于 2010-10-05T16:06:39.643 に答える
1

また、非常に大規模な恒久的なベータ プロジェクトにも携わってきました。

匿名メソッドとインライン デリゲートを使用して、比較的単純な use-one ロジックを、その唯一の使用場所の近くに保持しました。

再利用と信頼性のために、一般的なメソッドとクラスを使用しました。

クラスの不変条件を維持し、無効な状態のオブジェクトによって引き起こされるバグの可能性を排除するために、コンストラクターでクラスを可能な限り完全に初期化しました。

列挙子ブロックを使用して、列挙子クラスを作成するために必要なコードの量を数行に減らしました。

これらはすべて、急速に変化する大規模なプロジェクトを信頼できる状態に維持するのに役立ちます。

編集して続行できない場合は、編集してからやり直します。ほとんどの場合、これには数秒かかりますが、厄介な場合には数分かかります。コードについて推論する能力が向上し、再利用による信頼性が向上したことで、何時間も節約できたのは価値があります。

バグを見つけやすくするためにできることはたくさんありますが、バグを見つけやすくなるかどうかはわかりません。

于 2010-10-05T16:09:25.713 に答える
0

テスト駆動開発を試すことができます。デバッガーをまったく使用しないようにすることは非常に便利であることがわかりました。新しいテスト (単体テストなど) から開始し、この単体テストを実行して開発を確認するだけです。アプリケーション全体を常に実行する必要はありません。これは、編集して続行する必要がないことを意味します。

TDD が現在のバズワードであることは知っていますが、私にとっては非常に効果的です。デバッガーを使用する必要がある場合は、個人的な失敗と見なします:)

于 2010-10-05T16:05:01.813 に答える
0

あなたが抱えていると思われる問題は次のとおりです。

アプリを再構築して再起動し、作業中の UI に到達するまでに時間がかかりすぎます。

誰もが言っているように、単体テストは、UI コードのないバグを見つけて修正するためにアプリを実行しなければならない回数を減らすのに役立ちます。ただし、UI のレイアウトなどの問題には役立ちません。

過去に、サイクル タイムを短縮するために、作業中の UI をすばやく読み込み、それにダミー データを入力するテスト アプリを作成しました。

単体テストでテストできる他のクラスに UI コードを分離しないと、それらのクラスですべての C# 構成を使用できるようになります。次に、UI コード自体で使用されている構成を制限することができます。

多くのユニット テストを書き始めたとき、「エディット コンティニュ」の使用が減り、UI コード以外ではほとんど使用しなくなりました。

于 2010-10-05T17:54:50.147 に答える
0

Edit and Contに頼る。単体テストはおろか、新機能の設計にほとんど時間が費やされていないように思えます。おそらく多くのデバッグとバグ修正を行うことになり、バグ修正がさらに多くのバグを引き起こすこともあるので、これは悪いことだと思いますよね?

ただし、言語機能を使用する必要があるかどうかを判断するのは非常に困難です。これは、プロジェクトの要件、リリース期限、チームのスキル、リファクタリング後のコード管理のコストなど、他の多くの要因にも依存するためです。 .

お役に立てれば！

于 2010-10-05T16:12:32.597 に答える