我们应该对这些新技术感到振奋。它们解决了许多它们出现之前存在的问题。它们的网站上都是各种宣称生产效率如何之高的广告语，类似于15分钟创建一个博客应用；2分钟快速教程等。比起过去21天才能学会XXX，现在它们在上手难度上早已大幅度降低。

      需要泼冷水的是，本文开篇提出的问题，在上述任何一种外出和OA对接这块需要二次开发软件的技术下，都如幽灵般挥之不去。采用Ruby on Rails 的某高效团队在10人团队工作半年之后，构建时间从当初的2 分钟变成两个小时致远服软认为：http://www.soft8.com.cn/之前采用Microsoft .NET 3.5（C# 3.0）的一个项目，在产生2 万行代码的时候，构建时间已经超过半小时。我们的一些客户，工作在10年股票大盘演示软件的代码库上——他们竭尽全力，保持技术栈与时俱进：Spring、Hibernate、Struts 等，面对的困境是他们需要同时打开72个项目才能在Eclipse中获得编译；由于编译打包时间过长，他们去掉了大部分的单元测试——带来了巨大的质量风险。

      如果你真的在一个长期的股票大盘演示软件项目工作过，应该清楚地了解，这种痛苦似乎是任何一种框架都不能够根本性解决的。这些新时代的框架解决了大部分显而易见的问题，然而在一个长期项目中所面对的问题上，它们无能为力。一步一步：架构是如何腐化的无论架构师在任何时代以何种绚丽的方式描述架构，开发中的项目都不会超出图1 所示架构。

下面为一些基本的准则。

• 为了降低耦合，系统应当以恰当的方式进行分层。目前最经考验的分层是MVC+Service。

• 为了提供基础的访问，应该引入一些基本的、平台级别的API，用Spring 之类的框架来做这件事情。

• 用AOP 进行横向切分业务层面共性的操作，例如日志、权限等。

• 为了保证项目正常构建，你还需要股票大盘演示软件构建的数据库、持续集成服务器以及对应的与环境无关的构建脚本和数据库迁移脚本。  

      满足这个条件的架构在初期是非常令人愉悦的。前面我们描述的框架都符合这种架构。这个阶段开发非常快：IDE打开很快，开发功能完成很快，团队这个时候往往规模较小，交流也没有问题。所有人都很高兴——因为用了新技术，因为这个架构是如此简单、清晰、有效。