分类： IT业界
2012-06-12 16:33:25
技术访谈
受访人 采访人
概要
架构是什么？架构设计就是设计接口吗？如何成为一个好的架构师？架构种类很多，开发人员如何选择？如何划分用例的粒度？架构设计过程中一定要引入很多的文档吗？如何将需求转化成一个良好设计的架构？UMLChina首席专家潘加宇和资深咨询顾问温昱和读者分享了他们对这些让人迷惑的问题的看法。
受访人简介
潘加宇，UMLChina首席专家，北京大学硕士，1999年创建UMLChina，研究需求和设计技能，2002年以“聚焦最后一公里”的方式，对外提供UML需求和设计的技术指导和训练服务。
温昱，资深咨询顾问，软件架构专家，著有《软件架构设计》，松耦合空间网站创办人。作为资深咨询顾问，已为众多知名企业提供了卓有成效的培训与咨询服务。
请二位向大家自我介绍一下。
潘加宇（以下简称潘）：大家好，我是UMLChina的潘加宇，很高兴能有机会和大家在这里交流。
温昱（以下简称温）：大家好，我是温昱，现在是专门来做这个软件架构的培训和咨询，是去年的时候从公司辞职，专门来做这一块。之前涉及的行业比较多，从金融到航空领域到操作系统，之后涉及到这个电信、多媒体，包括最后我服务的一家企业是做平台。从去年开始专职做这个架构的培训和咨询之后，也积累了一些相关的客户，大家对我的这个培训和咨询的反馈，使得我更有信心把这块做下去，谢谢大家。
我们今天讨论的主题，就是说是从需求到架构这样的一个过渡，那么我想请问一下二位，到底说软件开发这边，我们经常会提到一个词是架构，在二位的心目中架构到底是个什么？
温：我来说一下个人看法，整个软件架构这个领域还是很年轻，在业界当中关于架构的定义个数很多。我们在业界，也就是说是实践者，我们会为它归类，第一大类我把它叫做结构派，在我的书籍上也会提到；第二大类叫决策派，第一大类基本上可以说软件架构等于组件加交互，传统的说法是架构等于组件加交互，加约束。伦巴斯先生为这个经典的定义又加入了最新的元素，他说架构等于多个结构，那么每个结构等于组件加交互，加外部可见属性，这个也是在我们业界当中呢，架构的定义认可度最高的一块。第二种类型是决策派，他的典型就是RUP提出的这个定义：软件架构是一系列有层次的这个决策，它包括了哪些种类等。这是两个流派，但是这两个流派绝对不是矛盾的，我们实践当中的确如此，或者说从这个实践的主体、客体角度来解释一下，那组成派就是关注实践的客体，软件本身；那决策派关心的是软件主体、架构师，这两个概念本身是非常好的统一的。请加宇谈一谈。
潘：温昱这些知识应该比我要丰富得多，因为我只要关注的是需求和设计的这个技能和细节上面，架构对我来说是比较宏大的一个概念，但是我记得Martin Fowler曾经在书里面，对架构模式书里面说，架构这个词是最容易混淆的一个东西了。架构是什么，不同人有不同说法，这个我们很多公司里面都有架构师，也有接触过很多架构师头衔的开发人员，但有的实际上就是部门经理，有的人是项目经理，喜欢自称架构师。所以这个概念是比较宏大的，那我在我理解来说，架构应该是一些对某个软件的类型来说，比较稳定的一些东西，他是从很多个项目里面提炼出来，就像我们这个人，还有那个脊椎动物都有骨骼一样，你不管人怎么样，长得怎么样，里面的骨骼的机制是一样的，那这些东西可能跟具体的一些项目是没关系的。那正是因为它没关系，所以一旦我们一个团队选定了一个架构之后，我想这个架构上面的变化就不应该很大，而是应该重点就把这个精力放在业务上面，这是我对这个架构的看法。
好的，那目前有很多人有这么一个误解，认为架构设计其实就是设计接口，那么基本上就引入到设计模式的问题，那二位对这方面有什么看法呢？
温：看来InfoQ还是很专业。的确，我和客户接触这么多呢，我发现非常非常多的这个开发出身的程序员，往往是抱以这种观点，我这里还会有相关的案例，那我这个客户还是微软的合作伙伴，他负责架构，后来也在咨询我这个问题。那温老师，您说是不是我要把这个架构设计好，是不是直接要考虑哪种设计模式呢？我们说这里面是有误解的，直接考虑设计模式问题很大。设计模式也好，接口也好，是架构设计成果当中非常关键的部分。但是我们整个架构设计的活动，前期还有更加关键的因素。或者这么说，从我的培训来讲，我关注三个环节，依次，首先是从需求向架构过渡这块，这个环节呢，我们业界有一些具体的说法，包括国外的这个统计，说架构师面对的需求有很多需求是衍生需求，系统分析师未必能够看到这些需求，甚至直接有统计数据出来，这个一般的做出来的需求和我们架构师面对的需求，这个数量是不在一个数量级之上的，于是我们比较强调从需求向架构设计过渡这个环节。再比如说，这个环节当中会关注一个问题，就是说需求的数量非常的庞大，那么我们架构师没有足够的时间，把所有的需求分析透彻，这时候怎么办呢？也是我们从需求向架构设计过渡当中非常重要的问题；第二个环节是概念架构设计，这个词汇本身，大家可能会觉得生疏，但是整个业界、国际业界都是这么做的，概念架构设计，我这里提一点，就是这个架构模式。架构模式什么时候引入的？和设计模式的引入绝对不在一个层面。所以说概念性架构还是很关键的，我这里已经提到了架构模式的一个典型。
那么到了架构设计的后期阶段，才会考虑这个接口以及我们的这个设计模式等等，我们把它叫做细化架构设计，这一块工作量自然是最大的，也会用到业界，非常标准的这种多视图的设计方法，这是谈了对刚刚的这种业界比较流行的这种架构设计，就是设计接口和设计模式，这样一种观点。我们强调比较体系化的方法，需求进，架构出，是每个架构师非常非常关心的一个这种结果。那么中间怎么做？大致呢我的看法是三个环节相相环套。
刚才说三个环节，是什么？
温：第一个环节就是从需求向架构过渡，这个往往要看经验；第二个概念架构设计，工作量不大，但是对后期影响非常大；第三个就是大家一般看到的这种细化的环节。
那跟平时说的那个需求分析设计有什么区别？除了中间多了一个架构这两个字之外，他们的具体的区别在哪里？是什么？
温：需求设计，设计在整个国际生产层次，架构设计和详细设计，这种我谈得是架构设计的内部的一些工作，也就是说呢，外部的朋友看到架构师仅仅是设计出来了架构，但我们架构师到底是怎么做得，那我们通过这种整个业界最佳实践的这种总结，包括我们个人的10年的经验的这种加入，最终我们认为架构师所做的工作会包括大致三个环节。
那比如说拿一个RoR的那个项目，那比如说刚才那几个环节的话，他们产出的工件是什么样的工件呢？或者是一个Java项目也好，包括现在流行的Ruby的ROR项目，应该出什么样的工件呢？你的观点呢？
温：这个问题在内训的时候也经常问到。第一个环节从需求向架构过渡，不产生整个企业可见的工件，它会反应在这个架构设计文档当中的一项，就是需求的权衡考虑；那第二块呢，概念架构设计依然，它的工件本身呢，不是说正式的工件，有个概念架构设计文档，虽然我们会用这个概念架构设计的成果去做这个像投标的工作啊，但是他本身是没有专门的这个工件产生的，也是反应在架构设计文档当中，比如概述部分。倒是这个第三个阶段，细化架构设计，它产生的文档是真真实实的这种，特别是居于多视图的架构文档。
潘：那我对这方面的话，就是架构方面我了解的并不是很多，主要还是关注技能上面.但还是我刚才那个观点就是说，很多还是细节上的问题，宏观上面的话，我们把握的是一个问题，但是很多时候出问题是在细节上。所以细节上的话，温昱在这方面有什么看法呢。
怎样再成长为一个比较好的，能够把握从需求到系统架构这些经验，有什么好的提高的方法，以及平时要注意什么？
温：加宇提到一些很具体的问题，我这里说一个例子。那我这个客户是微软的合作伙伴，他在做架构的时候呢，我跟他说你早期要考虑一个很具体的问题，就Server的问题，你不要认为你做得是一个整体的应用，你要考虑，你的这个用户的这种数量这么大，你整个系统未来是一个很大的系统，你怎么样在最早期的时候关注把整个系统划分成不同的硬盘，而不说一大块硬盘。包括后面他会涉及到一个很具体的问题，他说我怎么样管理我的这个用户状态，他会是做社区，他的用户呢，他告诉我两大类，第一类微软的客户，MSN的这个注册用户；第二类是我自己社区的注册用户，他会问我这个用户的状态怎么管？我说我之前不是跟你说了吗，你要考虑Server的问题，你要考虑是不是有些问题可以抽取出来，现在你这个上下文有很重要的一个可以利用的一个技术平台，就是微软的MSN，已经做得非常不错了，那么你会问自己一个问题，为什么你要亲自来管用户的状态？我给他的建议是让微软帮你做，怎么帮？他已经帮你了，微软整个MSN Messenger，它会把用户的状态管理起来。那么你可以做一个非常非常细节的调整，我在用户注册的时候，必须要求用户提交MSN的帐号，最终你做用户状态管理的时候，只需要做一个封装，MSN有专门的这个Notification Server，就是管理用户状态的，是实时的管理，你封装起来，你是他的合作伙伴，一定会非常完善的把这个状态管理起来。的确，加宇说得很对，每个层次的工作都有很多这个细节的工作，包括架构设计，架构设计虽然是解决很宏大的问题，但是有非常非常多的细节，也会依赖我们架构师的经验把它解决好。
我们现在引到一个新的问题，那就是从需求到架构的过渡环节中，有什么比较典型的案例分析呢？
温：从需求向架构过渡，实际上这个很巧，是我明天演讲的一个话题，我在演讲当中也会举一个案例，那我提一下。这个案例是我特意设计的，因为我发现这个分层架构大家怎么用的，用来用去，展现层、业务层、数据层这种方式。我们说呢，架构模式不是拍脑袋出来的，也不是说直接照抄的，我们的系统到底有什么样的特点？这时候你要考虑它到底是什么样的分层架构，到底分几层。那我们做平台的时候要做七层架构，我这里案例当中呢，它的背景是压缩，背景是压缩，我们要做压缩系统、压缩工具，这时候在这个内训的时候呢，很多的学员呢，也会做出来使用经典的三层架构出来。最终呢，实际上我们培训的目标是要告诉大家，先分析后综合，架构模式是分析出来的，不是拍脑袋和照抄过来的。你去分析我的系统会涉及到什么职责，最终架构模式会把这些职责非常好地、非常有秩序地这个组合起来。这里提到一个观点，提到一个综合，做我们的这种架构模式的规划。其他方面呢，时间关系也不便展开。听听加宇的意见。
潘：实际上我能谈的就是说这个从需求往设计方面走，那这里面经常会有很多误解，就是说很多开发人员觉得我只要学那些设计的技术就可以了，比如说设计模式、对象分析的思想等等。但实际上这里面真正的瓶颈不是设计的技术，也不是建模技术。你要做好，实际上你需求是问题域，相当于提出问题，相当于出题。那我们的这个设计相当于把那个题目给做了，做到这个需求，满足需求的这个结果，那这本身的话，从问题跳到解决方案本身它是鸿沟，有一道鸿沟，这鸿沟计算机是无法帮我们推导的，所以才需要开发人员来推导，而鸿沟下面是可以推导的，你说现在的模型，你自动，像有些嵌入式的系统，他们状态以及模式，就直接就执行了，他不会有人工编码的，因为人工编码会引进危险的。那也就是鸿沟下面的这部分，就是说跳到解决方案之后的部分，是可以计算机自动过渡的，难度在于就是说如何从问题跳到第一步这个解决方案，这部分只能靠我们人脑。那么这个人脑只有我们的系统分析原理，用架构师的大脑。他一方面要具备业务知识，第二方面要具备这个建模的技术，你要掌握一种建模技术，要么是面向对象的，要么是以前的结构化分析和设计都可以，这两个都可以。但是想想最终的瓶颈，我认为还是在这个业务知识上面，你说对象基础你掌握到一定程度，它里面的原则都知道了，那对象基础里面的原理、原则、模式，原理不就那么几条吗，原则也就十几条，模式上千个，这些都融会贯通就没有问题了。但实际上即使你掌握了原理，也没用，为什么？你怎么面对对象分离变化？那这个口号都会喊了，但实际上真正的难点，真正的细节上的难点，你怎么知道那个是变的，那个是不变的，那你必须要对业务有一个很透彻的了解。所以很多开发人员他以为学那个就可以了，所以真正瓶颈都在这里。就是说如果我们对业务没有一个很贴切的，对这个业务内涵没有一个透彻的理解的话，实际上最终出来的模型肯定还是不好的，所以就是说不管怎么样，一定要对业务有透彻的理解，这才能够做好这个从需求到架构的过渡。
关于这个架构这些种类吧，目前有这样四种，一个是业务架构，一个是信息架构，一个是应用架构还有技术架构，这个二位怎么看呢？
温：这个提法是企业架构领域当中的一种架构框架，它具体提出来的就是业务架构、应用架构、信息架构和技术架构，实际上作为我们架构师一定要认识到一点，这四种是架构视图。我们说整个业界做软件架构设计，很多视图的方法已经在IEEE1471标准当中已经明确推荐的，怎么样描述架构，怎么样思考架构。那么企业架构（EA）这一块是架构的一个很重要的分支，他也会提出来自己的方法，这个提法应该是企业架构设计方法的这种多视图的方法，不是四种架构，这个问题也很典型。
我在写软件架构设计这本书的时候，我的一位朋友问我，温昱你写这本书是写什么架构？我说呢，我知道你是怎么想的，你认为架构分几种，那么我想告诉你，是我们架构设计方法当中把它分成了视图，只不过我们在实践当中不想说这个业务架构视图，实际上是视图的概念。这个概念呢，我们生活当中也会有很有意思的例子，互联网是一个非常非常大型的系统，他的架构视图在哪里？为什么伊拉克战争的时候，报纸上会说这个软件行业，这IT行业真的很棒，对不对？这样一个国家会轰炸的非常厉害，但是消息依然能够通过互联网发送出去，怎么样，包的存储转发。但是在这个一年之前吧，台湾光缆断裂事件，使得我们的这个互联网受到了非常多的媒体的批评，这问题怎么理解，为什么刚刚还是很好的，现在突然变成很坏了？可以通过我们架构视图的这个思维角度去解释它。互联网这个系统它的逻辑架构设计的非常棒，包的存储转发机制就是当中一个非常非常好的想法，那么我们的互联网呢，它的这个物理架构或者叫部署架构设计有问题，恐怕是这个基于成本的考虑，我只在那个非常容易发生地震的海峡部署了一条关键路径的这样一个光缆。于是断裂了之后影响互通性，这是我对这个架构视图的一个看法。
潘：我对这个没有什么看法，主要还是在细节上，着力我还是说这个。
那就是RUP这边呢，他提出有一个四加一的视图，然后中间有一个很重要观点就是，有一个很重要的概念就是说用例视图，然后这里边呢人们经常会对这个用例视图里边的一个粒度会产生一些疑问，那我想问一下，就是说二位在这个对用例的粒度这方面怎么划分？二位有什么样的看法？
潘：那这个问题实际上也是我被问得最多的，也是大家问这个用例问的最多的，实际上这个涉及到一个很关键的问题，就我们为什么我们要使用用例这种方法？不是说有人拿出来推销，也不是说最终一定要用这个，否则不时髦，那是被逼无奈，就是我们现在的以前这种捕获需求的方式已经不够了，如果还够的，包括架构设计一样，如果说以前的方法还灵，还够用，我们为什么要用它呢？那是因为没办法，谁也不想多干活，但是问题是什么？不行了，市场经济了，你不这样想是不行了，所以这种新方法，这种更好的方法它主要的目的就是说首先必须要把重心放在社众的这一端，然后来揣摩社众的真实的用心，比如说你用例用得对不对，关键点就是有没有加强我们和社众之间的联系，那么从这点来看，用例的粒度应该就不成问题了，用力实际上就是一个契约吗，就是系统能够为我们提供什么样的契约，那么这个契约到底是多大多小合适呢？完全是取决于社众对他的看法。
那实际上大家想象一个问题就明白了。比如说经常我会有人问的，比如说我们去医院，以医院为研究对象，挂号算不算用例？那实际上这个问题，如果说能回答对，为什么你说是，为什么是？不是，为什么不是？能够回答对，基本上就已经理解了这契约的含义。答案是不对，不是。那为什么呢？不是说挂号没价值，而是说在涉众的心里面，医院能够向他承诺的契约，不只是挂号那么简单。如果说你只是挂完号，涉众觉得这个医院的契约已经完成了，那么显然很可能这个人就不是病人了，可能是“黄牛党”去挂号，那么医院很可能会为“黄牛党”提供挂号的服务，但是为病人提供的，他向病人承诺的，以及病人对医院的这种期望，它远远不只挂号这么简单。因为我们研究对象是医院，所以医院他的契约是看病，但是如果说我们转换一个研究对象，比如说挂号室，那么挂号就是他的用例。为什么？因为病人他不会说因为挂号室只给他了挂号，不给他看病，他会骂这个挂号室。他不会，那么这个就是我们首先为什么会有粒度的看法，是因为很多时候，我们头脑里面的概念模糊掉了，才会有粒度的看法，那么头脑里面概念很清楚，就是说首先破解的关键，就是说你的研究对象是什么？只要讨论用例的时候，第一个事情是要问，你到底目前的研究对象是什么？很多人觉得这个事情没价值。比如说，我们再举一个例子，比如说有一人事管理系统，那么我们的员工在这个系统里面请假，交请假单，然后老板要批假，然后人事部门要备案，这三个事情完成之后，才能算是请到假。那经常就会有人认为，真正的用例是什么？是请假，为什么？在员工看来呢，能够请到假而且回家了，才算是达到了目的。但实际上这个目的的时候，当他这样说的时候，他头脑里面已经把他的研究对象偷偷的改变掉了。他把系统还有他的上司还有人事部门那人绑在一起，作为一个研究对象，实际上这只有这几个东西才能够向他承诺能请到假，系统本身是无法承诺让他能请到假的，他只能向他承诺什么？他把请假单交进来，然后他把他行起来，那么这个才是系统的契约，如果说在这个地方有模糊，那么实际上我们只要问一个问题，我们的研究对象是什么，就可以了。
那么第二个问题是经常会有人问了，就是比如我现在一个Email，发Email的一个系统，那么这个研究人员也很清楚了，那么到底发邮件、收邮件是两个用例呢？还是收发邮件是一个用例，这是一个最常问的问题，类似的问题，那是很简单，标准答案在涉众的心里面，没有标准答案，就是说你在涉众看来收邮件、发邮件是两个事情还是一个事情？这个没有答案的，那到底是两个事情还是一个事情？我问大家的话，大家肯定会说，肯定是一个事情，不是的。那么前两天我刚经历一个项目，就是两个事情，那么这个用户，汽车的用户，他对收邮件是很在意的，这个用例是摆在什么？很高的位置，但发邮件，他并不想在汽车上发邮件，点点的他不能，他也不想，这个需求是很低的，很可能这个版本根本不需要这个功能。主要是两点，第一个，我们的研究对象是什么？这个是能破解力度问题；第二个就是说剩下的问题交给涉众，我们就去揣摩社众的心意，其他的就没有标准答案了，不管怎么样都是对的。
目前二位谈到的这些一些传统架构设计方法，会引入很多的文档，然后目前社区里边有另外一种呼声是说，我们要减少这些面面俱到的文档，然后让尽量精简这样的设计，然后就让代码，就把代码作为一种设计，那二位对这方面是怎么样一个看法呢？
温：发散谈一下吧。代码里面肯定是藏着设计的，包括我的职业生涯中有时候是拿到大量源代码，前面的工作是前任做的，文档很差，人走掉了，这时候怎么办？最终依然推进下去了，因为代码里面有设计，我也会和大家分享，一些读代码的技巧，第一要借助建模工具，正逆向工程；第二怎么样删代码，当你要读程序的时候，删代码是很好的一个技巧，把不关键代码删掉，你读出代码当中的架构；第三接触重构，有些核心代码，大家去改它的时候，不敢乱碰，只是在很小心地增加，最后充满了这种注释，Modify by谁谁谁，对不对？最终我们说读核心代码的时候，可以借助重构的方式，把相关的名称，相关的职责都可以调整划分开来。
再谈另外一点，很多时候，我会见到一些入职的员工，他们去画类图等等，他们直接从代码当中找到类图，这些类图本身是设计不错，但是我们说如果细节高了价值是不大的。你画和这个工具逆向出来有什么差异吗？所以说我们在考虑设计的时候，未必是把所有的细节的这种依赖都画出来，这是设计或者说直接整个代替这种设计文档的一种做法的不妥之处，任何时候你的细节程度一样，那么你的图和代码没什么区别，这时候倒是说这个代码就是设计，这块会有一定的问题。画出蜘蛛网式的图永远是有问题的，包括UML当中的每一种图，一定要有相关的抽象，才可以方便交流。
潘：对这方面的话确实也有很多的话语，因为这毕竟是一个很吸引人的一个说法，如果代码可以设计就可以不写文档，这个本身我也没什么意见。我的观点就是说，世界上有各种各样的团队，各种各样的项目，没有一个统一的标准，如果说代码能当文档用，可以不写文档那很好，但很多时候我们还是我刚才的说法，不是我们自己想做而喜欢做，谁想多干活呢？很多时候就是被迫为之吗，你不得不干，那么这种很多很多。所以就是说如果能够少做一点，那当然好，但是很多时候是必须要做的，那么Ivar Jacobson他以前也是，推断的RUP，那么后来他也发现大家用的时候很多误区，就是说经常会人问说，有没有一个团队完完整整实施RUP？经常会有这样问，但实际上RUP这种东西他不是让你完完整整实施的，是要经过团队的特点来裁减，那么在团队的特点来裁减的话，按道理来说，整个世界上不应该有两只团队，他们的过程是完全一样的，就是该出什么样的文档，很详细的文档还是很粗的文档，出不出文档应该是没有完全一样的。就像足球比赛一样，战术，巴西有巴西的战术，德国有德国的战术，意大利有意大利的战术，不能够说巴西队他看了意大利拿了冠军，他就学意大利，肯定不行，那么他跟团队成员的情况，跟这个项目的类型是密切相关的。所以我的观点就是说与其去争论文档多少，或者说过程应该规范好，还是敏捷好，当然敏捷这两个字就像革命一样，它已经占了这个道德上的制高点啊。但是要注意占领这个道德上制高点的东西，我们更要很谨慎的对待它，那么我不并是说敏捷不好，而是说关键还是中间的技能，如果我们的技能能上去，选择什么样的过程这个不是问题，出多少文档就不是问题；如果说是技能上不去的话，你出一个文档也是错的，包括你的代码也是错的，这些技能就是我刚刚说得一些需求的技能，就找到问题的技能，里面有很多很多的细节，设计的技能有很多很多细节，那我觉得改进的重点还是要在这个技能问题上，特别是技能的细节上。如果说像，还是拿足球举例，如果中国队有12个或者20个罗纳尔迪尼奥，那么以前的朱广沪他就不会说，为打什么样的战术而伤神。那以前朱广沪是什么？就是说中国队员上场要像疯狗一样，喊口号，但事实上对疯狗的意思讲就是要勇，后来不行了，我中国队员不但要当疯狗，还要当警犬，这些都是口号。但实际上问题的关键不在口号而在于什么？如何能从一个不再疯的狗变成疯狗，如何能够从一个很普通的狗变成警犬，这里面有很大量的技能问题，如果大家都像警犬，都像罗纳尔迪尼奥一样，打什么战术这里有很大的余地。但是如果说你手上的人，他的素质是非常低的，都是年轻球员，那很多你可选择的余地是非常小的，已经非常非常。，那实际上这里面，还是我的观点就是说技能改进为主，过程改进这个东西，或者说到底是用规范点的方法，还是包括XP好还是其他方法等，这个东西，我都不想去争论，实际上包括Ivar Jacobson，他现在说过程够了，我们实践吧。也就是说他把归纳最佳实践就用就行了，至于你该用哪一些，这本身不是很重要，每个团队跟人家是不一样的。
温：好了，我来补充一句，加宇刚才提到一个非常好的一点观点就是文档，做多少、做到什么程度要看这个实际情况，要看团队情况。那我还想补充一小点，就是还要看客户的情况，总之想看文档的人到底是什么样的角色，如果是客户就是你这个项目业主是直接外包给你，还要看相关的文档，也会考虑他的要求，总之是要看整个这个实际情况是怎么样，有没有这个去看文档的需求，可以这么说吧。
那怎么保证就是说从需求到架构这个，这是一个就是细化解释的这个过程，怎么把需求就是转化成一个良好设计的架构，就是说除了技能方面，还有什么东西能够保证的吗？
温：这个呢，大师Grade Booch大致是怎么归纳的呢？三方面，第一方面呢，就是偷，也就是借鉴业界现成的一些正确的做法或者说是成功的做法；第二种是方法，我们先说第三种，第三种就是直接靠经验或者灵感来创造。第一种是偷，第三种是创造，那么介于两者之间呢，我们刚才也提到方法。方法它不是说完全照搬，也不是说我就完全创造，它会有一些理性的分析，也会权衡怎么样来做这件事情，大致来讲，这个Grade Booch已经帮我们回答这个问题了。
