ID非公開

2021/4/6 12:21

66回答

現在のプログラマーは

補足

コメント有り難うございました。 色々と参考になりました。

ベストアンサー

1

1人がナイス!しています

kkkさんの補足をします。 オブジェクト指向が出現した時に従来のフローチャートが現実的に書けなくなりました。 ファウンデーションクラスとかスケルトンというのですが最初に雛形があり、それを改造する形式がオブジェクト指向では大半です。 オブジェクト指向ってオブジェクト指向が便利というより雛形で簡単にアプリが作れるというメリットが大きいです。 こうなると90%が雛形で10%の改造部分という構造になりフローが書きにくくなりました。

その他の回答(5件)

0

ビジネスロジック自体がややこしい時は書く事もある。 滅多に書かないけどな。

1

書かないですね。 フローチャート自体はJIS規格で標準化はされているんですが、その類の記述法って会社や大学等の組織によりいろんな亜種があったのね。 それじゃぁアカンということでOMGという組織でまとめたのが統一モデリング言語(UML Unified Modeling Language)であり、フローチャートに相当するダイアグラムとしてシーケンス図というのが用いられました。 特にオブジェクト指向という開発が流行した2000年代ごろからはずいぶんと多用されたもので、このころには実務でフローチャートなんて見かける機会もなくなってました。 今はUML自体が下火になってきている感じです。

1人がナイス!しています

ID非公開

質問者2021/4/8 9:23

コメント有り難うございました♪

0

プログラムを書き出す時にってことなら、書かないですね。 よほど複雑な条件などがある場合は、整理のためにテーブル作ったりフローを書いたりはしますけど、ごく稀です。 ちなみに、プログラムの説明としてのドキュメントなんて書くのはほぼ無駄なことです。大体は修正によってプログラムの実態とかけ離れてくるので、信用されません。 そんなことに労力を掛けるくらいなら、クラス名、メソッド名、変数名などを読めば分かるようなプログラムを書くことを心がけた方が、よほど有益です。

0

書きますよ。 まあアプリケーションが複雑化しているので、その動作全てをフローチャート化するという事はないかなと思いますが、要件定義段階で業務フローを確認したり、通信関連の動作、スレッドの動きの設計(これはシーケンス図のほうが多いか)とか、部分部分では普通に書きます。

0

参考に一部を一部を書くことはあっても、正規なドキュメントとしての フローチャートはここ数十年見ていない・・・

ID非公開

質問者2021/4/6 12:41

有り難うございました。 仕様書から フローじゃない形のドキュメントは書くのでしょうか? リストのみ残すのが定番ですか?