您不应该停留在您发现的编写“有效”代码的第一种方法上。

I really don't think this should be controversial, but it is. People see an example from elsewhere in the code, from online, or from some old "Teach yourself Advanced Power SQLJava#BeansServer in 3.14159 minutes" book dated 1999, and they think they know something and they copy it into their code. They don't walk through the example to find out what each line does. They don't think about the design of their program and see if there might be a more organized or more natural way to do the same thing. They don't make any attempt at keeping their skill sets up to date to learn that they are using ideas and methods deprecated in the last year of the previous millenium. They don't seem to have the experience to learn that what they're copying has created specific horrific maintenance burdens for programmers for years and that they can be avoided with a little more thought.

事实上，他们似乎甚至没有意识到做一件事可能有不止一种方法。

I come from the Perl world, where one of the slogans is "There's More Than One Way To Do It." (TMTOWTDI) People who've taken a cursory look at Perl have written it off as "write-only" or "unreadable," largely because they've looked at crappy code written by people with the mindset I described above. Those people have given zero thought to design, maintainability, organization, reduction of duplication in code, coupling, cohesion, encapsulation, etc. They write crap. Those people exist programming in every language, and easy to learn languages with many ways to do things give them plenty of rope and guns to shoot and hang themselves with. Simultaneously.

But if you hang around the Perl world for longer than a cursory look, and watch what the long-timers in the community are doing, you see a remarkable thing: the good Perl programmers spend some time seeking to find the best way to do something. When they're naming a new module, they ask around for suggestions and bounce their ideas off of people. They hand their code out to get looked at, critiqued, and modified. If they have to do something nasty, they encapsulate it in the smallest way possible in a module for use in a more organized way. Several implementations of the same idea might hang around for awhile, but they compete for mindshare and marketshare, and they compete by trying to do the best job, and a big part of that is by making themselves easily maintainable. Really good Perl programmers seem to think hard about what they are doing and looking for the best way to do things, rather than just grabbing the first idea that flits through their brain.

如今，我主要在Java世界中编程。我见过一些非常好的Java代码，但我也见过很多垃圾代码，而且我还看到了更多我在开头描述的心态:人们选择了第一个看起来可以工作的丑陋代码块，而不理解它，也不考虑是否有更好的方法。

You will see both mindsets in every language. I'm not trying to impugn Java specifically. (Actually I really like it in some ways ... maybe that should be my real controversial opinion!) But I'm coming to believe that every programmer needs to spend a good couple of years with a TMTOWTDI-style language, because even though conventional wisdom has it that this leads to chaos and crappy code, it actually seems to produce people who understand that you need to think about the repercussions of what you are doing instead of trusting your language to have been designed to make you do the right thing with no effort.

我确实认为你可能会在另一个方向上走得太远:例如，完美主义完全忽略了你的真正需求和目标(通常是你的业务的真正需求和目标，通常是盈利能力)。但我不认为任何人都能成为一个真正伟大的程序员，除非学会投入一些高于平均水平的努力来思考寻找最好的(或至少是最好的一种)方法来编码他们正在做的事情。

继承是邪恶的，应该被摈弃。

事实是，在任何情况下，聚合都更好。静态类型的OOP语言不能避免继承，它是描述方法想从类型中得到什么的唯一方法。但是动态语言和鸭子类型可以没有它。Ruby mixins比继承强大得多，也更可控。

我有争议的观点是，“While”结构应该从所有编程语言中删除。

你可以很容易地复制而使用“重复”和一个布尔标志，我只是不相信这是有用的，有两个结构。事实上，我认为同时拥有“重复……”直到”和“While..”一种语言中的EndWhile”会让新程序员感到困惑。

更新-额外说明

新程序员在使用While时常犯的一个错误是，他们认为一旦测试条件标记为false，代码就会中断。因此，如果While测试在代码进行到一半时标记为假，则假定While循环爆发。使用Repeat时就不会犯这么多错误。

只要只有一个循环类型，我实际上并不关心这两个循环类型中哪一个被保留。我选择Repeat而不是While的另一个原因是“While”功能用“Repeat”写比用“While”写更有意义。

