我以为静态输入就是你一动不动地坐在键盘前。

面向对象始终是设计源代码的最佳方式，而且永远都是。

我是一名初出茅庐的年轻开发者，希望从事专业的开发工作，因为这是我所热爱的，以下是我曾经持有的一些观点，这些观点都是我在短暂的经验中学到的，但都是错误的

当你根本不把用户界面和逻辑分开时，你最终会遇到的可怕的混乱是可以接受的，这也是每个人写软件的方式

不存在太多复杂或抽象的东西

一类责任——我从未真正有过这个概念，它对我来说是非常正式的

测试是我在卧室里编写代码时不需要做的事情

我不需要源代码控制，因为它对我所做的项目来说是多余的

开发人员什么都做，我们应该知道如何设计图标和做出漂亮的布局

Dispose并不总是需要结束符

任何类型的错误发生时都应该抛出异常

异常是针对错误情况的，很多时候只返回一个指示失败的值就可以了。我最近才明白这一点，我一直在说这一点，并且在很长一段时间内仍然抛出异常

我可以编写一个完全没有错误的应用程序

总是没有足够的时间在最后期限前完成。

喂!,

我只是在设计和写代码。

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

欢呼,

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.