我是一个优秀的程序员!

编程很简单。

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

这种简单性几乎总能战胜复杂性。愚蠢的规则。

编辑:正如葛格所说，我把这个颠倒了。我的思绪一定是在回复中迷失了。如果使用得当，简单性几乎总是能让代码变得更好。

没开始做的事，永远做不完。

看起来真的很愚蠢，但我推迟了这么多项目，因为规模太大了。我刚刚完成了一个巨大的项目，我意识到如果我意识到它的范围，我就不会开始了。在现实中，即使是最复杂的系统，当被分解成离散的和明确的部分时，也是相当简单的。然而，从宏观层面来看，它很快就被压倒了。

当然，您可以查看FindBugs和PMD，但这些是我最喜欢的陷阱和技巧(所有Java):

字段没有被覆盖，而是被遮蔽。

没有显式的super。超级访问。

未定义构造函数的类具有隐式零参数构造函数。今年我犯了一个与此相关的实际错误。

要获得对内部类的父类的引用，可以使用“Outer”语法。这“消除方法调用或同步的歧义”。

在c++术语中，类是“它们自己的朋友”，该类的任何实例的私有方法和字段都可以从同一类的任何方法引用，甚至是静态方法。这将使我早期的一些clone()和copy构造函数简单得多。

在扩展类的静态上下文中可以访问受保护的方法和字段，但前提是该类在同一个包中。我很高兴flex.messaging.io.amf不是一个密封的包。