我正在对初级(也许是高级)软件工程师所犯的常见错误和错误假设进行一些研究。
你坚持时间最长、最终被纠正的假设是什么?
例如，我误解了整数的大小不是标准的，而是取决于语言和目标。说起来有点尴尬，但事实就是这样。
坦率地说;你有什么坚定的信念?你大概坚持了多长时间?它可以是关于一种算法、一种语言、一个编程概念、测试，或者任何关于编程、编程语言或计算机科学的东西。
当前回答
在80年代早期，当我开始玩电脑(ZX81, 1K内存)时，我花了几个小时为杂志上的游戏输入大量的机器代码(字节，而不是人类可读的汇编语言)，基本上是使用BASIC Poke指令。
我相信，如果我输入了一条错误的指令，那么我就必须从头开始，从头开始输入机器代码。
其他回答
订阅许多RSS订阅，阅读许多博客并参与开源项目是很重要的。
我意识到，真正重要的是我花了更多的时间来写代码。我有阅读和关注许多博客的习惯，虽然它们是丰富的信息来源，但真的不可能吸收所有的东西。平衡阅读是很重要的，要多强调练习。
Reg。开源的话，我怕我不会受欢迎。我尝试过参与开源项目，大部分都是。net。看到许多开源项目甚至没有遵循适当的体系结构，我感到震惊。我看到。net中的一个系统没有使用分层架构，数据库连接代码到处都是，包括后面的代码，我放弃了。
我通过阅读K&R自学了C。不幸的是，我没有逐字逐句地读，肯定漏掉了一些东西。我编写了我自己的malloc和calloc版本，我在不同的工作中都随身携带，因为我不知道你可以只链接现有的库。我这样做了好几年，直到最后有人问我为什么要带着这些东西到处走，“嗯……你知道你可以直接链接现有的库，对吧?”
大的注释/代码比率是一件好事。
我花了一段时间才意识到代码应该是自文档化的。当然，如果代码不能更清晰，或者有重要的原因，这里或那里的注释是有帮助的。但是，一般来说，最好还是把注释时间花在重命名变量上。它更清晰，注释不会与代码“不同步”。
评论越多越好。我总是试图让我的代码尽可能具有可读性——主要是因为我几乎肯定是那个会修复我漏过的bug的人。所以在过去的几年里，我经常会收到一段又一段的评论。
最终，我明白了，有一个点，更多的评论——无论结构多么整齐——没有增加价值，实际上成为一个麻烦的维护。这些天，我采取了目录+脚注的方法，每个人都为此感到高兴。
代码行数越多，软件就越好。
