これは正当なツールですか、それとも最終的には不要になる松葉杖ですか?
更新：操作の順序で、つまり：
- アプリを起動
- 読み取り設定
- 設定から値を計算する
- 環境設定をファイルに書き込む...
現在、プログラム フローの視覚化に問題がある場合は、メソッド レベルとアプリ レベルで図を描いています。
3290 次
8 に答える
9
文字通り「フローチャート」を意味する場合は、
いいえ、経験豊富なプログラマーはフローチャートを使用せず、データフロー図、アクション図、シーケンス図、ユースケースなどを使用します。フローチャートは 1970 年代に人気を失い、設計ツールとしては役に立たないことが実証研究* でほぼ実証されました。
- たとえば、アルゴリズムのグラフィカル表現の実証研究の調査を参照してください。
...GRA の実証研究は、主にフローチャートに焦点を当てており、これらの研究の結果は、理解を助けるものとしてのその有効性が疑わしいことを示しています。
「ダイアグラム」だけを意味する場合は、
はい、もちろんです。視覚的な比喩は便利なツールです。
于 2009-06-28T05:06:11.040 に答える
3
フロー チャートは、昔ながらのhttp://en.wikipedia.org/wiki/Flowchartと同様に、 発明された時点では悪い考えでしたが、今でも悪い考えです。
良くも悪くも、それらを使っているプログラマーを私は知りません。物事をより明確にすることができる問題は些細なものであり、些細ではない問題は、フローチャートによって理解されるのではなく、理解しにくくなるという点で、それらは役に立ちません。私は、プログラミング用の形式化された描画システムは時間の無駄だとまで言っています。確かに、ホワイトボードや鉛筆と紙でいくつかのスケッチを作成することはできますが、これを超える (たとえば、visio、私はあなたのばかを見ています) のは時間の無駄です。
于 2009-06-28T04:59:21.080 に答える
1
ふと頭に浮かんだのは、主にビジネス アナリストが関与するときと、主に仕様が策定されているときのフローチャートです。
技術者以外の人と作業する場合、これはデータ/情報の流れをモデル化する便利な方法です。
そうそう: それらはほとんどの場合非常に単純です (少なくとも良いものは)。一握り以上の多角形と線を含む単一のフローチャートでは、人を失い始めます.
于 2009-06-28T04:37:36.317 に答える
1
私の意見では、メソッドまたは式レベルで作業する場合、フローチャートは通常やり過ぎです。ただし、学習や、アプリケーションの幅広い制御フローを理解するのに役立ちます。
それらが便利だと思うなら、使わない理由はありません。
于 2009-06-28T04:39:29.000 に答える
0
私はコードからドキュメントを生成しようとしていますが、その逆ではありません。
私は通常、それをコーディングして、要件を満たすまで修正し、コード内または生成されたドキュメントを作成します。
私の現在のシステム (ほぼ完全に SQL ベース) では、システム内のプロセスはテーブルにあり、メタデータはシステム メタデータまたは管理している補助テーブルから抽出されます。フロー ダイアグラムは、MSAGL を使用してこれらの依存関係から生成されます。ダイアグラムは、インタラクティブなダッシュボードとしても機能します。
于 2009-06-28T04:37:26.660 に答える
0
プロセス フローの複雑さによって異なります。情報の流れやワークフローを視覚的に表示するためのツールです。それが簡単なら、ぜひ頭の中で実行してください。私は通常、(これを14年間行った後でも) コード設計中に一目でわかるようにすると、正しい順序でプロセスに集中し続けるのに役立ちます。
于 2009-06-28T04:50:27.860 に答える
0
私が描くものはたくさんありますが、抽象化を理解する私の能力次第です。それを松葉杖としてではなく、必要なツールとして考えないでください。あなたの能力は他の人とは異なります。他の誰も使用していなくても、エンジニアになるのに役立つツールを使用したことで自分を責めないでください。
しかし重要なことは、常により良い方法を探していることです。
于 2009-06-28T04:35:27.920 に答える
-1
私は常にフローチャートを使用して、操作の順序を計画しています。
「プログラムの全体的なデータフロー」という意味で「操作の順序」を意味する場合、フローチャートは絶対に必要です。誰もがコピーを持っている特定の図があり、それらは非常に重要/一般的であるため、オフィス中のホワイトボードで見られます。たとえば、「アプリケーションからのデータは、UDP ヘッダーを使用してカプセル化され、IP 層に移動し、そこでヘッダーが追加されます...」を説明する図です。
「このコードはどのように機能するか」という意味で「操作の順序」を意味する場合、そうです-フローチャートはそこでも絶対に役立ちます。「このルーチンで最初に行うことは、チェックサムを計算することです。次に、ポインターを次のルーチンに渡し、タイマーを設定します。タイマーのコールバック関数は...」
式の数学的評価として「操作の順序」を意味する場合、これは、誰かのコードを理解しようとするとき、または独自のアルゴリズムを作成しようとするときにも重要になる可能性があります。「最初にポインタをインクリメントし、次に値を読み取れるように逆参照します...」または「整数を 32 回右シフトし、1 の存在を確認してから...」これらは、アルゴリズムのフローチャートである場合もあれば、オペレーターのフローチャートである場合もあります。どちらの場合でも、頭の中でコードを解析しなくても、何が起こっているのかを理解するのに役立ちます。
つまり、彼らはまったく松葉杖ではありません。
注意すべき点: 数学的評価では...多くの場合、式が読みにくい場合 (多くのネストされた操作や括弧、逆参照、インクリメント、算術など、さまざまな優先順位の演算子がある場合があります)、ブレークする方がよい場合があります。コードを複数の小さなステップに分割します。そうすれば、計算のロジックと実装を簡単に示すことができます。フローチャートが必要な場合もありますが、コード自体は読みやすくなっています。
最後に、より高度な/経験豊富なプログラマーは、それほど多くのフローチャートを必要としない場合があります。彼らはすでに関連する図を覚えているか、特定の慣用句を認識しているため、論理をよりよく解析できます。まだ開発していない場合は、確実に開発するでしょう。しかし、それまでの間、何かを理解する必要がある場合にフローチャートを使用しない理由はありません。まったく松葉杖ではありません！
于 2009-06-28T04:50:42.230 に答える