「APIデザインの極意」のメモ

「APIデザインの極意」の感想Blogがとても素晴らしいのでメモ。
「APIデザインの極意」を買おうと思ったら、台風で警報が出ており、買いに行けないのが残念。
ラフなメモ書き。

【元ネタ】
アジャイルAPI設計時代の到来！？APIデザインの極意を読みました。 - シスアーキ in はてな

ソフトウェア再利用の概念: プログラマの思索

ソフトウェア部品化の幻想: プログラマの思索

SIerの俺様フレームワークは最悪に激しく同意: プログラマの思索

【1】ソフトウェア再利用の概念としては、ホワイトボックス再利用、ブラックボックス再利用の2種類の区別がある。

ブラックボックス再利用とは、再利用資産を変更なしでその まま利用する。
よくある例は、GUIコンポーネントや数値演算ライブラリなど。
例えば、DLL、Jar、Exeなどのバイナリの実行ファイルが相当するだろう。

ホワイトボックス再利用とは、再利用資産を要求に合わせて部分的に変更して使用する。
よくある例は、オブジェクト指向設計によるフレームワークなど。
例えば、Struts、Hibernate、Rails、Playなどの有名フレームワークが相当するだろう。

2000年代初頭の頃までは、コンポーネント指向開発が今後進むべき道だ、と言われていた。
オブジェクトを再利用資産として持ち、その資産を触らず、接着剤の部分だけソースを書けばよい、と。

【2】しかし、実際は、再利用できる部品を作り出すのが難しい。
再利用できる部品になるような設計が難しいのだ。
実際は、部品そのものに手を入れてしまい、中身はスパゲティコードになり、破たんする。
ソフトウェアプロダクトラインも、ドメインから再利用できる概念をコア資産として抽出しようとしたが、開発コストがかかり過ぎる割には、効果が薄いという評価が多い。

最近の傾向としては、フレームワークを使った開発手法を取るのが多い。
受託開発では、アーキテクチャ設計時に、どのフレームワークを採用するか、という決断が大きなウェートを占める。
良いフレームワークを採用すれば、開発効率や品質を担保できるし、知名度が高ければ、開発者の要員確保も楽になる。
その後の保守もやりやすいはず。

特に、Webシステム開発では、工期短縮のために、その時に有名なフレームワークを採用して、一気に作り上げる開発スタイルが多いと思う。

【3】しかし、フレームワークの利用にも癖がある。
SIerの俺様フレームワークは最悪に激しく同意: プログラマの思索にも書いたが、大手SI独自のフレームワークを作りこんだ場合、保守が非常に大変だ。

俺様フレームワークはなので、中身が公開されていないので自分たちでパッチを当てることもできない。
フレームワークの修正を依頼しても拒否されたら、仕方なく、非常にダーティなパッチを当てて、その場限りの障害再現の回避を取らざるを得ない。
そんなことをしていくうちに、本番稼働中のソースを修正するのは忘れ去られて、ソースがどんどん汚くなる。

しかも、フレームワークのバージョンアップに追随できなくなる。
パッチを当てた箇所に影響が出るかもしれないから。
つまり、フレームワークのバージョンアップのたびに回帰テストの工数が増えて、顧客から見れば、何の価値も生まないバージョンアップに多大なコストを強いる。

【4】「APIデザインの極意」では、外部公開されるAPIのプログラミングに力点を置いて、そのノウハウが書かれているらしい。
内容を推測すると、ブラックボックス再利用の観点と思われるが、ホワイトボックス再利用の観点でも役立つだろう。

APIで思いつく例としては、SOAやWebサービスが思いつく。
よくある例は、クレジット会社が提供するクレジットカード支払いサービスがあるだろう。
カード支払いサービスのAPIを使えば、ECサイトの支払方法でカード支払いのロジックを作りこむ必要がなくなる。
特に、カード支払いサービスの利用事例が多いほど、パフォーマンスや品質も枯れていると推測できるから、下手に自分たちで作りこんで本番障害を発生させるよりも楽だ。
最近は、カード情報のような個人情報を自社で資産として持つ危険性の方が高いので、外部サービスを使った方がリスクが減るメリットもある。

アジャイルAPI設計時代の到来！？APIデザインの極意を読みました。 - シスアーキ in はてなを読んで、僕が、なるほどと思った点は以下の通り。

・APIの後方互換性の担保が重要。
　APIを長持ちさせるには、ソース互換性、バイナリ互換性、特に機能互換性が重要。

・APIが後方互換性を維持しながら健全に発展できる為の具体的な手法の一つとして「不変型を指定するためにJavaインタフェースを使用する」「メソッドを安全に追加できる型としてfinalクラスを使用する」

・Decoratorパターンは問題になりやすい。
　APIは使用者向けと提供者（サービスプロバイダー）向けに分けて提供する。

・テストをサポートするテストAPI、テスト互換性キットは、仕様書の代わりになる。
　APIの後方互換性の維持のために非常に役立つ。

・今後APIはより、宣言型プログラミングや関数型プログラミングに向いて進化する

APIに関する実際のノウハウが公開されているのは興味深い。