最初にプログラミングを始めたとき、私はフローチャート（およびプリンター間隔チャート）に大きく依存していました。COBOLクラスにいる間、フローチャートがインストラクターによってサインオフされるまで、コードを書き始めることができませんでした。当時、私はすべてのフローチャートを作成する必要がありました。

25年後の今日、私は2種類のことだけをフローチャート化しています。ロジックがトリッキーまたは非常に一般的な概念であるすべての大きなステップを適切な順序で定義できるようにするための非常に具体的なアルゴリズム。

私が単に見落としているフローチャートの他のユースケースはありますか？

絶対に。

これまでに行ったことのないものを実装するたびに（そしてアルゴリズムが数ステップ以上かかる）、それをグラフ化します。グラフ化されていない場合よりも、原子レベルで徹底的にソリューション全体を分析する必要があることがわかりました。このプラクティスには3つの大きな利点があることがわかりました。

• アルゴリズム全体を考え抜いたので、「ああがらくた」が減りました。
• システムの残りの部分で発生する可能性のあるノックオンの問題をフラッシュします
• アルゴリズムを他の人に簡単に説明できます

これらを実際に使用する2つの異なる機会は次のとおりです。

• 低（ish）レベルのアルゴリズム。私は非常に具体的な問題に対する非常に具体的な解決策を意味します。通常、実装前にこれらをピアから渡します。
• ユーザーフロー。これを使用してピアを渡すだけでなく、ユーザビリティの専門家にフローを（非常に非技術的な方法で）説明するためにも使用できます。

とはいえ、私はフローチャートを毎日作成していません（そして、たとえそれが終わったとしても、テクニカルデザインドキュメントを書いていない限り、それは一般にホワイトボードセッションです）。

決して

フローチャート-特に25年以上前に実践された-は、はるかに表現力の高いダイアグラム作成技術に取って代わられました（アクションダイアグラム、シーケンスチャート、ステートチャートなどを参照）。

IBM自身の調査では、フローチャートの使用はシステムの設計や実装の品質に影響を与えないことが示されました（ただし、ユーザーや他の開発者とのコミュニケーションにはわずかに役立ちました）[正確なリファレンスはすぐには利用できませんが、James MartinのDiagramming Techniquesアナリストおよびプログラマー向け ]。

1976年の最初のプログラミングクラス以来、古典的なフローチャートを作成していません。また、80年代前半から他の誰も作成していません。フローチャートは、コードがアセンブリ言語であるときにプログラムロジックを伝達するのに役立ちました。1960年代後半までに、アセンブリ言語プログラマは擬似コードを使用していました。最新のオブジェクト指向言語でプログラミングする場合、フローチャートも擬似コードも価値がありません。実装言語で高レベルのコードを書くこともできます。

デザインのアイデアを表現するために、ほとんどが紙でUML図を描くこともありますが、これらの図は議論が終わるまでしか存在しません。また、状態遷移図を時々描画し、それらを実装言語の状態テーブルに変換します。

私はいくつかの理由で常にフローチャートを使用しています。

1. 私の意見では、UMLユースケース図よりも優れています。それらは多くの異なるユースケースとそれらがどのように相互作用するかを反映することができ、ユーザーエクスペリエンスと意思決定をまとめて全体的に良い仕事をします。

2. それらは理解しやすく、より直感的です。あなたの心は最初から最後まで迷路のように自然に矢印に従います。フローチャートを使用して、別のユーザーストーリーの別のフローチャートを終了および参照できます。通常、それらをページ番号付きの本に印刷し、ページをすばやくめくって次のフローチャートに移動できます。

3. それらは普遍的です。ソフトウェアエンジニアリング以外の人はUMLダイアグラムを知っていて理解している人はほとんどいません。UMLダイアグラムでは、フローチャートダイアグラムがユーザーやビジネスアナリストに認識されやすくなっています。私は複雑なユースケースを顧客に伝えようとしますが、彼らは時々理解に苦労し、フローチャートを描いて、彼らが思ったよりもはるかに複雑にしているすべてのニュアンスを最終的に理解する理由を理解します。

フローチャートは、特定の順序で処理を行う必要がある場合に役立ちます。彼らが本当に私の頭に浮かぶのは、どこで決定が下されるかを示し、可能な各決定に道があることを確認することです。これにより、管理者（98％の時間を承認する）が「いいえ」と言った場合、不正な承認が必要なプログラムを作成できなくなりますが、対処する方法がありません。最も一般的なパスが唯一のパスではないことを思い出させてくれます。要件についてユーザーに話すのに役立つのは、たいていの場合、最も一般的な道しか教えてくれないからです。

フローチャートは、非常に構造の悪いコードのリバースエンジニアリングに役立ちます。特にgotoがある場合。ありがたいことに、私は最近多くのgotoに乗ったコードを見ていません。

他の人がエンドユーザーとのコミュニケーションについて述べたように。フローチャートで文書化されたテレビ送信機のスタートアップを並べ替えます。ハードウェアとソフトウェアの人々には共通の仕様がありました。

UMLアクティビティ図とフローチャートは、プロセスまたはアルゴリズムの低から中程度の複雑さを示すのに役立ちます。

ビジネスルールについてビジネスユーザーと通信する場合に非常に優れています。

BPMN 2.0の形式にはバリエーションがあり、ビジネスプロセスモデリングで非常に役立ちます。

一部のBPMNツールは、チャートから実行中のWebアプリケーションを生成できます。

そのため、フローチャートにはまだ場所がありますが、賢明に使用する必要があります。

私はプログラマーではありません。私はハードウェアエンジニアリング技術者です。

少なくとも、使用される論理ブロックを説明するコメントから始めることは理にかなっています。その後、実際のコードでプログラムの骨組みを肉付けします。これは、ストーリーボードで映画の脚本を開始し、その後でアクションの詳細とダイアログに入力するのに似ています。

価値のある努力を慎重に計画すべきではありませんか？ハードウェアの分野では、顧客の要求ドキュメントから始め、ハードウェア仕様ドキュメントを書き、次に回路図を具体化し、ボードレイアウトを作成し、アセンブリドキュメントを作成します。最終製品を作るためのアイデアを思いついたときに、部品をつかみ、はんだ付けするだけではありません。

実際のコーディングを開始する前に、十分な準備作業をせずに15KBまたは15MBプログラムで効率的なコードを作成する方法はわかりません。