フローチャートを書く書かない

Question

元ハード屋です。
先日ＡＳＩＣ設計（半導体設計）の方との話で驚いたことがあります。その方はＣ言語を使いフローチャートは書かずにいきなりコーデングするそうです。
装置物（マイコンでの制御）の設計を10年位前にしていましたが、その時一緒に仕事をしてましたソフト屋さんはたしかＣ言語を使い、そして沢山のフローチャートを書いていました。
最近はＣ言語ではフローチャートを書かないのでしょうか。また言語（ＦＯＲＴＲＡＮ、ＣＯＢＯＬ、ＢＡＳＩＣ、、、）或いはやる内容により差があるのでしょうか。私はプログラマーでは有りませんが最近Ｖｉｓｕａｌ　Ｂａｓｉｃで割合大きなプログラムを組みましたが、その時はフローチャートを書きました。あとで変更する時フローチャートが無いと困るだろうと感じています。

Mechirun · Accepted Answer

頭の中で整理できたり、小規模なモノ、動作させながら仕組みが変わる可能性が
ある場合はフローチャートを書かずにすぐに打ち込みするのではないでしょうか？

比較的小さいものはフローチャートを書かずに組ながら考えます。
出来上がってからちゃんとしたフォローチャートを残しますけど。
(プログラムを入力するのは面倒ではなくてもフローチャートを書くのは面倒
という人もいますので。)

caceres · Answer

私もこの十年、書く書かないで変化を感じていますので一言言わせてください。
6800,8080からアセンブラを始めてH8,PIC,SH4,Basic,C,C++,Delphiと今でも現役ですが低位な言語ほどフローは重要と思っています。
アセンブラならほぼ一対一でフロー通りに打ち込めばバグは殆ど無いレベルが可能。　フローをいい加減にすると単純なバグ取りで大幅に時間がかかると思います。
Cでは経験によりライブラリが貯まりますのでそれにより機能ブロックで書くことが多くなりました。
WindowsアプリではユーザーIFは仕様書に近いレベルとしハードアクセスやシーケンス、時分割動作などは仕組みに納得がいくまで紙で表現してからコーティングしています。
25年前のアセンブラ、コンパイル時間と比較すると相当な差がありますがその分作業も増えていますのでやはり一言で説明できないような処理をフローなど書かないでいきなり打ち込んでいくのは複雑なシステムになるほど危険度が高くなるでしょう。
部下や学生に指導する機会があったときは「わからなくなったら紙に書きなさい」と言っています。
脳内思考で見渡せないときは既に能力のオーバーフローBitが立っていますのでブロック図やシーケンスチャート見直すことで道が開けてくると思っています。
ですから言語やシステムによる違いがあると思いますが教育や業務であるなら間違いなく何が目的か理解できるようなソース以外の表現が必要と思います。

kokorone · Answer

#5です。
規模が小さければ、モジュール単位で、
何をしているか、またＩ／Ｆの詳細など
書けば、こと足りると思います。

言語の知識と、ある程度の設計書があれば、
ディーテールフローがなくても、別の人が
メンテするのも、可能と思われます。
－－－－－－－－－－－－－－－－－－
先日のニュースで、金融系企業で現行のシステム
をメンテナンスしようとしたところ、現在のＳＥ、
ＰＧでは、当時の設計書が理解できないため、現
行のシステムに変る新しいシステム開発に着手し
たと言っていました。

kokorone · Answer

いまは、現場を離れたＳＥです。
お客様と契約する際、納品物を明記します。
その中で、フローがあれば、当然書きますし、
フロー作成の時間もスケジューリングし、契約
見積りを立てます。
お客様によっては、機能仕様書・外部設計書（
モジュール構成）・内部設計書（詳細設計書）・
ソースコードのレビューを要求されるケースも
あります。

また、ソフト業界では、ＩＳＯを取得するところ
も、増えたため、品質管理の一環としても、ドキ
ュメントの作成フェーズは、重要視されてきてい
と思います。

0x131cc6e · Answer

言語に関わらず、ソースコードと１対１になっているような詳細なフローチャートは書かないですね。
機能単位でのフローは書きますが。
あと、家にいてPCが手もとにない時にふとアイデアが浮かんだりすると裏紙にグリグリ書いて形にする、というのもあります。
いずれにせよフルには書かないです。
理由は、
１、実装速度
２、プログラマとコーダが同一人物であること（＝僕なんですが：笑）
３、メンテナンスも同一人物であること
といったところです。
要するに後の事を考慮できるほど金額的にも納期的にも余裕が無い場合が多い、って事かな。トホホ…

ただ、コーディングと同じレベル（やスピード）でフローチャートが書けるならやった方が絶対いいと思います。
机上でロジックが完成してあとは打ち込むだけ…。
素晴らしい。僕もそうありたいです。

OsieteG00 · Answer

外部設計などでDFDを書くことはありますが、プログラムレベルの内部設計でフローチャートを書く事はないですね。

モジュールレベルで詳細に設計しておいて、状態遷移図を記入するぐらいでしょうか。


RAD用のツールでPADを定義してソースを生成するものがありましたが。

gtamo2 · Answer

最近はＣＯＢＯＬとＳＱＬを使っている、一般的なソフト開発者です。ホストの経験、ＰＬ／Ｉ、ＶＢＳ等あります。

最近フローを書いた記憶がありません。要件定義から始まって機能設計書を書くまでの段階で、機能をバラバラにしてしまい、一つ一つのモジュールをフローを書くまでもないくらいの単機能にしてしまいますから。

フローを書かないと分からないようなモジュールを新人に渡しても、どんな物が出来てくるか分かりませんしね、テストもケースばかり増えて効率悪いです。

今の現場ではあまりフローは書きませんよ。

フローチャートを書く書かない

頭の中で整理できたり、小規模なモノ、動作させながら仕組みが変わる可能性が

私もこの十年、書く書かないで変化を感じていますので一言言わせてください。

#5です。

いまは、現場を離れたＳＥです。

言語に関わらず、ソースコードと１対１になっているような詳細なフローチャートは書かないですね。

外部設計などでDFDを書くことはありますが、プログラムレベルの内部設計でフローチャートを書く事はないですね。

最近はＣＯＢＯＬとＳＱＬを使っている、一般的なソフト開発者です。

似たような質問が見つかりました

関連するカテゴリからQ&Aを探す

デイリーランキングこのカテゴリの人気デイリーQ&Aランキング

マンスリーランキングこのカテゴリの人気マンスリーQ&Aランキング