西门子中国中央研究院首席架构师、图书《架构之美——软件架构的艺术》作者李伟，从架构师的定义和内涵、能力和素质要求、成长途径等方面向您阐述成为一个真正的架构师需要经历的历程。

　　记者： 您认为具备哪些能力，才算是真正的架构师？

　　李伟：虽然业界有关什么是“软件架构”有着明确的定义及共识，但是确实没有软件架构师的定义。简单地讲，架构师是一个技术控制的角色。技术控制是从客户或市场开始，一直到交付或服务的整个链条。如果大家对一个应用研发机构或产品研制机构的主要活动熟悉的话，就知道该链条上存在很多需要架构师负责的控制点。以西门子为例，西门子的战略市场部门就会和业务部门的很多架构师进行协作。这主要是由于战略市场部门的职能之一就是对未来十到十五年的技术和创新进行预判。这样的技术预判，如果没有架构师作为技术控制，单凭MBA出身的市场人员，大家能相信这样的技术预判吗？所以架构师需要具备一定程度的技术及创新预判能力。

　　从一个架构师的日常工作来看，他面对的基本上有七大问题：商业问题、系统问题、子系统问题、构件问题、技术问题、流程问题、项目管理问题。其中，前五项是一个架构师主要负责解决的。这里我尝试提几个问题，让大家检验一下自己是否具备解决这些问题的能力。

　　如果进行企业应用开发，你知道经典的商业运营手段一般有哪些吗？例如：公司中一般有哪些典型的职能机构？最经典的公司财务部运作是什么样的？最经典的公司纯研究机构的运作是什么样的？或者，最经典的公司纯销售机构是怎样运作的？

　　如果你负责一个实时系统的架构，经典的架构构建步骤有几步？一个医学CT机系统应该用什么架构风格来构建？军用舰艇上的3C系统又应该使用什么架构风格？除了我们都熟悉的MVC风格的架构，你还知道哪些架构风格？再具体一些，对于系统的并发问题，你知道业界流行的经典解决手段包括哪些?

　　如果你负责子系统及构件设计，经典的设计步骤有几步？分别又有哪些活动？除了你熟悉的Gang of Four的23个设计模式，你还知道什么设计实践？再具体一些，设计中有关同步、事件、资源管理等，你知道哪些前人的最佳实践呢？

　　实践工作中，我们遇到的现实是：盲目追随业界通用框架，即对框架或中间件的严重依赖。这些框架或中间件背后实际隐藏了很多技术、设计、应用场景，也就是说为设计开发人员隐藏了很多系统设计开发的复杂性。如果架构师把各项系统级架构质量的要求，想当然统统扔给这些框架或中间件去处理，将会带来灾难性的后果。业界有这样一句话：“框架或中间件是用来帮助你的，而不是代替你去思考和工作的。”所以我们必须根据现实的系统要求，自己动脑筋去构建适合现状的软件架构！

　　简而言之，架构师需要具备的能力=熟知最佳实践+动脑灵活使用+技术及创新预判。

　　记者： 在中国，一个程序员如何才能成长为一个职业架构师？

　　李伟：曾经无意间读过一篇纪事报告《最后的大师》。此文作者是应钱学森先生的邀请，来记录自己的导师，清华大学物理系及清华大学创始人之一的叶企孙先生。叶先生早年在美国留学期间，在物理方面做出过杰出的贡献。虽然大多数后人并不知道叶先生，但是他的学生没有一个会忘记他，其中包括三钱、华罗庚、李政道、杨振宁等等。可以这样说，你所知道的中国大师，大多都是他的学生。阅读完此文，颇受启发：真可谓“大师培养大师”。我非常欣赏这句话。

　　如果身边有大师，自然是从程序员成长为架构师的捷径了。我身边没有大师，便选择这样的道路：认真反思自己这些年来的学习和实践，并将其上升为智慧。毕竟，智慧既是指导我继续工作的原始动力，也将指导自己未来的创新工作。因此，我选择了阅读、学习和思考。

　　记者： 您认为在中国的软件企业中，大家在普遍认识中对架构师这一职业有哪些误区？

　　李伟：误区一，架构师与项目经理没有区别。大家经常在谈论架构师时，混淆了项目经理的职责和架构师的职能。项目经理要对人、流程、钱等内容负责。但是架构师主要是对技术负责。所以我个人不是很喜欢在谈论系统架构时，过多的谈论流程或管理。虽然我也是流程方面和管理方面的专家。

　　误区二，技术好的人就能成为架构师。其实，职业架构师与职业编程人员有着同样重要的分量，只不过各自负责的工作内容及需要具备的能力各不相同。例如：架构师熟知如何将系统架构构建得适应系统后续国际化/本地化的工作；但是并不一定必须知道界面热键在.NET下调用什么来实现。

　　误区三，架构师必须懂得业务领域的知识。从本质上来看，软件架构本身就是在模仿人类大脑的问题思考和解决习惯。自然，专业架构师所掌握的知识就是解决那些反复出现的相似问题的最佳手段。所以，业界都知道这样一个著名的故事：一个非航天专业的软件架构人员，可以被美国国家航天局请去做航天系统的架构评审。这一点儿都不奇怪，因为他知道解决系统并发问题时，当今最经典的那么几种手段，你能说航天系统的并发问题与企业应用并发问题本质上不一样吗？由于当前国内软件研发的各种局限，很多软件从业人员的认知还停留在“懂业务+技术好”就是架构师这样的层面上。其实，懂得经典的解决方法，并能从实践中抽象出理论或最佳实践的人，才是架构人员的专业水平。

　　记者： 在《架构之美——软件架构的艺术》一书中，您认为最创新的理念有哪些？

　　李伟：一个架构从创建、进化、老化到消亡的整个过程，是此书的核心。如同宇宙万物，架构也存在一个生命周期的概念。即“架构生命周期（Architecture Lifecycle）”。

　　怎样才是一个真正意义上的软件架构师？

　　当面临构建一个软件架构时，应该采用怎样的流程去工作呢？

　　怎么做才能构建出满意的高品质架构及设计呢？

　　当我们阶段性地完成了架构的构建，如何去评估结果呢？

　　软件产品在演化，软件架构也会跟随演化，如何应对这种变化？

　　十年前开发的产品，架构文档残缺不全，设计人员已经离职，怎么把产品的架构从纷繁复杂的头绪中清理出来呢？

　　如果我们要研发十几个功能相似的产品，该如何高效地工作呢？

　　上述这些理念，基本上是一个职业架构人员所需具备的专业素养。奉献给大家，以供参考。

（责编：陈广成）

免责声明：本网站（http://www.ciotimes.com/）内容主要来自原创、合作媒体供稿和第三方投稿，凡在本网站出现的信息，均仅供参考。本网站将尽力确保所提供信息的准确性及可靠性，但不保证有关资料的准确性及可靠性，读者在使用前请进一步核实，并对任何自主决定的行为负责。本网站对有关资料所引致的错误、不确或遗漏，概不负任何法律责任。
本网站刊载的所有内容（包括但不仅限文字、图片、LOGO、音频、视频、软件、程序等）版权归原作者所有。任何单位或个人认为本网站中的内容可能涉嫌侵犯其知识产权或存在不实内容时，请及时通知本站，予以删除。