編集とコンテンを破るC＃構成を避けたり、受け入れたりしますか？

https://stackoverflow.com/questions/3865454

28-09-2019
|

質問

C＃2.0で記述された大きな（500K+ LOC）WINFORMSアプリを開発および維持しています。マルチユーザーであり、現在約15台のマシンに展開されています。システムの開発は継続的であり（永続的なベータ版と考えることができます）、毎週のビルドで導入される可能性のある潜在的な新しいバグからユーザーを保護するための完了はほとんどありません。

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

私は、編集と継続的に、コードを積極的に記述して完全に互換性があるように書いています。たとえば、私は避けてください：

匿名の方法とインライン代表者（書き換えることが完全に不可能でない限り）
一般的な方法（安定した、変化のないユーティリティコードを除く）
「任意のCPU」でのプロジェクトのターゲティング（つまり、64ビットで実行されない）
宣言の時点でフィールドの初期化（初期化がコンストラクターに移動されます）
使用する列挙者の書き込みブロック yield （ユーティリティコードを除く）

現在、C＃3と4の新しい言語機能は、編集と接続（Lambda Expressions、Linqなど）とほとんど矛盾していることを完全に認識しています。これが、プロジェクトをフレームワークの新しいバージョンに移動することに抵抗する理由の1つです。

私の質問は、非常に簡単にデバッグできるコードを支持して、これらのより高度なコンストラクトを使用することを避けることが良い習慣であるかどうかです。この種の開発に正当性はありますか、それとも無駄ですか？また、重要なことに、これらのコンストラクト（ラムダ式、匿名の方法など）のいずれかが、よく書かれた、編集と継続的な互換性のあるコードを回避できるパフォーマンス/メモリオーバーヘッドを負担しますか？ ...または、C＃コンパイラの内側の仕組みにより、このような高度なコンストラクトが手動で書かれた「拡張」コードよりも速く実行されますか？

解決

些細なことをしたいと思わない - 編集に依存するのではなく、ユニット/統合テストを作成することをお勧めします。

そうすれば、あなたは一度努力を費やし、それ以外の時間は「無料」です...

今、私はあなたがあなたのすべてのコードのために遡及的にユニットを書くことを提案していません。むしろ、バグを修正するたびに、修正を証明するテスト（またはより一般的に複数のテスト）を作成することから始めます。

@dave Swerskyがコメントで言及しているように、Mchael Feathersの本、レガシーコードで効果的に作業します良いリソースですか（それはあなたがそれを書いてから5分後にレガシーですよね？）

はい、編集を許可して続行することを支持して、新しいC＃Contructを避けるのは間違いだと思います。しかし、私はまた、それのためだけに新しい構造を受け入れること、特にそれらがコードを理解するのが難しい場合には間違いだと思います。

他のヒント

「編集と続行」が大好きです。私はそれがインタラクティブな開発/デバッグのための大きなイネーブラーであると思います、そして私もそれが機能しないとき、それは非常に迷惑です。

「編集して継続する」場合、開発方法論を支援する場合、それを促進するために選択を行い、あきらめているものの価値を念頭に置いてください。

私のペットのおしっこの1つは、Lambda Expressionsが「編集」を破って機能する機能で何かを編集することです。私がそれを十分につまずいたら、私はラムダの表現を書き出すかもしれません。私はラムダの表情でフェンスにいます。私は彼らと一緒にいくつかのことをすることができますが、後でそれらを書き留めても時間を節約しません。

私の場合、私は本当に必要ではないときにラムダの表現を使用しないようにします。彼らが邪魔をしている場合、私はそれらを使用するコードを「編集して続行する」ことができるように、私はそれらを関数に包むことができます。彼らが無償であるならば、私はそれらを書き留めるかもしれません。

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

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

非常に簡単にデバッグできるコードを支持して、これらのより高度なコンストラクトを使用しないようにすることは良い習慣ですか？

編集と続行は実際にはデバッグではなく、開発中です。新しいC＃機能は非常にデバッグ可能であるため、この区別をします。言語の各バージョンは、新しい言語機能のデバッグサポートを追加して、できるだけ簡単にデバッグするようにします。

プロセスを停止せずに、すべてをリアルタイムで試してテストすることができます。

この声明は誤解を招くものです。編集が可能であり、非常に具体的な問題の修正が変更されていることを確認し続けます。変更が正しいことを確認するのははるかに困難であり、他の多くの問題を破らないことを確認します。つまり、編集と続行はディスク上のバイナリを変更しないため、単体テストなどのアイテムが許可されていないためです。

