ゆなこんブログ

ゆなこんぴゅーたー (Yuna Computer) の公式ブログ

プログラムのエラーを早くに出す

プログラミングにおいても小さい失敗を早くに出す

プログラミングのする時に「小さい失敗を早くに出す」という考え方ができていないと、まともなプログラミングはできません。

昨日「小さい失敗を早くに出す」という記事を書きました。

blog.yuna-computer.com

「失敗を0」って考えを持っている(持たされた)人たちは、プログラミングにおいてもこんなことになるようです。

togetter.com

プログラミングにある程度慣れた人から見れば「は?」というレベルの話ですが、これが現実のようです。 「失敗を0」にするために表面的に「取り繕う」わけです。

現実にはエラーは必ず出ますし、大きなエラーを減らすために小さいエラーに対処するのがプログラミングです。 小さいエラーは出ていいのです。小さいエラーが出ることを許容し、小さいエラーに対処しましょう。

エラーは早くに出ればいい

プログラミングにはいくつか段階・過程がありますが、早い段階でエラーが出ればいいです。 最悪なのは本番環境、お客様が使う時になって出るエラーです。

ざっくりとした段階分けをすると

  1. 構想・仕様の決定・設計(デザイン)
  2. コーディング
  3. ビルド(コンパイル・リンク・バンドル)
  4. 実行(テスト。開発環境での動作確認、テストコードによる自動テスト)
  5. 実行(お客様環境での本番)

こんな感じです。

構想・仕様の決定・設計(デザイン)

もし構想・仕様の決定時によく考えて問題を洗い出せていれば、納期予算のバランスをとったり、適切な開発言語を選んだりできます。 ここでのエラーを無視すると、納期で年単位、予算で数百万から数億の損害がでることがあります。

あ、全然関係ありませんが、みずほ銀行の開発現場では炎上が起きているそうですね。

コーディング

最近はコーディング時にエラーを見つけることができるようになりました。 これは Visual Studio などの IDE、あるいはエディタのプラグインなどが、裏でコンパイルあるいは lint してくれているからで、 リアルタイムで文法のミスを直すことができるようになりました。 いちいち手動でコンパイルする手間も減りますし、時間の節約効果がすごいですね。

ビルド(コンパイル・リンク・バンドル)

もちろん手動のコンパイルも大切です。 コーディング時より詳細なエラーが出てくれることもありますし、コンパイラのオプションで警告を表示させることもできます。 基本的に最初からすべての警告も出力する設定にした方がいいですし、さらに警告をエラーとして扱う設定もしておいた方がいいです。 (ただし警告が多すぎると、たいていの人は警告を無視しだします。出すぎないようにする工夫は絶対に必要です。) ここでエラーに対処しておけば、本番環境での実行時エラーを予防できます。

実行(テスト。開発環境での動作確認、テストコードによる自動テスト)

そしてプログラムの実行です。 開発環境あるいはテスト環境ならば、いくらでもエラーが出てかまいません。 プログラミング入門者のうちは、手動で実行して、目で実行結果を確認してもいいかもしれません。 しかし、初心者~上級者は必ずテストコードを書いて自動のテストもします。 テストコードの目的には「エラーを早くに見つける」「エラーを毎回見つける」などたくさんあります。 手動テストだと「エラーを毎回見つける」のは時間的・量的に無理ですし、「エラーを毎回見つける」ことをミスります。

実行(お客様環境での本番)

お客様環境での本番でも「プログラムのエラーを早くに出す」考えは大切です。 よく「エラーを握りつぶす」「例外を握りつぶす」なんていいますが、これは「表面的にエラーを0」にしているだけです。 後で大きなエラーが出るのがオチです。 「後で」だと問題が起きた時から時間が経ちすぎて調査が難航します。 「大きなエラー」だとそりゃ対処が大変です。

(すべてのプログラムでそうあるべきとは言いませんが)基本的に、対処できないエラーが起きたら「必要な通知後、プログラムをすぐさまクラッシュさせる」のが正しいです。 ものすごく大胆に感じられるかもしれません。 達人プログラマーにはそのへんのことが書いてあります。 可能であれば、クラッシュさせる直前にログを取ったり、開発者に何らかの方法でエラー内容を送るなどします。 これによりエラーに早く対処できます。

まとめ

  • エラーをできる限り早く出す
  • 小さいエラーを許容する
  • 小さいエラーに対処する
  • エラーにできる限り早く対処する