我正在对初级(也许是高级)软件工程师所犯的常见错误和错误假设进行一些研究。
你坚持时间最长、最终被纠正的假设是什么?
例如,我误解了整数的大小不是标准的,而是取决于语言和目标。说起来有点尴尬,但事实就是这样。
坦率地说;你有什么坚定的信念?你大概坚持了多长时间?它可以是关于一种算法、一种语言、一个编程概念、测试,或者任何关于编程、编程语言或计算机科学的东西。
我正在对初级(也许是高级)软件工程师所犯的常见错误和错误假设进行一些研究。
你坚持时间最长、最终被纠正的假设是什么?
例如,我误解了整数的大小不是标准的,而是取决于语言和目标。说起来有点尴尬,但事实就是这样。
坦率地说;你有什么坚定的信念?你大概坚持了多长时间?它可以是关于一种算法、一种语言、一个编程概念、测试,或者任何关于编程、编程语言或计算机科学的东西。
当前回答
我想我需要它。
其他回答
人们知道他们想要什么。
在很长一段时间里,我以为我会和人们交谈,他们会描述一个问题或工作流程,我将其放入代码并自动化。结果每次发生这种情况,他们以为自己想要的并不是他们真正想要的。
Edit: I agree with most of the comments. This is not a technical answer and may not be what the questioner was looking for. It doesn't apply only to programming. I'm sure it's not my longest-held assumption either, but it was the most striking thing I've learned in the 10 short years I've been doing this. I'm sure it was pure naivete on my part but the way my brain is/was wired and the teaching and experiences I had prior to entering the business world led me to believe that I would be doing what I answered; that I would be able to use code and computers to fix people's problems.
我想这个答案类似于Robin关于非程序员理解/关心我所谈论的内容的回答。这是关于将业务作为一个敏捷的、迭代的、交互的过程来学习。它是关于学习编程猴子和软件开发人员之间的区别。这是关于意识到两者之间的区别,并且在该领域真正优秀,不仅仅是语法和输入速度。
编辑:这个答案现在是社区-wiki,以安抚人们对这个答案感到不安,给我代表。
其他人会像我一样被已知的错误所困扰,并且会把修复它们作为项目工作的优先级。
一个函数/方法应该只有一个出口点。
我以为静态输入就是你一动不动地坐在键盘前。
当主流设计模式在计算机科学课上被引入时,我认为它们很棒。在此之前,我有8年的编程经验,对于如何创建好的抽象概念,我真的没有扎实的理解。
设计模式就像魔法一样;你可以做一些很棒的事情。后来我发现了函数式编程(通过Mozart/Oz、OCaml、后来的Scala、Haskell和Clojure),然后我明白了许多模式只是样板,或者额外的复杂性,因为语言表达能力不够。
当然,几乎总是有某种模式,但它们在表达性语言中处于更高的层次。现在我一直在用Java进行一些专业编码,当我不得不使用访问者或命令模式等惯例而不是模式匹配和更高阶函数时,我真的感到很痛苦。