悪いAPIは伝染していく（2）

以前、「悪いAPIは伝染していく」という短い記事を書きました。

APIが悪いライブラリを使用する別のライブラリを設計する場合には、元のライブラリのAPIの悪さを、新たなライブラリでは修正することが可能です。しかし、よく見かけるのは、使用する元のライブラリのAPIの悪さをそのまま引きずったライブラリが設計されることです。その意味で、低レベルのライブラリのAPIの悪さは、上位レベルへと伝染していきます。悪さが伝染しないように新たにAPIを設計できるエンジニアは少ないようです。

きちんとしたAPIを持つライブラリを使用しているのにもかかわらず、出来の悪いAPIを持つ上位のライブラリが作成されることがあります。私自身がかなりレビューしてAPIを整備させたライブラリを使用して、その上に出来の悪いAPIを持つライブラリが設計されているのを見ると、がっかりしてしまいます。

どんなAPIでも、最初のバージョンは完璧ではないです。しかし、それを理由に、出来の悪いAPIを設計してい良い訳ではありません。

私自身の経験から言えば、2000年にC++言語用のメモリ管理ライブラリとそれを使用した基本的なライブラリ（スレッドやコレクション関連）※1を設計しました。私自身がAPIを設計したライブラリでしたが、実際に私がそれを使用してコードを書くことはありませんでした※2。しかし、2003年からそのライブラリを使用して、自分でもかなりのコードを書くことで、いくつかのAPI設計の誤りに気付いたのです。その誤りのほとんどは、些細なものでした。しかし、1行で書けるべきところを2行書かなければならなかったりして、非常に面倒に感じたのです。結局、その場合には、後方互換性を保ったままAPIを修正することが可能だったので、APIを修正しました。

※1 Fuji Xerox社のカラー複合機ApeosPortで使用されているライブラリです。
※2 私自身は、主に設計コンサルタント的な活動をしていました。

私が大学で情報工学を学んだ頃には、優れたAPIを設計することに関する教育はありませんでしたし、今でもないのではないかと思います。社会人となっても、体系的に教えられたりすることもなく、自己学習しながらでした。ただ、その中でも、様々な書籍を読むことで、著者が体験して習得したこを学んだ部分は大きいです※3。

※3 私自身にとって、もっとも衝撃だったのは『Effective Java プログラミング言語ガイド』でした。

最初からきちんとしたAPIを作成できるようにはなりませんが、優れたAPIを作成するために、様々な学習を続けて実践していくことがソフトウェアエンジニアには求められると思います。「サラリーマンエンジニア」であれば、API設計に必要な書籍を読むことなく、悪いAPIを伝染させたり、APIを改悪していくことになります。