微软亚太研发集团服务器与开发工具事业部高性能计算首席架构师徐明强博士，长期从事高性能计算（HPC）系统和编程软件的研发工作，并热衷于高性能计算的普及事业。2004年微软提出“让每个科学家都有一台高性能计算机”的口号，徐明强对此产生了强烈共鸣，并于2004年加入微软，投入到高性能计算的普及浪潮中。同时徐明强也是微软在中国为数不多的架构师之一，相信他的架构师之路，可以给那些正在努力成为架构师的人一些启示。《程序员》杂志近日专访了徐明强，请他与我们分享他不寻常的人生之路、架构师之路。
记者：能简单谈谈您的童年经历吗？童年哪些事、哪些人对您的影响最大？
徐明强：我是一名60后，出生在西安。父母都是西安交大老师，为了把我留在他们身边，从幼儿园到西安交大毕业，我从没有离开过西安。在我的成长过程中，父母一直陪伴在我左右，他们对我儿时的启蒙教育为我以后的事业发展奠定了坚实的基础。
父亲热衷于无线电，从小喜欢自学，所以在我很小的时候他就有意识地培养我自己解决问题的能力。每当我遇到难题时，他不会直接帮我解决，而是让我独立去解决问题。记得小时候曾做过一个单晶体管收音机，当时以为按照线路图组装后就大功告成了，但组装完成后才知道，天线的设计也是不可缺少的步骤，只有长短合适的天线才能保证收听到好音质的广播。诸如此类的小事，都在潜移默化地影响着我的思考方法，同时也给了我很多启示。就拿设计单晶体管收音机来说吧，将它与编程过程进行类比，可以看出很多相似之处。对于编程，不是只把编程模式设计好就完事了，虽然它至关重要，但仅仅是工作的一步。系统的可维护性、纠错性、容错性在编程模式设计完后就要重点进行考虑和设计了。
对我儿时成长影响比较大的另一件事就是古典音乐。上中学时，我特别喜欢听古典音乐，尤其是贝多芬的音乐。他不向命运低头、不服输的气质为他的音乐注入了一种不可抗拒的力量。我被这种力量深深感染，为他那与命运抗争的精神而感动。在他音乐的感召下，我逐渐形成了不向困难低头、乐观的处世态度。现在每当遇到有挑战的难题时，我都会把它当作一种机遇、一种乐趣，用积极的心态去面对它、解决它。古典音乐也是我儿时学习的动力之源。我上中学时还是80年代，当时听音乐只能用录音带，要录制比较长的交响乐只能用很贵的进口录音带，为了向父母要钱买进口录音带，我首先要保证把功课做好。可以说对古典音乐的痴迷一直在促进我的学习。
记者：考入西安交大后，您才开始接触计算机吗？当时感觉如何？对大学生活有什么感触？
徐明强：1982年我考上了西安交大，读的是计算机软件专业。也是从那时起我才开始接触计算机，接触编程。
记得报考大学专业时，父亲希望我能学习最前沿的技术，他问了一些西安交大的老师，了解到当时最前沿的技术是计算机软件开发。于是就帮我报考了计算机软件专业。报考时，我还不知道计算机软件是什么。后来读大学的哥哥告诉我计算机软件就是编程，这是我第一次对计算机软件有了一个初步认识，当时感觉蛮不错的。
等到了大学，随着对计算机软件学习的深入，我越发觉得软件开发真的是件很棒的事。软件开发可以实现你能想象到的任何事情，可以说只有你想不到的，没有它实现不了的，这是软件开发的魅力所在，也正是它的这种独特魅力深深吸引了我。
回想起大学四年，前两年的收获还是蛮多的，学习了计算机软件的基础课，为我以后的学习和研究提供了充实的营养成分。大学后两年开始学习更深层的涉及软件底层的一些理论知识，像计算机体系结构等课程，这些课程很抽象且不好理解。当时国内软件还很不发达，大学师资力量也比较薄弱，专门从事计算机软件科研的教师很少，而且大多是从数学系转过来的，本身没有深厚的软件研发功底。他们也只是照本宣科，罗列一些抽象的概念，对他们讲的知识，我总结不出任何规律。在思维方式上我属于抽象归纳型，记忆力不是很好，若对接触的事物找不到任何规律，我是很难记住它们的。所以在大学的后两年，我的收获并不多，对很多知识也是一知半解，很多东西也是出国后才搞清楚。
在大学的学习过程中，我的编程实践也在逐渐深入。其中编程最多、做得最大的系统是在毕业设计时，与带我的老师协作开发的一个系统。这个系统由编译系统和可视化系统组成，其中编译系统是对COBOL语言进行编译，由带我的老师来做；把编译系统生成的中间代码进行可视化的可视化系统由我来负责。当时除了画图部分由C语言实现外，大部分用Pascal语言来实现。在设计可视化系统时，我设计了作业调度器解决了COBOL语言分支跳转的问题，同时用递归加栈的方法对算法进行了优化。后来这个系统的毕业论文还获奖了。也是因为这次毕业设计，让我对算法产生了浓厚的兴趣。
记者：大学毕业后，您就直接出国留学了。出国留学后，您的经历如何？都遇到了哪些挑战？获得了哪些成就？
徐明强：1986年我大学毕业，年底正好赶上第一批中英友好奖学金，我通过英语考试选拔后，就去英国埃克塞特大学（University of Exeter）留学了。
去英国留学我直接读的是博士。当时英国读博的要求没美国那么严格（美国要求只有读研究生后才有资格读博），所以我可以跨越研究生课程，直接读博士。由于本科后两年没扎实学到实质性的东西，再加上缺乏研究经验，所以刚学习博士课程时，面临着很多挑战，而其中最大的挑战就是要用英语理解所有课程。面对课本上众多不认识甚至都没见过的词汇，我不得不从头开始逐词学习，同时研究生课程的空白对我来说无疑也是一个很大的坎儿。当时我选的研究课题是并行计算，对我来说，这完全是一个陌生的领域，在国内从没接触过。带我的导师又是一位对我比较放手的导师，让我一个人安排学习计划及科研方向。当时我完全处于一种被动、迷茫的境地。
面对种种挑战，我静下心来花了18个月的时间，进行了大量阅读和编程实验，填补了研究生课程的空缺，同时还确定了博士学位的主攻课题。主攻课题的确定是我博士学业中的一个转折点，只有确定了课题，才能研究如何解决这个问题。后来我用了大概一年半到两年的时间来解决这个课题。
我现在热衷于普及高性能计算机，也是从那时开始的。当时并行计算是一个新领域，而搞并行计算，算法最关键，而研究算法需要高性能的机器才能测出算法的提速效益。当时我们用于科研的实验室里只有四个节点且都是单晶机，而这样的硬件条件是无法进行算法研究的。无奈之下，我放弃了算法研究，转去搞模拟和协议。这件事对我的触动很大。当时我就想，像我们这些专门搞并行计算的人都无法拥有实验所需的高性能计算机，而那些搞科学的科研人员又要等到什么时候呢？2004年初，微软提出了“让每个科学家都有一台高性能计算机”的口号，我对此产生了很强的共鸣，当时就下定决心也要为高性能计算机的普及助推一把。
时至今日，在高性能计算机领域，有5500万人还无法使用高性能计算机。无法使用，并不是受限于高性能计算机的价格，而是复杂的技术导致。使用高性能计算机不仅要懂系统管理，还要懂网络管理，这对于一般科研人员来说是件很困难的事。要想普及高性能计算机，就要从技术、服务上下手，让高性能计算机的使用变得简单化、服务一体化。我个人认为唯有微软有这方面的基因，可以把复杂的东西变简单，把只有少数人专有的技术简单化并普及给大众。
1991年博士毕业后，我去曼彻斯特大学做了两年的助理研究员，同样做并行计算研究。其实这两年的收获并不多，最大的收获便是学会了优雅系统和实用、高效系统的选择和取舍。
那时业界存在分布式编程模式和共享内存编程模式两大阵营。当时曼彻斯特大学买了一台虚拟内存机器KSR，它属于操作系统级，解决了Cache Coherence一致性的问题，同时可以在多机上提供共享的虚拟内存，它的编程模式非常优雅。我也是被它优雅的编程模式吸引并开始钻研。后来发现虚拟内存技术性能差，因为它只针对应用和管理，对应用所使用的内存情况一点也不了解，所以它的性能是没办法提高的。而当时采用分布式编程模式的MPI则不一样，它靠应用开发者把内存有效地分开并进行分布，然后通过有效的消息传送降低开销，提高了性能。从哲学角度来说，不知道应用对数据的访问细节，就不可能把性能做好，所以在高性能计算领域，很多时候性能和优雅度需要保持一个平衡。现在我在架构没有明显改变的情况下，对虚拟内存技术一般是抱比较健康的怀疑态度的。
离开曼彻斯特大学后，1993~1995年，我在美国阿冈国家实验室完成了博士后研究。当时是跟着Ian Forster（后来被誉为“网格之父”）。Ian Forster是搞并行逻辑语言的编译及运行时系统的。当时他搞的并行逻辑语言并没得到别人的认可，所以他基于Fortran发明了Fortran-M语言。他给Fortran加了一些消息传送，而我为这些信息传送编了一个编译器。
记者：您的第一份工作是编程，可以说您也是从程序员起步的。那在程序员成长过程中，您最难忘的事是什么？
徐明强：1996年，我在加拿大Platform Computing公司做开发工程师，当时有个系统在客户那里总是coredump，而且crash的地方都不同。后来，公司派我去客户数据中心“救火”。在机场的时候，我就开始逐行读程序。从数十万行中要找出问题，真有大海捞针的感觉。我当时祈祷，愿天地的主宰帮助我，结果不久我就发现一个循环中有一句语句的二维数组的索引用反了。举例说明，本来应该是array[i][j]=1.0结果笔误成 array[j][i] =1.0。
把这个问题修正后，我在客户那儿的三天，系统一直没出问题，之后也没出现任何问题。这次经历给了我很深的体会——程序员手中的责任是何等的大。据统计，许多的程序错误都是在周五最后一个工作小时提交进系统的，而且，不少错误都是重现以前的错误。同样，这类错误常常在程序员筋疲力尽的时候引入的。所以，在这之后，我开始注意编程时的身体和精神状况，确保在编程时候保持良好的状态。
记者：在架构师成长过程中，您最难忘的事是什么？您认为架构师需要具备哪些素质？
徐明强：1997年，我在Platform Computing公司开始负责公司某产品的架构重建工作。这是一个近十年的软件产品，在软件维护、新功能添加、扩展等方面存在比较大的困难。我一开始就犯了许多技术人员常犯的错误，即没有定义原产品架构的具体问题就开始着手写解决方案，结果整个方案无法得到认可。后来我花了一个月的时间，将原产品架构的问题一一定义清楚，包括问题描述、根结定义。有了清晰的问题定义，整个方案很容易就进入了后续设计、开发阶段。这次经历后，无论我再做任何事情，不管大小，都会首先把问题定义清楚，同时搞清问题实质，有时候对问题本身的兴趣要超过寻找解决方案的兴趣。技术人员最大的误区就是急于展示身手，而且常常为自己的技术找问题。如果把自己擅长的技术比作铁锤，技术人员很容易把所有问题都看成钉子，很少在问题本身上下工夫。结果，往往很快步入迷途，真正该解决的问题没有得到解决。
我觉得架构师必须学会的第一件事情就是要懂得如何进行权衡。因为我们面对的都是相互矛盾的一些设计要素和限制，但事实却要求你在这些相互矛盾的要素限制和约束条件之间取得巧妙的平衡，因此，我认为平衡能力是微软架构师的第一个重要素质。
第二是架构师必须足够成熟。因为他们往往需要在无法获得完整信息的情况下，迅速领会问题，并根据经验做出审慎判断。其实微软内部有一个能力要求（Deal With Ambiguity），即能把一张比较模糊的图片清晰化。如果从经验层面上谈，我想归纳四个方面。首先当然是在专题领域的经验和对微软软件开发工程的经验。第二就是要有判断力、决定力和领导力，以推动各个团队的技术进展，并且能在压力下作出关键性的决策，然后将开发贯彻到底，并提高效率。架构师有权在技术上作出决定，在大家意见不一致的时候，他要能给出大部分人比较能够接受的意见。第三是善于沟通。沟通的关键就是赢得他人的信任。微软架构师跟其他合作人没有直接的上下级关系，应该通过沟通去赢得其他人的赞同，而不能靠命令强制指导。同时为了提高效率，架构师必须赢得项目团队、管理团队、合作伙伴和客户等多方面的认同，这样才能将产品开发出来。第四是通常说的抽象思维和分析能力。具体思维的人可能比较注重细节，但往往也会将问题复杂化，使头绪增多而无法收敛。抽象思维可以帮架构师从大量信息、系统文件中，看出一些规律来，并找出与之相关的方面，归纳关键问题，表述模糊的概念并将其变成相关各方能够理解的项目构件，并以具体的语言进行沟通。
最后，我认为无论是什么样的架构师都要具备一定的商业头脑，充分把握业务的知识，因为对业务的把握能够带来拥抱变化的能力，而且可以在设计的时候留出一点扩展的余地，适应将来可能来临的需求变化。
记者：您能谈谈微软是怎么培养架构师的吗？
徐明强：像微软这样庞大的软件开发组织结构里，架构师会根据产品团队，工作职能进行进一步划分。微软基本上是从产品组资深人员里选拔架构师。
如果要理解微软的架构师职能划分，就需要先了解微软的产品部门划分。通常在微软的产品组有三个更小一级的分组：项目经理组、开发组、测试组。每个组都可以培养出架构师。
项目经理组主要负责业务的需求定义和产品规格书的撰写；开发组主要负责软件的实现，以满足项目经理所定义的需求规格书；测试组主要确保软件产品交付的质量。从这个角度看，我们可以把架构师分为项目经理架构师、开发架构师和测试架构师三种基本类型。
不同的架构师职能大相径庭，比如项目经理架构师，更侧重于业务上的需要。从这个意义上看，你就会发现不同架构师之间的区别。由于项目经理主要是看用户的需求，对整个系统性能和工作品质提出要求，同时还要确认在用户应用场景，产品是否可以有效地被系统支撑。
而开发架构师比较侧重于技术，尽管某些问题上会与项目经理架构师重叠，但更多时候分工还是非常明确的。技术架构师的一大职能是技术选型，比如在产品中选择使用什么技术，数据库要采用哪种规格的SQL Server，数据库的模式（Schema）应该怎样设计，.NET组件的选择等，这些都是开发组架构师所关注的。
测试架构师则关注测试系统对架构设计的帮助，包括如何自动化测试、如何更有效地手工测试等。比如HPC Server测试组的架构师的工作，由于涉及很复杂的分布式系统，就需要做可扩展性测试，计算资源分配的测试，包括测试方法的设计等。
记者：您对年轻技术人员有哪些建议？
徐明强：我主要提三点建议。
第一，要避免“急功近利”的心态和作风。在小事上要忠心，然后才可能被赋予重任。我加入Platform Computing公司的第一个任务，是写一个相对简单的脚本文件，但我还是花了100%的热情去写。我发现原来的脚本文件有许多冗余部分，而且其中记录临时文件的程序容易出错。我修改了这部分脚本文件，使得今后编写程序的程序员能够更便捷地编写脚本文件。后来，我就开始做比较复杂和核心的项目。可以说，从小事赢得别人的信任。
第二，要对系统的稳定性和性能问题感兴趣并多解决这些问题。解决这些问题需要有蓝领精神，需要挽起袖筒做脏活。做这些“侦探”工作可以帮助你对系统有更全面的了解，而且可以培养出务实的精神。许多大的发现都是从小处着手，然后就会有奇特收获。大多年轻人都想有重大成就，其实很多时候，只要你工作足够细致，好的结果就呼之欲出了。年轻的时候总是想很快结束战斗，而资深的架构师常常问自己和合作的人，我们还有什么没有考虑到？在讨论解决方案的时候，往往开始20%的时间，可以想到80%的解决方案。而最好的方案往往需要用剩下的80%的时间去寻找。好的解决方案，如同宝藏，要用耐心和细心去发掘。
第三，要对公司的愿景和商业策略感兴趣。对公司来说，架构师最大的贡献就是能够创建数年的产品计划、能够清晰表述客户价值的产品路途、能够前瞻市场变化并能够以最佳时间推出市场欢迎的产品。如何做到呢？起点就是要珍惜每一次访问客户的机会，用心当学徒式地学习用户是如何使用自己的产品。每一个步骤都要记清楚，真正理解用户的商业流程和应用场景。许多时候，我们只是把用户的需求记录下来，对于用户的应用场景缺乏了解，结果设计出来的产品非用户所需。我的一个资深开发员同事用了个非常好的比喻：车子上有许多螺丝钉，是要用电动工具的。如果你只看表面现象，看见车上的螺钉，就给别人一个螺丝刀。那么，别人用起来手腕会要断掉的。
（本文来自《程序员》杂志10年12期）
