アローチャートとプログラミング　Vol.4

広報部＠なおです。

ブログを担当させていただいて、もう4回目になります。
読み飽きた！という方、もう少々お付き合いください。
あと数回続く予定です^^

今回はアローチャートでは疾患にあたるのでしょうか。
バグについて書いていきたいと思います。

ニーズを探すこともアローチャートでは大きな要素になりますよね。
プログラミングにおけるニーズは、プログラムを発注した人の頭の中から仕様書という形で先に出てきてしまいます。

と、これでは話が全く進みません。
プログラミングをしていく中で、プログラマーが予期しない動き（バグ）が起こることがあります。
このバグ修正は「本当は出るべきものではありませんが」重要な作業になります。

第2回に投稿した際のフローチャートでご飯を炊くというプログラムの流れをご紹介しました。
ご飯を3合炊きますよ！という指令を与えて、普通に動くプログラムでも、5.5合のご飯を炊きますよ！という指示に対応しているとは限りません。
整数でしかご飯の量を考えていなかったとします。
プログラムでは0.5合という単位を考えていなかったわけですね。

この場合、プログラミングされていない内容を指示されたわけですから、人間と違って応用が利かないのが機械です。
どのような動きをするのか全く想像がつかないのが現実となるわけです。
もちろん、プログラマーは作っている段階でこのバグには気づかず、テストの段階で気づくことになります。
5合まできちんとお米を用意してから固まるのか、最初から動かないのか、もしくは止まらなくなるのか…。
このバグを修正するのは、仕様書などで与えられたニーズではなく、プログラムを作っていく途中で出てくるニーズということになるでしょうか。

アローチャートでも「疾患にはニーズがある」とされています。
プログラミングでも同じように、バグという疾患にはニーズが出てくることになりますね。
その疾患が治れば、ニーズは解決されていきます。
ここも同じですね♪

フローチャートに関しては第2回の投稿をご覧ください。

アローチャートでもフローチャートでも、チェックをしなければならない場所というのは決まってくるものかもしれません。
その過程は同じものではありませんが。
ニーズに向き合っていく、解決するためにはどうするか考える…
疾患という本人が意図しない事柄に対して、どのように対処したらいいのか。
大切なことは変わらないようです。

では今回はこの辺で終了します♪

次回もお楽しみに！

（投稿：広報部＠なお）