外部コード内の任意の関数/クラスへの呼び出しを禁止する

システムでの負の結果を防ぐために、外部ライブラリとフレームワークのAPIへのアクセスを制限することが重要になる場合があります。

たとえば、SharePointアプリケーションではspList.Items.GetItemById、ループ内であっても、リストアイテムを取得するために呼び出すのが自然に思えるかもしれません。

また、テスト環境ですべての電子メールを適切にプロキシおよびモックできるように、全員に独自のクラスを使用して電子メールを送信させるために、SmtpClientの使用を禁止する必要がある場合もあります。

独自のコードの特定の特定の場所を除き、外部コードでこれらの制約を達成するための信頼できる合理的な方法はありますか？すべての状況下で、これらのメソッド/クラスへのアクセスを完全に禁止する必要はありません。たとえば、リフレクションまたは何らかの無効化によって、それらを使用しないことを厳しく警告する必要があります。できればプログラマーに積極的にこれらの制約を無効にするための措置をとるように強制します。

独自のコードの特定の特定の場所を除き、外部コードでこれらの制約を達成するための信頼できる合理的な方法はありますか？

質問は特にC＃に関するものであるため、このようなルールを実施するためにここで使用できるコンパイラベースのソリューションがあります：Roslyn Analyzers。特定のAPIへのアクセスをコンパイルエラーまたは警告として報告する独自のアナライザーを作成できます。

独自の記述に関する多くのサンプルコードを提供するアナライザーのサンプルセットは、C＃の古いStyleCop機能に代わるStyleCop Analyzersです。

そうは言っても、そのような自動化されたチェックは、「ルールを破る」と決心した人々によっていつでも回避できます。したがって、このアプローチは、Karl Bielefeldtの回答で説明されているコードレビューの代替ではありません。このようなレビューを支援できますが、それらを置き換えるべきではありません。

不要な操作を除外する外部APIのラッパーを作成するなど、時間のかかる作業を行うことができますが、トレーニングやコードのレビューに勝るものはありません。 。

たとえば、Scalaで記述されたいくつかのサービスがあり、コードレビュー時に要求することの1つは不変性varsです。先日誰かがval x：ListBuffer [Boolean]を使用して、リスト内の唯一の項目として単一の可変変数を保持していました。ListBufferx に別のものを割り当てることはできませんが、リストの項目を必要なだけ置き換えることができます。を使用するのvarと同じくらいひどいですが、スニーカーです。

言い換えれば、人々があなたの技術的ソリューションを回避しているかどうかを確認する必要があります。それらの技術的ソリューションが高価で複雑になる場合は、それらが正しくコーディングされていることを確認するだけでもかまいません。

カールの答えは100％正しいです。適合性を保証する方法はありません。ただし、トレーニングとコードレビューに加えて、コンプライアンスを確保するために静的分析ツールの使用を検討してください。（注：カールが述べたのとまったく同じ方法でそれらをバイパスすることができるので、「に加えて」と言いました）。

静的分析ツールを使用する利点は、「IEnumerableの複数使用」のインスタンスや、あなたが見ている週のパフォーマンスの問題（または、少なくとも、私は常に見つめている）。これにより、コードのレビューとトレーニングが、より「興味深い」問題に集中できるようになります。

C＃については、具体的には、以下にいくつかの提案を含めました。これらをビルド環境に接続すれば、準備完了です。しかし、一般的に、使用している言語に関係なく、静的分析ツールがどこかにあります。

Wikipediaページから直接コピー/貼り付け、最新の情報とリンクについてはwikiページを使用してください：https : //en.wikipedia.org/wiki/List_of_tools_for_static_code_analysis#.NET

• .NET Compiler Platform（コードネームRoslyn）– Microsoft .NETによって開発されたC＃およびVisual Basic .NET用のオープンソースコンパイラフレームワーク。構文を分析および操作するためのAPIを提供します。
• CodeIt.Right –静的コード分析と自動リファクタリングをベストプラクティスに組み合わせることにより、コードエラーと違反を自動的に修正できます。C＃とVB.NETをサポートします。
• CodeRush – Visual Studioのプラグインで、ベストプラクティスの違反をユーザーに警告します。
• FxCop – CILにコンパイルされるMicrosoft .NETプログラムの無料の静的分析。スタンドアロンで、一部のMicrosoft Visual Studioエディションに統合されています。マイクロソフトによる。
• NDepend –コードの依存関係の分析と視覚化、設計ルールの定義、影響分析の実行、異なるバージョンのコードの比較により、複雑な.NETコードベースの管理を簡素化します。Visual Studioに統合します。
• Parasoft dotTEST – Visual Studioの静的分析、単体テスト、およびコードレビュープラグイン。C＃、VB.NET、ASP.NET、マネージC ++など、Microsoft .NET Frameworkおよび.NET Compact Frameworkの言語で動作します。
• Sonargraph – C＃、Java、C / C ++をサポートし、依存関係分析、自動化されたアーキテクチャチェック、メトリック、およびカスタムメトリックとコードチェッカーを追加する機能に重点を置いています。
• StyleCop – C＃ソースコードを分析して、一連のスタイルと一貫性のルールを実施します。Microsoft Visual Studioの内部から実行するか、MSBuildプロジェクトに統合できます。

別の回答で提起された「トレーニングとコードレビュー」の提案について詳しく説明すると、禁止したいコードは合法コードであるため、コンパイラがそれを妨げているとは考えられず、後のプロセスに頼る必要があります。レビュー。

これには、手動および自動の両方のレビュー手順を含めることができます（また含める必要があります）。

• 既知の問題のチェックリストを準備し、手動のコードレビューで1つずつ確認します。定期的な会議を開いて、チェックリストを確認および更新します。厄介なバグを見つけて分析するたびに、チェックリストに追加してください。

• 既知のパターンを探すためのチェックインルールを追加します。これは書くのが複雑な場合がありますが、大規模なプロジェクトでは、時間が経つと便利な場合があります。TFSではC＃でルールを記述でき、他のビルドシステムには独自のフックがあります。ゲートビルドを使用して、パターンに一致するチェックインを拒否することを検討してください。はい、それは開発を遅くしますが、特定のプロジェクトのサイズと複雑さの後、開発者を遅くすることは良いことです。

コンパイラは、不要な呼び出しをキャッチするのに役立つ可能性があります。

外部のlibクライアントが使用してはならない独自のlib内のコードのクラス/メソッドの名前を変更します。クラス/メソッドを交互に内部化し、それらの使用を許可されているクラスに見える内部を追加します。

外部のlibユーザーは、コンパイルエラーメソッド/クラスが見つかりません。

パブリックライブラリの禁止されたクラス/メソッド：ライブラリに同じ名前空間/クラス/メソッドを作成します

クラスが重複しているため、外部libユーザーはコンパイルエラーを受け取ります。

[更新]

すべての状況下で、これらのメソッド/クラスへのアクセスを完全に禁止する必要はありません。たとえば、リフレクションや何らかの無効化などによって...

プログラマー（... libのクライアント）に、これらの制約を可能/必要に応じてオーバーライドするための措置を積極的に講じることを強制します。