プログラムの前に、設計図（フローチャート）を見ていきましょう。
私は、もう10年くらいフローチャートを書いていないし、見るのさえ何年ぶりになるだろうか。 世の中に、まだ、goto文と同様に諸悪の根源とされているフローチャートを業務に使っている職場 が存在していたとは恐ろしいことです。私の知っている限り、プログラム開発現場の第一線で活躍 している人たちは、もう誰もフローチャートは使っていません。早く使用中止にしたほうが良いの ではないでしょうか。フローチャートは、「ソフトウェア考古学」の対象であり、情報処理技術者 試験の中にだけ今だに残っているものです。
設計技法、開発技法の本はいっぱい出版されています。フローチャート以外の方法について、概 略で十分ですから、何か適当な本を読んでおくことは重要です。
では、発掘にかかるとしましょう。
 図３−１ |
 図３−２ |
 図３−３ |
 図３−４ |
 図３−５ |
送られてきたフローチャートが図３−１〜図３−５です。main関数だけで、Ａ４用紙５枚も書か れていました。素晴らしい努力とほめたいところですが、ほとんど意味不明の図です。
まず、フローチャートの記号の規則に従っていないので、見る者に誤解を与えてしまいます。他 のページに続く記号にプリントアウト記号を使っては絶対いけません。図３−１を見る限り、どう しても、このプログラムは、図２、図３、図４、図５のいずれかの図を条件により印字するものと 思ってしまいます。実際は、「この部分の処理は別の図２に書いています」という意味だったので す。これが分かった時にはショックを受けてしまいました。
フローチャートなど書かなくて良いと思いますが、書く以上は、世の中で通じる書き方にしない といけません。
フローチャートに、代入文とかをいちいち書くものではありません。それでは、プログラム設計 ではなく、コーディングをフローチャートを使ってしているだけです。これはフローチャート以前 のことで、そもそもプログラム設計とは何かということが理解できていないようです。
設計とは、目的の処理をどうやって実現するか、どう関数に分解するかなどの「意図」や「全体 の流れ」を書きあげるものです。
送られてきたフローチャートの図３−２〜図３−５は、まるでコピーして、ホワイトでちょっと 修正すれば作れてしまうのではないかと思われる代物です。ほとんど同じものを手書きで書いてし まうという神経には恐れ入ります。私のように横着しようといつも考えている人間には想像もつか ない行動です。（「気合い」でやりぬく「努力型」ということに納得できてしまいます。しかし、 ソフトウェア技術者としては、最悪のパターンといえます。）ほとんど同じということは、関数に して、引数をちょっと工夫することで実現できるはずです。
それに、mainのフローチャートが用紙５枚になってしまうこと自体、異常なことです。１枚で説 明しきれないほど複雑ならば、もっと小さな単位に分割することを考えるべきです。「設計とは細 分化の作業」です。いかに細分化するかが腕の見せどころです。したがって、このプログラムのよ うに細分化されていないものは、それだけで悪いプログラムといえます。
フローチャートは禁止しましょう。フローチャートは制御の流れを「もろ」に書けてしまうので 良くありません。プログラムは、データを処理するためにあり、データの違いによって制御の流れ が変更されます。あくまでも、データが主体です。変数、引数などのデータをどう定義するかで、 プログラムの組易さは大幅に改良されます。データ構造がどうなっているかの図の方が、フローチャー トよりはるかに役立ちます。データの意味だけはしっかり書きましょう。
ナンプレ問題
自動生成
これで、今日から
貴方もパズル作家
