保守可能でテスト可能なC＃コードを作成します

C＃コードをよく書くための鍵は、メンテナンス性とテスト可能性です。合理的に責任を分割し、単一の責任原則（SRP）に従って、それぞれリポジトリ、サービス、およびコントローラーによるデータアクセス、ビジネスロジック、および要求処理を行い、構造の明確さとテスト効率を改善します。多目的インターフェースと依存関係注入（DI）は、交換の実装、機能の拡張、シミュレーションテストを促進します。単体テストは、外部依存関係を分離し、模擬ツールを使用してロジックを検証して、高速で安定した実行を確保する必要があります。読みやすさとメンテナンスの効率を改善するために、命名と小さな機能の分割を標準化します。明確な構造、明確な責任、テストに優しい原則を順守することで、開発効率とコードの品質を大幅に向上させることができます。

C＃コードを上手に書くことは、「ただ実行」だけではありません。レベルを実際にテストするのは、コードがメンテナンスとテストが簡単であるかどうかです。特にチームのコラボレーションと長期プロジェクトでは、これら2つのポイントが開発効率と製品の品質に直接影響します。いくつかの実用的な視点からそれを行う方法について話しましょう。

責任を合理的に分割し、カテゴリを「疲れている」とさせないでください

タイプはあまりにも多くのことをします、そしてそれは後の段階でcocoを剥がすようなものであり、それが全身を動かします。単一の責任原則（SRP）に従うようにしてください。各クラスは1つのことだけを行い、非常に関連性の高いロジックセットを扱います。

たとえば、データアクセスとビジネスロジックを分離する必要があります。データベースとクラスで計算を行う場合、データベースを変更したり、将来アルゴリズムを調整したりするのは面倒です。リポジトリモードを使用して、データ操作を抽出し、サービスクラスと併せてビジネスロジックを処理すると、構造はより明確かつシミュレートしてテストしやすくなります。

一般的な慣行：

• データベース操作をリポジトリに配置します
• ビジネスロジックをサービスクラスに任せます
• コントローラーは、リクエストを受信して​​結果を返す責任があります

この階層化の後、テスト時にデータレイヤーをmockするだけで、データベースに実際に接続しないでください。

複数のインターフェイスを使用して、特定の実装への依存度を低くします

インターフェイスは、スキルを披露するためではなく、コードをより柔軟にするためのものです。依存関係噴射（DI）とインターフェイスの抽象化により、さまざまな実装を簡単に交換できます。これは、単体テストに特に役立ちます。

たとえば、メールを送信するメールサービスがあります。他のクラスが直接新しい場合、テストのために模擬または偽の実装に置き換えることは困難です。ただし、iEmailserviceインターフェイスと他のクラスがこのインターフェイスにのみ依存していることを定義する場合、実際に電子メールを送信せずにテストするときに偽の実装を渡すことができます。

利点はテスト以上のものです。

• 新機能の拡張が簡単です（テキストメッセージの追加など）
• モジュール間の結合を削減します
• 便利な統合テストとシミュレーションテスト

コードを書くときは、「この関数は将来変化する可能性がありますか？」答えが「はい」の場合、インターフェイスに抽象化する価値があります。

ユニットテストは簡単でなければなりません、環境に引きずり込まないでください

コードを書いた後にいくつかのテストを書くのは良い習慣です。しかし、多くの人々がデータベースに接続し、書面で外部サービスを調整し始めます。その結果、テストはゆっくりと実行され、失敗するのは簡単です - コードに問題があるということではなく、環境が不安定であることです。

正しい方法は、外部依存関係を分離し、論理検証に焦点を当てることです。

たとえば、ユーザーレベルに基づいて割引を計算する方法があるため、データベースをチェックしてユーザー情報を取得しないでください。代わりに、レベルをパラメーターとして渡すか、コンストラクターを介してiUserProviderインターフェイスを挿入し、テスト中に偽の実装を渡す必要があります。

提案：

• MOQまたはXunitの模擬ツールを使用して、依存関係をシミュレートする
• ユニットテストで実際のデータベースやネットワークにアクセスしないでください
• Test namingは、 CalculateDiscount_WhenLevelIsVip_Returns10Percentなどの意味があります

このようにして、テストは迅速に実行でき、安定して信頼性があります。

規範と小さな機能の命名、文のように読みます

多くのコードは、複雑なロジックのためではなく、乱雑な変数名と長すぎる関数のために、読みにくいです。関数の分解を恐れないでください。小さな関数は、1つの小さなもののみを実行します。これは理解しやすいです。

たとえば、この段落：

 if（user！= null && user.isactive && user.role == "admin"）

にカプセル化できます：

 if（userhelper.iselibibleforaccess（user））

ユーザーが権限を持っているかどうかを判断していることを一目で伝えることができます。読みやすさが向上し、維持する方がはるかに便利です。

さらに、次のような命名はスタイルと一致する必要があります。

• パスカルケース
• インターフェイス名はiで始まります
• プライベートフィールドはアンダースコアから始まります

これらの詳細は小さく見えますが、複数人のコラボレーションでは非常に重要です。

基本的にそれだけです。保守可能でテスト可能なC＃コードを書くことは、高度なスキルに依存していません。重要なのは、明確な構造、明確な責任、およびテストに優しいことです。これらの指示に固執すると、バグの変更と機能の追加が時間とともにはるかに簡単になることがわかります。

以上が保守可能でテスト可能なC＃コードを作成しますの詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。