特集：.NETアーキテクトの実用プラクティス

.NET開発のITアーキテクトになるための極意

C#とVBのどちらを選択すればよいかを、アーキテクトとして答えなくてはならないシチュエーションによく遭遇する。プロジェクトの状況によりどちらを選択するか決めるのだが、筆者は基本的にC#を推奨している。理由は、ECMA、ISO、JISという標準化団体で認定されていることと、マイクロソフトの.NET構想の中核言語であるためだ。

いざツールを導入してみると、ツールの不具合が後になって発覚して問題となることが多い。ツールの経験者から意見が得られることや、WebにFAQが存在すること、不具合報告のしやすさなどをあらかじめチェックしておくとよい。また、導入を決定してから「実は不具合により要件に対応できなかった」ということもある。要件に対応できるかは事前調査を徹底的に行おう。

あるWebアプリケーションのプロジェクトで、アクセス数の増加によるパフォーマンス低下の発生を懸念する声が上がった。そのため、アプリケーションのパフォーマンス・チューニングで対応を検討するとともに、スケール・アップ、スケール・アウトで対応できるようにするために、サーバ構成に関する設計を行う必要があった。

あるプロジェクトで、.NETの標準から外れた独自のコントロール機能など、「作ろうと思えば作れる。ただし、工数がかかる」というようなUI設計の画面ばかりを顧客に提案していたSEがいた。.NET Frameworkを使用したUIでの得意、不得意をSEに説明することにより手戻りを減らすことができた。

少ない開発工数で仕様変更に強い設計にするため、Enterprise Libraryなどのライブラリを使用したことは効果があった。

ASP.NETでは、「<」文字などのタグに該当する文字の入力を禁止するための、@PageディレクティブのValidateRequest属性が、デフォルトでtrue（禁止状態）になっている。しかし、「<」文字の入力が必要な場合に柔軟な対応ができない場合や、ValidateRequest属性の設定によって禁止される文字がマイクロソフトから明示的に公開されていないため、エンド・ユーザーに入力が禁止される文字を提示することができない場合がある。このため、VaidateRequest属性をfalseに設定して、独自にサニタイジング（無害化）処理を実装したことがあった。

インフラの設計／実装は、開発とは別のチームが行う場合が多いが、アプリケーション側とインフラ側の情報連携がうまくいっておらず、「MSDTCの設定は、そっちで対応すると思っていた」などの意思疎通ができていない状況が発生したことがある。事前に、発生し得る障害を列挙し、対応範囲を明確にしておく必要がある。

初級プログラマーがいるプロジェクトで、コーディング・ルールの内容自体が理解されていないことがあった。静的解析や、コード・レビューでチェックすることで、ルールに違反していないかを洗い出した。

プロジェクト・メンバーの経験が浅く、コード・サンプルを提供すると「サンプルとして」書いた簡易なコード部分を、内容を理解せずにコピー＆ペーストしてしまい、間違った使い方のコードを大量生産していたことがあった。これを教訓に、以降はあらかじめサンプルに詳細なコメントを記述したり、内容を理解してから利用するように指導したりして、予防するようにしている。

メンバーの入れ替わりが多いプロジェクトで、入れ替わるたびに開発環境を説明していたことがあった。開発環境構築手順をドキュメント化したことで毎回説明する手間がかからなくなった。

VSSを使用する場合は、最新のバージョンを使用するようにする。旧バージョンを使用すると、Unicodeファイルを保存すると破損する場合や、クライアントPCのシステム日時がサーバと同期されていないと、ラベル（＝特定時点でのソース・コードに付与する名前）やバージョン管理が正しく動作しない場合などがある。

品質管理を行うには、事前に品質基準を設ける必要がある。また、後述する「テスト設計」の項の「経験談」にもあるように、品質基準はプロジェクトの工数などの状況に応じて決める必要がある。

すべてのコードを対象に、単体テストの自動化を行うことを義務付けているプロジェクトがあった。しかし、仕様変更などでプログラムを変更、修正する際に、工数の都合できちんと単体テスト・コードを更新できない場合が発生し、結局、自動テストは常にエラーとなる状態になっていた。工数が限られている場合は、複雑なロジック部分のみに単体テストの自動化を検討して、やみくもにプロジェクト全体に適用しないようにするなど、単体テストの自動化を行う範囲を限定する。