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