memo.xight.org

・バグは無くならない
・バグを生んだ他人を責めない
・バグを生んでも，見つけてすぐに直せばいい
・バグを見つけやすいように色々な方策を講じよう

  ほとんどのバグはAPIの仕様の理解不足から生じる．
  (ココでのAPIとは「自分以外の人が作ったモノ全て」)

- APIの例

・OSのシステムコール
・低レベルなライブラリ(libcなど)
・X Window Systemライブラリ(Xlib, Xt)
・GNOMEライブラリ(glib, GDK, GTK+, gnome-lib, etc.)
・Win32 API，(Windows)COM
・libapr, libapr-util

- 回避策

・マニュアルを良く読む
・馴染みが薄いAPIの場合，そのAPIの動作だけを確認する小さなコードを書く
・自分の書くコードでは，assert(3)で条件を明示する
・自分の書くコードでは，外部に見せる関数(モジュール境界)に極度に気を使う
  ・公開ヘッダにきちんとコメントをつける
  ・公開ヘッダは保守的にする(仕様はあまり変えず，公開部分も最小限にする)

- 抜本的な解決策

・言語仕様から見直す (ポインタの無い言語にする，など)
・他人の作ったAPIは使わない
・枯れて良く知っている環境に安住して，そこから離れない(POSIXの環境から離れない，など)

- 具体的な例

・そのネットワークAPIはブロックするのかしないのか?
・そのAPIはスレッドセーフか否か?
・APIが返すメモリの所有者は?
・APIに渡すメモリの所有者は?
・(設計に問題があるにせよ)現実的には，呼び出し順序が意味を持つAPI群は多いので，そのコンテキスト依存性は?

- Reference
  Ariel Networks - バグとの付き合い方
  http://dev.ariel-networks.com/blog/?itemid=347
  Ariel Networks - 失敗を恐れない文化 - 産み落とした多くのバグへの鎮魂歌 -
  http://dev.ariel-networks.com/blog/?itemid=50