開発者であり、アーキテクトであり、著書も持つSimon Brown氏はプロジェクトを成功させるには良いコード以上のものが必要だと考える。良いコードだけでは不十分と題したプレゼンで氏はプロジェクトの成功に必要なすべての要素について、事前の設計から運用尾のための文書まで、くまなく論じた。
良いコードがあるということはスタート地点に立つことであり、プロジェクトの成功には何をビルドしたか、何がリリースされたかそしてどのように動作するかを知る必要がある、というのが氏の考えだ。
ビルドするべきことを知るためには、一揃えの要求が必要だ。要求が集まったら“全体像” が描ける。これはこの時点での構築すべき製品に対する理解が反映されたソフトウエア設計図だ。それから、大きな問題を小さな解決策に分解する必要がある。こうすることで各コンポーネントやその間のやり取り、利用するサービスがはっきりする。そして、このソリューションが実装にどのくらいかかるか見積もれるようになる。氏によれば、要求の決定から見積もりの作成までのすべて合わせて1、2日で行うべきだ。これはひとりで行う作業ではない。アイディアを異種交配させるために関係者全員で協力して行うべきだ。
この行程がきちんとできたら、軽量のソフトウエアアーキテクチャを使ってプロジェクトに次のふたつを導入する。“どんなコンポーネントがどのように互いにやり取りをするのか”を表す構造と“パターンやテンプレート、原則の文書化によって作成される”ガイドラインだ。こうして“共通の問題を解決するための標準的な手法”を持つことで一貫性が得られる。まだ、プロジェクト関係者は“全体像”を見ているので、自分がどこに向かっているかを把握できるほどの明確さも得られる。悪い例として氏が挙げるのは、Spring、EJB、Hibernateの3つの永続化ソリューションを利用するプロジェクトだ。事前にどのような永続化フレームワークを利用するのかを誰も決めないとこうなってしまう。
次の段階は優先度付けだ。小さなプロジェクトでない限り、一回のビルドとリリースでプロジェクトが完了させようとはせずに、何が最も重要で一番に行うかを決める。この作業では初期バージョンとして十分に動作させるために、要求のどの部分を実装するするかを練りながら、対象を批判的に検討しつつ決定する。
次は進捗を追跡することだ。これにはさまざまな方法がある。例えばスプレットシートやカンバンボードを使った方法だ。氏が指摘するには、いままでのところこれらの方法はイテレーションの進捗の完了を把握するのに使われるが、実際のソフトウエアのリリースを追跡しない。
アーキテクチャは動作するか。結果のソリューションが望み通りに動かなければすべては役に立たない。ソリューションを動作させるにはアーキテクチャは次の要求を満たさなければならないと氏は指摘する。
- アーキテクチャドライバを満たすたしていること。つまり機能要求、非機能要求、環境の制約、原則の適用などを満たしていること。
- コードのためのしっかりとした基礎を提供すること。この上にコードが構築される。
- このソリューションが扱おうとしている初期のビジネス上の問題を解決するプラットフォームを提供すること。
プロトタイプを構築する。アーキテクチャがどんなに優れていても、コードがどんなに美しくても、システムが満足に動くかどうか、拡張性があるかどうかは誰にもわからない。ここでプロトタイプが必要になる。プロトタイプはシステムが正常に動作することを確認するが、これにはシステムを縦で割った場合の構成の動作に問題がないことの検証も含まれる。また、このプロトタイプは要求や基盤の感触を確かめ、実際の機能をシュミレートし、システム全体の負荷テストが実施できる程度のものでいい。プロトタイプに使われたコードは後の製品版で利用してもいいし、捨ててしまってもいい。
負荷テストは“できれば本運用環境となるべく近い環境で、複数のユーザの典型的な使い方の分析結果のシュミレーション”を使って行う。プロトタイプと負荷テストは、アーキテクチャを検証するためにプロジェクトの早い段階で実施されるべきだ。
ソースコード制御を使うのはソリューションを構築するための重要な一歩だ。これを使えばソースコードのバックアップや変更履歴、前のバージョンへ戻すことや、平行開発の簡素化が実現できる。
また自動テストも必要だ。何かの機能を破壊するためだけに新しいコードを追加していないか。プロジェクトの一部の変更は他の部分に悪い影響を生む可能性がある。変更による損害を抑制するため、プロジェクトの単体テストや結合テストは必須だ。これらのテストがないのなら、変更を行った後に必ず手動でシステム全体をテストする必要がある。ではどのくらいテストすればいいか。氏は100%テストで網羅するのは難しく実践的でない、最も重要なコードの80%が網羅されていればいい、と考える。
自動ビルド。コードをテストした後、ビルドして対象のマシン(複数のマシンかもしれない)に配置する必要がある。しかし、このビルド結果は他のマシンで動かない場合が多い。ビルドスクリプトが必要なのはどんなマシンでもビルド結果が正常に動作することを保証するためだ。
氏によれば継続的統合も有効な手段のひとつだ。継続的統合サーバは自動的にリポジトリのソースコードを検索して、コンパイルし、テストし、パッケージ化して、インストールまで行う。この一連の処理の中で発生したエラーはどんなものでも通知される。これを使えばコードのビルドが正常に行われることを保証できるし、どんな問題でも早期に発見できる。
テストとビルドの自動化を行うことで一貫性と再現性が生まれる。また、自動化は平行開発を行う場合やさまざまに分岐したコードを扱う場合にも役に立つ。
構成情報の外部化。システムの構成情報は環境に依存する。コードの外の一カ所に保持してメンテナンスするのがよい。
アプリケーションのバージョンはどこかに含めておく必要がある。メタデータでも、診断ページでもログファイルの中でもよい。どのバージョンのプログラムを探しているのか簡単に教えれるようにするためだ。
そして最後に運用文書。開発チームが開発したソフトウエアのサポートを行わないのなら、システムの使われ方、監視方法、管理方法、問題発生時の診断方法が書いてある運用文書が必要だ。
下記のスライドには成功しそうな製品を作るのに貢献するすべての要素が含まれている。
