我正在对初级(也许是高级)软件工程师所犯的常见错误和错误假设进行一些研究。

你坚持时间最长、最终被纠正的假设是什么?

例如,我误解了整数的大小不是标准的,而是取决于语言和目标。说起来有点尴尬,但事实就是这样。

坦率地说;你有什么坚定的信念?你大概坚持了多长时间?它可以是关于一种算法、一种语言、一个编程概念、测试,或者任何关于编程、编程语言或计算机科学的东西。


当前回答

. net结构体(c#和VB.NET)是引用类型,就像类一样。

我是在。net 1.0出现之前或之后的某个时刻“收到”这条智慧的(我不知道从哪里来的,它可能完全从我的脑海中冒出来,就像雅典娜从宙斯的额头上冒出来一样),并一直保存着它,直到大约4个月前Jon Skeet对这个概念进行了消除。

感谢乔恩。

附注:与编程无关,但我也相信(直到5分钟前)“阿波罗从宙斯的额头上长成了一个完整的阿波罗”。

其他回答

喂!,

我只是在设计和写代码。

没有需求收集、文档或支持。

欢呼,

我从没想过我会成为一名专业程序员,我以为我会从事电子工作。但最终,编程更容易,薪水也更高,所以最初的副业变成了我的主要工作。

我在计算机科学课程中所学的Karnaugh地图在编程中永远找不到实际用途。

不熟悉SQL和关系数据库的过程开发人员/程序员不需要任何正式的培训,也不需要了解如何使用SQL,快速阅读SQL For Dummies之类的东西就足以使用像Oracle和SQL Server这样的关系数据库。

在处理存储在关系数据库(如Oracle和SQL Server)中的数据的应用程序中,许多错误往往是由于缺乏对关系数据库语言的理解或如何使用造成的;SQL。

I used to work for a software vendor who had the mentality that all a developer needed was the SQL For Dummies book or something similiar and they would be fully equipped to handle any relational database issue. Now that the clients of this vendor have databases measuring in hundreds of gigabytes this lack of SQL knowledge is coming back around in a negative way. It's not just bad performing lookups and or updates and inserts that are a problem but the actual design of the database itself that is the real obstacle.

如果当时开发主管能够像对待他们构建应用程序所用的语言那样对待SQL和关系数据库,那么所有这些都是可以避免的,而且成本也会低得多。

不要认为SQL不重要,因为它最终会回来困扰你。你可能可以在一段时间内摆脱它,甚至几年,但你最终会达到一个断点,在没有完全重新设计数据库的情况下,你无法继续前进,那是成本最高的时候。

至少6年来,我一直坚信,每个问题都只有一个解。

完全不知道不同复杂性的多种算法、空间/时间的权衡、面向对象、功能和命令式、抽象级别和无法确定的问题。当那种幸福的天真被打破时,它打开了一个充满可能性的世界,关上了坐下来建造东西的大门。我花了很长时间才弄清楚怎么选一个然后用它来运行。