行き当たりばったりで始める
大企業はどうなのか知らんが- フローチャートは運用手順とかでしかつかわん
プログラムのフローチャート書くなら詳細作ったほうが早いわ - 大企業は協力会社に書かせるから
- HCPチャートこそが至高
あれに比べたらフローチャート(笑)はもちろんUMLなどすらゴミに見える少なくとも「アルゴリズム」を書くならHCP以上に優れた記法はない
データ構造等は弱いが - >>4
まあコンパクトに書けるのはいいよね
細かいように見えて実はわりと大きな要素 - 書かんわな
コードこねくり回しながら頭の中で出来てる - 他の人に説明する機会とかないの？
- うわぁこのスレ高給取りたくさんいそう……抱いて欲しい
- プログラムの進捗見るのにフローチャート書くけど、お前ら本当に働いてるの?
- >>1
アジャイルだな
>>9
アジャイルだって設計はするんだぜ- >>16
うん。アジャイル形式だったけど、UMLは一応書いたことがある。
そのほうが説明しやすい＋引き継ぎしやすいので。 - 思考の整理で稀に書くくらい
- 中小弱小ですが、
USDMとXDDPで乗り切ります。UMLは、クラス図だけ使う。
あとは、PFDで役割分担しっかり決める位でしょうか - 中小は紙とペン使って書く
- そんなのつくる工数もらえないからな
安けりゃなんでもいいっていう客が多すぎ - 凝り固まったシステム開発をまだやってるところはフローチャートをがっつり書かないとコーディングできないのかもな
プロトタイプをサクッと作ってから文書に起こして漏れや穴を精査したほうがずっとスピードが速い - 企画からリリースまで全部一人でやるから何の文書もないわ
どうせ誰もダウンロードしてくれないし、そもそも趣味の話だけど - 中小どころか零細の一人SEみたいのになると
そもそもチームで作業することがないからフローチャートどころかコメントすらろくに書かなくなる - 書かない 裏紙にメモ程度には書くけど
ドキュメントを納品しろだと？ソースがドキュメントだ！ドン！ - フローチャートだとオブジェクト指向言語に適用するの難しいでしょ。
関数にオブジェクト返してもらって、ポリモルフィズムでその先の動きが
同名メソッドなのに全然違うとかさ。 - 処理全体の流れのフローなんかはばかばかしくて書かないけど
並列処理の同期制御の検証に必要だからシーケンス図は書くぞ - 箇条書きが至高
フローチャートなんて客先説明以外は使えない - 未完成だろうととにかくブツを納入先の人に見てもらって「そーそーこんな感じよｗ」って了解を取るのが無茶苦茶大きいからな
待たせまくってやっと出来たものをいきなり見せて「なんじゃこりゃあああああ」になるのを防げる
これはクライアントに近いポジションの人間ほど持つ感覚かも - 外資もフローチャートとかは書かないな
POCの前にシーケンス図みたいなのは書く - フロー的な図を書くとしたら、プログラム内部の制御の説明より、
運用や操作手順の説明といった外的な仕様の検討資料、マニュアル用素材やないかな - シーケンス図の方が描くこと多いけどアクティビティ図もたまに描くよ
- 結局コード読んだ方が早いでしょってなっちゃうな…
- クソ細かいことばかり書いてるか、大きな流れ書くかで普段の担当範囲が分かる
- フローチャートとか手間の割に見返りが殆どない
- 複数入り乱れる非同期処理とかイベント駆動のやつとかフローチャートでかけないよ
- そろそろ長くなったな
オブジェクト化しとくかって感じだからな現代においてフローは意味がない
- ソースコードを全部日本語に書き直してるだけじゃね
- システム全体のざっくりしたものは書くけど
細かいものは書かないだろ - 色んな新しいサービスとかライブラリ使おうとして、
きっちり設計しようとする所なんなの、馬鹿なの。
さっさと動かして調査検証しろよ。 - 発注元から要求されないの？
- 最近はどんなに設計してもAPIとかのほうがドキュメントに書いてなくて確かめてね？仕様だからプログラミングしない設計はありえん
- 一部の難解なロジックのところか概略の部分でしかフローチャート書かない
障害発生したcocoaのリスク評価の所みたいな値処理が後の動作に関係するはフローチャートにおこしとくべき
- >>1
でもお前無職童貞引きこもりのハゲ散らかしてる子供部屋おじさんじゃん - なんか自分のイメージ用に手書きで書く
そのままどっかいく - 何も書かんよ
実装して終わりや - まずは日本語の文章で書けよ
中小企業のプログラマーだとフローチャートなんて書かないよな
嫌儲
コメント