全体的にはい、私は新しいC＃が編集を許可して継続することを好むことを避けるのは間違いだと思います。編集と続行は素晴らしい機能です（C ++日に初めて遭遇したときに本当に気に入ってくれます）。しかし、生産サーバーのヘルパーが新しいC＃機能IMHOからの生産性の向上を補っていないため、それは価値です。

私の質問は、非常に簡単にデバッグできるコードを支持して、これらのより高度なコンストラクトを使用しないようにすることが良い習慣であるかどうかです

私は、あなたが自分自身を強制的にコードを書くことを強制しているときはいつでも、次のと主張します。

表現力が低い
より長いです
繰り返し（一般的な方法を避けることから）
ポータブルではありません（デバッグとテスト64bit ??！？！？）

デバッガーの「編集と継続」機能の損失をはるかに上回る全体的なメンテナンスコストに追加されています。

IDEの機能を作るコードではなく、可能な限り最高のコードを書きます。

あなたのアプローチに本質的に間違っていることは何もありませんが、IDEが理解する表現力の量に制限されます。あなたのコードはの反映になります これは 言語ではなく能力、したがって、開発の世界での全体的な価値は低下します。なぜなら、他の生産性向上テクニックを学ぶことを妨げているためです。編集とコンタニューを支持してlinqを避けることは、個人的に私にとって大きな機会コストのように感じますが、パラドックスは、あなたがそのように感じる前に、あなたがそれである程度の経験を積む必要があるということです。

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

ソフトウェアを展開する前にバグを見つけて排除するのに役立つ継続統合を実際に導入する必要があります。特に大きなプロジェクト（500Kは非常に大きいと思います）は、ある種の検証が必要です。

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

具体的な質問については、これらの構成を避けないでください。狂ったデバッグスキルに依存しないでください。バグをまったく避けてください（展開されたソフトウェア）。代わりにユニットテストを書きます。

また、非常に大規模なパーマネントベータプロジェクトに取り組んできました。

匿名のメソッドとインライン代表を使用して、比較的単純な使用法の一部を使用する場所に近づけています。

再利用と信頼性のために一般的な方法とクラスを使用しました。

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

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

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

編集して編集できない場合は、編集して再起動します。これはほとんどの場合数秒かかり、厄介なケースでは数分かかります。コードについて推論するより大きな能力と再利用による信頼性の向上は、私を救うことができます。

バグを見つけるのを簡単にするためにやることはたくさんありますが、バグも簡単にするのではありません。

試してみることができますテスト駆動型開発. 。デバッガーの使用を避けるのは非常に便利だと思いました。新しいテスト（ユニットテストなど）から開始し、このユニットテストを実行して開発を確認するだけです。アプリケーション全体を常に実行する必要はありません。そして、これはあなたが編集とコンティンを必要としないことを意味します！

TDDが現在のバズワードであることは知っていますが、それは本当に私にとってはうまくいきます。デバッガーを使用する必要がある場合、私はそれを個人的な失敗として取っています:)

編集と続きに依存しています。ユニットテストはもちろんのこと、新しい機能の設計に費やす時間がほとんどないかのように聞こえます。これは悪いことだと思います。なぜなら、あなたはおそらく多くのデバッグとバグの修正を行うことになり、バグの修正がより多くのバグを引き起こすことがあるからですよね？

ただし、言語機能を使用すべきかどうかを判断するのは非常に困難です。これは、プロジェクトのREQ、リリースの締め切り、チームスキル、リファクタリング後のコード管理のコスト、いくつかの名前を付けて、他の多くの要因にも依存するため、非常に困難です。。

お役に立てれば！

あなたが抱えているように見える問題は次のとおりです。

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

誰もが言ったように、ユニットテストは、None UIコードでバグを見つけ/修正するためにアプリを実行する必要がある回数を減らすのに役立ちます。ただし、UIのレイアウトのような問題を支援しません。

過去に、私が取り組んでいるUIをすばやくロードし、サイクル時間を短縮するためにダミーデータを埋めるテストアプリを作成しました。

ユニットテストでテストできる他のクラスにUIコードを分離することで、それらのクラスですべてのC＃コンストラクトを使用できます。次に、UIコードで使用されているコンストラクトを自己コードに制限するだけです。

たくさんのユニットテストを書き始めたとき、「編集とコンティン」の使用法はダウンしました。UIコード以外にそれをほとんど使用しません。

ライセンス： CC-BY-SA と帰属

所属していません StackOverflow