clibと呼ばれるライブラリー開発の思い出（３）

（前回はこちら）

記憶が定かではないですが、2000年の後半からカラーデジタル複合機の新たなコントローラソフトウェアの開発が始まりました。一枚のコントローラボードですべてのサービスを動作させるということで、ほとんどのサービスは新規に開発するというプロジェクトでした。

開発に先立ち、オブジェクト指向で開発を行うということで、当時FXISにいた私、荒井礼子さん、皆川さんの三人で富士ゼロックスのソフトウェア技術者（200名以上）に以下のことを行いことになりました。

• C++教育を含むオブジェクト指向に関する基礎教育（一週間？）
• 実際の開発成果物のレビューを含むコンサルティング

ほとんどのソフトウェアエンジニアは、デジタル複合機に関するドメイン知識はありましたが、オブジェクト指向言語（C++）やオブジェクト指向開発は初めてということで、基礎教育をFXISへ発注してもらって実施しました。

教育を受けただけでは、正しく実践できる保証はないため、これもFXISへ発注してもらい、希望する開発グループに対してコンサルティングをすることになりました。実際、私自身は、この頃から、2002年8月に米国へ赴任するまで、多くのレビューを行っていました。特に2001年には、週に3日とか4日は、朝から一日中レビューをしていました。

同時に開発に先立って私が書いたのが、『Code Review Guide』と『C++ Coding Standard』です。

『Code Review Guide』では、コードレビューのやり方を書いてあるのですが、特徴的なのは、開発者が単体テストを実施する前に、コードレビューを実施するということです。開発者がテストしてしまった後にコードレビューを実施して読みやすさに関する指摘をしても、コードを書き直してもう一度テストするというのは心理的な抵抗が強くなってしまうので、テストする前にレビューするように規定していました。当時は、自動テストではなく、手作業によるテストの時代でした。

『C++ Coding Standard』は、C++での様々な命名規則、クラスやインタフェースの宣言方法、定数の宣言方法、実装の隠蔽方法、禁止事項などを書いたものです。これは、IM200開発でのC++の経験に加えて、1996年から独学で学んだJavaの知識の多くをC++へ盛り込んだものとなっていました。

おそらく、2000年の夏頃からclibのAPI設計を始めたのだと思います。まず、書いたのは、『メモリ管理ライブラリ』のAPI仕様書です。次に、『メモリ管理ライブラリ』に基づく『スレッドライブラリ』のAPI仕様書を書きました。『スレッドライブラリ』には、単なるマルチスレッドプログラミング用のAPIだけではなく、コレクションライブラリも含めました。『メモリ管理ライブラリ』と『スレッドライブラリ』を総称して「clib」と呼んでいました。

clibは、製品で使われるOSであるVxWorks版が実装されただけでなく、さらにWindows版とSolaris版が実装されて開発者に提供されました。clibだけで実装されるライブラリであれば、Windows上でもSolaris上でも実装・デバッグできるようになっていました（最終的な商品では、VxWorks用にソースコードがクロスコンパイルされます）。

一方で、私自身がいくつかの開発グループのコンサルティング（主にクラス図やコードのレビュー）を行っていましたので、共通に必要と考えられる機能は、順次『スレッドライブラリ』へ追加していきました。追加した機能で最も実装が複雑だったのは、ReaderWriterLockでした。

clibはC++用のライブラリでしたが、Javaの影響を色濃く反映したものになっていました。特に、「インタフェース」概念の導入、「インタフェースの実装」を除く「クラスの多重継承の禁止」、staticファクトリーメソッドの推奨などです。

次回は、『メモリ管理ライブラリ』について書きます。