フールプルーフとは

どんな操作ミスをしても安全が損なわれず危険な事態を避けるような設計である。
ただしこれはユーザが守られるのであって開発者は守られない。
フールプルーフをプログラミングに導入し開発者の安全を守るための方法を考える。

開発者のリスクは何か

ここで言うリスクは訴訟リスク、損害賠償リスクである。賠償せねばならないようなバグは発生させてはいけない。
また、強いクレームが来る様なバグも避けなければならない。
しかしバグは無くせない。ならばどうすればいいか？

バグの隠蔽

ユーザが見るのは結果である。内部構造は関係ないので計算結果の表示段階で正当性をチェックし表示する。
文字列であれば、文字化けは絶対避けねばならないし、数値なら範囲チェックが必要である。
ユーザがそれがソフトの異常どころか品質に疑問を抱くような表示は絶対に避けるべきである。
内部構造がどんなにバグっていても表示段階で空文字や0にでも置き換えれば最悪の事態は避けられる。
ユーザに簡単なミスと誤認識させることが出来ればリスクは下がる。
例外やら何やらが表示されるような状態は問題外である。

表示を先行させる

ユーザの目に付く表示部が重要であるため、先に表示部を作り内部構造なんて捨てて入力と出力が繋がる状態を実現した方がよい。
先に内部構造を作った所で表示部分が無いなら単体テストもやりにくいし、バグを発見しにくいこともある。

ファジーな設計

ファジーと言う言葉が死語になって久しいが、プログラムはファジーである方がよい。
ごちゃごちゃした設定が必要なんて時間の無駄である。
デフォルトでなんかよさげな表示をするように設計しておくと、後半は凄く楽である。
何もしなくてもよさげな結果が出せるプログラムこそ求めるものである。
そして、良くない結果に対して蓋をして見せないようにするのである。

操作制限

ここがホントのフールプルーフだが、実際は未定義状態であることが多い。
そのため、入力制限をどうするかを事前に文書化しておかないと1円60万株とか困ったことになる。
あれは取り消しが出来ないことが問題だったけど、入力自体をどうにか制限すべきだったろう。
最悪の事態に対してどうするかを協議して決めておくしかリスクを回避する方法は無い。

フールプルーフプログラミング

バグの隠蔽やファジーな設計でリスクの無いプログラミングをしよう。