开始之前先说说当年的开发：大约10年前，当我做程序员的时候，经常遇到这样的项目开发过程：解决方案：A一堆文档（很多都是从网上复制过来的）满足客户的目的和出价，主要是Word纯文本。投标完成，客户支付定金后，项目组成立，一般为（0对1）项目经理或项目负责人+（1对N）程序员的项目组模式设计：项目组长或最有经验的成员参与编写设计。运气不好的时候会得到一个纯中文形式的按照软件工程的设计思路（不好意思我只能这样描述），更坏的情况下会得到一个完全看不懂的Rose文档（时代是UML大放异彩的时代，那时候我在UML完全是个***）开发：只有这里是我的参与。作为项目组的中低层人员，前面的内容通常是不透明的。拿到“设计”后，我们只能靠自己的“猜测”去实现。***给经理看界面是否符合他的“设计要求”。测试？没有这个项目，只要程序能跑通，就直接交付。项目的结果不言而喻，最多的沟通就是吵架，被客户训斥和抱怨。这种情况很可笑，但更可笑的是，我听很多朋友跟我讲过类似的惨痛经历。不是他们没有设计，没有沟通，没有管理。只是每个人都在用自己的方式表达，没有共同的语言和沟通方式。那么换一个沟通能力强的项目经理就可以改变这种情况吗？可能是可以的，但是遇到最多的只能是改进，但是苦B的角色换成了项目经理，因为本质上并没有太大的变化。我很庆幸有这样一段难受的开发经历，因为它太难过了，促使我想办法，去学习，去努力去改变。下一部分将是我过去10年的一些经验总结，因为我学到的东西非常复杂。那时我在大学里没有这些知识，只能靠项目实践前进。受过MSF和Agile开发的启发，我是一个反UML的人，但一直没有完全采用某种标准化的开发方法和开发流程。多年来，我只是将我对这些方法的理解应用到我的项目中。而这里我不想过多讨论开发方法论和项目管理，只是把架构和设计相关的内容提炼出来讨论一下。世界上最难表达一个有思想的架构师职责的两件事是：把别人口袋里的钱放到自己口袋里；把自己脑子里的想法放到别人脑子里。在大家的印象中，项目经理是项目中最善于交际的角色。事实上，架构师的沟通量并不逊色于项目经理。在中国更多的情况下，架构师和项目经理是同一个人。作为系统/项目的首席设计师，不仅仅是给客户想出一个技术方案，然后做一个设计，丢给项目组。介绍或说明设计的初衷和概念。EffectiveCommunication本文的主要内容，简单来说就是，建筑师推销自己的设计的一些方式方法。除了开发设计能力，“有效沟通”也是架构师非常重要的一项技能。与项目经理不同，架构师和项目经理不会把所有的工作时间和精力都花在沟通上，但是如果沟通不当，架构师的设计时间就会因为反复的沟通而被消耗，甚至会设计出一个看不懂的架构，即使设计本身无论含金量多高，在找到伯乐之前，都只能处于“高而寡”的尴尬境地。我之所以把交流当成一种修行，还有一个原因就是这些内容是书本上看不到的，只能从实战中慢慢积累，不同的体会可能不一样下面是我多年积累的经验总结：如果开发过程是一个大的迭代，那么设计就是要经过小的迭代来完善。项目中每个参与者的想法和建议都很重要。它是建筑师修改设计和积累迭代的参考来源。因此，建筑师的交流需要双向鼓动。我按照在项目中与架构师沟通最频繁的角色、掌握的技能、信息需求进行了分类，这样会更容易理解什么样的沟通方式最有效：销售沟通需求：从中寻找卖点设计具有特色，丰富的销售计划和定制的售前计划。知识技能：开发或深入的技术内容可能只存在于概念上的理解、对市场的第一手信息和对客户需求的最佳理解。推荐工具：FullFeatureList,Field:Feature+SummaryFeatured10itemfunctions（其实3条就够了，实践告诉我只有前3条别人最记得），这10条feature也叫“购买理由”，然后是整个系统的所有特色功能（FullFeatures）。我经常会因为某个特性与销售发生激烈的碰撞，但***销售提出的意见和建议往往起着最重要的作用，有时甚至会直接影响到项目的可行性。实践方法：放弃所有技术实现细节，写/说出产品最重要的三个特性放弃所有技术实现细节，认真听取“非专业”意见。对于专业的技术人员来说，这不是一件容易的事，细节决定成败，往往最简单最不起眼的人或事可能就是重点。项目经理沟通需求：时间估算、项目资源准备和根据设计工作分解。知识技能：大多熟悉架构知识（你要知道他/她是偏技术还是偏管理），热衷于沟通和跟踪沟通工具：Excel制图工具：架构图、原理图项目manager是架构师在项目中最重要的伙伴，因为他负责跟踪和确保你的设计实现的全过程，是项目资源的提供者和进度的控制者，他需要了解每一个检查点（CheckPoint）和里程碑（Milestone），这也是项目经理和架构师之间最重要的连接点（ConnectionPoint）。我和项目经理讨论最多的就是系统实施的原则和实施各个部分可能遇到的困难和可能存在的风险。练习方法：用最简单的图形进行可视化设计下面两张图是我能拿来举例的几个公共项目的例子。我使用的设计工具是Excel：图1：技术架构图2：应用架构注：这两张图是我多年的开源项目DotNetAgeCMS的架构图。感兴趣的朋友可以访问GitHub或者DotNetAge（英文）官网了解其他相关内容开发交流需求：根据设计需求进行技术准备，部署开发环境，编写DEMO和最终编码，关心技术细节和实现方式你负责。知识技能：掌握或精通特定的开发工具和开发技巧交流工具：示例代码图形化工具：时序图、状态图、类图与开发人员的交流是最难、最发人深省的环节，开发人员就像孩子一般满具有尝试新事物的勇气和想法，要在不受体制和行政压力影响的情况下，让他们完全“自律”，并非易事。我不认为架构师或项目经理必须在地位和管理方面领导其他成员。这种“自然的等级制度”不利于沟通，反而容易让项目组变成“独来独往”。我认为与开发人员有效沟通的最佳方式是“用代码说话”，这也是我在第一篇文章中提出架构师也需要是代码控制者的另一个原因。我们交付给开发者的是一个空的公共接口或公共类。开发人员不能随意更改任何接口、类或方法的命名。这是最基本的约定，不然就乱套了。此外，针对核心、多人使用、原理复杂的代码必须有代码示例。代码示例是与开发者讨论和鼓动的专门区域，也是未来加入项目的人快速入门的最佳方式，可以大大减少看不见、难实现、高难度的情况发生。-风险代码概率。实践方法：边设计边写示例代码，让示例代码成为设计的一部分测试沟通要求：根据设计划分测试粒度、测试覆盖率、准备测试环境、定制测试计划是关于错误在哪里的自然直觉。交流工具：类用法参考图形工具：架构图、时序图、状态图、类图我认为测试人员的架构能力往往不亚于任何架构师。能从常规测试（单元测试、接口测试）中发现问题的，是最初级的测试人员；能从系统性能、流程或架构上发现问题的测试，是靠经验、经验甚至是一种直觉或能力“嗅出问题”（我会在下一篇文章中详细解释这种能力的来源），这就是高级测试员，跟测试员的沟通和开发有点类似，只是在没有高级测试员配置的情况下，架构师只能扮演这个角色，作为软件设计师，他最能了解自己系统可能出现的问题。沟通，这些“问题”是沟通的重点，必要时还需要反复观察检测报告的结果，找出“隐患”所在，这里所谓的修炼方法基本相同如上一点，这里我们只对常见的角色进行粗略的分类，根据我们采用的开发方式不同，可能还有更多的其他角色如：RM（ReleaseManager），TM（TechnicalManager）等c.，不再一一细分。.#p#ControlMethodology上一篇文章更多的是如何表达一些方法和见解，如何向不同角色的人表达自己的设计和思考，架构师的能力也很重要。方法论的掌握、理解和实践成为一个架构师真正的“资本”，用更通俗的语言来说就是所谓的“核心价值”。我是一个很迟钝的人。10多年来我看了很多这方面的知识，但真正能理解和使用的只有两三个。确实是环境和经验所限。许多理论只有在没有特定环境的情况下才能使用。把它当作小说来读。通过对各种方法论的学习，我领悟到：“方法论的学习曲线是迭代的，就是同一个理论，经过不同的经历再学习，会有更深的理解和新的感悟。”我一直没有停下脚步独自一人对《设计模式》这本书进行迭代学习和实践，每次实践都能得到新的理解和体会。我将在下一篇文章中描述我认为对迭代学习最有价值的方法论。接下来我会讲一些我认为在设计中非常有用的方法论，以及我对这些方法论的一些总结。框架理论近年来随着.netframework的成功推广，“框架”这个词被用坏了。一切都会加上一个XXX框架，这可能是市场需求所致。在.net诞生之前，我就接触到了“框架”这个词或者说这个理论。在开始讨论框架之前，我在WhatIs上找到了一个更合适的软件框架定义：结构变成有用的东西。在计算机系统中，框架通常是一种分层结构，表明可以或应该构建什么样的程序以及它们将如何相互关联。一些计算机系统框架还包括实际程序、指定编程接口或提供用于使用框架的编程工具。框架可能针对系统中的一组功能以及它们如何相互关联；应用子系统；如何在网络的某个层面上标准化通信；等等。框架通常比协议更全面，比结构更规范。构建一些有用的东西并实现其结构对或概念的支持或指导在计算机系统中，框架通常用于描述程序应在其中构建的层次结构。一些系统架构甚至会包括实际的程序、接口或开发工具集。框架可能是指一组相关的功能集合，操作系统中的一些层，或者是子系统中的一层，或者是网络中某个层结构下的标准化通信方式等。框架通常比一个框架更全面协议定义，比结构定义更具规范性。在设计上，我对框架的理解是：框架是用来定义和锁定对某个概念的理解和实现的边界。在既定的边界下，它可以体现在它的实现中，并且可以迭代地演进一个设计。导则是架构师手中的总体设计蓝图。这是我喜欢使用的一种方法论，微软在MSF中的FunctionSpec（功能规范）与它有些相似。它是第一次以技术架构的形式细化用户需求的输出。我喜欢这个方法论的原因是它“简单”、“高度灵活”，不需要标准化（标准化的东西不需要设计，只需要应用，就是一种模式），只需要掌握两个原则。构建整体图（BuildAWholePicture）在阅读框架文档时，即使忘记了所有内容，只要能将整个设计图印在读者的脑海中，目标就达到了。这是一个指引，也是思考的起点。一张共同的图片自然会引出共同的讨论点，锁定设计与话题的边界。也是系统演进的重要依据。定义边界（CompressiveDefinitions）所谓边界，其实就是对要绘制的模块的功能进行清晰明了的文字描述，让读者在建立全景蓝图后能够深刻理解各个部分的具体含义，从而深化系统意识。从如何学习入手，最简单的方法就是从你熟悉或了解的系统入手，重新画出它的框架。然后把你知道的每一部分的定义放进去，你会发现你对现有的系统建立了一个新的认识。至于工具，可以用最原始的纸笔，熟练后Excel就可以了（想更漂亮可以用PhotoShop）。最重要的一点是不要让工具分散你的注意力，所以要保持简单。至此，如果你开始尝试这种方法，你可能会明白为什么我需要在本系列的开头花这么长时间来解释先成为架构师和成为代码控制者的必要性，因为从蓝图开始需要两者超越语言限制并且需要对语言有扎实的理解。UML如果你想成为一名架构师，UML是必修课。相关的资料和学习资源非常丰富，相关的学习方法也非常人性化，掌握就好，这里就不赘述了。在这里，我只是想分享一下我在学习和使用UML方面的一些心得。首先，在开始UML之前，你必须非常熟悉面向对象的所有基本概念，否则基本上就是浪费时间。然后是选择性学习。毕竟，UML是一种非常古老的方法论。即使到了2.0版本，如果真把所有的UML理论作为核心开发指导，那也是很坑爹的。是重武器！看看年度最佳X设计工具：Rationalrose虽然功能强大，但我觉得它更像是一个玩具。他所谓的文档，只有设计师才能看懂。用例基本上是一个集成了丑陋和非人类思想的图形。我基本不用，因为他是在和人交流，在整理自己的想法。显得极其不便，还不如直接用文字写两句说明问题（纯属个人吐槽）。UML是设计常识或用来建立通用设计语言，但不要将其用作蓝图。它在发现类、抽象接口、理清类之间或类与类之间的关系和交互方面起着重要作用。我的方法是只学图形不学过程。设计让人看得懂，不需要安装专门的UML工具。优秀的IDE一般都有一些基本的UML图形工具，比如：VisualStudio。总之：UML只是一种通用语言，“灵活运用就好”。设计模式设计模式是架构师解决复杂问题的双刃剑。如果用得好，问题可能会大大简化，甚至巧妙地解决，但如果用得不好，也可能导致系统架构不可控地膨胀，变成糟糕的设计。面对设计模式的概念，我们需要以清醒的态度去面对它。当我们了解或掌握了某种模式后，肯定会有尝试的冲动，但请不要将这种头脑发热的行为套用到设计上。冲动做一个实际的例子。毕竟理论的掌握和实践的理解会有一定的距离。如果将这种肤浅的认识直接投入到设计中，一旦使用不当，就会导致类的规模无法控制而造成设计错误。上面这些话并不是让大家不用设计模式，而是需要谨慎使用，灵活运用，理解透彻后再使用。为了掌握它们，我不得不吃很多苦。这里我总结了一些应用经验供参考：clearMotivationDon'tbepatternforpattern'ssake。模式本身是为解决某个问题领域而提出的高度抽象的对象模型。每个模式都会有使用动机的清晰描述。这种动机是否符合我们的实际需求是衡量其适用性的标准。使用该模式前，建议先独立创建一个项目。以TDD方式实施模式并同时对其进行测试。虽然网上有很多模式实现的“套路”，但很多写的比较乱，能用的不多。唯一值得推荐的是EnterpriseLibrary。也加了MS的实践，可以说是设计师入门的宝库。EL的代码虽然很多，但是按照我在第一篇文章中提到的读代码的方式学习起来也不会很难。在开发人员使用项目的公共接口和类之前，架构师最应该做的就是模型测试。对于采用设计模式的架构，最有效的文档是示例代码，可以避免解释内部原理的时间。开发者用能用的人就好了。另外，作为设计者本人，编写示例代码可以验证设计的准确性和正确性，也是编写测试用例的重要参考指南。通过示例代码，我们可以同时向两个角色（开发、测试）交付实际的设计结果。理解组合效应标准的23种模式并不是独立存在的，模式之间的互通往往会产生1+1>2的效果。但同时需要注意的是，提高使用效果也会增加系统的复杂度。设计模式是架构师的伴侣，她就是为解决问题和简化问题而生的。纵观23种模式，都比较注重不同场景下的耦合度、封装度和易用性。因此，我测试模式使用效果的简单标准是：耦合度是否降低？接口是否隐藏了实现细节（封装）？对外接口实现简单吗？设计模式浓缩了设计大师的思想和经验精华，不是一本速成的设计手册。我们需要模式是因为我们还没有总结出自己的最佳设计实践，这需要我们长期积累实战经验。有了设计模式，我们就可以站在大师的肩膀上进行设计和创作。反复研究设计模式，学会理解、掌握、使用，直到忘记模式，一切水到渠成。那就是建筑师自己的设计领域和空间。大家都知道测试在测试驱动（TDD）中的重要性，但是很少有人将其应用到实际中并贯彻到整个开发过程中。可能是“测试”的可选择性和“QuicklyandDirty”的思想让测试没有被放在绝对重要的位置。说实话，我也是最近两三年才充分体会到TDD给我带来的便利和重要性。尤其是在设计大型项目时，架构师再强，也不可能考虑到全面的细节，尤其是代码实现。MOQ等工具库的出现也非常有助于我模拟类实现后的效果，可以直接测试模型中可能存在的隐式或显式问题而被忽略。测试在团队开发过程中的作用更为普遍。一个好的测试流程可以让项目经理在没有沟通的情况下了解每个CheckPoint的完成情况；它允许架构师模拟实现、测试类模型和编写使用范例；它允许开发人员拥有最少的代码运行入口；如上所述，一个高级测试人员的设计能力可以与架构师比肩，他们可以从表象中发现架构中隐藏的问题。是不是架构师也应该具备相应的高级测试能力？显而易见的答案是肯定的。架构师最起码需要掌握试驾相关知识，至少懂得单元测试、序列测试的编写以及使用MOQ模拟接口实现等基本测试方法。总结在这篇文章中，我并没有像上一篇那样给出一些具体的方法，因为这篇文章所讨论的更多的是对自己一点点经验的总结，更多的是来自于思考。我以自己有限的写作能力尽量表达了这种意识和思考，但最后还是觉得有很多内容可能不够详尽，或者大家可以尝试通过实践来检验我以上的理论。而在下一篇文章中，我会更深入地探讨我认为是设计中一个高层次的内容：“变化”。***同一句话：敬请期待。
