ポステルの頑健性原則に関する事例
仕事でバイナリデータをCSV形式に変換するデータコンバートツールを作った時のことだ。
コンバートツールのテスト項目に、
「データ変換に関係ない部分のデータが異常でも動作を停止しない。」
というのがあって、これが客の目にとまり、気に入らなかったらしく、
「データ変換に関係ない部分の異常でもチェックして、変換が中止されるようにしてほしい。」
という要求があった。
内心、「変換データに関係ないのなら、チェックしなくてもいいのでは？」とおもいつつ仕様を変更し、テスト項目も追加した。
で、実際にサンプルデータを変換してみたら、バイナリデータを生成する側のメモリクリアが不十分で、変換に関係ない部分にゴミデータが混じっていた。その結果、私が作ったコンバートツールはデータ変換の途中で止まってしまった。
この事例は、ポステルの頑健性原則
TCP の実装は，頑健性の一般原則に従うものとする： 己のなすことには慎重たれ，他人のなすことには寛容たれ。
を破ったため、起こったのではないか？
データ変換に関係ない部分まで厳密にチェックしてしまったため、頑健性が無くなってしまったのだ。
ポステルの頑健性原則は，一見すると「世の中をうまく動かすための真理」のように思えるが，実は問題の原因を内包した原則でもある。誤りを許容するという体質は，誤りの発見の機会を減らし，いずれ誤りをスタンダード化させてしまうというリスクを抱えている。究極に寛容なマークアップ言語であるところの HTML が，非常に扱いの難しい言語となってしまっていることを考えれば分かりやすいかもしれない。
と述べられているように、ポステルの頑健性が万能でない事も示している。厳密なチェックを行わなければ、バイナリデータの生成側のメモリクリアが不十分な事に気づかなかったのだ。
最終的には、オプションでその動作を切り替えられるようにしたのだが、はたして、変換に関係のないゴミデータの有無まで厳密にチェックする必要があったのかどうか、機能の追加やテストにかかった時間は本当に必要だったのだろうか。
当時は転職後間もないこともあり、穏健に行動していたのだが、それではエンジニアとしてちゃんと役に立っていると言えない場合もあると言うことを実感した事例だった。
