学校では、行ごとに書いた小さなプログラムをフローチャートにすることがしばしば必要でした。
それらのフローチャートは、写真のサイズのために非常に大きくなる傾向があり、しばしば描くのが面倒でした.
とにかく本質的にコードを書いていたのは、常に非常に詳細でした。
私はフローチャート/UML スタイルの手法を使用してより高いレベルのものを開発していますが、実際のループに到達すると、やり過ぎのように思えます。
より詳細なアルゴリズムを疑似コーディングすることがよくありますが、それでも非常に細かい点までではありません。
これは、学校では物事が非常に小さかったため、「フローチャート」に他に何もないため、細目を使用する必要があったものの 1 つにすぎませんか?
フローチャート、いいえ --シーケンス図、はい。アイデアをすぐに誰かに伝えるために、私はそれらを非常に高いレベルに保つようにしています. すべての詳細を取り込もうとはしません。重要と思われる場合は、エッジ ケースを示す別の図を補足することがあります。
スケッチとしてのコミュニケーションには最適です -- 仕様には適していないと思います (ただし、詳細なセクションへの導入には適しています)。
実際のコードの ifs と whiles のフロー チャートは (30 年間) 役に立ちませんでした。
要件を引き出すための議論の助けとして...では、ここにいるとき、何が起こるでしょうか? ... どのように判断しますか ... > 95% の場合はどうしますか ... 参考になります。ある種のユーザーは、ホワイトボード上のこのような図が話しやすいと感じます。
正直に言うと、どのような課題にもフローチャートを添付する必要があったことを非常にうれしく思います。彼らは私に構造的に考えさせられました。それは、私に欠けていたものです (そして、おそらく、まだある程度欠けているものです)。
ですから、「グランド ピアノを弾きに行く」という時流にすぐに飛び乗らないでください。フローチャートは実際に機能します。
自明ではない論理に少し縛られていることに気付いたことは一度もありません。紙の上にフローチャート形式でロジックをレイアウトした後 (数分かかります)、必然的にすべてが明らかになります。
ええ、同意します。要点は、フロー チャートを理解してもらうことであり、行ごとのコード カバレッジにフロー チャートを使用する必要があることを意味するものではありません。
正直なところ、本当に低レベルのプログラミングでない限り、デモンストレーション以外の疑似コードで時間を無駄にする理由さえわかりません。
私はそれらを自分で使用しません。しかし、たまにしかプログラミングしない同僚はそうします。これは、彼が 1 年前に書いたプログラムの要点を思い出すのに非常に便利な方法です。彼はあまりプログラミングをしないので、シーケンス図などを学ぶ価値はありません。
また、ほとんどプログラムをしない人でも簡単に読めるタイプのダイアグラムです。彼の立場ではどちらがプラスです。
フローチャートの詳細があまり役に立たないと思います。私は一枚の紙にUMLスタイルの手法を使用しています。グループ設定でホワイトボードを使用します。中間レベルのクラス図とシーケンス図は、アイデアを整理し、設計意図を伝えるのに非常に役立ちます。
プロセスを説明するためにホワイトボードに表示されることもありますが、実際の設計やドキュメントには表示されません。私はいつも形にこだわるわけではないので、それらを「フローチャートのような」ものとして説明します。
TDDは、必要に応じて基本コードに適したオプションであり、他にも多くの利点があります。
有機的に成長した大規模なアプリケーションがあり、ドキュメントがほとんどないため、フローチャートを使用してアプリケーション内のコンポーネントを文書化することは、運用のビジネス面で非常に役立つことが証明されています。
それらは行ごとのレベルではありませんが、ビジネス ロジックのすべての分岐を後続の処理と出力でカバーします (ただし、厳密なフロー チャートの規則には従いません - 一部のブロックは複数のプロセスを記述します)。
かなり複雑なワークフローを持つ社内アプリケーションがあります。フローチャートは、システムのこの部分の仕様の大きな部分を占めています。そうです、フローチャートはシステムを仕様化するための便利なツールです。これらは通常、技術者以外の人にも理解されるため、ユーザー要件の一部である場合に役立ちます。いいえ、通常は非常に低いレベルでそれらを使用することはありませんし、システムの一部がフローチャートによってのみ仕様化または文書化されることも期待しません。