架构师修炼

架构师修炼II 表达思维与驾驭方法论世界上最难的两件事是：将别人口袋的钱放到自己的口袋里面；将自己脑子的想法完整放到别人的脑子里面。

在大家的印象中，项目经理是项目中沟通得最多的角色，其实架构师的沟通量也不逊于项目经理……作者：Ray Liang来源：博客园|2014-07-11 09:35收藏分享开篇之前我想先说说当年开发的那点事儿：大约10年前吧，我还是一个程序员的时候经常都是遇到这样的项目开发流程：∙解决方案：满足客户目的和投标用的一堆文档（不少还是互联网上抄的），是以Word为主的纯文字。

∙投标完成和客户付订金后项目组成立，通常为（0至1）个项目经理或者叫项目负责人+（1至N）个程序员的项目组模式∙设计：由项目的头或者经验最足的成员参与编写设计。

倒霉的时候我们会得到一份按照软件工程学的纯中文形式的设计想法(抱歉我只能这样来形容)，而更糟的情况是得到一份完全看不懂的Rose文档（那个年代可是UML大放异彩的时代，而当时我对UML完全就是个瞎子）∙开发：到这里才有我参与的份，前面的内容通常作为项目组中低层的人员是不透明的。

得到“设计”后，我们只能靠自己的“猜想”来实现，最后拿着界面给经理看是否符合他的“设计要求”。

∙测试？这项目是没有的，只要程序能跑通直接就交付了。

项目的结果不言而喻，最多的沟通就是吵架与被训斥还有就是被客户抱怨。

在这种例子很可笑，但更可笑的是至今我还听到不少的朋友跟我说起这种类似的苦B经历。

他们不是没有设计，不是没有沟通也不是没有管理，只是每个人都在用自己方式在表达，没有共同的语言和沟通方式。

那么换个沟通能力很强大的项目经理会改变这种境况吗？可能可以，但遇到最多的只能是改善，只是苦B这个角色换成项目经理而已，因为本质上没有多大的变化。

我很感恩能有这么让人难受的开发经历，因为太难过了所以才促成当时的我去想办法，去学习最后努力去改变。

接下来的部分会是我将这10多年来的经历进行的一些总结，因为我学的东东很杂当时在大学里根本没有这些知识只能靠在项目实践中摸索前行，我受MSF与敏捷开发的影响很大，并且我是一个反UML人士，但我并没有完全去采用某一种标准化的开发方法与开发流程，长年来只是以我对这些方法论的理解应用到我的项目里，而在这里我不想过多地讨论关于开发方法论与项目管理的内容，而只是将其中与架构和设计相关的内容抽取出来论述。

表达思维架构师的职责世界上最难的两件事是：将别人口袋的钱放到自己的口袋里面；将自己脑子的想法完整放到别人的脑子里面。

在大家的印象中，项目经理是项目中沟通得最多的角色，其实架构师的沟通量也不逊于项目经理。

在国内更多的情况是架构师与项目经理就是同一个人。

作为系统/项目的总设计师，并不是单纯只为客户想出技术解决方案然后做出一份设计扔给项目组就完事了，而需要向每个位参与项目的成员或角色从不同的层面介绍或解释设计原意与理念。

有效沟通本文的主要内容说得简单一点就是架构师销售自己的设计的一些方式与方法。

除了开发能力与设计能力以外“有效沟通”也是架构师的很重要一项技能。

架构师与项目经理不同主要工作时间与精力不是全放在沟通上，但如果沟通不当就会出现因为反复沟通而大量消耗架构师的设计时间，甚至设计出让人难以理解的架构，就算设计本身的含金量再高，在没有找到伯乐之前也只能处于“曲高和寡”的尴尬局面。

我之所以将沟通看作一项修炼的另一个原因是这些内容都是从书看不到的，只能从实战中摸趴滚打慢慢积累而成，不同的经历可能也会有不一样的看法与心得，而接下来就是我积累多年的一点经验的总结：如果说开发流程是大的迭代那么设计就是经历一次次的小迭代以至于完善，项目的每个参与者的想法与建议都是架构师修正设计，积累迭代的参考来源,。

所以，架构师的沟通是需要双向激荡的。

我按照项目中与架构师沟通频率最高的角色、掌握的技能、信息的需求进行了归类，这样将更便于了解怎么样的沟通方式最为有效：销售∙沟通的需求：从设计中寻找卖点与特色，丰富销售方案和定制预售计划。

∙知识技能：对开发或深入的技术内容可能只存在于概念性的理解、掌握市场的第一手信息并且对客户的需求最为了解。

∙推荐工具：特色列表(Full Feature List)，字段：特色功能(Feature)+说明(Summary)以产品开发（做项目会省事，没有这一步）为例，我与销售讨论整个产品的最具有特色的10项目功能（实际上3项就够了，实践告诉我只有前3项是别人记得最深刻的），这10项特色我们又称之为“购买理由”，然后是整个系统全部特色功能（Full Features）。

我经常会与销售因为某个特色功能而经常激烈地碰撞，但最后销售所提出的意见与建议往往发挥着最重要的作用，有时甚至直接影响到项目的可行性。

修练的法门：∙抛弃一切技术实现细节，写/说出产品最重要的三个特色∙抛弃一切技术实现细节，用心聆听“非专业”的意见这项修炼看起很简单，重于练心，做起来对于专业技术人员并不是容易的事，细节决定成败，往往最简单最不引起注意的人或事可能是一个关键点。

项目经理∙沟通需求：根据设计进行时间估算、准备项目资源与工作分解。

