如何做一个好的软件架构师
最近有人问我一个好的架构师需要哪些能力，我回想了一下自己差不多10年的架构师生涯，又去网上搜了一些什么是好的架构师的文章，把自己觉得重要的东西总结在了下面。技术方面就不多说了，这篇文章主要谈谈非技术方面的软实力。
架构师的日常工作
我们首先从架构师的日常工作开始说起，当然每个架构师的工作会不尽相同，我下面列了一些我日常工作中需要做的事情。从这里我们基本就可以看出来架构师需要具备的能力。
- 收集和评估功能和非功能需求
- 调研和评估技术选项，选择技术栈
- 制定开发标准，比如编码标准，代码评审流程，测试要求等
- 决定部署模式
- 设计系统架构
- 向别人（业务需求方、项目管理方、关联产品、开发测试人员、其他利益相关方）讲述或者推销系统架构
- 评估别人提出的系统架构
- 估计开发量
- 预防和缓解项目的技术风险，制定在风险发生时的应急预案
- 确保系统设计在团队中得以正确的实施
- 监督代码质量和非功能需求的实现
- 制定团队和产品的技术方向
- 组织团队和产品的技术文档
- 管理和提升团队的技术能力
- 保障团队在实现功能需求的同时，留出足够的时间来改善产品质量比如消除技术债
- 参与各种技术讨论，向别人提问，也回答别人的问题
- 等等
架构师需要的硬实力
一个好的软件架构师肯定得既懂技术，又懂业务，还懂项目管理，这是我认为好的架构师需要具备的三项硬实力。好的架构师既是软件专家，又是领域专家，还是流程专家。然而每个人的精力有限，不可能做到样样精通，就需要合理的把握深度和广度，也就是我们常说的T型结构，在某些方面是专家，有深度。同时涉猎很多方面，有广度。
懂技术
对于软件来说，要深度就意味着得上手写代码，所谓纸上得来终觉浅。在做系统架构的时候时不时的要动手写个原型，排除一些技术上的风险和不确定性。要广度就意味着得持续学习，所谓读万卷书行万里路，多看新技术，多看别的产品是怎么做的，比如ThoughtWorks的技术雷达就是一个很好的参考。
懂业务
这个就需要在项目的开发过程中多问为什么，真正理解用户的需求。对于很多程序员来说领域知识可能没有软件知识有趣，但是只有真正理解领域知识，才可能做出对用户真正有用的产品。
懂项目管理
这个要求相对比较容易做到，毕竟做了几年程序员后对软件开发流程都熟悉了。我觉得最值得注意的是关于项目风险的把控，除了最直观的技术风险，要考虑非技术风险，比如预算、团队情况、对其他团队的依赖等。对所有的技术和非技术风险，都要有相应的预防缓解措施（mitigation plan）和应急预案（contingency plan），这些很多时候都是做系统架构时必须考虑的制约因素。
架构师需要的软实力
和上面的硬实力不同，软实力的养成更需要经验的累积和刻意的训练，我觉得往往比硬实力更难获得，但是这些软实力在某种程度上更能决定架构师的水平。下面就是我认为好的架构师需要具备的九项软实力。
一、既有远见，又能务实的能力
架构师是团队的技术领袖，需要给出团队的技术发展路线图，所以一定要有远见（Vision），要知道尽管现在还没达到，但是将来我们的产品应该是什么样子。同时架构师也要和项目经理、产品经理一起保证产品能够按时发布，满足业务需求，这就要求架构师能够务实，理解在现有的约束（发布日期，团队能力，外部依赖等）下，我们能把产品做成什么样子。
这就意味着架构师脑子里从技术的角度需要有一条清晰的路径，这条路径上贯穿着产品的长期目标、中期目标和短期目标。架构师要保证短期目标和中期目标都在这条路径上，不会出现南辕北辙的情况。既有远见、又能务实说起来容易做起来很难，需要知道什么时候应该坚持，什么时候可以妥协，这就是下面这条权衡的能力。
二、权衡的能力
我一直觉得架构设计就是一个不断权衡的过程，如果针对一个问题，有一种解决方案在各方面都明显的好过其它所有的选项，在这种情况下是不需要架构师的，直接做就好了。可是现实中有很多问题的不同解决办法之间总是各有优缺点，有的方案符合产品长远目标，但是开发量太大不能及时交付；有的方案能让产品很快推出，但是会留下技术债让后来的维护和添加新功能更麻烦。如何在不同的选项之间权衡就成了每个架构师时时刻刻需要面对的问题。
架构权衡分析方法Architecture Tradeoff Analysis Method (ATAM)就是一种帮我们做权衡的方法。在ATAM的流程中所有的利益相关方包括需求方，领域专家，项目管理者，架构师，开发，测试都齐聚一堂，我们一起明确：
- 业务功能需求
- 非功能需求
- 约束
- 架构目标和原则
- 质量属性效用树
在这个基础上，大家一起充分讨论可选的架构方案的优缺点，特别要看是不是符合我们的架构目标和原则，从而得出最合适当前情况的方案。ATAM的流程是相对繁琐和耗时的，往往只需要针对重大决定才需要这么做。但是这个思维方法我觉得是每个架构师都应该掌握的，针对其它或大或小的问题，都可以在自己的脑子里走一遍，让自己带上不同人的帽子，找到最适合当前的解决方案。
除了要权衡不同的解决方案，还需要权衡不同事情的优先级，随着负责的事情越来越多，区分轻重缓急也越来越重要。有些决定必须马上做，晚了就会让团队干等着，或者给团队带来将来的返工。有些决定可以以后等掌握了更多的信息再做，随着不确定性越来越小，我们做出的决定也会更加明智。有些决定必须自己做，有些决定可以委托给别人做，这就引出了下面这条委托放权的能力。
三、委托放权的能力
在我看来委托放权的能力有两个部分：
- 一个是从优先级或者重要性出发，关注对你来说最重要的决定。比如架构师通常更关心模块或者服务之间的关系，模块或者服务内部的设计细节就可以委托给别人来做。如果我们的产品是对可靠性要求很高，对性能没有什么要求，我们就可以专注于影响可靠性方面的设计决定，把影响性能的决定委托给别人来做。同样的，如果你关注的是几个产品串成一整套完整的解决方案，那你就可以专注于产品之间的关系，每个产品内部委托给每个产品的架构师来决定。
- 另一个是要知道自己的能力圈，在硬实力的部分我们说过，我们的能力会是一个T型结构，这就意味着很多方面我不是专家。要勇于承认自己在很多领域的不足，在这些领域如果有技术专家的话要大胆的求助别人，不要强行做决定。架构师的目标是做出好的产品，带出好的团队，不是证明自己是这个屋子里能力最聪明的人。
无论是自己做决定，还是把这个做决定的权利委托给了别人，都意味着架构师要有做决定的能力。
四、做决定的能力
架构师需要做很多的决定，需要给出很多的答案。在业务需求方会问架构师这个需求可不可行、容不容易，项目经理会问架构师这个版本需要多少工作量，开发会问架构师这两个解决方案哪个更好，测试会问架构师这次改动会影响哪些方面，需要做哪些回归测试，等等等等。
这里面很多问题随着经验的增长会越来越容易回答，但是也有些问题随着经验的增长反而会越来越难回答，我自己的感觉是和上面提到的架构师需要具备的权衡的能力很相关。正是因为架构师做了很多的权衡，所以更明白很多决定，很多答案都不是非黑即白的。架构师当然可以尽可能多的收集信息，就像上面权衡的能力那部分提到的，做一个最合适的决定，但是往往我们需要在没有完全准备好的时候就给出答案，做出决定。这个时候，架构师作为团队的技术负责人，要勇于拍板，要坚定自信的做出决定，当然做出错误决定的时候也要勇于承担责任。
架构师在很多时候和开发人员、测试人员是没有上下级关系的，和项目经理、业务需求方更没有上下级关系，同样的，和其它需要配合的部门也没有上下级的关系。但是架构师做出的决定，或者架构师建议的方案却需要很多人采纳、接受，这就是下一个架构师需要具备的软能力——说服别人的能力。
五、说服别人的能力
培养自己的说服能力，我觉得可以从下面四个方面入手。
- 首先是让自己成为一个值得信任的人，让别人喜欢听从你的建议（至少在技术这个方面）。这个没有什么捷径，就是要珍惜自己的羽毛，尽量让自己做的每个决定都是有理有据，都是在当时情况下做出的最好的决定。很多时候有很多非技术的因素会对最终的决定有影响，架构师最好在给别人讲述的时候把技术因素和非技术因素区分清楚。有时候一些所谓的办公室政治也在所难免，但是架构师的底线我觉得是在所有的讨论中关于技术的部分一定是要合理的，一旦这个底线被越过的话，别人会对你的技术能力产生怀疑，这个时候就丧失了信任的基础。
- 其次要有求同存异、追求双赢的思维方式。自己的主张中一定要有优先级的概念，要明确哪些是必须争取的，哪些是可以让步的。在和别人的谈判中要抓大放小，确保自己的主要目标要达成。
- 第三是寻找盟友，要建立自己的人脉。这个并不是说要搞小团体，拉帮结派，而是你需要在工作中有一些愿意帮你、替你说话的盟友们。建立人脉和第一条有点关系，首先基础就是别人觉得你是一个值得信任的人。另外不要吝啬自己的帮助，多帮帮别人以后都会有回报的。盟友不止是技术方面的，也需要在管理层和业务方找到自己的盟友。
- 第四是要有同理心，站在别人的角度思考问题。人们常说想要说服别人需要的是诉诸利益，而非诉诸理性。很多时候告诉别人这么做给他们带来的好处远比讲大段大段的道理更有用。这也就是英文里常说的WIIFM（What’s in it for me）。另外一个方面，如果你的方案给别人带来了一些损失，你也要站在对方的角度，尽量想办法让这个损失最小化，或者和别人分担这个损失，再或者从别的地方给与一些补偿。
如何让自己更有同理心，就引出了下面一个能力——理解别人的能力。
六、理解别人的能力
理解别人的能力包含三个层面，第一个层面就是简单的听明白别人说的话。这个要求看似简单，其实很难。随着自己知识和经验的累积，在很多时候我们和别人沟通的时候，我们是可以大概猜到别人要表达的意思的，在这种情况下更要有意识的控制自己，不要轻易的去打断别人，或者先入为主的认为自己已经知道了别人要说什么。沟通最重要的目的就是获取信息、达成共识，获取信息靠的就是倾听，达成共识靠的就是上一条的说服。我们可以在认真听完别人说什么之后，再去用自己的语言去总结复述别人说过的话，来确保自己理解的和别人想表达的是一样的。倾听是一个宽泛的词，它真实的意思包含听别人说了什么，也包含读别人写给你的邮件和消息，还包含在沟通时看别人的表情和动作等身体语言。判断自己有没有做好这条听明白别人说的话，最好的方式是看看自己在别人说完之后能不能问出一针见血、直击要害的好问题。还有一个万能问题也能帮助我们听明白别人说的话，那就是“为什么”。最常见的应用场景是当我们和业务需求方沟通时，他们经常会说需要一个功能，这个很有可能不是一个需求，而是一个解决方案，多问一句“用户为什么需要这个需求？”或者“有了这个需求能给用户带来什么好处”能更好的帮助我们裂解真正的需求是什么，往往我们就能一起头脑风暴出一个更好的解决方案。
理解别人的能力的第二个层面是看明白别人做的事。每个人做事情都有背后的动机，看明白别人做的事的目的是根据别人的行为来更好的理解别人关注的点，从而理解别人的优先级，这样我们才能预判别人在什么场景下会做出什么样的行为，更重要的是如何通过改变会影响别人的动机的情况从而让别人做出我们希望做的事情。特别是当别人做了一些你看起来很反常的事情，或者说了一些很反常的话的时候，更要注意，这多半意味着你之前对别人的理解不到位，你忽略了一些很重要的东西，而这些东西对别人有很大的影响。
理解别人的第三个层面是想明白别人的想法，或者说从别人的角度来思考问题。所谓的“己所不欲，勿施于人”就是说你不想要别人怎么对你，就别怎么对别人。同样的还有“己所欲之，施之于人”，就是说想要别人怎么对你，就怎么对待别人。只有真正的想明白了别人的想法，才能更好的知道在说服别人的时候，哪些东西是别人最在意的，是不能妥协的，是你需要调整你的方案来一起保护的，或者需要在你的方案里面给与补偿的。
理解别人并不是只是为了说服别人，也为了让别人更好的帮助你解决问题。举个简单的例子，假如你调用了其他团队的一个服务，这个服务在某些情况下返回值不是你所期待的，你怎么跟这个团队沟通呢？第一种做法是你说“你们提供的服务有问题，有bug，你们代码是怎么写的？导致我们的服务都挂掉了，赶紧在A时间之前修好”，第二种做法是“我们发现在X场景下你们服务返回的值是Y，我们觉得返回Z更合适。我们做了A的调试方法，得到了B的调试结果。因为这个问题导致我的服务中断了，希望你们在C时间之前能帮忙修好，如果有困难请告诉我们，我们一起想办法，如果需要我们协助的我们一定全力以赴”。哪种做法更有利于问题的解决呢？
我们经常会看到有的人很容易获得别人的帮助，有的人却到处碰壁。除了上面说服别人的能力里在寻找盟友里提到的要互帮互助建立人脉之外，更重要的是你有没有把别人帮你的门槛很低。大部分人都是乐于助人的，因为帮到了别人会让自己开心。同样的大部分的人都是好为人师的，因为教了会让自己觉得有成就感。选择不施予援手大部分仅仅是因为提供帮助太麻烦，如果你在请求帮助时把自己的诉求说的很明白，把需要别人做的事情也说的很明白，让别人不怎么费劲就能给你提供帮助，这样的话很多时候别人时愿意帮你的。
怎么把自己的诉求说明白，怎么把对别人的要求说明白，就需要下面这条把问题说清楚的能力。
七、把问题说清楚的能力
我们平时要讨论的技术问题大部分都是比较复杂的，怎么把复杂问题讲清楚就是一项重要的能力，只有首先把问题讲清楚了，才能找到解决的办法。
把问题讲清楚的第一步是自己把问题想清楚了，就像橡皮鸭调试中所说的，很多情况下，只要我们能把问题描述清楚，答案自然而然的就浮现出来了。很多情况下我们没有想出来解决办法，只是因为我们没有想清楚问题本身。
做好把问题想清楚的第一步，接下来就是怎么把这个自己想清楚的问题再明白无误的传递给别人。把问题给别人说清楚一定要因人而异，要充分理解谈话的对象，知道他们关注的点是什么，然后针对这个关注的点重新抽象问题，重点突出，无关的部分简化。比如如果要和领导层说问题完全没必要谈到技术细节，和开发测试说问题完全没必要谈到项目预算。另外还需要尽量使用听众的语言，基于已有的共识，比如和业务需求方讨论时尽量避免软件术语，尽量使用他们熟悉的领域语言。
把问题说清楚有一些技巧，比如先说结论，再说论据。先说重点，再说补充。还有一定要简洁、简洁、简洁。
和不同的人用不同的语音和模型和来交流，就意味架构师需要下面这条从多个层面上抽象的能力。
八、从多个层面上抽象的能力
从多个层面进行抽象是说对同一件事情，要有不同维度，不同粒度的抽象。或者用软件的话说就是针对同一个Model，要有不同的View。举个例子来说，项目的系统架构需要有不同的视图（View），就算是同一个视图，也需要有不同的细节粒度。换句话说，架构师在准备系统架构的时候，需要有一个完备的架构作为基础（Model），然后可以提取出不同的视图来服务不同的应用场景。就算是同一个视图，还需要有类似于放大和缩小按钮一样的功能，可以站远了看宏观或者走进了看微观。比如同样的事情，再给CEO做汇报和给别的架构师做分享，当然需要不同的细节力度。架构师除了要在写代码的时候会抽象，也需要在写文档时会抽象。考虑到架构师在很多时候的沟通工具是幻灯片（PowerPoint），这当然就意味着架构师需要有写文档和画图表的能力。
不同的文档和图表用在不同的场合，给不同的对象传递他们最关注的信息。这也就引出了下面一条协调各方的能力。
九、协调各方的能力
架构师在很多时候可以起到粘合剂的作用，能够有效的协调各方实现我们的目标。
在团队内部，架构师基于自己懂技术、懂业务、懂项目管理这三个硬实力来协调项目经理、业务需求方和开发团队。对于项目经理来说，架构师帮助项目经理理解和管理项目的技术风险，并且一起找出最有利于团队的发展路线。对业务需求方来说，架构师帮助业务需求方更好的找到真正的业务需求，衡量各种解决方案中哪个选项最能给用户带来价值。对于开发团队来说，架构师帮助他们理解业务需求，并且把有利于开发团队长远利益的非功能需求，比如重构、消除技术债等反馈给项目经理和业务需求方，安排在项目的开发计划中，保证团队在实现功能需求的同时，有足够的时间来做对于团队来说最有利的事情。
在不同的团队之间，架构师通过架构师之间的网络，充分实现技术层面的沟通和合作。架构师之间的交流更简单和直接，很多时候可以绕开所谓的办公室政治和各个团队之间目标不一致的情况，从技术这个争议相对较小而且更容易达成共识的独特角度出发，实现各个团队更好的合作。
总结
上面就是我觉得成为一个好的架构师需要具备的三硬九软，以后有机会再针对里面的每一条展开聊聊。
参考文章：
本文在总结自己的思考的同时参考了下面这些文章。
Path to a Software Architect
What makes a good software architect? What are the defining characteristics of an architect, and differences between an architect and an engineering manager?
So, you want to be an architect?
5 Personality Traits of a Great Software Architect
Two key traits of an Effective Software Architect and how to maintain them
16 things to practice to become a better software architect
Software Architect Role, Skills, and Impact on Product Success
