我正在对初级(也许是高级)软件工程师所犯的常见错误和错误假设进行一些研究。
你坚持时间最长、最终被纠正的假设是什么?
例如,我误解了整数的大小不是标准的,而是取决于语言和目标。说起来有点尴尬,但事实就是这样。
坦率地说;你有什么坚定的信念?你大概坚持了多长时间?它可以是关于一种算法、一种语言、一个编程概念、测试,或者任何关于编程、编程语言或计算机科学的东西。
我正在对初级(也许是高级)软件工程师所犯的常见错误和错误假设进行一些研究。
你坚持时间最长、最终被纠正的假设是什么?
例如,我误解了整数的大小不是标准的,而是取决于语言和目标。说起来有点尴尬,但事实就是这样。
坦率地说;你有什么坚定的信念?你大概坚持了多长时间?它可以是关于一种算法、一种语言、一个编程概念、测试,或者任何关于编程、编程语言或计算机科学的东西。
当前回答
不是持有时间最长的,但在某一时刻,有几年的时间,我:
以为微软Windows是世界上唯一的操作系统(那是1992年) 了解DOS对于拥有“高级”操作系统知识已经足够了。
这就是为什么我在高中没有选择“计算机课程”。我以为我对计算机已经了解得够多了。
后来在大学里,出于我的错误:
我认为UNIX操作系统/程序是完美的,DOS/Windows永远不会接近它(那时候看起来很真实,我猜Linus也是这么想的,这就是为什么Linux和UNIX如此相似,而不是。其他操作系统)
最后,在很长一段时间里,我想:
只有我的软件很糟糕,而商业软件是完美无缺的,因为……它是“商业”软件 美国的软件/工程师/产品是优秀的同义词,其他的都只是糟糕的尝试。
其他回答
不熟悉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不重要,因为它最终会回来困扰你。你可能可以在一段时间内摆脱它,甚至几年,但你最终会达到一个断点,在没有完全重新设计数据库的情况下,你无法继续前进,那是成本最高的时候。
字节和字符实际上是一回事——“ASCII”只是将字节值映射到屏幕上的符号的一种方式。
阅读关于Unicode的文章真的让我大开眼界(尽管我仍然没有完全理解它)。
我持有时间最长(因此也是代价最大)的错误假设是:“业务需求是理智和合理的,我只是还没有理解它们。”
100个绿色假设坐在墙上, 如果一个绿色假设不小心掉了, 墙上有99个绿色假设。
交替:
胖墩儿坐在墙上。 矮胖子摔了一跤, 所有国王的马,所有国王的人, 艾菲姆说,他只是个技术人员。
你需要一个客户规范来完成一个项目。很多时候,你从一个销售会议和一个记事本开始。当然,在会议结束时,他们想要一个最后期限,“只是大概的时间”。
我认为编写足够好的软件是一项简单的任务