開発の台所事情を隠すと後が面倒だと思う件について

何度か、組み込み系の案件で「もしもエラーがあっても、お客さんにわかりにくいようにせよ」という指針が出されることがあります。

「あれ？　あれ？　うーん、とりあえずリセットしてみよ。あ、なおった」ということを期待するのは、出荷台数が多く、環境が多彩で、異常が致命的な事故にならないような機器なら、正直なところ妥当なケースもあるでしょう。

しかし、わかりにくいようにせよ、ってどうやるんでしょう。だぶんエラーダイアログ出したり、システムリセットしたりするな、ってことなんでしょうけど、エラー処理を書かない、という方向に突き進む勇者たちがいます。だいたい、いくつか後のフェイズで原因不明の異常が発生して、調査に日数をかけ、幸い原因がわかったとしても、どう対処したものか疲れ果てた頭で考える姿が目に浮かびます。

基本的に、

• 自分以外から受け取るもの（メソッドの引数とか、呼び出したメソッドから得たデータ）が想定外のものでないかチェックして、アウトならログしてエラーリターン。（早めに門前払い）
• 処理結果が NG かどうかは result == NGでなく、 result != OK でチェックする。（自分を異常だと言えるうちは想定内の異常）
• 客観的事実をログする。「○○データ取得失敗」じゃなくて「ObjectA.methodX() result!=OK」みたく。（ログに裏切られるとかなり辛い）

これぐらいやるだけで、わりと早いフェイズで色々見つかると思うんですけどね。出荷チェック用のビルドを作るまでは、できるだけエラーがバレやすい状態にしたほうがいい。

というベタなネタって割と見たことがないような気がしたので、とりあえず書いてみました。