なぜか信頼されるフローチャート
いや、シーケンス図で良いじゃない。
極論、図とかいらないじゃない。
その一言に集約されることではあるんですが……。
なんてことを言い出す理由の一つとして、資料化されるフローチャートってなぜか機能ごとに分割されてるってことがほぼない。
いやもっと切り分けられるでしょ、って。
例えば通信がいるなら、送るのコレね！
で、受け取るのコレね！
これ受け取ったらこうしてね！
で、良いハズなんですよ。
通信結果のパターンは数種類あるだろうという部分はあるにしても。
それを図表すれば普通にシーケンス図っぽくなるハズ……ハズ！！
それがフローチャートだと、いちいち両方の判定が載ってて結局どうすんのよ、となったり。
両方作る作業者なんてのは滅多にいない訳で、一作業者からすると必要ない情報まで載ってしまう訳で。
それはむこう側の詳細設計書にでも書いとけと言わざるを得ない情報が載ってたりするんですよ。
基本的な思想として、自分が担当してる部分以外の情報というのは本来必要ないノイズな訳です。
そりゃ全体を把握するって意味ではあっても良いんですけどね。
ただそれって間違いなく機能を作成する上で必要ない情報も結構多い。
まあそれ以前に、そもそも中身知っててコード知ってる人以外が書いたフローチャートに一切の説得力がなかったりするという裏事情。
なぜかって、内部的な処理を書いてるわけじゃなくて操作に対するレスポンスという観点で書いてしまってるから。
だから余計なことを書くし想定外のことも起こる。
そしてとりあえずフローチャートを書くことを強要する人に多いのが、言っちゃなんだけど古い世代の人たち。
いやそれ理解度を一定以下のレベルに落として分かった気になりたいだけだろ、と。
実際フローチャート書くことってたまにありますけど、結局意図的に必要な情報抜きまくってなんとなく概要だけ書いたものの方が評価が高い辺りなんというかなんというか。
というかフローチャート状にして全部書くと普通にコード見た方が分かりやすい上にシンプルになるからね、と言わざるを得ない。
というかまともにコメント書く人のコードならコード自体見なくてもコメントだけ読むだけで事足りるという。
まあ、いいや。
結論として、余計なことは書かないことをオススメしたい。
強くオススメしたい。
