フローチャートの作成

フローチャート不要論

以前は、コーディングの前にフローチャートを描き、書いたり消したりしながら揉んで、出来上がった図にしたがってプログラムのソースを書く、という手順が効率がよいと推奨されていました。従来型のたとえばJISに決められているような正統的フローチャートは、その各記号が逐次実行型のプログラムの１行１行に対応させるのが容易で分かりやすかったこともあります。

ところが、イベント・ドリブン型のプログラムになると、チャート表現がややこしくなって、さらにオブジェクト型のプログラムでは、むしろ無理矢理フローチャート化したものはソースコードを読むよりも煩雑になったり、というようなわけで、最近ではフローチャートとプログラミングとの相性が悪くなってしまったようです。
それで、「フローチャートは書かないように」というようなインストラクターの言説も多くみられるようになりました。なるほど、と思います。

しかし、使いようによっては、フローチャートは役に立つ、ということも大いにあります。
最近はいろいろなチャートが工夫され提案されているようで、ＷＥＢ 上に丁寧な紹介がたくさんあがっています。興味のある方は、調べてみてください。

フローチャート活用論

ここでは、プログラムの設計前でのフローチャートではなく、デバッグまたはアップグレイド時でのフローチャートの援用について。
言いたいことは、次の２点。

① ややこしい流れが想定されている場合、フローチャートで表現してみると、冗長な場所、モニターすべきポイントなどを容易に発見できる（という場合がある）。
② プレゼン用のチャートではないので、極端にいえば自分にわかればよい。したがって、既定の規則にとらわれないで、自分なりの表現規則で描けばよい。とくに、矢印の色や形の使い分けなど（ただし、あまり自由奔放にやってしまうと、後で自分にも解読しにくくなるので注意）。

下に例をあげました。

イベントを多用したようなプログラムだと、イベントが別のイベントを呼び出し、さらにもうひとつのイベントを呼び出し、そのイベントが実は大元のイベントであったり、というふうにこんがらがった挙動となる場合があり、変数がどこでいつ書き換えられるのか、期待どおりに走ってもらうためにイベントの実行を抑制するフラグをどこで立てたり降ろしたりすてばよいのか、などという大切なことが、ソースコードをにらんでいただけでは判然としないことがよくあります。
混乱した頭のままで出まかせにソースをいじっていると、下手をすると無限ループにはまってしまうなどということにもなりかねません。

この図の、細かい内容は関係ありません。　・・・が、
色のついた破線の矢印は、イベントの呼び出しを、赤丸はフラグを立てるタイミングを、といった具合に、一応の自己流規則にもとづいて作図してある・・・らしいことを感じとってください。
この図が、不審な挙動を示したバグを退治するのに、大活躍しました。

なんとなく感じをつかんでもらって、自分専用のフローチャートに挑戦していただけますように。

　　　　　祈・健闘

＜追記＞
こんな煩雑なフローチャートをお目にかけて、実はちょっと恥ずかしい気分です。本当は、パズルのような流れにならないように、全体のアーキテクチュアをすっきりさせることに注力することのほうが余程大切なことは論を待ちません。