Clever Geek Handbook

ソリューションの品質を改善する簡単な方法

おそらく皆さんは、SharePointのこのようなソリューションに出くわしました。ソリューションは機能しているように見えますが、いくつかの問題が絶えず発生し、データが保存されず、一見無害な操作中に奇妙なクラッシュが発生します。 テスターはそのようなソリューションに多くの時間を費やしますが、いくつかのバグを修正すると他のバグが発生します。 このようなソリューションを運用ファームに展開することは非常に難しく、サポートは非​​常に困難になります。 よく知っていますね



SPCAF（ http://spcaf.com ）のコード分析ルールを開発しているときに、この状況をすばやく修正する方法を見つけました。







この種類のすべてのコードブロックを検索します。 

try { // } catch(Exception e) { //  ,  throw; }


タイプthrow;



catch



。 catchが特定の種類の例外ではなく、基になるException



示すことが重要です。



アプリケーションがクラッシュし始め、見つかったすべてのエラーをthrow



を削除せずに修正する必要があります。 私はすでにさまざまなプロジェクトでこれを何度も行っていますが、これは非常に良い結果をもたらしました。 プログラマーが抵抗しても、 throw



ことを許可しないでください。



リサーチ



ルールをテストするために、約70個の.wspファイル、SharePointソリューションを収集しました。 それらのほとんどは私が参加したプロジェクトであり、開発中に発生したすべての問題をよく認識しています。 私はthrow



せずにtry\catch



ブロックの密度を計算しました、これは何が起こったのですか：





正当化



すべての例外をキャッチすることはほとんど常に推奨されません; Visual Studioコード分析はそれを誓います;これはフレームワーク設計ガイドラインに書かれています。 例外なくすべてのプログラマーに読む価値がある本Pragamtic Programmerでは、ルールは簡潔かつ簡潔に定式化されています-クラッシュ、ゴミ箱にしないでください。



実際、すべての例外をキャッチすることは、プログラマーが犯した間違いを抑えるための試みです。 エラーはまだクロールされますが、それほど明白ではなく、多くの場合完全に別の場所で発生します。 これにより、ソリューションの開発時に問題が発生します。 APIは非常に複雑であるため、これは特にSharePointに当てはまります。



開発者のエラーがポータルをあふれさせないように、すべての例外をキャッチし、それ以上スローしないことを正当化する場合、SharePointソリューションの1つのケースのみを知っています。 しかし、それらの場合でも、連続して全員をキャッチするのではなく、特定のタイプの例外を処理することを検討する価値があります。 それ以外の場合、コードは可能な限り迅速かつ大声でクラッシュし、できれば何が悪いのかを報告する必要があります。 例外が発生した場合にfalse



またはnull



を返さないでください。コードを落とすと、開発者とテスターはユーザーに表示される前にエラーを表示します。



おわりに



エラー抑制の問題は、SharePointソリューションだけでなく、C＃と.NETプラットフォームだけにも関係します。 おそらく他のプロジェクトでは、例外の抑制を排除することで状況を大幅に改善できます。



PS。 決定を確認した一連のルール-http://spcafcontrib.codeplex.com/


More articles:


All Articles