我正在对初级(也许是高级)软件工程师所犯的常见错误和错误假设进行一些研究。
你坚持时间最长、最终被纠正的假设是什么?
例如,我误解了整数的大小不是标准的,而是取决于语言和目标。说起来有点尴尬,但事实就是这样。
坦率地说;你有什么坚定的信念?你大概坚持了多长时间?它可以是关于一种算法、一种语言、一个编程概念、测试,或者任何关于编程、编程语言或计算机科学的东西。
我正在对初级(也许是高级)软件工程师所犯的常见错误和错误假设进行一些研究。
你坚持时间最长、最终被纠正的假设是什么?
例如,我误解了整数的大小不是标准的,而是取决于语言和目标。说起来有点尴尬,但事实就是这样。
坦率地说;你有什么坚定的信念?你大概坚持了多长时间?它可以是关于一种算法、一种语言、一个编程概念、测试,或者任何关于编程、编程语言或计算机科学的东西。
当前回答
PHP的mysql_fetch_row是从执行的SQL查询中检索数据的唯一方法。
老实说,我编写了一个完整的web应用程序,而没有使用mysql_fetch_array,并且每次我想要更改函数以添加额外的列时都必须更改一堆数字。
其他回答
后藤是有害的。
现在我们决定是继续还是中断。
My co-workers were/are producing supposedly bad code because they sucked/suck. It took me a while to learn that I should first check what really happened. Most of the times, bad code was caused by lack of management, customers who didn't want to check what they really wanted and started changing their minds like there's no tomorrow, or other circunstances out of anyone's control, like economic crysis. Customers demand "for yesterday" features because they are stupid: Not really. It's about communication. If someone tells them it everything can really be done in 1 week, guess what? they'll want it in 1 week. "Never change code that works". This is not a good thing IMO. You obviously don't have to change what's really working. However, if you never change a piece of code because it's supposedly working and it's too complex to change, you may end up finding out that code isn't really doing what it's supposed to do. Eg: I've seen a sales commission calculation software doing wrong calculations for two years because nobody wanted to maintain the software. Nobody at sales knew about it. The formula was so complex they didn't really know how to check the numbers.
我所受的教育将为我在野外工作做好准备。
html元素id和name属性是可以互换的。
事实证明,带有'name'属性的元素是相关的/被使用的。引用post等和'id'属性用于DOM引用。
我最大的先入之见是,我将被允许以我想要的方式编程。当然,后来我离开了大学,进入了一家拥有荒谬框架、规则和程序的公司,这不仅意味着我不能以自己想要的方式编程,而且意味着我编程得很糟糕。