我正在对初级(也许是高级)软件工程师所犯的常见错误和错误假设进行一些研究。
你坚持时间最长、最终被纠正的假设是什么?
例如,我误解了整数的大小不是标准的,而是取决于语言和目标。说起来有点尴尬,但事实就是这样。
坦率地说;你有什么坚定的信念?你大概坚持了多长时间?它可以是关于一种算法、一种语言、一个编程概念、测试,或者任何关于编程、编程语言或计算机科学的东西。
我正在对初级(也许是高级)软件工程师所犯的常见错误和错误假设进行一些研究。
你坚持时间最长、最终被纠正的假设是什么?
例如,我误解了整数的大小不是标准的,而是取决于语言和目标。说起来有点尴尬,但事实就是这样。
坦率地说;你有什么坚定的信念?你大概坚持了多长时间?它可以是关于一种算法、一种语言、一个编程概念、测试,或者任何关于编程、编程语言或计算机科学的东西。
当前回答
In the early days, most personal computers had a cassette tape interface for loading and storing programs. I did not have a computer at this time but read everything I could get my hands on (mostly magazines) that had anything to do with computers (this was the late 70's - no internet for me). For some reason I was under the impression that programs were executed directly from the cassette tape and that the only reason computers had any RAM was to store variables while the program ran. I figured that when the code had to execute a jump instruction, it would somehow rewind or advance the tape to the correct position and continue from there.
其他回答
Windows中的线程很便宜。
事实证明,这只是部分正确。线程有一定的开销,需要自己的地址空间,在那里它可以生存和快乐。因此,如果我发现自己在一个应用程序中处理数十个线程,我会问自己如何将所有内容简化并整合到更少的线程中。
Java将对象的副本传递给函数,而不是引用。
换句话说,我认为如果你将一个对象传递给一个方法,然后以某种方式改变对象,它不会改变调用范围内的对象。我总是将对象传递给方法,操作它们,然后返回它们!
我曾经认为应用程序的大部分工作实际上是编程。我相信这在某些情况下是正确的,但根据我的经验,我花了更多的时间来研究、记录、讨论和分析,而不是实际编码。(我从事的是操作基于激光的传感器的软件,确定如何最好地控制硬件比编写代码更具挑战性。)
我也曾经认为,程序员可以回头问旁边的人问题的开放环境是程序员团队敲定解决方案的最佳环境。事实证明,不管有没有团队,一个黑暗孤独的房间效率更高。
当我毕业时,我认为专业编程就像在大学编程一样,这意味着我将得到输入和预期输出,并被要求填写进行转换的黑框。在现实中,我必须弄清楚输入,输出和黑盒。
我过去并不认为市场和销售人员是人类的祸害,太天真了。
我仍然对以下的一些误解感到困扰——尽管我知道这些误解是正确的,但我仍然试图抓住它们不放:
All stakeholders will make decisions about software design objectively. Those that aren't embroiled in writing the code make all sorts of decisions based entirely on emotion that don't always make sense to us developers. Project budgets always make sense - I've seen companies that are quite happy to drop [just for example] $50,000 a month for years rather than pay $250,000 to have a project completed in 6 months. The government for one loses their annual budget if they don't spend it - so spend it they will, come hell or high water. It astounds me at how many project dollars are wasted on things like this. You should always use the right tools for the right job - sometimes this decision is not in your hands. Sometimes it comes down from on high that "thou shalt use X technology" for this project, leaving you thinking "WTF! Who came up with that ridiculous idea?"... the guy paying your paycheque, that's who, now get it done. Programming ideology comes first and foremost, everything else is secondary. In reality, deadlines and business objectives need to be met in order to get your paycheque. Sometimes you make the worst decisions because you just don't have time to do it the right way... just as sometimes that word is on the tip of your tongue but the minute it takes to recall it makes you choose a different and less ideal word. There isn't always time to do it right, sometimes there is only time to do it - however that may be. Hence oft' seen anti-patterns used by so called experienced developers who have to knock out a solution to a problem 10 minutes before the presentation deadline for the software being delivered to your best client tomorrow.
私有成员变量是实例私有的,而不是类私有的。