フローチャートは基本、基本を大事にしようね。
でっかい分岐が出来て、処理の最後の方で合流するとかはやっちゃダメだよっていってもその理由を考えようとしてもくれなかったりします。まあ、メモリも潤沢にある環境でプログラムを考えるとどうでもいいことなのかもしれないけれども、そういう小さな積み重ねが色々な問題に発展するし、業務の一番表面的な、つまり仕様どおり書いていればいいところを作れるようにはなりますが、仕掛けの部分なんて作らせられません。
——-
フローチャートをきっちり仕上げてくる人は、その先でシンプルできれいなコードを書いてくれることが多いです。そして、慣れてくればフローチャートなんて書かなくてもコードがシンプルに構造化されていくものなのです。
引用元:フローチャートとFizzBuzz問題(novtan別館)
この人の言ってることは正しいし、常識的である。
人間はフローチャートのようには考えない
結局のところ、なぜフローチャートが駄目かといえばこれに尽きる。人間の発想は、フローチャートほど簡単ではない。せっかくプログラミング言語がそれに追随しているのに、わざわざフローチャートを使ってそれをダウングレードするのは、極上のトロをツナ缶にしてしまうようなものだ。
——–
しかし、それは「すでに出来上がったプログラムの概要を説明するため」のものであって、「仕様をプログラムにする」ためであってはならない。フローチャートはプログラムを書いた後に書くものなのだ。プログラムを書く前のものではなくて。
引用元:フローチャートがダメな3つの理由(404 Blog Not Found)
言語特性があるので、プログラム言語を想定しないでフローチャートをかくというのは無理があることは認めよう。で、たいていの人は、頭の中でフローチャートを書いてそれをそのままプログラム言語に落としこめるので、一見、フローチャートと言うものが必要ないように思うだけ。弾氏の記事を読むプログラムのできない人たちは、ますますできなくなると思うよ。それ、わざとですか?たとえば、UMLとかも設計時にやっぱりそれなりに書かないとプログラム構造とか作れないので書くけど、それとは別に、完成したプログラムソースからUMLを自動生成している。設計時のUMLは概要みたいなもの。完成したプログラムソースからUMLは、本当に詳細なものだということだけ。UMLってなにというとフローチャートに似たようなもの。
たとえばPerlでテキスト処理を書くとしたら、正規表現とかつかえるので、そのようなフローチャートを頭にかいてコードに落とすでしょう。決して、人間の自由な発想をコードにおとしてるわけではありません。Perlという制限のかかった世界にむりやり人間の思考をあわせていると言うほうが正しいと思う。
最近の若者が作るソースはひどい。構造化ができてない。たぶん、フローチャート的な考え方が存在しないのだろう。オブジェクト指向とかそういう以前の問題で、NG。
情報源
関連記事
http://d.hatena.ne.jp/scinfaxi/20080720
![]() |
UMLモデリングレッスン 21の基本パターンでわかる要求モデルの作り方 平澤 章 |














