外部ベンダーさんに開発してもらったASP.NETの社内システムがあって、昨日はそのソースを眺めてました。
いろいろツッコミどころはありますが、一番気になったのは例外処理のまずさ。
やっぱり、こういう感じなんですね〜。
bool GetDataSet(string id, out DataSet dataSet, out string errorMessage) { try { //DBにアクセスするコード dataSet = //メソッド内で取得したDataSet return true; } catch (Exception e) { errorMessage = e.Message; return false; } }
というわけであっちこっちで例外をキャッチして、メソッドの戻り値は成功/失敗を表すbool型になっています。
例のヤヴァイシステムを含めて、どうも.NETやJavaの例外をしっかり理解している人が少ない気がします。
適切に使えばこれほど便利なエラー処理方法はないのですが、パラダイムシフトができずにC言語やVB時代のエラー処理方法に無理矢理あてはめようとして、例外の「うまみ」を完全に消し去ってしまってるんじゃないでしょうか？
一言でいうと、「例外はキャッチするな」です。特に.NET言語はそう。
例外を処理する部分はシステム内で1カ所だけに済むように設計するのがベストプラクティスです。
詳しくは赤間信幸先生の以下のブログをチェックすべし！
http://blogs.msdn.com/nakama/archive/2008/12/29/net-part-1.aspx
「まず、大原則を覚えてください。よほどのことがない限り、アプリケーションで try-catch を書いてはいけません。」と赤間さんも強調されています。
また、スマートな例外処理方法は「ASP.NET ランタイムや Windows フォームなどでは、これらの画面を差し替えるための機能を備えています。」と書かれている部分をチェック！
とはいえ、このベンダーさんが作ったシステムは既存の内製システムに比べるとはるかにしっかりしています。
コーディングに一貫性があり、メソッドの行数もそれほど長くないので、見た目がきれいです。
またコメントも多いので、初見の開発者は助かります。
メソッドの戻り値の大半がbool型になっていますが、こちらで確認する限り、呼び出し側は成功/失敗の確認をきちんと入れているようです。
あと、仕様書をきちんと作ってあるのもすばらしい！(外部ベンダーなら当たり前か)
100点満点とは言えませんが、これまで見てきたソースの中ではかなり上位に入る品質でした。
(なんかまた上から目線でごめんなさい。。。)
