首先要承认，这是一个有点糟糕的系列标题。“快速开发”过于陈词滥调，几乎就是各种代码生成器的代名词，不出彩之余还有可能遭人鄙视；“0代码开发”则类似于一个朝鲜7:0胜葡萄牙的梦想（刚看完葡萄牙7:0胜朝鲜的杯洗具），毕竟我们不是微软，应该没有胆量用上MOSS的宣传口号。但所幸我们常常秉持一个基本道理，就是判断事物的标准不应是“该不该”，而应是“是不是”。 

现在的企业系统开发，至少国内的企业系统开发，有不少公司都在进入一个误区。由于受到CMMI12345这种金字招牌的引导，项目管理理论受到了空前的重视（至少在表面上受到空前的重视，尤其是客户在场的时候），较为正规的公司都建立起了质控部门参与到各个项目的整个过程中，通过强化对文档的管理和以方法论为指引监控项目的整个过程。这种举措，应该来说，是正确的，是应该实施的；但是可惜的是，围绕项目管理这一中心理念建立起来的控制体系，在某一方面来说，却从基本理念上走进了一个误区：认为每一个项目是管理和控制的目标，而忽略了项目和项目之间应有的关联。什么是项目和项目之间应用的关联？软件项目和其他项目（譬如建筑工程项目）的{zd0}区别就是，除了参与人员的经验积累之外，软件项目的产品（应用系统）和开发产品的工具（开发技术），和房子展会之类的其他项目“管理”的对象不一样，很大程度上应该是可以重用的，并且可以快速发展的。简单的来说，存在两个脱节：项目管理和技术脱节，于是项目和项目之间的技术关联也脱节。 

 所以，这个系列{zx0}要强调的是：软件公司应该重视技术积累。 所谓重视，应该不只是喊喊口号，而应该有一套细致的包括激励政策在内的实施细则，让架构师和开发人员有意识地不仅仅在为一个个独立的项目在做贡献，而是在享受之前同事们的贡献成果的同时，也在为公司的未来发展和他们自己将来的轻松生活做贡献。 

说到这里，终于可以切入正题：至少对于外包公司而言，尤其是对于有志于扩展业务范围甚至最终产品化的外包公司而言，如果要真正实施技术积累策略，他们需要一个技术积累的载体；而这个载体，{zh0}的选择，就首先应该是一个囊括系统基本架构，快速原型和各种开发工具在内的，能够不断提升开发效率的开发辅助平台和通用基本框架。它首先应该是高效的，代码简练的（我个人对于针对每一个特定的领域模型----更糟糕的，是针对数据库表----都生成包含大量代码，例如在对应数据访问类中包含增删改查的代码，表示层生成特定的界面控件从而导致大量相似但又不同的代码这种做法深恶痛绝）；然后，应该是通用的，易于扩展的，适应需求变更的，可插拔的；还有很重要的一点，为了便于帮助销售拿到订单，它应该是界面华丽炫酷的，并且可以迅速生成，配置的，它应该能够在拿到需求之后的数日甚至一日之内就可以华丽地呈现在客户的眼前并已经能够直接使用，甚至，可以现场在客户的面前根据客户的需要用非常便捷的方式直接通过浏览器定义和调整界面。这，就是标题里提到的所谓“快速开发”和“0代码开发”。 

说到这里，顺便说一下MOSS。我们并不是要自己去发明一个MOSS。我们的目的，依然是开发一个拥有完整代码的系统，而不是像MOSS那样，哪怕MOSS是栋大厦，我们能做的也只是在上面装修。他们应该各有不同的应用场合，否则微软也不用推出ASP.NET MVC2；而之前强调过的易于扩展的特点，实际上就包括了如果需要的话，我们的开发辅助平台应该可以让我们的系统和MOSS快速的整合。例如MOSS的各种Webpart的开发，列表，工作流的应用等，也应该可以通过我们的开发辅助平台来高效定义或实现。而这些，应该是技术积累的目标和范围之一。 

总而言之，本文首先提出了：首先，从软件公司的角度来说，软件公司需要技术积累，需要发展自己的核心技术，需要提高自己的核心竞争力；而后，技术积累的载体，尤其是对于以企业系统开发为主业的公司，首先的选择，应该是一个囊括系统基本架构，快速原型和各种开发工具在内的，能够不断提升开发效率的开发辅助平台和通用基本框架。快速开发，是其基本目标，0代码开发，则是长远目标；而在实现0代码开发之前，应该逐步地实现1。定制代码越来越少；2。客户可以用便捷的方式越来越多地直接介入系统设计和实现，尤其是表示层呈现、权限控制、数据校验规则等直接和业务相关或与用户直接交互的部分。 

结束本篇之前，先提出疑问：面对不同行业，不同业务目标，需求千变万化的系统，如何满足“通用”的要求？这里面的理论基础，将在下篇讲述。 

 下一篇：快速开发与0代码开发理论及实践（二）：理论基础----OO和领域模型驱动开发 

下下一篇：快速开发与0代码开发理论及实践（三）：从理论到实践----OO从下至上的统一模型：从数据库到界面