第二次更新: 我猜，我是目前唯一一个得分为负的人，这意味着这实际上是一个有争议的观点。(不像你们其他人。哈!)

getter和setter被过度使用

我见过数百万人声称公共字段是邪恶的，所以他们将它们设置为私有字段，并为所有这些字段提供getter和setter。我相信这与公开字段几乎是一样的，如果你使用线程(但通常不是这样)或如果你的访问器有业务/表示逻辑(至少有些“奇怪”)，可能会有点不同。

我不赞成公共字段，但反对为每个字段创建getter/setter(或Property)，然后声称这样做是封装或信息隐藏……哈!

更新:

这个答案在评论中引起了一些争议，所以我会试着澄清一下(我不会动原文，因为这是许多人点赞的)。

首先，任何使用公共场地的人都应该坐牢

现在，创建私有字段，然后使用IDE为每个私有字段自动生成getter和setter，几乎和使用公共字段一样糟糕。

很多人认为:

私有字段+公共访问器==封装

我说(自动或非自动)为字段生成getter/setter对有效地违背了您试图实现的所谓封装。

最后，让我引用Bob叔叔在这个主题中的一句话(摘自“干净代码”的第6章):

我们保持沉默是有原因的 私有变量。我们不想要 没有人可以依靠他们。我们想要的 自由地改变他们的类型或者 心血来潮地执行 冲动。那么，为什么要这么多呢 程序员会自动添加getter 和对象的setter，暴露 他们的私人领域，就好像他们是 公众吗?

糟糕的IDE会让编程语言变弱

优秀的编程ide确实使某些语言的工作更容易，更好地监督。在我的职业生涯中，我有点被宠坏了，我工作的公司总是有最新的Visual Studio可供使用。

在过去的8个月里，我一直在做很多关于Cocoa的工作，而Xcode编辑器使得使用这种语言变得非常困难。重载很难找到，处理打开文件的整体方式只会让你的屏幕非常混乱，非常快。这真的很遗憾，因为Cocoa是一种很酷且功能强大的语言。

当然死忠的Xcode粉丝现在会投票否决我的文章，但是有很多ide确实更好。

人们正在转向IT行业，而这些人本不该转向IT行业

这是从我去年的一篇博客文章中复制/粘贴的。

我的经验主要是关于荷兰市场的，但也可以适用于任何其他市场。

我们(我将所有软件工程师归为一类)目前处于一个对我们非常有利的市场中。公司正拼命地想要得到软件工程师(从现在开始)，无论价格如何。如果你现在换工作，你几乎可以要求任何你想要的东西。在荷兰，现在有一种趋势，甚至给两辆租赁车一份工作，只是为了让你为他们工作。这有多奇怪?我怎么能同时开两辆车?

当然，这听起来对我们来说很好，但这也造成了一个非常不健康的局面。

例如: 如果你目前正在为一家快速发展的公司工作，你正试图吸引更多的同事，最终从地面得到一些严肃的软件开发，没有人能找到不提供天价薪水的人。寻找优秀的同事是非常困难的。很多人被我们这种工作所吸引，因为高薪，但这也意味着很多没有正确激情的人正在进入我们的市场。

Passion, yes, I think that is the right word. When you have passion for your job, your job won’t stop at 05:00 PM. You will keep refreshing all of your development RSS feeds all night. You will search the internet for the latest technologies that might be interesting to use at work. And you will start about a dozen new ‘promising’ projects a month, just to see if you can master that latest technology you just read about a couple of weeks ago (and find an useful way of actually using that technology).

如果没有这种激情，市场可能看起来很好(因为汽车、金钱，当然还有我们吸引的辣妹)，但我认为，只要是消防员或战斗机飞行员，市场就不会那么有趣。

听起来我是在保护自己的工作，这在一定程度上是对的。但我也在努力保护自己不受我不想共事的人的伤害。我想就我读到的东西进行热烈的讨论。我希望能够与那些对工作有同样“热情”的人进行辩论。我希望同事与我共事是出于正确的原因。

我要找的人在哪里!!

HTML 5 + JavaScript将是未来最常用的UI编程平台。Flash、Silverlight、Java applet等等都将无声地消亡