今天看到CSDN中的两个讨论贴，一个帖子在说技术经理不允许团队成员使用面向对象的方式开发程序，另外一个帖子（找不到地址了）说某个团队成员在尝试使用面向对象的方式设计和写程序，但是遭到了其它程序员的鄙视。

或许你也在郁闷，为什么跳槽了这么多公司，想学一些面向对象的开发方式，怎么弄来弄去都还是基于对象（基于面向对象框架的开发）的开发呢？我想，其中的原因可以从几个方面来说：

公司

1. 公司性质

如果公司本身就是一个面向小客户（比如制作小网站）、面向外包的小公司，或者公司并不小，但是公司的开发团队仅仅属于公司的后勤部门，开发的产品并不能给公司带来利润等等原因都可能使得开发向简单化、过程化发展。

2. 管理团队

就像前面那个网友说的，技术经理不允许面向对象开发。可能技术经理看的是项目的维护性、看的是项目的进度，而没有看到项目远期的维护性和扩展性。也可能技术经理并不反对，而他的上司是非常看重眼前利益的，技术经理也无能为力。管理团队的任何一个层次都可能会对开发模式产生影响。

项目

正因为有前面说的那些公司，导致项目往往有以下的特点：

1. 项目进度非常赶并且一个接一个。我们除了能运用成熟的开发流程、框架之外哪里还要时间思考过多的问题呢？

2. 项目的可维护性和可扩展性不重要，甚至有的项目要求就是可维护性差、可扩展性差（公司希望项目卖出去之后从客户那里获取更高的维护费用）。

3. 项目非常小，而且偏向于网站。由于网站以数据为中心、业务逻辑较少并且注重性能的特殊性，要在这样的项目中推行面向对象的开发确实是实际效果比较差的。

团队

由于公司的性质或项目的性质就导致了产生了这样的一些团队：

1. 开发人员水平参差不齐。这里的水平包括基础、经验以及学习能力。由于面向对象需要开发人员有一定时间的OO思想的积累，对于这样一个团队，即使推行了OO，不知他们之间的协作会有什么问题呢？

2. 开发人员没有良好的OO背景。有些人以前是做ASP的，有些人以前是做VB的，可能对于做ASP.NET的开发人员来说有ASP和VB背景的人比较多。这样的话就会导致难以整体转化开发思想，即使转换了，代价也比较大。

3. 团队中没有对OO经验丰富的人，或者从组织结构上说，团队中并没有设计师的角色，项目经理手下都是普通“老百姓”。

4. 团队的学习气氛不好。很多团队死气沉沉，上班-下班，团队中也有很多年龄较大的程序员，要在这样的团队中推行新的开发思想确实很难。

5. 团队过于庞大。

6. 更极端的情况是，团队中所有人都是只会增删改的初级程序员，而项目经理完全不懂技术（招聘的时候只求工资低，面试只看是不是会使用控件进行增删改）。

技术

如果团队已经习惯了基于过程化的开发，那么要向面向对象开发进行转换还需要解决非常多的关键问题：

1. 持久化

关系型数据库和领域（业务对象）模型之间有比较大的差异，我们不得不依靠一些ORM框架来实现业务对象的持久化，ORM框架的性能、ORM框架的学习难度、ORM框架的可靠性都是在把框架应用到项目中需要考虑的问题。

2. 对象呈现

业务对象往往是相互关联的复杂结构，而UI往往是平面化（一维或二维）的趋向于关系型数据库一种表现方式，这个转换过程可能会很复杂，所谓的面向对象是不是没事找事把关系型数据转化为业务对象，再把业务对象格式化成UI喜欢的数据源（比如DataTable）呢？

3. 性能

前面说的2点都可能会产生性能问题。首先，表现层是否需要完整的业务对象，其次，是否需要从数据库中获取完整的业务对象。如果界面上只希望显示10K数据，而ORM框架却从数据库中获取了100K数据并且把它们都传给了表现层，是不是不太合理？如果说还引入了分布式的话，那么网络上传输的代价就会更大。从小的层次来说，面向对象本身就或多或少降低了性能。

主观原因

如果上述这些客观原因都不存在的话推行面向对象开发还有难度，那么可能还有一些主观原因存在：

1. 给自己很多不使用OO的理由。拿到项目了，总是想项目太小、进度太紧，算了这次不尝试OO了，以后遇到其它项目再来尝试吧。没有小项目的思考，怎么能遇到大项目而不慌乱呢？

2. 没有责任心。希望尽快结束项目，在项目可维护性变得很差连自己都不想维护的时候往往也是我们引咎辞职的时候。

3. 没有转换的动力。大家沉浸在一个不错的过程化开发过程中，宁可愿意把维护的工作留给新来的同事也不愿意去尝试新的开发过程。

理想的环境

你或许一直在寻觅这样一个环境：

1. 不错的公司，从事大型企业级软件的开发，有着经验丰富并且开明的项目经理。

2. 项目周期长、项目大且复杂，客户对项目的维护性和扩展性要求比较高。

3. 团队中不乏经验丰富的构架师和OO达人，团队讨论气氛良好。

4. 有完整的基于面向对象的解决方案，开发流程非常正规。

说实话在国内确实很少。很多时候，我们能看到的也仅仅是在表面上非常好，而在真正的开发过程中发生扭曲的环境。

说说我们的情况

1. 项目是为公司的产品服务的，团队的产出不会给公司带来直接利润，也不是公司的技术核心。

2. 团队不大，团队成员水平相差较大，以我为90分的话，那么团队中有20分的，也有80分的。几乎所有人都有非OO语言的背景，也可以说是由于ASP.NET而接触C#的，而不是由于C#而基础ASP.NET的，导致基本没有任何OO概念。

3. 项目都是不超过2个月的超小项目，甚至会有很多2天的“项目”（其实就是做一个页面）。项目基本都是以数据为中心的网站，而且对性能要求非常高。项目对时间要求非常苛刻，说好这个时间点连一天都不能晚。

基于这些情况，我思考了很久还是决定以一套学习曲线低的构架、流程来开发这些项目。不过，这并不是说我们永远就是过程化开发了，我会在时机成熟的时候把一套合适的面向对象开发流程推给团队（请注意这里的“时机成熟”以及“合适的”两个词）。个人认为，只要有明确的开发方式、相对成熟的开发框架，上面的3点并不能挡住我们OO的脚步（“我们”仅指我们团队），只不过，我还在寻找一个合适的切入点。

讨论

基于这些客观或主观原因（其实，往往这些原因是交错的，因为这个也就产生了那个），真正面向对象的开发（包括完善的开发流程）在国内大多数公司（包括我们公司）中难以推行，（由于快下班了，我并没有过多去思考改善的方法）请大家讨论…………（本文只是总结一下现况，并不表达过程化开发和面向对象开发的优劣）