ソフトウェア開発の「現場」はソースコード

マルチスレッドプログラミングを本格的に行ったのは、1993年夏以降にSolaris 2.3を利用してソフトウェアを開発した時でした。Solarisとしては、初めてＯＳレベルでマルチスレッドをサポートしたばかりでした。当時は、マルチスレッドに関する書籍はほとんどなく、Solarisに付属するドキュメントを読んで学習したと記憶しています。

マルチスレッド関連の書籍が出始めたのが、1995年頃ではないかと思います。すでにかなりのマルチスレッドプログラミングをしていたので、復習および理解を深めるために、3冊ほど読んだと記憶しています。

Solaris 2.3を用いた開発では、開発言語はC++でした。C++で本格的に開発を始める前に、書籍でC++を学習したのですが、どの本を読んでも、公開ＡＰＩ（公開クラス）から実装の詳細（protectedやprivateのフィールドやメンバー関数）を隠蔽する方法が書かれていないく、困ったなと思いました。チームで分担して開発するには、それは必須と考えていたからです。

さんざん考えて、公開ＡＰＩクラスでは、すべてのメンバー関数を純粋仮想関数と宣言し、フィールドは宣言しない。そして、そのサブクラスとして実装を行えば良いという考えに到達しました。ただし、staticファクトリーメソッドは思い付かなかったため、インスタンス生成用の関数を別途クラスごとに用意するということにしました（クラス名の前にnew_を付けた生成関数を用意するということです）。

ということで、この公開ＡＰＩとその実装を隠蔽することを、開発グループ全体で統一して行うことを徹底することにして、本格的な開発を開始しました。実装の詳細は隠蔽されていましたので、ライブラリーの開発者は、クライアント側のコードをリコンパイルすることなく、ライブラリーの実装を自由に変更してテストすることが可能でした。

Solaris 2.3を用いたこのプロジェクトでは、24時間365日安定して動作させる必要があるため、メモリー管理も標準のnewオペレータとdeleteオペレータの実装ではなく、独自に実装して、メモリー破壊やメモリーリークを検出する仕組みを入れました。

ビルドも当初は2週間に一回でしたが、毎日夜間ビルドするようにもしたものです。しかし、当時は、残念ながらリコンパイルだけであり、テストはすべて手作業という時代でした。（「Writing code without tests ...」）

このプロジェクトに従事したエンジニアは、システム全体のアーキテクチャの検討から詳細設計・コーディング・デバッグまでを行っていました。それだけ、個々のエンジニアにも創造性と自発性が求められていた訳です。その意味で、私自身は上流工程の分析だけしかしなくて、実際の詳細設計・コーディング・デバッグは別の人が行うような開発プロセスは、今も馴染めません。

どんなに上流の分析で詳細を考え抜いても完璧ではなく、ソフトウェアの設計が終わるのは、ソースコードとして書かれた機能がテストを経て完成した時だと思っています。最終的にデバッグをして、システムを完成されせるのは現場のエンジニアであり、個々のエンジニアがその技量を伸ばす努力をしないで、言われたとおりにプログラミングしましたというのでは、システムは完成しないかもしれません。

そして、ある意味では、ソフトウェア開発の「現場」はソースコードです。理解するのが困難で保守性が低い「負債」としてではなく、理解が容易で保守性が高い「資産」として、ソースコードを残していく努力を個々のソフトウェアエンジニアには求められると思います。