読者です 読者をやめる 読者になる 読者になる

@hanadix REBOOTED

音楽好き(聴く書く演る)なイット系労働者の日常と妄想

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

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

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

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

基本的に、

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

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

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