API: 「使いやすさ」対「誤用しにくさ」

Linux カーネル開発者 Rusty Russell のブログより、API 設計・開発における考え方について書いた記事を翻訳しました。

Original Title	APIs: "Easy to Use" vs "Hard to Misuse"
Author	Rusty Russell
Japanese Translator	Sho Shimauchi
Original Document URL	http://ozlabs.org/~rusty/index.cgi/tech/2008-03-18.html

使いやすく作ることは、API の設計における基本的な目的である。自分に使いやすく、一年後の自分に使いやすく、他の人に使いやすくすることである。それを前提としよう。

いくつもの目的が「使いやすい」ことと対立するが、最も扱いが難しいのは誤用しにくいことという要件である。扱いの容易さはユーザを惹きつける、しかし誤用の困難さはユーザを生き残らせるのだ。

この概念をはっきりとさせるため、実生活における2つの例を挙げよう。一つ目は銃の安全装置である。誤用しにくさは使いやすさを駆逐する。

2つ目の例は Linux カーネルの kmalloc 動的メモリ割り当て関数である。この関数は2つの引数をとる。サイズとフラグである。最も一般的に使われるフラグ引数は GFP_KERNEL と GFP_ATOMIC だ。この例では他のフラグは考えないものとする。

このフラグは突然メモリが枯渇したときにアロケータがどうすべきかを示す。メモリが解放される、あるいはスワップアウトされるまで待つ(スリープする)べきか(GFP_KERNEL)、即座に NULL を返すかだ(GFP_ATOMIC)。しかしこのフラグは完全に冗長である。kmalloc() は自身でスリープ可能かどうか把握できるからだ。malloc() を実装するのに何も頭を使う必要はないし、カーネルコーダーにとっては普通は使いやすいだろう。ならなぜ使わないのか？(訂正:Jon Corbet が特定の設定においてはこれは全くの冗長というわけではないことを指摘してくれた。我々はもう数行余分な仕事をする必要がありそうだ。)

なぜならアトミックな割り当ては避けるべきだからだ。有限の領域から取り出すので、失敗しやすくなるか他のアトミックな割り当てを失敗させやすくなるだろう。こうした仕様を作者に明記させることで、我々はアトミックな割り当てを発見することが容易になり、そのため誤用しにくくなる。

そして我々が API を誤用しにくいように作りたいなら API の得点を測る必要があるが、それは次の記事のテーマとしよう。

This work is licensed under a Creative Commons Attribution 2.5 Australia License.