敏捷架构思考

分享到

敏捷架构思考

作者：陈晴阳 ,发布于2011-11-17

1、敏捷软件开发不需要架构设计？

相对于传统瀑布式开发过程及RUP这样的重量级开发过程而言，敏捷软件“重视与客户的沟通；小步快跑，尽早交付；迭代式开发，拥抱变化”等实践正好符合互联网要求快速迭代、坚持以用户为中心的设计（UCD）等特征相吻合，因此敏捷软甲开发过程成为了互联网软件开发的标准模式。

一直以来都觉得敏捷软件是“轻架构设计”的，不管是XP、Scrum、FDD、Getting Real等敏捷软件开发过程对待设计（Design）的理念都遵循了演进式设计 (evolutionary design) 而非计划性的设计(Planned Design)。

而且由于类似于Ruby on Rails、SSH（Struts+Spring+Hibernate）、Django、CakePHP这样快速开发架构的出现，技术架构已经成为流行的术语，一个刚毕业的小孩也能够大谈架构设计、设计模式、架构模式，传统的架构设计似乎已经没有太多的必要。

但在实践过程中，会发现轻架构设计的一堆严重后果，诸如：陷入了"code and fix" 的恶梦；系统越来越复杂和混乱，架构完全失控；

再读Martin Fowler的《Is Design Dead?》，才发现自己对于敏捷软件的理解是如此的教条：

Continuous integration、testing 和 refactoring 这些有效的实作方法让 evolutionary design 看似很有道理。但是我们尚未找出其间的平衡点。我相信，不论外界对 XP 存有什么印象，XP 不仅仅是 testing、coding 和 refactoring。在 coding 之前还有 design 的必要。部份的 design 在 coding 之前准备，大部份的 design 则发生在实作每一项详列的功能之前。总之，在 up-front design 和 refactoring 之间可以找到新的平衡。

大师不愧为大师，能够准确把握住事物的本质，能够把握住过犹不及的度。其实任何方法论都有其应用的边界，方法论没有问题，错误的根源在于使用方法论的人的教条主义。

2、形形色色的架构

“架构”这词成为了一个技术领域时尚的话题，每一个人都在谈论架构，似乎不谈架构就没有技术品位，于是乎出现了一堆与架构有关的术语，包括：软件架构（Software Architecture）、系统架构（System Architecture）、企业架构（Enterprise Architecture ）、信息架构（Information Architecture ）、应用架构（Application Architecture ）、IT架构（IT Architecture）、产品架构（Product Architecture）、业务架构（Business Architecture）、技术架构（Technology Architecture）、解决方案架构（Solution Architecture）、基础架构（Infrastructure Architecture）、领域架构（Domain Architecture）

3、敏捷架构

敏捷模型驱动开发(Agile Model Driven Development)中对于Agile Architecture Modeling有比较清晰的描述，也回答了为何在敏捷软件开发过程中需要进行架构设计的原因：

1）、Improved productivity. You can think through some of the critical technical issues facing your project and potentially avoid going down fruitless technical paths.

2）、Reduced technical risk. Your team gains the advantage of having a guiding vision without the disadvantage of having to overbuild your system – just because you’ve modeled it doesn’t mean you have to build it.

3）、Reduced development time. Initial agile architecture modeling enables you to make better cost and time estimates for your project, two pieces of information which management will want.

4）、Improved communication. Having a high-level architecture model helps you to communicate what you think you’re going to build and how you think that you’ll build it, two more critical pieces of information desired by management.

5）、Scaling agile software development. Your initial architecture model will be a key work product in any "agile at scale" efforts because it provides the technical direction required by sub-teams to define and guide their efforts within the overall project.

6）、Improved team organization. Effective teams are organized around the architecture or line of business, not around job function. As you scale to larger and/or distributed teams the sub-teams should each be responsible for one or more sub-systems — you don’t want to organize your sub-teams around job function (e.g. an architecture team, a development team, a testing team, …) because that requires you to increase the documentation and bureaucracy overhead which in turn increases risk, cost, and time to value.

相对于其他的敏捷软件开发过程，在Agile Model Driven Development（AMDD）中明确包括了初始需求分析与架构建模，这个过程发生在敏捷项目开发的第0次迭代中。所谓第0次迭代，就相当于项目的热身活动，是项目得以启动的基础。

Agile Enterprise Architecture 中谈到了敏捷软件架构的一些指导思想：

1）、Focus on people, not technology or techniques

2）、Keep it simple

3）、Work iteratively and incrementally

4）、Roll up your sleeves

5）、Look at the whole picture

6）、Make enterprise architecture attractive to your customers

4、关于架构的一些思考

4.1、架构！=技术架构

敏捷架构并不只是指技术架构本身，正如前面提到的，还包括产品架构、业务架构、信息架构、应用架构等等。

技术架构不单纯只是技术实现本身，还承载了业务架构、产品架构、信息架构、应用架构的具体实现，纯粹的技术框架本身没有太多的价值。纯粹的技术框架的架构可以一次性完成，但对于业务架构、产品架构的架构必须随着公司对于行业深入的了解才能逐步完善，对于业务需求的管理能力成为一个公司发展的决定性因素。

对于一个运营型的互联网公司，核心的竞争力之一在于对所服务的行业业务及客户深刻的理解并具备将这种行业经验转化为产品及服务的能力。互联网在服务过程中积累的不单纯只是技术架构的积累，更为重要的是行业需求的积累，而这需要对应的业务架构和产品架构来作为持续积累的框架。技术架构可以较为容易获取和变迁，但行业经验却难以短期突破。

对于中国这些互联网公司而言，基本上没有太多原创的产品，尚没有能力做到技术驱动、创新驱动的层次，大家还停留在做简单的行业应用上，公司间的竞争基本上也停留在应用开发能力及运营能力的竞争。因此对于中国互联网公司而言，合理的业务架构及产品架构比技术架构本身意义更为重要。

4.2、架构是管理出来的，而不是架构出来的

在中国公司比较典型的情景：

1）、公司原有架构师及开发人员因为某种原因离职，公司招聘一个新的架构师

2）、新的架构师被公司寄予较大期望，由于维护老的架构吃力不讨好，而架构师要急于证明自己的能力，最为简单有效的办法就是重做一套系统。

3）、新的架构师将原有的架构推倒再重新做一遍，并承诺了完美的架构：能够解决目前产品、运营、财务人员们面临的所有问题

4）、新的架构上线后架构师及技术人员不断应付开发新的需求和迁移老的需求，疲于奔命，没有精力去整体把控架构，于是将架构的维护权限移交给每一个开发人员

5）、销售、运营、财务发现与当初承诺的需求不符合，投诉不断；架构师认为已经完成系统架构，剩下的都是开发的问题、产品的问题

6）、新的架构被否定掉，开发人员们或是离职或是沉沦

7）、同样的悲剧不断上演

一个好的架构不是一蹴而就的，没有一个架构是一次性完美地架构出来的，完美架构的诀窍就在于持续维护、持续完善。任何架构都有一个从孕育->诞生->成长->成熟->衰退的演进过程，没有经历风雨的完美架构只能是温室中的鲜花。

对于架构的持续完善不单纯只是一个技术问题，而是一个研发管理的核心问题，架构的完善应当贯穿于市场管理流程、需求管理流程、产品研发流程各大流程中。对于架构的管理必须有专门的组织机构、流程制度来保障。