有经验的程序员仍然使用流程图来确定操作顺序，还是在头脑中做？ [英] Do experienced programmers still use flowcharts to work out the order of operations, or do they do it in their heads?
问题描述
这是否是一个合法的工具，还是一个拐点，我将最终成长为需要？
更新：按操作顺序我的意思是：
- 启动应用程序
- 阅读prefs
- 从prefs计算值
- 写入文件...
现在，当我无法可视化程序流程时，我会在方法级别以及应用级别中绘制图表。
我一直使用流程图来绘制操作顺序。
如果你的意思是操作顺序 程序的整体数据流的感觉，那么流程图是绝对必须的。有一些图表，每个人都有一个副本，这是在办公室周围的白板上看到的，因为它们非常重要/常见。例如，描述来自应用程序的数据，使用UDP标头封装，然后传送到IP层，然后添加标题的图。
如果你的意思是这个代码如何工作的意思是操作顺序，那么是的 - 流程图也绝对有帮助。 我们在这个例程中做的第一件事是计算校验和，然后我们把指针传给下一个例程并设置一个定时器，定时器的回调函数是...
如果您的意思是操作顺序作为表达式的数学评估，那么当尝试了解某人的代码或尝试编写自己的算法时，这也是重要的。 首先我们增加指针，然后我们取消引用它，以便我们可以读取值...或我们需要右移整数32次，检查是否存在1，然后...这些有时是算法流程图，有时也是算子流程图。在任何一种情况下，它们都有助于理解正在发生的事情，而无需精神解析代码。
这就是说，它们根本不是拐杖。有些事情要注意：通过数学评估...经常，如果一个表达式不容易读取（许多嵌套操作或括号，可能会有许多不同优先级的运算符，如解引用） ，递增和算术），最好将代码分解成多个较小的步骤。这样就可以轻松显示计算的逻辑以及实现。您可能仍然需要一个流程图，但代码本身看起来更容易。
最后，更高级/有经验的程序员有时不需要尽可能多的流程图。他们已经有相关的图表被记住了，或者他们可以更好地解析逻辑，因为他们认识到某些成语。你一定会发展出来，如果你还没有。但在此期间，如果您需要了解某些内容，则没有理由不使用流程图。不是拐杖！
Is this a legit tool or is it a crutch that I will eventually grow out of needing?
Update: By order of operations, I mean:
- launch app
- read prefs
- calculate value from prefs
- write prefs to file...
Right now, I draw diagrams at the method level as well as the app level when I'm having trouble visualizing the program flow.
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!
这篇关于有经验的程序员仍然使用流程图来确定操作顺序，还是在头脑中做？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
