这是一个合法的工具,还是我最终会不再需要的拐杖?
更新:按操作顺序,我的意思是:
- 启动应用程序
- 阅读偏好
- 从首选项计算值
- 将首选项写入文件...
现在,当我无法可视化程序流程时,我会在方法级别和应用程序级别绘制图表。
这是一个合法的工具,还是我最终会不再需要的拐杖?
更新:按操作顺序,我的意思是:
现在,当我无法可视化程序流程时,我会在方法级别和应用程序级别绘制图表。
不,有经验的程序员不使用流程图,他们使用数据流程图、动作图、序列图、用例等;流程图在 1970 年代失宠,当时实证研究* 几乎证明它们作为设计工具毫无用处
... GRA 的实证研究主要集中在流程图上,这些研究的结果表明其作为理解辅助工具的有效性值得怀疑。
是的,当然。视觉隐喻是有用的工具。
流程图,就像老式的http://en.wikipedia.org/wiki/Flowchart一样 ,在发明时是个坏主意,现在仍然是个坏主意。
我不认识任何使用它们的程序员,无论好坏。他们没有帮助,因为他们可以使事情变得更清晰的问题是微不足道的,任何不是微不足道的问题都会变得不那么容易理解,而不是通过流程图来理解。我什至会说任何形式化的编程绘图系统都是浪费时间。当然,您可以在白板上或用铅笔和纸画一些有用的草图,但超出此范围(例如 visio,我在看您的白痴)是浪费时间。
在我的脑海中,我主要看到了涉及业务分析师时的流程图,主要是在制定规范时。
与非技术人员一起工作时,这是一种建模数据/信息流的便捷方式。
哦,是的:它们几乎总是非常简单(至少是好的)。任何具有多个多边形和线条的单一流程图,您都会开始失去人脉。
我的观点是,在方法或表达式级别工作时,流程图通常是多余的。但是,它们对于学习或理解应用程序中的广泛控制流很有用。
如果您发现它们有用,则没有理由不使用它们。
我画的东西很多,这取决于我理解抽象的能力。不要将其视为拐杖,而是您需要并因此使用的工具。你的能力与其他人不同,有时更好有时更差。不要因为使用可以帮助您成为工程师的工具而自责,即使没有其他人使用它们。
但重要的是,您应该始终寻找更好的方法。
我尝试从代码生成文档,而不是反过来,所以我会说不。
我通常对它进行编码并修复它,直到它满足要求并且在代码中或生成任何文档。
在我当前的系统(几乎完全基于 SQL)中,系统中的进程在表中,元数据是从系统元数据或我们维护的辅助表中提取的。使用 MSAGL 从这些依赖关系中生成流程图。这些图表还充当我们的交互式仪表板。
这取决于工艺流程的复杂程度。它是一种可视化显示信息流或工作流程的工具。如果它很简单,那么一定要在你的脑海中完成它。我通常会发现(即使在这样做了 14 年后)在我的代码设计期间查看它对于让我以正确的顺序专注于流程很有用。
我一直使用流程图来绘制操作顺序。
如果您的意思是“程序的整体数据流”意义上的“操作顺序”,那么流程图是绝对必须的。出现了某些图表,每个人都有一份副本,并且可以在办公室周围的白板上看到,因为它们非常重要/常见。例如,描述“来自应用程序的数据,使用 UDP 标头封装,然后传输到 IP 层,然后添加标头......”的图表
如果您的意思是“此代码如何工作”意义上的“操作顺序”,那么是的 - 流程图也绝对有帮助。“我们在这个例程中做的第一件事是计算校验和。然后我们将指针传递给下一个例程并设置一个计时器。计时器的回调函数是......”
如果您的意思是“运算顺序”作为表达式的数学评估,那么在尝试理解某人的代码或尝试编写自己的算法时,这也很重要。“首先我们增加指针,然后我们取消引用它以便我们可以读取值......”或“我们需要将整数右移 32 次,检查是否存在 1,然后......”这些有时是算法流程图,有时是操作员流程图。无论哪种情况,它们都有助于理解正在发生的事情,而无需在精神上解析代码。
也就是说,它们根本不是拐杖。
需要注意的一些事情:通过数学评估...通常,如果表达式不易阅读(许多嵌套操作或括号,可能有许多不同优先级的操作符 - 例如取消引用、递增和算术),最好打破将代码分成多个较小的步骤。这样您就可以轻松地显示计算的逻辑以及实现。您可能仍然需要流程图,但代码本身更容易阅读。
最后,更高级/更有经验的程序员有时不需要那么多流程图。他们已经记住了相关的图表,或者他们可以更好地解析逻辑,因为他们能够识别某些习语。如果你还没有,你肯定会开发它。但与此同时,如果您需要了解某些内容,没有理由不使用流程图。根本不是拐杖!