ほとんどの大きな開発組織は何らかの形のコーディング標準とベストプラクティスをもっている。これらの標準をわかりやすくドキュメント化して常に最新に保つことは、多くの組織にとって重要なチャレンジとなりうるし、まして、それらの標準やベストプラクティスを一貫して実施することは、もっと困難だ。だが、私たちの組織は、コーディング標準とベストプラクティスの実施をビルドプロセスの一部として自動化するのが非常に効果的であることに気付いた。
私たちのソリューションでもっとも重要なのは、その積極的な性質にある。コードレビューを行い、コードのよくないプラクティスに対しては個々の従業員から直接フィードバックを得られる仕組をもった成熟した組織であったとしても、そのプロセスを過去にさかのぼって実施すると、そこでたくさんの問題点が見つかることになり、開発者は過去に犯したミスの対応に追われる。さらによくないのは、もしレビューが開発中に行われなければ、品質の低いコードが製品にまぎれこみ、製品にダメージをあたえてしまうことだ。私たちのビルドプロセスは一元管理され、コンプライアンスのチェックはあらゆるソフトウェア資産のビルドにおいて自動的に実行されるので、有害なコードが製品に組み込まれてしまうことはそもそも起こらないし、コストのかかるプロジェクトのクリーンアップや、遡及的な監査戦略から生じる従業員のパフォーマンスに関する不愉快な議論を減らすことができる。その代わり開発者はシステムによってすぐさまフィードバック（私たちのシステムでは HTML 形式のレポート）を受ける。システムは、自分の誤りを恐れるなど感情に左右されることはない。これにより、開発者は新しいコーディング標準を思い出すのにビルドを何回か試みなければならないかもしれないが、自分たちの誤りから学習する機会をもつことができるし、システムは組織が危険なコードから守られていることを積極的に保証しつづける。
集中ビルドプロセス
私たちがここで議論する戦略が効果を発揮するには、次の二つのことが必要だ。:
- サーバベースの集中ビルドプロセスが必要である。 私たちが使っているのは、Ant スクリプトをベースにした自社開発のビルドシステムだ。自分たちでシステムを開発したのは、当時 AntHill や Maven といった製品がまだ成熟していなかったからだが、これからビルドシステムを導入するのであれば、自分で開発するよりもサードパーティ製のものを利用することをすすめる。私たちはビルドシステムを自分たちで構築したため、これから述べるプロセスのカスタマイズは直接そのシステムに実装する形になったが、みなさんはそれらの機能をサードパーティ製ビルドシステムに組み込むことができるはずである。
- そのビルドシステムを通さなければ開発者がコードをテスト環境や運用環境に適用できないようにする必要がある。私はものごとを独断的に見るのは好きではないが、これについては選択の余地はない。もし開発者がビルドシステムを迂回し、 FTP を使って Java クラスファイルをテスト環境や運用環境に直接アップロードすることができるなら、ここで私たちが議論しているソリューションの効果は激減する。このようなシナリオから環境を保護するため、私たちは、サーバ上にある関連ディレクトリの書き込みアクセスをできないようにし、ビルドシステムを動かす JVM プロセスを実行するアカウントにのみ書き込み権限を与えることによって、ビルドプロセスを開発者がコードをテスト環境や運用環境にアップロードすることのできる唯一のメカニズムとした。ビルドシステムは、ビルドを実行する都度、ソースコード管理リポジトリからプロジェクトを取得するので、先に述べた書き込み権限のロックによって、二つのことが実現される。それは、テスト環境および運用環境にあるすべてのコードが、管理されているソースコードと同じものであること、そして自動化された監査を通過しているということである。
ツールによるソフトウェア監査の自動化
私たちはコードの監査に Parasoft Jtest という製品を使うことになったが、ここで述べることを実現可能な製品は他にもある。Jtest には良い点と悪い点がある。全体的に見て Jtest は私たちにとって効果的なツールではあったが、私たちが必要とする動作をさせるためには周辺のインフラをハックしなければならなかったし、ここで提示する戦略を実現するには、そのままで利用できる製品ではなかった。Jtest には静的解析と動的解析というふたつのメイン機能がある。Jtest の動的解析機能は便利だが、今回の戦略のスコープからははずれてしまうので、ここでは論じない。
私たちはおよそ 4 年前、私たちの組織が、 try/catch/finally ブロックのなかでリソースが適切にクリーンアップされていないせいで運用環境においてデータベースコネクションがクローズされないという問題にぶつかったときに Jtest を購入した。思い当たるふしのある人もいるのではないだろうか？ それは Rod Johnson 氏が天から降臨してきて JdbcTemplate を私たちに与えてくれる以前のことで、当時、多くの組織がこの問題を解決しようと奮闘していた。この手のコーディングの問題を回避するのは、まさに Jtest が得意とするところだ。Jtest は Java クラスの構造と内容を解析し、ルールを適用する。ここでいうルールとは、たとえば、「あるメソッド内でデータベースコネクションが生成もしくはコネクションプールから取得されたのであれば、そこに try/catch/finally ブロックが存在し、finally ブロック内でコネクションをクローズもしくはコネクションプールに返却していることを確かめる」、といったものだ。手短にいうと、私たちは 4 年前まさにそのような Jtest 用ルールを作成して、それを「深刻度 1 」のエラーとし、そして（ここが重要なのだが）、深刻度 1 の Jtest エラーが起こったらビルドが自動的に失敗するようにビルドシステムを変更した。そのシステムはみごとに動作し、データベースコネクションの問題は解決した。
Rod 氏の JdbcTemplate がある今では、この特殊なルールのもつ意味は小さいが、Spring を利用するように変更されていないレガシーな Java アプリには今でも有用である。そして、現在でも有効な多くのルールがある。私たちは、それがアーキテクチャ的な標準を実施するためのすばらしいツールであることに気付いた。たとえば、私たちがロギングの標準を実施したときには、もはやその利用が認められなくなった System.out.println ステートメントを用いるのを不可能にするようなルールを適用した。だがこれらの例は Jtest の表面をなぞっているだけにすぎない。Jtest には数百のルールが最初から組み込まれているし、必要があれば自分でルールを作成することもできる。
Jtest について言っておきたいことがいくつかある。すでに述べたように、Jtest は私たちが購入した当時、サーバとしてはあまりよいとは言えなかった。Parasoft の主要な製品ラインは IDE 上で静的および動的解析を行う Eclipse プラグインだが、私が述べているのはそれのことではなく、サーバベースの Jtest 製品のことだ。私たちはその製品を、ビルドサーバから呼び出すコマンドラインを通じて自分たちのサーバインフラと統合した。Parasoft は、すべての開発者が IDE プラグインを購入して彼らを Parasoft の一元化されたレポーティングサーバとつなぐことで、私たちがここで議論している類の明確な組織的コントロールとガバナンスが達成できる、と考えているように思えるが、その考えは誤りだということに私たちは気付いた。問題は、開発者が CVS にコードをコミットする前に静的解析を実行することを Parasoft は保証できないということである。彼らは Eclipse の CVS プラグイン（または Subversion でも何でもいいが）をコントロールできないし、Jtest が「深刻度 1 のエラーがあるからコミットはできません」などと言ってコミットを中止させることのできる制御ポイントはない。そのため、テストはデスクトップ上ではなく中央のコントロールポイントで実行されなければならないし、私たちにとってはそれが自分たちのビルドシステムなのである。だから、私たちにはビルドの都度ビルドシステムから呼び出すことのできるサーババージョンの Jtest が必要だったし、その統合作業を自分たちで行わなくてはならなかった（それはひどく困難というわけでもなかったが）。
Jtest が唯一の選択肢ではないということも、あらためて言っておきたい。Adrian Colyer 氏やその他の人たちは AspectJ のアスペクトを使ってコーディング標準を実施したと語っている。これは集中ビルドサーバ上での実装も容易なのではないだろうか。Jtest でできることがすべてアスペクトでできるかどうかはわからないが、この方法はお金がかからない。そのほかの競合製品および Eclipse プラグインは Jtest で見ることのできるさまざまな静的解析機能のサブセットを実行する。気楽に始めてみたい人には Eclipse の標準 JDT に含まれている構文およびコーディングスタイル標準のためのサポートがある。
ガバナンスを広く行き渡らせるためのベストプラクティス
自動化されたソフトウェアガバナンスを展開していくための戦略は、そのソリューションを構築するためにどういうテクノロジを選択するかということよりもはるかに重要だ。ここに、私たちが数年間の経験から学んだ教訓をいくつか挙げておく。:
- ガバナンスの構造をシンプルに保つこと。 私たちはルールのカテゴリを深刻度 1, 2, 3 の 3 つだけにしている。深刻度 1 のルールはビルドを中止し、その問題が修正されるまではプロジェクトはテスト環境および運用環境に配備できない。深刻度 2 は基本的には中間準備的なものだ。そのルールは 6 ～ 12 ヶ月のうちに深刻度 1 に格上げされるので、納期に追われたりコードのビルドができなくなる前にその問題を修正するよう、開発者に伝える役割をもつ。深刻度 3 は修正を強制する効力をもたない。それは問題の修正を推奨するものではあるが、深刻度を 2 に上げないかぎり、実際に製品への適用を妨げる力とはならない。
- 保守的であること。 先に述べたように、Jtest には最初から数百のルールが用意されている。私たちがはじめて Jtest を配備したときに有効にした深刻度 1 のルールは、たった 2 つだった。その理由は単純で、間近にせまる納期にプロジェクトマネージャが悲鳴をあげていたため、私たちはコントロールポイントが迂回されてしまうような慣習が確立されるのを避けようと思ったのである。アグレッシブに例外を出しまくるよりも、保守的な態度をとってプロセスを信頼できる状態にしておくほうがいい。
- 積極的にインパクト解析を行うこと。 新たな深刻度 1 のルールを配備しようとしているなら、プロジェクトにおいてそれらの問題がどのくらいの頻度で発生するのか、そしてそのコードを修正するのに必要な時間とコストはどれくらいなのかについて、よく知っておいたほうがよい。これは難しいことではない。その新しいルールを有効にしてプロジェクト上で静的解析を走らせ、結果がどうなるかを見るだけでよい。それによって、新たな深刻度 1 のルールの配備が組織から支持されず、深刻度 2 への格下げを余儀なくされるという事態を避けることができるだろう。インパクト解析の結果、影響が大きすぎるということであれば、別の開発サイクルのためにそのルールの深刻度を 2 のままにしておく。もし発生件数の減少が見られないようなら、深刻度 2 の問題に対処する重要性について組織に対して伝える努力をしよう。問題がクリティカルであるために、広範に影響をおよぼす深刻度 1 のルールを実装せざるをえない場合もあるだろうが、その場合、経営陣がその影響を理解し決定を支持してくれることが絶対的に重要である。
- よくコミュニケーションをとること。 新しく作成したルールやそれらがもつ価値、そしてそのルールを実装することになった理由について、コミュニティに話をしよう。彼らはきっとあなたに同意してくれる。ただし彼らは、後になって突然知らされることは好まない。
私たちの実装の詳細にもかかわらず、積極的で自動化されたソフトウェア監査は私たちにとってすばらしい利益となった。私たちが制作するソフトウェア資産の品質は向上したが、おそらくもっと重要なのは、私たちがそれを実現するのに、信頼できるシステムを組織的にそしてメンテナンスに大きなエネルギーを費やすことなく利用したということだろう。標準をサポートするための組織的なプロセスが人の手による管理にもとづいている場合、そのメンテナンスには組織的リーダーシップを集中させることが求められる。開発をサポートするインフラを適切に設計することによって、より組織的なセキュリティを、より小さな努力で得ることができるのである。
著者紹介
Mark Figley 氏は AIG の抵当保険部門である AIG United Guaranty のアーキテクチャグループでリーダーを務める。AIG は 8,000億ドルの運用資産をもつ世界最大の保険会社である。
原文はこちらです：http://www.infoq.com/articles/governance-coding-standards
このArticleは2007年11月16日に原文が掲載されました）