我正在对初级(也许是高级)软件工程师所犯的常见错误和错误假设进行一些研究。
你坚持时间最长、最终被纠正的假设是什么?
例如，我误解了整数的大小不是标准的，而是取决于语言和目标。说起来有点尴尬，但事实就是这样。
坦率地说;你有什么坚定的信念?你大概坚持了多长时间?它可以是关于一种算法、一种语言、一个编程概念、测试，或者任何关于编程、编程语言或计算机科学的东西。
当前回答
变量实际上只是内存中特定区域的名称。
其他回答
我持有时间最长(因此也是代价最大)的错误假设是:“业务需求是理智和合理的，我只是还没有理解它们。”
100个绿色假设坐在墙上， 如果一个绿色假设不小心掉了， 墙上有99个绿色假设。
交替:
胖墩儿坐在墙上。 矮胖子摔了一跤， 所有国王的马，所有国王的人， 艾菲姆说，他只是个技术人员。
在不浪费字节和CPU周期的情况下编写高效的程序是非常重要的。
但随着经验的积累，它与字节或CPU周期无关，它与你的思想流有关，连续的，不间断的，就像一首诗。
本质上，不要太努力。
编程很简单。
我很早就开始学习编程了。那时我14岁左右。我有各种疯狂的想法，但不要问我准确的时间，因为那是很久以前的事了。
Ok, so, I believed for a while that if you use the term synchronize in Java, then Java solves this nasting synchronizing thing for you I believed for at least half a year, likely more, that static typing would improve performance. I believed that freeing something would return memory back to the OS. I believed that malloc calls boil down to checking if there is enough free space on the OS, so malloc would be inexpensive. I thought a long while that Java was built with all the benefits and flaws of the other languages in mind, into a "perfect blend" that would take the best properties of the other languages and reject the mistakes. I vastly overestimated the number of cases where LinkedLists outperform ArrayLists. I thought that NP-hardness was a proof that no INSTANCE could be solved efficiently, which is trivially false, for a while. I thought that finding the best flight-plan on travel agency web sites would take so long because of the "Travelling Salesman Problem", as I proudly chuckled to my relatives (when I was small, alright?!)
还能想出更多。不知道我坚持了多久。对不起。
PS: 啊，好吧，这个被清除得并不慢，但我看到新手时不时地这样做，所以我想你可能会感兴趣:我还认为要存储不确定数量的东西，你需要为每个东西声明一个新变量。所以我要创建变量a1 a2 a3…，而不是使用一个变量a，我将它声明为一个向量。
人们会关心最佳实践，甚至一致性。
