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

質問

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

回答No.1

noname#198951 · ベストアンサー

頭の中で整理できたり、小規模なモノ、動作させながら仕組みが変わる可能性が
ある場合はフローチャートを書かずにすぐに打ち込みするのではないでしょうか？

比較的小さいものはフローチャートを書かずに組ながら考えます。
出来上がってからちゃんとしたフォローチャートを残しますけど。
(プログラムを入力するのは面倒ではなくてもフローチャートを書くのは面倒
という人もいますので。)

お礼

ご回答有難う御座います。

＞比較的小さいものはフローチャートを書かずに組ながら考えます。
　これでしたら良く理解できます。

＞出来上がってからちゃんとしたフォローチャートを残しますけど。
　後でプログラムを見直す時や、特に製作者以外が見る時はフローチャートが無いと理解するのに大変だろうと考えた次第です。

回答No.7

caceres

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

お礼

ご回答有難う御座います。

＞6800,8080からアセンブラを始めて
懐かしいＣＰＵです。私はZ80をよく使ってハード設計をしていました。一緒に仕事をしてましたソフト屋さんからフロチャートが大事だと何度も聞いた記憶があります。

＞脳内思考で見渡せないときは既に能力のオーバーフローBitが立っていますのでブロック図やシーケンスチャート見直すことで道が開けてくると思っています。
　私も同じ考えです。

回答No.6

kokorone

#5です。
規模が小さければ、モジュール単位で、
何をしているか、またＩ／Ｆの詳細など
書けば、こと足りると思います。

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

お礼

再度のご回答有難う御座います。

回答No.5

kokorone

いまは、現場を離れたＳＥです。
お客様と契約する際、納品物を明記します。
その中で、フローがあれば、当然書きますし、
フロー作成の時間もスケジューリングし、契約
見積りを立てます。
お客様によっては、機能仕様書・外部設計書（
モジュール構成）・内部設計書（詳細設計書）・
ソースコードのレビューを要求されるケースも
あります。

また、ソフト業界では、ＩＳＯを取得するところ
も、増えたため、品質管理の一環としても、ドキ
ュメントの作成フェーズは、重要視されてきてい
と思います。

お礼

ご回答有難う御座います。
＞その中で、フローがあれば、当然書きますし、
　お書きになるのですね。
過去の発言を調べてみますと書く人書かない人とも沢山いらっしゃいます。書かない人は規模が小さいかフローチャートに代わる資料が有ると言う事でしょうか。

回答No.4

0x131cc6e

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

ただ、コーディングと同じレベル（やスピード）でフローチャートが書けるならやった方が絶対いいと思います。
机上でロジックが完成してあとは打ち込むだけ…。
素晴らしい。僕もそうありたいです。

お礼

ご回答有難う御座います。

＞言語に関わらず、ソースコードと１対１になっているような詳細なフローチャートは書かないですね。
機能単位でのフローは書きますが。
　これは私もそのようにしています。

＞３、メンテナンスも同一人物であること
　時間が経ちますとどんどん記憶が薄れていきますのでフローチャートを書かない人は後で大変ではないかと思ったのですが大丈夫なのでしょうか。

回答No.3

OsieteG00

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

モジュールレベルで詳細に設計しておいて、状態遷移図を記入するぐらいでしょうか。

RAD用のツールでPADを定義してソースを生成するものがありましたが。

お礼

ご回答有難う御座います。

回答No.2

gtamo2

最近はＣＯＢＯＬとＳＱＬを使っている、一般的なソフト開発者です。ホストの経験、ＰＬ／Ｉ、ＶＢＳ等あります。

最近フローを書いた記憶がありません。要件定義から始まって機能設計書を書くまでの段階で、機能をバラバラにしてしまい、一つ一つのモジュールをフローを書くまでもないくらいの単機能にしてしまいますから。

フローを書かないと分からないようなモジュールを新人に渡しても、どんな物が出来てくるか分かりませんしね、テストもケースばかり増えて効率悪いです。

今の現場ではあまりフローは書きませんよ。

お礼

ご回答有難う御座います。

＞最近フローを書いた記憶がありません。要件定義から始まって機能設計書を書くまでの段階で、
　何時ぐらいから書かなくなったのでしょうか。
製作者以外の人が全体のプログラムの内容を理解するのに要件定義、機能設計書があれば大丈夫と言う事でしょか。