今天捧起了<<The Rails Way>>，越看越惊奇，Obie同志的经历和想法和我他妈的太一致了。。。我真怀疑他曾经在某公司干过。。。谈到企业级应用的时候：

There are significant underlying reasons for the difficulties of software development, especially in enterprise environments:

• Hard-to-understand legacy systems.
• Highly complex business domains such as investment banking.
• Stakeholders and business analysts who don’t actually know what they want.
• Managers resistant to productivity because it shrinks their yearly budgets.
• End users who actively sabotage your project.
• Politics! Sticking your head out means worrying that it’ll get chopped off.

As a consultant to Fortune 1000 companies, I lived and breathed those situations on an everyday basis for almost 10 years, eventually stumbling upon a powerful concept.

注意"As a consultant to Fortune 1000 companies ..."，和某公司的口号真是太像鸟。再有：

"... ... The tools and technical infrastructure provided by Rails are comprehensive, encouraging us to focus on delivering business value. ... ... The best way to keep motivated and productive is to focus on delivering business value. ... ..."

使得我不得不再次怀疑他和某公司有一腿。。。

好了，估计是我多虑了，某公司应该没有此等和Zed Shaw同居过的牛人的。Obie列出了一些观点，有一些和传统看法明显向左的东西，但是放在Web开发上，的确不假，分享之。

• Developer motivation and productivity trump all other factors for project success.
• The best way to keep motivated and productive is to focus on delivering business value.
• Performance means “executing as fast as possible, on a given set of resources.”
• Scalability means “executing as fast as needed, on as many resources as needed.”
• Performance is irrelevant if you can’t scale.
• If you can scale cheaply, milking every ounce of performance from your processors should never be your first priority.
• Linking scalability to choice of development tools is a pervasive mistake in the industry and most software does not have extreme scalability requirements.
• Performance is related to choice of language and tools because higher-level languages are easier to write and understand. There is wide consensus that the performance problems in most applications are caused by poorly written application code.
• Convention over configuration is a better way to write software. Huge XML configuration files must be eliminated!
• Code portability, the ability to take code and run it on a different hardware platform, is not particularly important.
• It’s better to solve a problem well even if the solution only runs on one platform. Portability is irrelevant if your project fails.
• Database portability, the ability to run the same code on different relational database systems is rarely important and is almost never achieved.
• Presentation is very important, even for small projects. If your application looks bad, everyone will assume it is written badly.
• Allowing technology to dictate the approach to solving a business problem is usually a bad idea; however, that advice shouldn’t be used as an excuse to stick with inferior technology.
• The benefits of generalized application components are dubious. Individual projects usually have very particular business needs and wildly different infrastructure requirements, making parameterized reuse very difficult to achieve in practice.

大概只有受过Java折磨的webdev才能理解rails给人带来的那种救命稻草的感觉，这本书值得一看。