∙知识技能：大多是熟悉体系架构类的知识（需要了解他/她是偏向于技术还是管理），热衷于沟通与跟踪∙沟通工具：Excel∙图形工具：架构图、原理图项目经理是架构师在项目中最重要的伙伴，因为他在负责跟踪与保证你的设计被实现的全过程，是项目资源的提供者与进度的控制者，他需要了解每一个检查点(CheckPoint)与里程碑(Milestone)，这也是项目经理与架构师最重要的连接点（Connection Point）。

我与项目经理讨论得最多的是系统实现的原理和实现各部分可能存在的难度和可能发生的风险。

修炼法门：用最简单的图形视觉化设计以下这两个图是我为数不多的公开项目中可以拿出来作为示例的，我用的设计工具是Excel：图例1：技术架构图例2：应用程序架构注：这两个图例是我的一个多年的开源项目DotNetAge CMS的架构图，有兴趣的朋友可以访问GitHub或者DotNetAge (英文)官网了解其它的相关内容开发∙沟通需求：根据设计要求进行技术准备、部署开发环境、编写DEMO以及最终编码，关心自己所负责的技术细节与实现方法。

∙知识技能：掌握或精通特定的开发工具及开发技巧∙沟通工具：范例代码∙图形工具：序列图，状态图，类图与开发人员沟通是最困难也是最有思想激荡的环节，开发人员就像是小朋友一般富有尝试新事物的胆气与想法，在没有制度与行政压力的作用下要让他们完完全全“遵守纪律”可不是一件容易的事。

我并不认为架构师或者项目经理在地位与行政上要领导其它的成员，这种“自然层级”并不利于沟通，反而容易让项目组变成“一言堂”。

我认为与开发人员有效沟通的最佳方法就是“用代码说话”，这也是为什么我在第一篇文章就提出架构师也需要是一个代码控的另一原因。

我们交付到开发人员手上的都是空的公共接口或是公共类，开发人员是不能随意改动任何接口、类、方法的命名的，这是一种最基本的约定，否则就乱套了。

另外就是针对核心、多人使用、原理复杂的代码必须带有代码范例。

代码范例就是与开发人员产生讨论与激荡的专用区域，也是为以后加入项目的人员提供的快速入门的最好途径，可以在很大的程度上降低不可见的、难实现、高风险代码出现的机率。

修炼的法门：一边设计一边写范例代码，让范例代码成为设计的一部分测试∙沟通需求：根据设计划分测试粒度、测试的覆盖范围、准备测试环境、定制测试计划∙知识技能：掌握各种测试方法、对Bug的所在有着天然的直觉。

∙沟通工具：类使用参考∙图形工具：架构图，序列图，状态图，类图我认为测试人员的架构能力往往并不亚于任何的架构师。

能从常规化测试（单元测试、界面测试）发现问题是最为初等的测试人员；能从系统性能、流程或架构中发现问题的测试靠的是经验，阅历甚至是一种直觉或者说是能“嗅”出问题的所在（在下一篇文章中我将会详细解释这种能力的源泉），这才是高级的测试人员。

与测试人员的沟通与开发有点类似，只是当没有高级的测试人员配置时，架构师也只能充当这个角色，作为软件的设计师是最能了解自己的系统可能存在的问题，在沟通时这些“问题”就是沟通的重点，必要时需要反复地观察测试报告的结果，以找出“隐患”所在。

在这里，所谓的修炼法门与上一点基本相同。

在此只对常见角色进行大至的分类，按我们采用的开发方法不同可能还会存在更多的其它角色如：RM（发布经理），TM（技术经理）等等就不作一一细分了。

驾驭方法论前文更多在探讨如何向不同角色的人去表达自己的设计与思想的一些方法与见解，而作为架构师自身的能力也由为重要。

对方法论的掌握、理解与实践就成为架构师真正的“本钱”，用流行一点的语言就是所谓的“核心价值(Core Value)”。

我是一个很愚钝的人，10多年来读了很多的这方面的知识但真正能理解并用起来的也就两三个，实在是由于环境、阅历所限，很多理论没有特定的环境也只能当小说看。

通过对各种方法论的学习, 我悟到了一个心得：“ 方法论的学习曲线是迭代的，也就是说同样的理论在经过不同的经历后再次重新学习就会有更深入的理解和新的领悟。

”单单是《设计模式》一书我就从来没有停止过迭代式的学习与实践，而每一次实践我都能得到一次新的领悟与体会。

我会在下一篇文章中讲述我认为最有迭代学习价值的方法论。

接下来就说说我认为在设计中很用的一些方法论，以及我对这些方法论的一些总结。

框架理论“框架”一词近年来随着.net framework 的成功推广感觉上都被用烂了，什么东东都会加上个XXX框架，可能是源于市场需求吧。

我接触“框架”这个词或者说这个理论是在.net 诞生以前，在开始探讨框架之前，我在WhatIs 上找到了一段在软件框架方面比较贴切定义：原文：In general, a framework is a real or conceptual structure intended to serve as a support or guide for the building of something that expands the structure into something useful.In computer systems, a framework is often a layered structure indicating what kind of programs can or should be built and how they would interrelate. Some computer system frameworks also include actual programs, specify programming interfaces, or offer programming tools for using the frameworks. A framework may be for a set of functions within a system and how they interrelate; the layers of an operating system; the layers of an application subsystem; how communication should be standardized at some level of a network; and so forth. A framework is generally more comprehensive than a protocol and more prescriptive than a structure .From 译文【Ray】通常地一个框架是为了解释如何构建某项有用的事物及其结构的实现或概念的一份支持或指南。