刚开始编程时，我非常依赖流程图（和打印机间距图）。当我在COBOL课堂上时，直到我的流程图被教员批准后，我才能开始编写任何代码。那时，我必须为所有内容制作流程图。

今天，二十五年后，我发现自己只绘制了两种情况。逻辑很棘手的非常具体的算法或非常笼统的概念，以确保我按正确的顺序定义了所有重要步骤。

我只是忽略了流程图的其他用例吗？

绝对。

每当我实现以前没有做过的事情（该算法需要执行多个步骤）时，我都会对其进行规划。我发现，这确实迫使我比未提出解决方案更全面，更彻底地分析整个解决方案。我发现这种做法有三个主要好处：

• 减少“哦胡扯”，因为我已经考虑了整个算法
• 清除整个系统其余部分可能发生的任何潜在故障
• 让我轻松遍历其他人

我实际使用它们的两种不同情况是：

• 低（ish）级别的算法。我的意思是针对非常具体的问题的非常具体的解决方案。在实施之前，我通常会先经过同行。
• 用户流。我不仅可以使用它来传递给同行，还可以使用它（以非常非技术的方式）向可用性专家解释流程。

说了这么多，我不会每天制作流程图（即使完成了流程图，除非我写技术设计文档，否则通常是白板会议）。

决不

流程图-尤其是25年前的实践-已被更具表现力的制图技术所取代（请参阅操作图，序列图，状态图等）。

IBM自己的研究表明，流程图的使用对系统的设计或实现的质量没有影响（尽管它们对于与用户和其他开发人员进行交流而言微不足道）[精确参考资料不易获得，但在James Martin的Diagramming Techniques中被引用。[分析师和程序员 ]。

自1976年上第一堂编程课以来，我还没有绘制过经典的流程图，而且自80年代初以来就再也没有见过其他人创建过这种流程图。当代码使用汇编语言时，流程图对于传达程序逻辑很有用。到1960年代后期，汇编语言程序员开始使用伪代码。用现代的OO语言编程时，流程图和伪代码都没有任何价值。您也可以用实现语言编写高级代码。

我偶尔会绘制UML图（主要是在纸上）来表达设计思想，但是这些图仅在讨论结束之前有效。我还不时绘制状态转换图，然后将其转换为实现语言中的状态表。

由于各种原因，我一直使用流程图：

1. 在我看来，它们比UML用例图更好。它们可以反映许多不同的用例以及它们如何交互，并且在整体上做得更好，将用户体验和决策结合在一起。

2. 它们更易于理解和直观。您的思维自然就像迷宫一样从始至终跟随着箭头。您可以使用流程图结束并引用另一个流程图，以了解不同的用户故事。我通常可以将它们打印在页码编号的书中，然后快速翻转页面以导航到下一个流程图。

3. 它们是普遍的。软件工程以外的人很少了解和理解UML图，其中流程图被用户和业务分析师所识别。我尝试与客户交流复杂的用例，有时他们难以理解，我画了流程图，他们理解了为什么最终了解使它变得比他们想象的要复杂得多的所有细微差别。

当需要按特定顺序进行操作时，流程图很有用。它们在我的脑海中真正闪耀的地方表明了决策的制定位置，并确保每个可能的决策都有一条路。这样可以防止在需要获得批准的情况下创建程序，但是如果经理（98％的时间批准）拒绝则无法处理。他们提醒我们，最常见的路径不是唯一的路径。我发现它们在与用户讨论需求时很有用，因为它们通常只会告诉您最常见的路径。

流程图对于结构非常糟糕的代码的逆向工程很有用。尤其是在有问题的情况下。值得庆幸的是，我最近没有看到太多goto缠身的代码。

正如其他人指出的与最终用户进行交流。我将流程图记录的电视发射器的启动排序。硬件和软件人员具有共同的规范才能工作。

UML活动图和流程图可用于显示流程或算法的中低复杂性。

与业务用户就业务规则进行交流时，它们非常好。

BPMN 2.0的形式存在变体，在业务流程建模中非常有用。

一些BPMN工具可以从图表生成正在运行的Web应用程序。

因此，是的，流程图仍然占有一席之地，但需要明智地使用它们。

我不是程序员。我是硬件工程技术人员。

从我的角度出发，至少应从解释将要使用的逻辑块的注释开始。之后，用实际代码充实程序框架。这类似于使用故事板启动电影脚本，然后再填写动作详细信息和对话框。

是否应该认真计划任何有价值的工作？在硬件领域，我们从客户需求文档开始，然后写出硬件规格文档，然后充实原理图，然后绘制电路板布局，然后提供组装文档。在提出最终产品的想法时，我们不只是开始抓取零件并将其焊接在一起。

在开始实际编码之前，我不明白在没有大量准备工作的情况下如何用15KB或15MB程序编写高效代码。