企鹅客户端团队经历过3代架构:
  第一代,2006年以前企鹅的老客户端:客户端采用com技术,一个类达到3w行代码。为什么会有3w行代码的类?因为com结构易学难精,而且使用极其不友好,在系统内部模块之间采用这套架构维护和实现成本都很高,而项目的需求和团队的惰性双方面的结果就是臭虫越来越多。最后不可控制,不可维护,到了2008年不得不重构。
  第二代,2007年猪猪的架构,引入factory模式,实现接口在dll上的物理分离,采用表现层,逻辑层,网络层简单架构划分。因为未做系统解耦方面的设计,我可以推测,我们继续3个月出一个版本,估计在1年后,系统可维护性就告急了。
  第三代,2008年企鹅的架构,在factory模式基础上引入插件化架构,并且对底层服务进行了良好的解耦设计,设计的系统是以变化的和稳定的部分进行系统划分。
  因为本系统进行了插件化设计和基础模块的解耦,模块内部有臭虫,可以实现内部重构,而不影响整个系统,系统提供了比较好的重构条件,当然可维护性也大大提高。
  不过这个系统也有一个缺陷就是插件的创建和节点的创建不友好,这样,在惰性作用下,在产品的需求压迫下,我们逐渐写入一些臭虫的代码,而且随便把这些臭虫代码放到现有的插件中。
  第四代,这一代架构还在实施中,先保密,其目标也是提高客户端团队的敏捷性,提高产品的可运营性。具体实现后续介绍。
  我想一个在架构上具有持续敏捷性的项目应该具有如下几个特点:
1)一个简单易于使用的,易于扩展的原始架构。
  敏捷思想中提到架构是不断的开发过程中重构出来,这一点要我们这样的环境下,技术层次下实施几乎是不现实的。架构固然需要演化,进化,但是要在小规模的不断重构优化一个原始难用的架构,使其敏捷,对我们的团队水平几乎是不可完成的。而进行完美的架构设计也同样在成本,以及架构对未来的实用方面都有极大的不确定性。
  所以我个人倾向于选择一个易于使用的,易于扩展的架构,而不是完善的,全系统的设计架构,因为我们的产品是运营出来的。
2)团队leader重视重构,具有系统设计思想
  能够正确的决策支持重构,支持系统设计,最好是leader自己具有极强的系统抽象能力。
3)团队重视架构和程序结构。
  团队时刻的重视系统设计,重视维护和重构代码,要做到这一点很难,需要长期的团队建设。
4)项目pm和pd在风险可控范围内,鼓励重构和技术创新。
  在项目需求的过程中,PD设计产品时,有重心,在评估系统实现时,考虑开发团队的意见,对系统结构有破坏性的需求,性价比不高的需求适当调整和妥协。
  PD在产品规划的过程中,如果有一个较为长期的系统规划,这有利于团队架构设计的前瞻性,和技术预先的准备。   
  在开发过程中,适当考虑系统的重用性,和重用性系统开发应给予给多的资源,风险可控范围内,适当鼓励重用性设计。
  其实总结起来,只有一句话,原始架构和维护这个架构的团队,呵呵,说了等于没有说:)