在学校时,通常需要将我们逐行编写的小程序流程图。
由于图片的大小,这些流程图往往非常大,而且绘制起来往往很乏味。
总是如此详细,以至于您实际上是在编写代码。
我使用流程图/UML 风格的技术来开发更高级别的东西,但是当它涉及到实际的循环时,它似乎不是矫枉过正。
我会经常对更详细的算法进行伪编码,但仍然不会达到超细粒度的程度。
这只是那些在学校里的东西如此之小的事情之一,“流程图”就没有别的东西了,所以他们用做这些细节吗?
在学校时,通常需要将我们逐行编写的小程序流程图。
由于图片的大小,这些流程图往往非常大,而且绘制起来往往很乏味。
总是如此详细,以至于您实际上是在编写代码。
我使用流程图/UML 风格的技术来开发更高级别的东西,但是当它涉及到实际的循环时,它似乎不是矫枉过正。
我会经常对更详细的算法进行伪编码,但仍然不会达到超细粒度的程度。
这只是那些在学校里的东西如此之小的事情之一,“流程图”就没有别的东西了,所以他们用做这些细节吗?
流程图,不——序列图,是的。我试图让他们保持在一个非常高的水平,以便快速将这个想法传达给某人。我不会尝试了解每一个细节。如果它看起来很重要,我可能会补充另一个图表来显示边缘情况。
它非常适合作为草图进行交流 - 我认为它不适合规范(但会是详细部分的一个很好的介绍)
真实代码的 ifs 和 while 流程图,从未(30 年内)发现有用。
作为引发需求的讨论辅助……所以当我们在这里时,会发生什么?...您将如何决定...如果> 95%您会怎么做...可能会有所帮助。某类用户在白板上发现这样的图表很容易谈论。
老实说,我非常高兴我被要求用流程图来完成任何任务。它们让我从结构上思考,这是我缺乏的东西(也许在某种程度上仍然缺乏)。
所以不要急于跳上“我要去弹三角钢琴”的潮流,流程图确实有效。
我没有一次发现自己陷入了非平凡逻辑的束缚。在一张纸上以流程图形式列出逻辑之后(需要几分钟),这一切都不可避免地对我来说变得清晰了。
是的,我同意。重点是让您了解流程图,而不是暗示您应该将它们用于逐行代码覆盖。
老实说,我不知道你为什么还要在伪代码上浪费时间,除非它是一些非常低级的编程。
我自己不使用它们。但是一个偶尔只编程一次的同事会这样做。对于他来说,这是一种非常方便的方式来记住他一年前编写的那个程序的具体细节。他不会做太多的编程,所以对他来说学习序列图之类的东西是不值得的。
这也是其他几乎没有编程过的人能够轻松阅读的图表类型。这在他的位置上是一个加号。
我没有发现流程图中的详细信息很有帮助。我在一张纸上使用 UML 风格的技术。在小组设置中使用白板。中级类图和序列图对于组织您的想法和传达您的设计意图非常有帮助。
有时在白板上描述一个过程,但从不在实际设计或文档中。我会更多地将它们描述为“类似流程图”,因为我并不总是特别关注形状。
我们有一个内部应用程序,其中包含一些相当复杂的工作流程。流程图构成了系统这部分规范的重要组成部分。所以是的,流程图是规范系统的有用工具。它们通常也被非技术人员理解,如果它们是用户需求的一部分,这很有用。不,我通常不会在非常低的级别上使用它们,我也不希望系统的一部分仅由流程图指定或记录。
如果您愿意的话, TDD是基本代码的一个不错的选择,它还有很多其他的好处。
我们有一个大型的有机增长的应用程序,其文档很少,因此使用流程图来记录应用程序中的组件已被证明对运营的业务方面非常有用,因为即使他们不了解所有内容如何组合在一起。
它们不是逐行级别的,但确实涵盖了业务逻辑的所有分支以及后续处理和输出(尽管不遵循严格的流程图规则——一些块描述了多个流程)。