no, experienced programmers don't use flowcharts, they use data-flow diagrams, action diagrams, sequence diagrams, use cases, et al; flowcharts fell out of favor in the 1970s when empirical studies* pretty much demonstrated that they were useless as a design tool
...Empirical studies of GRA's have focused primarily on the flowchart and the results of these studies indicate its effectiveness as an aid to comprehension is questionable.
If you just mean "diagrams", then
yes, of course. Visual metaphors are useful tools.
I don't know any programmers, good or bad, who use them. They don't help, in that the problems in which they can make things clearer are trivial, and any problem which isn't trivial is made less comprehensible, rather than more by a flowchart. I would go so far as to say any formalized drawing system for programming is a waste of time. Sure, you can make some sketches on a whiteboard or with pencil and paper that can be helpful, but taking it beyond this (e.g. visio, I'm looking at your idiocy) is a waste of time.
My opinion is that when working at the method or expression level flow charts are usually overkill. However they can be useful for learning, or for understanding broad control flow in an application.
If you find them useful there is no reason not to use them.
Off the top of my head, I've mainly seen flowcharts when business analysts are involved and mainly when the specs are being worked out.
Wnen working with non-technical folks, it's a convenient way of modeling data/information flow.
Oh yes: They're almost always very simple (at least the good ones). Any single flow-chart with more than a handful of polygons and lines and you start losing people.
I use flowcharts all the time to map out orders of operations.
If you mean "order of operations" in the sense of "overall data flow of a program", then flowcharts are an absolute must. There come to be certain diagrams that everybody has a copy of, and that are seen on whiteboards all around the office because they are so important/common. eg, a diagram to describe that "Data from the application, is encapsulated using a UDP header, and then travels to the IP layer, where a header is then added..."
If you mean "order of operations" in the "how does this code work" sense, then yes - flowcharts absolutely help there as well. "The first thing we do in this routine is compute the checksum. Then we pass the pointer to the next routine and set a timer. The callback function for the timer is..."
If you mean "order of operations" as the mathematical evaluation of expressions, then this can be important as well when trying to understand someone's code, or when trying to write your own algorithm. "First we increment the pointer, and then we dereference it so that we can read the value..." or "We need to right-shift the integer 32 times, check for the presence of a 1, and then..." These are sometimes algorithm flowcharts, or sometimes operator flowcharts. In either case, they are useful to understanding what is going on without having to mentally parse code.
That is to say, they are not a crutch at all.
Some things to note: with the mathematical evaluation... often, if an expression is not easily readable (many nested operations or parentheses, may operators of many different precedence - like dereferencing, incrementing, and arithmetic), it might be better to break the code into multiple smaller steps. That way you can easily show the logic of the calculation, as well as the implementation. You might still need a flowchart, but the code itself reads easier.
Finally, more advanced/experienced programmers sometimes don't need as many flowcharts. They already have the relevant diagrams memorized, or they can parse logic better because they recognize certain idioms. You will certainly develop that, if you haven't already. But in the meantime, there is no reason not to use flowcharts if you need to understand something. Not a crutch at all!
There are many things I draw, it depends on the my capacity to comprehend an abstraction. Don't think of it as a crutch rather as tool you need and thus use. Your abilities are different to others sometimes better sometimes worse. Don't knock yourself for using a tools that helps you be an engineer, even if no one else uses them.
But importantly you should always be on the look out for better ways.
I try to generate documentation from the code, not the other way round, so I would say no.
I typically code it and fix it until it meets requirements and have any documentation either in the code or generated.
In my current system (almost entirely SQL-based), the processes in the system are in tables and metadata is extracted either from the system metadata or auxiliary tables we maintain. Flow diagrams are generated from these dependencies using MSAGL. The diagrams also act as our interactive dashboard.
It depends on how complex the process flow is. It's a tool for visually displaying the flow of information or the workflow. If it's simple then by all means do it in your head. I usually find (even after 14 years of doing this) that have it to glance at during my code design is useful to keep me focussed on the process in the correct order.
发布评论
评论（8）
如果您的字面意思是“流程图”，那么
< em>不，有经验的程序员不使用流程图，他们使用数据流图、动作图、序列图、用例等； 流程图在 20 世纪 70 年代失宠，当时实证研究*几乎证明它们作为设计工具毫无用处
如果您只是指“图表”，那么
当然。 视觉隐喻是有用的工具。
If you literally mean "Flowchart", then
no, experienced programmers don't use flowcharts, they use data-flow diagrams, action diagrams, sequence diagrams, use cases, et al; flowcharts fell out of favor in the 1970s when empirical studies* pretty much demonstrated that they were useless as a design tool
If you just mean "diagrams", then
yes, of course. Visual metaphors are useful tools.
流程图，如旧式http://en.wikipedia.org/wiki/Flowchart
它们在发明时是一个坏主意，现在仍然是一个坏主意。
我不知道有哪个程序员使用它们，无论好坏。 它们没有帮助，因为它们可以使事情变得更清晰的问题是微不足道的，而任何不微不足道的问题都会变得更难以理解，而不是通过流程图来解决。 我什至会说任何形式化的编程绘图系统都是浪费时间。 当然，您可以在白板上或用铅笔和纸画一些草图，这可能会有所帮助，但超出此范围（例如visio，我正在看您的白痴）就是浪费时间。
Flow charts, as in the old school kind http://en.wikipedia.org/wiki/Flowchart
were a bad idea when they were invented and are still a bad idea.
I don't know any programmers, good or bad, who use them. They don't help, in that the problems in which they can make things clearer are trivial, and any problem which isn't trivial is made less comprehensible, rather than more by a flowchart. I would go so far as to say any formalized drawing system for programming is a waste of time. Sure, you can make some sketches on a whiteboard or with pencil and paper that can be helpful, but taking it beyond this (e.g. visio, I'm looking at your idiocy) is a waste of time.
我的观点是，在方法或表达式级别工作时，流程图通常是多余的。 然而，它们对于学习或理解应用程序中的广泛控制流很有用。
如果您发现它们有用，就没有理由不使用它们。
My opinion is that when working at the method or expression level flow charts are usually overkill. However they can be useful for learning, or for understanding broad control flow in an application.
If you find them useful there is no reason not to use them.
在我的脑海中，我主要看到的是业务分析师参与时以及制定规范时的流程图。
在与非技术人员合作时，这是一种对数据/信息流进行建模的便捷方法。
哦，是的：它们几乎总是非常简单（至少是好的）。 任何包含多个多边形和线条的单一流程图都会开始失去人员。
Off the top of my head, I've mainly seen flowcharts when business analysts are involved and mainly when the specs are being worked out.
Wnen working with non-technical folks, it's a convenient way of modeling data/information flow.
Oh yes: They're almost always very simple (at least the good ones). Any single flow-chart with more than a handful of polygons and lines and you start losing people.
我一直使用流程图来制定操作顺序。
如果您的意思是“程序的整体数据流”意义上的“操作顺序”，那么流程图是绝对必须的。 某些图表每个人都有一份，并且在办公室各处的白板上都能看到，因为它们非常重要/常见。 例如，一个图表描述“来自应用程序的数据使用 UDP 标头进行封装，然后传输到 IP 层，然后在其中添加标头......”
如果您的意思是“如何操作”中的“操作顺序”这段代码是否有效”，那么是的 - 流程图也绝对有帮助。 “我们在这个例程中做的第一件事是计算校验和。然后我们将指针传递给下一个例程并设置一个计时器。计时器的回调函数是......”
如果您的意思是“操作顺序”作为数学表达式的求值，那么当尝试理解某人的代码或尝试编写自己的算法时，这也很重要。 “首先我们递增指针，然后取消引用它，以便我们可以读取值...”或“我们需要将整数右移 32 次，检查是否存在 1，然后...”这些有时是算法流程图，有时是操作员流程图。 无论哪种情况，它们都有助于理解正在发生的事情，而无需在心里解析代码。
也就是说，它们根本就不是拐杖。
需要注意的一些事情：对于数学评估......通常，如果表达式不易阅读（许多嵌套操作或括号，可能有许多不同优先级的运算符 - 例如解引用、递增和算术），最好打破将代码分成多个较小的步骤。 这样你就可以轻松地展示计算的逻辑以及实现。 您可能仍然需要流程图，但代码本身更容易阅读。
最后，更高级/经验丰富的程序员有时不需要那么多流程图。 他们已经记住了相关的图表，或者他们可以更好地解析逻辑，因为他们认识某些习语。 如果你还没有的话，你肯定会发展这一点。 但与此同时，如果您需要理解某些内容，没有理由不使用流程图。 根本不是拐杖！
I use flowcharts all the time to map out orders of operations.
If you mean "order of operations" in the sense of "overall data flow of a program", then flowcharts are an absolute must. There come to be certain diagrams that everybody has a copy of, and that are seen on whiteboards all around the office because they are so important/common. eg, a diagram to describe that "Data from the application, is encapsulated using a UDP header, and then travels to the IP layer, where a header is then added..."
If you mean "order of operations" in the "how does this code work" sense, then yes - flowcharts absolutely help there as well. "The first thing we do in this routine is compute the checksum. Then we pass the pointer to the next routine and set a timer. The callback function for the timer is..."
If you mean "order of operations" as the mathematical evaluation of expressions, then this can be important as well when trying to understand someone's code, or when trying to write your own algorithm. "First we increment the pointer, and then we dereference it so that we can read the value..." or "We need to right-shift the integer 32 times, check for the presence of a 1, and then..." These are sometimes algorithm flowcharts, or sometimes operator flowcharts. In either case, they are useful to understanding what is going on without having to mentally parse code.
That is to say, they are not a crutch at all.
Some things to note: with the mathematical evaluation... often, if an expression is not easily readable (many nested operations or parentheses, may operators of many different precedence - like dereferencing, incrementing, and arithmetic), it might be better to break the code into multiple smaller steps. That way you can easily show the logic of the calculation, as well as the implementation. You might still need a flowchart, but the code itself reads easier.
Finally, more advanced/experienced programmers sometimes don't need as many flowcharts. They already have the relevant diagrams memorized, or they can parse logic better because they recognize certain idioms. You will certainly develop that, if you haven't already. But in the meantime, there is no reason not to use flowcharts if you need to understand something. Not a crutch at all!
我画的东西有很多，这取决于我对抽象概念的理解能力。 不要将其视为拐杖，而应将其视为您需要并使用的工具。 你的能力与其他人不同，有时更好，有时更差。 不要因为使用了可以帮助你成为一名工程师的工具而自责，即使没有其他人使用它们。
但重要的是，您应该始终寻找更好的方法。
There are many things I draw, it depends on the my capacity to comprehend an abstraction. Don't think of it as a crutch rather as tool you need and thus use. Your abilities are different to others sometimes better sometimes worse. Don't knock yourself for using a tools that helps you be an engineer, even if no one else uses them.
But importantly you should always be on the look out for better ways.
我尝试从代码生成文档，而不是相反，所以我会说不。
我通常对其进行编码并修复它，直到它满足要求并且在代码中或生成了任何文档。
在我当前的系统（几乎完全基于 SQL）中，系统中的进程都在表中，并且元数据是从系统元数据或我们维护的辅助表中提取的。 流程图是使用 MSAGL 根据这些依赖关系生成的。 这些图表还充当我们的交互式仪表板。
I try to generate documentation from the code, not the other way round, so I would say no.
I typically code it and fix it until it meets requirements and have any documentation either in the code or generated.
In my current system (almost entirely SQL-based), the processes in the system are in tables and metadata is extracted either from the system metadata or auxiliary tables we maintain. Flow diagrams are generated from these dependencies using MSAGL. The diagrams also act as our interactive dashboard.
这取决于工艺流程的复杂程度。 它是一种直观地显示信息流或工作流程的工具。 如果很简单，那么一定要在脑海中完成。 我通常发现（即使已经这样做了 14 年）在代码设计过程中浏览一下它有助于让我以正确的顺序专注于流程。
It depends on how complex the process flow is. It's a tool for visually displaying the flow of information or the workflow. If it's simple then by all means do it in your head. I usually find (even after 14 years of doing this) that have it to glance at during my code design is useful to keep me focussed on the process in the correct order.