程序员是如何思考的？
这可能是一个无可救药的模糊问题。 但我很想听听人们在学习新概念或试图让大脑理解他们以前从未见过的代码时所经历的逻辑思维过程。
基本上，要采取哪些一般步骤来解决问题以及如何才能“解决问题”？ 如果你要绘制一个流程图来说明当你查看代码或尝试解决问题时你的思维过程是如何运作的，它会是什么样子？
您认为哪些常见的参考资料、技巧和心理假设对解决问题有用？
不同域之间有何不同？ 例如，网络程序员的思维过程与传统桌面应用程序开发人员的流程有何相似或不同？
This may be a hopelessly vague question. But I am interested to hear whatever logical thought processes people go through when learning a new concept or trying to get their brain around code they might not have ever seen before.
Basically, what general steps does one take to to break down problems and what does it take to "get it"? If you were to diagram a flowchart of how your mental process works when you look at code or try to solve a problem what might it look like?
What common references, tips, and mental assumptions do you find useful in problem solving?
How is this different between different domains? For example in what ways is a web programmer's thought process similar or different from a traditional desktop app developer's process?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（10）
呵呵，祝你好运。 这是一个很好的问题，我相信您会得到很多答案。 尽管我不得不说我无法对此给出令人满意的答案 - 我最后会用流程图来描述我的思维过程 - 我认为对此没有任何黄金公式。
我可以推荐的解决问题的唯一技巧是与其他人讨论。 当你遇到困难时，与同事一起克服它是非常宝贵的。 很多时候，他们实际上甚至不会对讨论做出太多贡献——在公开表达你所有想法的过程中，解决方案就会变得清晰。
Ho ho, good luck with this one. It's a great question and I'm sure you'll get a ton of answers. Although I have to say I cannot give a satisfactory answer to this - the last thing I would describe my thought processes as is a flow chart - I don't think there is any golden formula for this.
The only tip in problem solving I can recommend is discussing it with somebody else. In those times when you hit a brick wall, going through it with a colleague is invaluable. Quite often, as well, they will actually not even add much to the discussion - in the process of getting all your thoughts out in the open, the solution can become clear.
我坚信，无论您第一次查看什么类型的应用程序，可能是 Web 应用程序、桌面应用程序、设备驱动程序或其他任何应用程序，开发人员通常都会遵循三个步骤为了了解它是如何工作的：
了解大局：
看看它是如何工作的：
了解（或至少尝试）应用程序的设计方式：
第一步和第二步纯粹是技术性的，而第三步必须尽可能非技术性...更多的是关于心理学和理解应用程序是如何构建的。 这显然需要经验，但只要你足够努力思考，不要在技术细节上浪费你的大脑时间，你最终会得到它。
整个过程不需要使用键盘。 你只需要阅读、思考并在纸上做笔记（我不是在开玩笑：笔和纸！）。
I'm a big believer that no matter what type of application you're looking at for the first time, may it be a web app, a desktop app, a device driver, or whatever else, there are three steps one developer usually follows in order to understand how it works:
Get the big picture :
See how it works :
Understand (or at least try to) the way the app has been thought through:
The 1st and 2nd steps are purely technical, while the 3rd MUST be as untechnical as possible... it's more about psychology and understanding how the app has been built. It obviously requires experience, but as long as you think hard enough and don't waste your brain's time with technical details, you'll eventually get it.
This whole process shouldn't require the use of a keyboard. You're only supposed to read, think, and take notes on a paper (I'm not kidding: pen and paper!).
众所周知，人们不善于审视自己的思维过程，但我会尝试一下。 在智商测试中，我的视觉空间能力测试非常高，语言能力测试为中到高，数学能力测试为中等（我想这可以解释我的 A-level 数学成绩）。 当我开始设计软件时，我会考虑形状以及它们之间的联系。 当涉及到向其他人描述这些想法（或为自己澄清它们）时，我使用简单的框图或取自 Jacobson 的 Objectory 方法的对象图 - 而不是 UML 建议的过于复杂的东西。 我有时会写一些复杂事物的文字描述，主要是为了提醒自己，但从不使用数字或数学。
当然，这只是我的情况——我曾与数学高手一起工作过，他们和我一样优秀，甚至比我更好。
People are notoriously bad at examining their own thought processes, but I'll give it a whirl. I test very high for visuo-spacial ability in IQ tests, medium-to-high for verbal skills, and moderate for mathematical skills (explains my A-level Maths grade, I suppose). amd when I start to design software, I think in terms of shapes and the connections between them. When it comes to describing these thoughts to others (or clarifying them for myself), I use simple block diagrams or the object diagrams taken from Jacobson's Objectory method - NOT the over complex stuff that UML suggests. I sometimes write textual descriptions of complex things, mostly as reminders to myself, but never use numbers or maths.
Of course this is just me - I've worked with maths whizzes who were just as good or even better programmers than myself.
我不认为...我处理。
这实际上并不像听起来那么翻转。 我总是将任务分解为各个组件，然后进一步分解，这不仅仅适用于编写软件！ 就像@Mark Pim U 按顺序经历事情一样。
当我做晚饭时，我的妻子非常生气，因为我花了很长时间才开始。
I don't think... I process.
This is actually less flip than it sounds. I always break down tasks into their components and then break these down further, and that doesn't just go for writing software! Much like @Mark Pim U go through things sequentially.
My wife gets really annoyed when I make dinner because I take so long to get started.
这是我极少数会回答“它确实有效”的时候之一。 我通过碾压它们来学习东西。 我没有任何花招或设备来帮助我。 我花了一些时间学习 PHP，但之后 Javascript 就容易多了。 一旦你解决了一件事情，接下来的事情就会变得越来越容易。
This is one of the rare times I would answer with "it just works." I learn things by steamrolling through them. I don't have gimmicks, or devices to help me. Took me some time to learn PHP, but after that Javascript was much easier. Once you tackle one thing, the next items become cumulatively-easier.
除法 征服
我首先尝试掌握整个问题的本来面目，然后开始寻找我可以识别的模式，并在一种递归过程中对它们做同样的事情，直到我有一个可以更轻松地实施和遵循的分解解决方案。
Divide & Conquer
I start by trying grasp the entire problem as it is, and then start to find patterns I can recognize, and do the same for them in a kind of recursive process, until I have a broken down solution I can implement and follow more easily.
与 Jonathan Sampson 类似 - 它确实有效。
当我解决一个真正的问题时，我会尝试思考解决它的最合乎逻辑的方法。
然后，当一切都出错时（就像通常那样），我必须采取数百次回避措施才能完成任务。 只要继续专注于最终目标，以合乎逻辑的方式，你就会实现目标。
但最终，它决定为我工作，而我最终得到的成品通常与我计划的完全不同。 只要顾客开心，我就开心！
Similar to Jonathan Sampson - it kind of just works.
When I'm attacking a real problem, I try and think of the most logical way of getting through it is.
Then, when everything goes wrong (as it usually does), I have to make hundreds of sidesteps to get things done. Just keep focusing on that end goal, that logical way and you'll get there.
Eventually though, it decides to work for me and I end up with a finished product that is usually nothing like I planned it out to be. As long as the customers are happy, I am!
就我个人而言，我与自己进行了一次内部对话“好吧，所以我们需要循环这个整数列表。” “但当我们找到我们想要的价值时，我们就可以打破。” “好吧，当我们开始时，列表肯定会被初始化吗？”
我很想知道是否对解决问题的技巧进行过任何心理学研究。
Personally, I conduct an internal dialogue with myself 'OK so we need to loop over this list of integers.' 'But we can break when we find the value we want.' 'OK, will the list definitely be initialised when we start?'
I'd be interested to see if any psychological research had been done on problem solving techniques.
我的主要技能是识别我已经了解的模型或系统与手头的任务之间的相似之处。 其中一些之间的联系可能看起来相当抽象。 关键是要找出其中的联系。 这导致了广泛适用的通用模式和方法的抽象。 与此相关的是，我学到的关于算法的最重要的事情是，问题永远不是“想出一个智能算法来解决 X”。 它是“对问题 X 进行建模，使其可以通过现有的智能算法 Y 来解决”。
My main skill is identifying similarities between models or systems I already know about and the task at hand. The connections between some of these can seem quite abstract; the key is to spot the connections. This leads to the abstraction of common patterns and approaches which are widely applicable. Related to this, the most important thing I learnt about algorithms was that the problem is never 'come up with a smart algorithm to solve X'. It's 'model problem X such that it can be solved by existing smart algorithm Y'.
就我个人而言，我在脑海中以图像方式而不是文本方式（如 Neil Butterworth）看到代码 - 这有点难以描述，因为（引用 STIV）“没有共同的参考框架”。
Personally, I see code in my head pictorally rather than textually (like Neil Butterworth) - it's a bit hard to describe since (quoting STIV) "there's no common frame of reference."