领导力大挑战
在实施Scrum项目的过程中，Scrum Master的角色是相当关键的，因为他是团队的推动者。本文围绕什么是仆人式领导、仆人式领导的起源、如何将领导力传达给团队、Scrum Master作为仆人式领导者的角色展开叙述，同时重点阐述仆人式领导者应有的基本内外特征。
技术访谈
该内容已经被标记书签！
标记书签错误，请重试！
录制于：
张逸谈如何评价架构的优劣
受访人 张逸 采访人 刘申 发布于 2010年8月16日 长度 00:31:17 下载 MP3
概要
张逸是《软件设计精要与模式》的作者，在采访中他谈到如何理解架构师的角色，架构师和项目经理在项目中的分工，软件工程师在向架构师转型过程中的挑战，最后根据自己的实践重点谈到了如何评价架构的优劣。
个人简介
张逸，曾任HP中国系统架构师，具有十余年的软件开发、设计和管理经验，曾先后担任高级软件工程师、项目经理、系统架构师、技术总监等职务。主要擅长.NET技术，包括 C#，ASP.NET，.NET Remoting，WCF，LINQ等。精通OOP技术以及设计模式与架构设计。熟悉UML以及用例驱动开发和AOP技术。同时在项目管理尤其是敏捷软件管理方面具有比较丰富的经验。2006及2007届微软Connect System Developer的MVP。著作包括电子工业出版社出版的《软件设计精要与模式》，以及译著《WCF服务编程》。
关于会议
MPD大会是中国软件研发管理者自己的年会，是本土操作实践与海外研发经验分享的年会，主要面向以下软件开发管理人士：首席技术官（CTO）、研发总监、产品经理、开发主管、测试经理等与软件研发团队密切相关的领导成员。
张逸是《软件设计精要与模式》的作者，在采访中他谈到如何理解架构师的角色，架构师和项目经理在项目中的分工，软件工程师在向架构师转型过程中的挑战，最后根据自己的实践重点谈到了如何评价架构的优劣。
个人简介
张逸，曾任HP中国系统架构师，具有十余年的软件开发、设计和管理经验，曾先后担任高级软件工程师、项目经理、系统架构师、技术总监等职务。主要擅长.NET技术，包括 C#，ASP.NET，.NET Remoting，WCF，LINQ等。精通OOP技术以及设计模式与架构设计。熟悉UML以及用例驱动开发和AOP技术。同时在项目管理尤其是敏捷软件管理方面具有比较丰富的经验。2006及2007届微软Connect System Developer的MVP。著作包括电子工业出版社出版的《软件设计精要与模式》，以及译著《WCF服务编程》。
关于会议
MPD大会是中国软件研发管理者自己的年会，是本土操作实践与海外研发经验分享的年会，主要面向以下软件开发管理人士：首席技术官（CTO）、研发总监、产品经理、开发主管、测试经理等与软件研发团队密切相关的领导成员。
我叫张逸，是麦思博（MSUP）的金牌讲师，主要负责架构和设计的培训和咨询工作。在今年的上半年，我刚刚完成我这本书的第二版。目前从读者的反馈来看，这个书本的情况还是比较满意。我对开发和设计架构的经验，大约有十年左右的时间，先后在中兴通迅、惠普和中软国际工作，担任的职务也有普通的开发人员、软件开发工程师、架构师、项目经理、技术总监，在技术这块很多角色我都担任过，主要是在.NET方向有一定的经验，是2006年到2010年连续四年的微软的MVP。同时，我主要是在基于架构和设计掌握了一定的知识，也愿意和大家一块来分享架构和设计这一块，我的一些心得体会，谢谢。
说到架构师，从在技术方面讲，它应该是很高的一个级别。我们都知道软件的这个架构是从建筑学里边引喻过来的，我们称为架构Architecture，架构师是Architect。那么相对于建筑行业来说，架构师就相对于是建筑的设计师。但是软件行业，它跟建筑行业还有很大的区别，那么从我们业界来说，从几个不同的视角来看，一般的架构师可能会把它分解为，业务架构师、系统架构师、软件架构师。那么整体来看，我可以打一个比方，比如说这个项目是坐在一个车上，项目经理就是这个开车的司机，那么架构师，他的职责应该是来规定汽车的行驶的路线，保障在这个车在整个行驶过程中不会出现任何问题，并且能够毫无障碍的最后能够达到我们的目标位置，我觉得架构师就应该在把握整个技术，这个项目的方向，行驶的方向。
那么他的职责，首先从技术方面，要非常满足客户需求。同时，在非功能需求方面，也能够满足要求的这样一个解决方案。
第二，他是要在业务和技术人员两者之间搭建一个很好的桥梁。在日本的外包开发里面，把架构师有时候称为Bridge，桥梁的工程师，它的意思就是相当于把架构、技术和业务之间搭建一个沟通的桥梁，怎么样把业务需求给理解分析，得到我们的领域模型。同时，再把这个分析后得到的结果用模型设计出来。设计出来之后，由我们的开发人员来进行实现，这是第二方面。
第三方面应该是一个技术的带头人，就是负责在项目当中出现的技术问题，我们的开发人员应该首先通过架构师得到比较好的指导的意见。
第四个应该是作为一个规划师，就像我们整个改革开放有一个规划，几步走，分几步走，这样一个规划。那么对架构师来说，更多的是着眼于大局，而不是细节的这种实现，尤其是针对产品开发来说，产品研发来说，有一个产品线的这样一个规划，这个整体的规划，我认为是架构师非常重要的一个职责。
那么他的职责，首先从技术方面，要非常满足客户需求。同时，在非功能需求方面，也能够满足要求的这样一个解决方案。
第二，他是要在业务和技术人员两者之间搭建一个很好的桥梁。在日本的外包开发里面，把架构师有时候称为Bridge，桥梁的工程师，它的意思就是相当于把架构、技术和业务之间搭建一个沟通的桥梁，怎么样把业务需求给理解分析，得到我们的领域模型。同时，再把这个分析后得到的结果用模型设计出来。设计出来之后，由我们的开发人员来进行实现，这是第二方面。
第三方面应该是一个技术的带头人，就是负责在项目当中出现的技术问题，我们的开发人员应该首先通过架构师得到比较好的指导的意见。
第四个应该是作为一个规划师，就像我们整个改革开放有一个规划，几步走，分几步走，这样一个规划。那么对架构师来说，更多的是着眼于大局，而不是细节的这种实现，尤其是针对产品开发来说，产品研发来说，有一个产品线的这样一个规划，这个整体的规划，我认为是架构师非常重要的一个职责。
首先，不同的开发团队，不同的开发周期，选择不同的软件开发生命周期，可能在职责方面，他们的关系方面是有些区别的。从传统的软件开发管理来说，比如说瀑布式的、迭代的、RUP的，这些方面的组织结构相对来说，不是一个平行的结构，是有一个上下级的这种关系。但是在这种团队里面，项目经理和架构师应该是两个不同的关系，一方面是一个上下级的关系，也就是说架构师还是要向项目经理来负责，项目经理负责安排架构师的一些工作，这是一方面的关系。
但是另外一个更重要的关系是，架构师和项目经理应该是一个Partner的关系，就是合作的这种关系。因为项目经理是负责整个项目管理这一块，他更多的是操心的是怎么完成项目的进度，进度的安排，任务的跟踪，还有跟客户的协调。而架构师则是从技术方面以及业务的分析方面来完成，所以他们两个在这个层面上来说，应该是一个平行的这种关系。但是在很多敏捷的团队里边，因为这个角色的划分就不是很清晰。例如以Scrum来说，那么Scrum Master就相当于是我们传统所谓的项目经理，但是他的管理的职责权限被弱化了很多，而更多的是起到一个指导以及配合的这样一个作用。同时Scrum Master主要是负责把我们这个团队，把Scrum这个团队能够更好的运作起来。那么在这个团队里面，就没有所谓架构师这样一个职责，那么也许每个团队成员可能都会成为架构师。像这样一个情况的话，根据我以前呆的项目来看的话，如果我们过于强化这种架构师的这种角色，有可能会对我们整个团队，会造成一定伤害。像这种情况，我们就需要每个团队成员，发挥自己的这种自主能力，以平行的方式，在设计方面，更多的是以协作的方式，而不是以管理的方式来完成，这是我的一个理解。
但是另外一个更重要的关系是，架构师和项目经理应该是一个Partner的关系，就是合作的这种关系。因为项目经理是负责整个项目管理这一块，他更多的是操心的是怎么完成项目的进度，进度的安排，任务的跟踪，还有跟客户的协调。而架构师则是从技术方面以及业务的分析方面来完成，所以他们两个在这个层面上来说，应该是一个平行的这种关系。但是在很多敏捷的团队里边，因为这个角色的划分就不是很清晰。例如以Scrum来说，那么Scrum Master就相当于是我们传统所谓的项目经理，但是他的管理的职责权限被弱化了很多，而更多的是起到一个指导以及配合的这样一个作用。同时Scrum Master主要是负责把我们这个团队，把Scrum这个团队能够更好的运作起来。那么在这个团队里面，就没有所谓架构师这样一个职责，那么也许每个团队成员可能都会成为架构师。像这样一个情况的话，根据我以前呆的项目来看的话，如果我们过于强化这种架构师的这种角色，有可能会对我们整个团队，会造成一定伤害。像这种情况，我们就需要每个团队成员，发挥自己的这种自主能力，以平行的方式，在设计方面，更多的是以协作的方式，而不是以管理的方式来完成，这是我的一个理解。
因为之前，我在惠普有一个项目，我们在实施Scrum，但是我们原来有一种传统的，由于在公司，实施Scrum也是第一次，大家都没有经验。我们当时我们的团队成员，在开发能力方面、经验方面，还是有一定欠缺，所以当时由我来担任整个团队的架构师这个角色。但是在Scrum里面，本来是没有这个角色的，但是由于我们这个团队的特殊情况，增加这个角色。结果后来导致什么呢，就是我们这个团队，每个团队成员的这种主动性、积极性有一定的影响，他会对架构师产生一种依赖，觉得有什么问题都会去找我，出现了技术方面把握不好，乃至于从需求方面把握不好的，都会来找我，这样就会导致我们没有形成一个Team。我觉得这一方面来说，可能会造成一些影响，其实这也是在敏捷，在咱们中国有些小的公司，或者来自于一些大的公司推广起来，出现一个障碍的一个大的问题，就是我们团队成员，在能力上还很难达到每个人都够完整的来完成业务的分析、设计，最后编码实现一些测试。在宏观这个角度来说，很多人不具备这个大局观。因此，在架构方面也有很多欠缺，这是我的一个心得体会。
这件事确实是存在一个问题，我也跟很多一些刚刚踏入这个行业的程序员有过沟通，首先我问到他们的理想，如果是选择技术这块，他们的理想都是架构师。这个问题在我们这个行业来说是很突出的，我也和很多刚刚踏入这个行业的一些开发人员有过交流，我问到他们的理想，将来准备做什么，有的是想做管理，有的是想做技术。那么想做技术的这些开发人员来说，他们都很向往这种架构师的角色，应该说架构师也确实是站在技术这块是最高的级别。但是他们怎么成为架构师，在这个过程当中，他们应该做什么事情，应该怎么去往这个方向努力，其实他们都很茫然。事实上我们也知道，现在我们这个行业很多架构师，尤其是做技术的这些架构师，他们很多都是从开发人员这样一步一步走上来的。
但是在这个过程当中，有的人就倒下了，有的人就一直就是成为一名普通的开发人员，或者软件工程师，没有走上这样一个层面。原因就在于，架构师需要的能力和开发人员需要的能力还是有区别的，我们要求架构师要有实现方面能力，这跟做建筑这块不一样，建筑方面可以直接培养一个架构师，但是就我们这个行业来说，从学院里面培养出来一个架构师是不大可能的，是需要有很多经验的积累，也是要有编码的这样一些技巧，这是必须的。就是架构师必须要了解实现，但是如果停留在实现这个层面，就不可能成为一名合格的架构师，是因为架构师把握的更多的是大局的东西，是一个更高层面的、抽象方面的知识。
怎么才能成为一名架构师呢，需要在这方面有意识的培养自己，第一个培养，就是从行业这块，因为做我们这个软件行业，根据不同的领域，领域模型可能不一样，业务流程不一样，业务规则不一样。那么如果你对这个行业的业务规则、业务流程不清楚，你也很难得到一个好的理论模型，也就很难得到一个好的架构，所以从行业这方面，要有意识的培养这方面的能力。就是你可以集中在你公司所从事的一些行业，比如金融行业，或者制造行业，或者保险行业，电信、通讯这方面的行业，要有这方面的能力，你要有意识去积累。而不是要埋头光顾着写代码，而是有意识的去参与一些需求这块的理解和分析，这是我认为第一个。
第二个，就是要去掌握一些提高自己的抽象能力，提高自己的建模能力。因为架构师所需要具备的最大的、最强的一个能力，就是能够从很纷繁复杂的需求当中，从很多细节实现当中，能够去抽象出一个共同的东西出来，能够从不同的地方，能够找到共同的地方，也就是所谓的共性和可变性这样一种分析，他们在这一方面的能力把握的非常好。然后这一方面的能力，把握抽象出来以后，还要把它形成为一个模型，形成出领域模型、分析模型、设计模型，通过这个模型的方式来把它表达出来，就是我认为要有意识的要积累这方面的能力。
第三个，我认为应该有意识的、有前瞻性的去了解这方面的知识，不管是从网络上，包括像咱们InfoQ也有一个架构的专区，架构专区有很多很优秀的文章，都是国内外一流的架构师写的一些文章，可以有意识的去看这些方面的文章，或者是读一些优秀的书籍。那么从这方面来培养你在架构这一块的能力。
第四个我觉得还有一个交流，有意识的提高交流，很多开发人员为什么没有在最后成为架构师，就是因为他们很多技术人员可能比较内向，偏向于研究，偏向于和机器打交道，而忽略了和人打交道。而架构师，我刚才也说了，架构师是在业务和实现的技术人员两者之间搭建一个桥梁，这桥梁一方面是从书面的角度、文档的角度来进行协作、交流，另外一方面就是口头方面来交流，而我们开发人员在这一方面还有所欠缺。所以我认为，开发人员要最后成长为一个架构师，第一个你要把目标定好，定好之后，就要有意识的往这个方向去发展，要培养架构师具备的这些能力。再根据多做一些项目，有效的、及时的去总结这些项目的经验，或者说及时的去学习一些，因为你可能是开发人员，但是在你的项目组里边，肯定有架构师类似这样的角色存在，那么你可以有意识的向这个架构师去学习，或者说从他那个地方得到的一些东西、方案，你学会去思索，去思考，这样我觉得慢慢的从经验上去积累，从技术上去积累，从能力上去提高，慢慢的我想，给你一个好的机会，一定能会成为一名合格的，乃至于优秀的架构师。
但是在这个过程当中，有的人就倒下了，有的人就一直就是成为一名普通的开发人员，或者软件工程师，没有走上这样一个层面。原因就在于，架构师需要的能力和开发人员需要的能力还是有区别的，我们要求架构师要有实现方面能力，这跟做建筑这块不一样，建筑方面可以直接培养一个架构师，但是就我们这个行业来说，从学院里面培养出来一个架构师是不大可能的，是需要有很多经验的积累，也是要有编码的这样一些技巧，这是必须的。就是架构师必须要了解实现，但是如果停留在实现这个层面，就不可能成为一名合格的架构师，是因为架构师把握的更多的是大局的东西，是一个更高层面的、抽象方面的知识。
怎么才能成为一名架构师呢，需要在这方面有意识的培养自己，第一个培养，就是从行业这块，因为做我们这个软件行业，根据不同的领域，领域模型可能不一样，业务流程不一样，业务规则不一样。那么如果你对这个行业的业务规则、业务流程不清楚，你也很难得到一个好的理论模型，也就很难得到一个好的架构，所以从行业这方面，要有意识的培养这方面的能力。就是你可以集中在你公司所从事的一些行业，比如金融行业，或者制造行业，或者保险行业，电信、通讯这方面的行业，要有这方面的能力，你要有意识去积累。而不是要埋头光顾着写代码，而是有意识的去参与一些需求这块的理解和分析，这是我认为第一个。
第二个，就是要去掌握一些提高自己的抽象能力，提高自己的建模能力。因为架构师所需要具备的最大的、最强的一个能力，就是能够从很纷繁复杂的需求当中，从很多细节实现当中，能够去抽象出一个共同的东西出来，能够从不同的地方，能够找到共同的地方，也就是所谓的共性和可变性这样一种分析，他们在这一方面的能力把握的非常好。然后这一方面的能力，把握抽象出来以后，还要把它形成为一个模型，形成出领域模型、分析模型、设计模型，通过这个模型的方式来把它表达出来，就是我认为要有意识的要积累这方面的能力。
第三个，我认为应该有意识的、有前瞻性的去了解这方面的知识，不管是从网络上，包括像咱们InfoQ也有一个架构的专区，架构专区有很多很优秀的文章，都是国内外一流的架构师写的一些文章，可以有意识的去看这些方面的文章，或者是读一些优秀的书籍。那么从这方面来培养你在架构这一块的能力。
第四个我觉得还有一个交流，有意识的提高交流，很多开发人员为什么没有在最后成为架构师，就是因为他们很多技术人员可能比较内向，偏向于研究，偏向于和机器打交道，而忽略了和人打交道。而架构师，我刚才也说了，架构师是在业务和实现的技术人员两者之间搭建一个桥梁，这桥梁一方面是从书面的角度、文档的角度来进行协作、交流，另外一方面就是口头方面来交流，而我们开发人员在这一方面还有所欠缺。所以我认为，开发人员要最后成长为一个架构师，第一个你要把目标定好，定好之后，就要有意识的往这个方向去发展，要培养架构师具备的这些能力。再根据多做一些项目，有效的、及时的去总结这些项目的经验，或者说及时的去学习一些，因为你可能是开发人员，但是在你的项目组里边，肯定有架构师类似这样的角色存在，那么你可以有意识的向这个架构师去学习，或者说从他那个地方得到的一些东西、方案，你学会去思索，去思考，这样我觉得慢慢的从经验上去积累，从技术上去积累，从能力上去提高，慢慢的我想，给你一个好的机会，一定能会成为一名合格的，乃至于优秀的架构师。
困难应该还是抽象的能力和大局观的能力。因为我们要求开发人员的能力，就是要求他具体的实现能力，把握细节，某一个算法的一个实现，然后某一个业务流程，他怎么去实现，或者某一个技术，不管是什么语言，或者什么平台，某一个技术，比如说安全，或者是写一个Web Service，或者是写一个权限管理。在这一块来说，他们的能力是很强的，但是怎么把它提取到更高的抽象能力和大局观这块，我觉得很多开发人员都比较欠缺。
首先从技术角度先说一下，对于架构师我的看法是首先要专，然后是博。就是第一个，必须得深入去了解你所擅长的某一个框架，某一个平台，一定要专。我说所谓的专，不是说把它每个细节都掌握得很清楚，而是要把它内在的原理搞得很清楚，这样即使碰到一个新的问题，你也可以能够很快的解决。因为架构师在基础这块，要树立起技术的权威，如果你设计出来的模型你自己都不清楚，我打个比方来说，你对通讯的协议都不清楚，你怎么去做架构设计，你怎么去把握它，所以必须得专。
但是，还有一个很重要的就是要博，因为我们做架构、做软件，不一定是，一直做项目都会只用一个平台，只用一门技术，而且现在的项目，其实有一个发展，是多语言、多平台共存的这样一种发展，很多项目我们看到都有这种趋势。那么如果说你只懂一门技术，只钻一门框架，只钻一门平台，那么当需要你去集成多个系统的时候，你可能就束手无策了，所以一定要博。那么博的意思是说，由于软件，不管是什么平台，不管是什么框架，不管是什么语言，其实它的原理是相通的。由于你专了，所以你对它的语言、原理、平台的机制都很清楚，你要再去快速的掌握其他的技术，是非常容易的。但是又有区别，你需要去把握它不同的地方，同时你还可以取长补短，你可以用另外一个技术的优势来弥足你现在所用的技术的缺陷，所以这是我对技术方面的认为。
而从业务来说，你要成为一位行业的专家，当然是最好，但是人的精力是有限的。一般来说我们有两种情况，一种情况就是如果这个架构师，他一直只做一个方向，就是他一直做汽车制造这块，那他可能随着经验的积累，慢慢慢慢的，他可能会成为一个汽车行业专家。但是事实上这种情况是很少的，很多架构师可能会面对另外一个新的项目，比如说你原来做汽车制造，现在让你做金融的，那你该怎么办？所以我们一般的做法是，如果一个大的公司、大的团队，我们会有专门的领域专家，由领域专家来负责业务这块，或者由客户来负责业务这块。但是我们的架构师也必须要对业务要有一定的了解，至少你要把一些行业的术语要搞清楚，这样你才能够和你的客户和领域专家在沟通上没有任何的问题，所以我不认为说，每个架构师都必须得成为一个业务专家，但是至少你在做这个架构之前，你必须要了解这个业务，了解这个行业。
但是，还有一个很重要的就是要博，因为我们做架构、做软件，不一定是，一直做项目都会只用一个平台，只用一门技术，而且现在的项目，其实有一个发展，是多语言、多平台共存的这样一种发展，很多项目我们看到都有这种趋势。那么如果说你只懂一门技术，只钻一门框架，只钻一门平台，那么当需要你去集成多个系统的时候，你可能就束手无策了，所以一定要博。那么博的意思是说，由于软件，不管是什么平台，不管是什么框架，不管是什么语言，其实它的原理是相通的。由于你专了，所以你对它的语言、原理、平台的机制都很清楚，你要再去快速的掌握其他的技术，是非常容易的。但是又有区别，你需要去把握它不同的地方，同时你还可以取长补短，你可以用另外一个技术的优势来弥足你现在所用的技术的缺陷，所以这是我对技术方面的认为。
而从业务来说，你要成为一位行业的专家，当然是最好，但是人的精力是有限的。一般来说我们有两种情况，一种情况就是如果这个架构师，他一直只做一个方向，就是他一直做汽车制造这块，那他可能随着经验的积累，慢慢慢慢的，他可能会成为一个汽车行业专家。但是事实上这种情况是很少的，很多架构师可能会面对另外一个新的项目，比如说你原来做汽车制造，现在让你做金融的，那你该怎么办？所以我们一般的做法是，如果一个大的公司、大的团队，我们会有专门的领域专家，由领域专家来负责业务这块，或者由客户来负责业务这块。但是我们的架构师也必须要对业务要有一定的了解，至少你要把一些行业的术语要搞清楚，这样你才能够和你的客户和领域专家在沟通上没有任何的问题，所以我不认为说，每个架构师都必须得成为一个业务专家，但是至少你在做这个架构之前，你必须要了解这个业务，了解这个行业。
这个问题我觉得，应该说也是一个难题。我们也看到有很多项目，包括有很多很牛的架构师，开发团队也很好，公司也很好，但是失败了，那原因有很多，架构这一块其实是一个至关重要的。架构一般我认为从功能需求方面和非功能需求方面，可以分成这两大方面。
从功能需求方面来说，如何去衡量架构师是成功的、是好的，其实很简单，就是要满足功能、满足客户需求。那我们可以利用一些方法，比如说需求矩阵、用需求跟踪这些方面，或者通过原形这些角度来和客户进行沟通，通过客户这边来了解我们这个架构方案在功能需求方面是否满足需求。然后我们可以利用一些方法，比如驱动设计，或者通过用力这些方式去驱动，把领域模式，也就是所谓的业务模型，把它建好。
从非功能性需求来说，其实是架构的一个难题，提到有安全方面、性能方面、可扩展性、可伸缩性，要求都很多。比如我们现在，都知道像Twitter、FaceBook，他们的业务都很简单，像Twitter就很简单，我follow你，然后你去follow我，那业务很简单。但是作为一个Twitter的架构师要求很高，要求最高的可能在性能、安全稳定性这块，因为访问的人很多，所以性能这块如何去衡量，就需要有一些衡量的指标，比如响应时间之类的。在业界有很多解决这种非功能性需求方面的通用的一些方法，比如从性能角度来说，一般是利用缓存，在硬件方面不能再高的改善的情况之下，最重要的可能就是利用缓存，不管是用普通的缓存，还是用分布式缓冲。另外就是考虑可伸缩性，通过集群的方式，增加服务器的方式来提高这种性能。这些东西呢，我们就是在做架构的时候，我觉得在前期就要考虑好。
而且我觉得还有一个方法，就是把每一个功能、非功能性的因素，在权衡或者评价这个架构是否合适的时候，可以把它的因素扩大化，比如原来客户只要求能够承担十万人同时上线，你可以把它放大，你放大到一百万人，当同时上线的人数达到一百万人的时候，这个架构会不会出问题，通过这样一种方式，就是把某一个因素扩大化，来衡量你的架构。另外一个预先做调研，预先做架构，架构这块我可以先做，先做出一个原形出来，架构的原形，我们通过一些测试手段，通过压力测试，这方面的一些测试手段，来权衡这个架构是否有问题。
从功能需求方面来说，如何去衡量架构师是成功的、是好的，其实很简单，就是要满足功能、满足客户需求。那我们可以利用一些方法，比如说需求矩阵、用需求跟踪这些方面，或者通过原形这些角度来和客户进行沟通，通过客户这边来了解我们这个架构方案在功能需求方面是否满足需求。然后我们可以利用一些方法，比如驱动设计，或者通过用力这些方式去驱动，把领域模式，也就是所谓的业务模型，把它建好。
从非功能性需求来说，其实是架构的一个难题，提到有安全方面、性能方面、可扩展性、可伸缩性，要求都很多。比如我们现在，都知道像Twitter、FaceBook，他们的业务都很简单，像Twitter就很简单，我follow你，然后你去follow我，那业务很简单。但是作为一个Twitter的架构师要求很高，要求最高的可能在性能、安全稳定性这块，因为访问的人很多，所以性能这块如何去衡量，就需要有一些衡量的指标，比如响应时间之类的。在业界有很多解决这种非功能性需求方面的通用的一些方法，比如从性能角度来说，一般是利用缓存，在硬件方面不能再高的改善的情况之下，最重要的可能就是利用缓存，不管是用普通的缓存，还是用分布式缓冲。另外就是考虑可伸缩性，通过集群的方式，增加服务器的方式来提高这种性能。这些东西呢，我们就是在做架构的时候，我觉得在前期就要考虑好。
而且我觉得还有一个方法，就是把每一个功能、非功能性的因素，在权衡或者评价这个架构是否合适的时候，可以把它的因素扩大化，比如原来客户只要求能够承担十万人同时上线，你可以把它放大，你放大到一百万人，当同时上线的人数达到一百万人的时候，这个架构会不会出问题，通过这样一种方式，就是把某一个因素扩大化，来衡量你的架构。另外一个预先做调研，预先做架构，架构这块我可以先做，先做出一个原形出来，架构的原形，我们通过一些测试手段，通过压力测试，这方面的一些测试手段，来权衡这个架构是否有问题。
应该说这个时候架构师扮演的是救火人员、消防人员的这样一个角色，其实做到后面出问题，本身从职责来看，本来就是架构师的问题，你之前没考虑到，比如我们做一个医保项目，之前你不考虑，网络断开的情况之下，怎么来处理应对这种情况，比如说突然网络断了，难道就让这个系统停掉吗，让它不能支撑这种断线的、离线的这种方式，如果没考虑，肯定就有问题。所以首先第一点，其实也是刚才我说的，最开始就要考虑去这些问题，我们都说要考虑未来，在功能上来说，去考虑未来很困难的，不可能今天去考虑到未来很多年后功能的变化，敏捷这个角度来说也是这样去分析，我们只说今天要做的事情。但是从非功能性需求方面，你可以适当的考虑一下未来，考虑一下未来在性能上、安全上、在可伸缩性方面、可扩展性方面，他的要求，所以你先要去考虑。
如果你预先去考虑到这些东西，那么后来出现问题的可能性就会少很多，当然如果真是出现的话，怎么办？这个时候其实没有其他的办法，只有是架构师的这种经验。另外架构师不要搞的太固步自封，或者过于的自信，觉得丢面子，去求助于别人，其实架构师不是所有都懂，比如在硬件、网络、安全，会有专门的网络专家、硬件专家和安全专家，我们称为叫基础设施，基础设施也有架构师，你作为这个项目的主要负责架构师，大项目有一个架构师团队，小的项目你可以去寻求帮助，寻求其他的公司或者我们公司的其他人，寻求帮助，尽快的解决这个问题。在出现这个问题的时候，首先要找到原因，找到它的症结所在，然后解决方案的提出，你可以根据你的经验，同时也要寻求帮助，尽快的解决这个问题。我觉得很多架构师就是面子观念，我都是很No.1的，我是Leader，怎么我还去寻求其他人的帮助？但事实上每个架构师都有他的短板。
如果你预先去考虑到这些东西，那么后来出现问题的可能性就会少很多，当然如果真是出现的话，怎么办？这个时候其实没有其他的办法，只有是架构师的这种经验。另外架构师不要搞的太固步自封，或者过于的自信，觉得丢面子，去求助于别人，其实架构师不是所有都懂，比如在硬件、网络、安全，会有专门的网络专家、硬件专家和安全专家，我们称为叫基础设施，基础设施也有架构师，你作为这个项目的主要负责架构师，大项目有一个架构师团队，小的项目你可以去寻求帮助，寻求其他的公司或者我们公司的其他人，寻求帮助，尽快的解决这个问题。在出现这个问题的时候，首先要找到原因，找到它的症结所在，然后解决方案的提出，你可以根据你的经验，同时也要寻求帮助，尽快的解决这个问题。我觉得很多架构师就是面子观念，我都是很No.1的，我是Leader，怎么我还去寻求其他人的帮助？但事实上每个架构师都有他的短板。
这个我觉得就是刚才你提到一个问题，就是需不需要编码，我觉得编码也是能够提高他的技术敏锐度。但是这个编码，我的理解是这样的，架构最好是写一些编码，第一个最好是写整个解决方案的大体上的一些编码，而不是去抠这些具体的算法，一些细节的实现，比如说我甚至可以写一个框架性的东西出来，然后具体的实现由开发人员去填，另外比较困难的东西，可以由你来编码去解决。还有从面向对象的角度来说，你可以写一些基类或者抽象类，把一些共同的东西提取出来。如何保持敏锐度呢，首先编码这个角度来说，我们要随时磨炼，我知道像我们很多世界一流的，象Kent Beck、Martin Fowler这些人，他们每天都还在写代码，就是要提高这方面能力，如果长期不写，就有可能到真正去做项目的时候，碰到一个问题需要你来写的时候，你写不出来。
第一个就是，要认清自己，就说你的特长是什么，你的性格，你自己要有充分的了解，如果你确实在协调能力方面、组织能力方面、口头表达能力方面、交流能力方面、抽象能力方面你达不到，你可以选择另外路子。而不是觉得架构师好，你就一定要去做，其实在这个行业有很多角色都是非常好的，走到最后成为专家照样是能够得到很好的事业，第一个要认清自己；第二个要认清目标，认清了自己之后，你还要认清目标，你的目标是什么。而且你这个目标有一个近期的短期和长期目标，你在近一年要做什么事情，过三年、五年你要达到一个什么样的高度，这是第二个。
第三，要找到适合自己的方法，因为每个人的能力不一样，特长不一样，学习方法可能都不一样，那么你的方法是什么，你要找到。比如说你可以通过多去阅读源代码，阅读一些开源的项目，或者说你可以多看书，多做项目之后，你可以在网上多找一些相关的文档，这些都是一些好的学习方法，像我现在每天保持阅读网络上的一些文章，或者是阅读书籍，特别有的书籍，是一些很一流的，战斗在一线的架构师，写的一些心得体会的总结。有的东西，可能在我们做的项目根本就没办法碰得到，但是在将来的项目中有可能会碰到，如果你还寄希望于在将来的时候碰到问题的时候你再去找，那就会出现很大的问题，所以这是我说的第三个要找到自己学习的方法。
第四，未雨绸缪，你要事先做好准备，打下坚实的基础；最后一个，我认为最重要的是，基础很关键，不要好高骛远，不要一下子我要成为架构师了，好，我现在就去面向对象思想我都不太了解，设计模式我都不太了解，好，我现在就去搞架构模式，我去做架构的研究，我去分析这些架构的整个实现的原理，你根本就没有办法去掌握，所以你先要脚踏实地的先把最关键、最基础的东西先掌握好，就像我刚才说的要先专后博。先把这个东西研究的很透，而且不要抱着一个思想，就说我知道了就行了，要知其然，而不知其所以然，这样就会有很大的问题，我们要去把它研究透。包括像现在，就拿C#这种语言来说，你可能觉得这门语言你很清楚了，但事实上这个C#里面，涉及到框架的，比如说PC垃圾回收怎么运行机制，内存的管理是怎么去管理的，多线程是怎么处理的，并发是怎么去解决的，有很多很多东西需要深入的去分析，而不是盲目的知道C#的语法就够了，这五点对于开发者来说是一个比较重要的，应该说是比较重要的一个能力。
第三，要找到适合自己的方法，因为每个人的能力不一样，特长不一样，学习方法可能都不一样，那么你的方法是什么，你要找到。比如说你可以通过多去阅读源代码，阅读一些开源的项目，或者说你可以多看书，多做项目之后，你可以在网上多找一些相关的文档，这些都是一些好的学习方法，像我现在每天保持阅读网络上的一些文章，或者是阅读书籍，特别有的书籍，是一些很一流的，战斗在一线的架构师，写的一些心得体会的总结。有的东西，可能在我们做的项目根本就没办法碰得到，但是在将来的项目中有可能会碰到，如果你还寄希望于在将来的时候碰到问题的时候你再去找，那就会出现很大的问题，所以这是我说的第三个要找到自己学习的方法。
第四，未雨绸缪，你要事先做好准备，打下坚实的基础；最后一个，我认为最重要的是，基础很关键，不要好高骛远，不要一下子我要成为架构师了，好，我现在就去面向对象思想我都不太了解，设计模式我都不太了解，好，我现在就去搞架构模式，我去做架构的研究，我去分析这些架构的整个实现的原理，你根本就没有办法去掌握，所以你先要脚踏实地的先把最关键、最基础的东西先掌握好，就像我刚才说的要先专后博。先把这个东西研究的很透，而且不要抱着一个思想，就说我知道了就行了，要知其然，而不知其所以然，这样就会有很大的问题，我们要去把它研究透。包括像现在，就拿C#这种语言来说，你可能觉得这门语言你很清楚了，但事实上这个C#里面，涉及到框架的，比如说PC垃圾回收怎么运行机制，内存的管理是怎么去管理的，多线程是怎么处理的，并发是怎么去解决的，有很多很多东西需要深入的去分析，而不是盲目的知道C#的语法就够了，这五点对于开发者来说是一个比较重要的，应该说是比较重要的一个能力。
采访人 刘申 在08年毕业于哈工大，管理科学与工程硕士。对Web前端开发、Ruby、RoR以及极限编程十分感兴趣。
慢得我泪流满面啊
发表人
ZHOU Tony
发表于
Re: 慢得我泪流满面啊
发表人
yang eric
发表于
Re: 慢得我泪流满面啊
发表人
Guo Eidson
发表于
Re: 慢得我泪流满面啊
发表人
yang jiangy
发表于
-
慢得我泪流满面啊
-
发言比较笼统,说得是对的,但是有些偏颇. 抱歉.
他既然已经提及架构师是分几个层面,不同领域,那么就不能以偏概全,认为架构师偏向技术而项目经理才偏向管理,这个不现实,特别他提到做过的Scrums的项目,由于技术人员水平问题而导致他自己出现困惑,我相信他最后不是很成功的从那个项目里出来的,如果他真正认识到Scrum的方法,不应该得到这么一个不"敏捷"的结论.
了解任何一个职位,比如架构师,都要了解它怎么产生的,就象建筑设计师,一开始能有么?肯定没有,都是在长期的实践中得到一些理论,然后提炼升华出来的方法论的倡导者.
我不相信他深刻的理解了"C#里面，涉及到框架的，比如说PC垃圾回收怎么运行机制，内存的管理是怎么去管理的，多线程是怎么处理的，并发是怎么去解决的，有很多很多东西需要深入的去分析" -- 我也相信他并不是建议大家都去真的深入多少,所以我批评一下,并且修改一下,他只是建议大家多去实践,正是因为他实践了那么多,才可以说出来.就这么简单. 再举个简单例子,搞一个零售项目,如果他没几个相关方面项目经验,我不熟悉他,不知道他的风格和能力(非技术),让我请他作架构师是绝对不可能的,比如看他的简历,我的项目需要java开发,那么可能一开始我就否定他了. -
我觉得成为一个架构师必然是由具体实现、设计模式、架构模式一步步不断往复迭代过来的。可以以某一个技术平台为起点，做精，做专，那么其他的平台也都大同小异了。当对大部分知识都熟练掌握了之后，架构的技术方面应该是没有问题了。但还要注意的是，架构师不仅仅需要将架构设计出来，还需要将其推动起来，让其得以实现。这些就比较考验管理或者组织方面的能力了。
-
Eidson Guo,非常认同你的看法
4 条回复
关注此讨论 回复