salesforceの基調講演 - 妙に納得させられたこと -
初日の基調講演ということで主催者側の講演者の選択にも、講演内容にも唸らせられた。責任分解点をメトリクスによって定義しているところに妙に納得した。カバレッジも共有リソースも結構前から知っていたのに、こういう組合せ、はかりかたもあるんだなぁと納得させられた。当たり前といえば当たり前なんだが．．
5/21～5/27に米ミネアポリスで開催されたICSE(International Conference on Software Engineering)の本会議の初日の基調講演でsalesforceの方が講演をされていた。聴講者もかなり多かったと思う。講演の後半はデモンストレーション中心になっていたが、聴衆を考えるともう少しアーキテクチャの話をしてくれたほうが適していたように思う。
salesforceはエンタープライズ系のソフトウェアをサービスとして提供するために必要なインフラを提供する企業である。比較的粒度の小さい機能をサービスとして提供し、ユーザはそれらを組合わせて購入、利用することができる。カフェテリア方式といえるだろう。これ自体は、特にsalesforceの特徴ということではないが、サービスはサードパーティや顧客が独自に開発したものも含む。サードパーティや顧客はsalesforceが提供するストレージやSQLベースのDBやネットワークのフロントエンドを利用しつつ、独自のロジックを持つサービスを追加できる。
一見簡単な話にみえるが、共用のストレージ(データベース)、共用のネットワークで、特にサードパーティや顧客独自のアプリケーションを動かすことは結構難しい。1つは特定のサービス(アプリケーション)が多くのリソースを使ってしまわないような仕組みを作ること、もう1つは、データベース、ミドルウェアのバージョンアップをする際に、ある程度足並みを揃える必要があること、である。前者はvirtualizationがある程度解決してくれるといえるだろう。後者の足並みが揃わないとリソースを共用しているメリットが小さくなっていく。ここをそれなりにカバーしようとしている点が、私がおもしろいなと思った部分である。
具体的には、以下のとおり。
- サービス自体を記述しているコードとそれの単体テスト用のコードを同時に登録することを必須とする。（ミドルウェアやデータベースのバージョンアップの前に単体テストを実行して問題が起きないかを確認するため）
- 登録する単体テスト用のコードには最低コードカバレッジが課されていて、原則的にカバレッジが低いテスト用コードは受け入れられない。
- 自分が作ったサービスの脆弱性のチェックをやってくれる。
salesforceが提供するインフラを利用する場合に限った話ではないが、ソフトウェア開発の観点からいうと、ストレージやDB周りはバックアップや管理が非常にやっかいなので、ここを代わってやってくれるのは非常に助かると思う。必要以上に富豪的プログラミングを助長してしまうのかもしれないが、virtualizationにより、計算機リソースを動的に変更できる点もありがたいと思う。
これを読んでおられる方には釈迦に説法になりそうだが、コードカバレッジをはじめとしたカバレッジはこれ1つで大丈夫というメトリクスではないが、テストの網羅性をはかるための有力な指標の1つである。
キーワード記事*
※このキーワードリンクは、オルタナティブ・ブログ事務局の編集によるものです。