《思路不对，搬再多的砖也成不了架构师》分享实录

各位千聊的小伙伴们和开发者们，大家晚上好。先做一个简单的自我介绍吧，我是来自聚合数据大数据部门的技术总监，我长期在一线从事基础的技术开发和管理工作，所以在工作中，对开发者的需求，以及怎样成为一个资深开发者，甚至成为一个架构师，有一些体会。

也非常高兴和码农基地以及千聊有这样一个合作机会，把自己的感触分享给大家。首先说一下为什么会选择这样一个话题呢？聚合数据不知道大家了不了解？聚合数据实际上是一家以数据接口形式，服务于开发者的服务平台。我们提供了大概了两百多种接口，包括生活常用、一些金融、汽车以及科学运算相关的数据，大家有兴趣可以在juhe.cn上去看一下有没有大家需要的数据。

因为聚合数据一直是以api的形式去服务开发者，我们在服务开发者的过程中，也接触到了很多开发者。但是我们发现大多数开发者的思想层次还停留在一个开发人员的层面，他们对自己的工作仅仅是把功能完成，所以我也希望我自己的经验能分享一下，希望能够让广大的开发者能够从术的层面到道的层面，有一个质的提升。

开发朋友们一定对架构师这样一个角色非常向往，刚才也在交流群里看到，有一些开发朋友非常期待成为一个架构师，下面我们简单列举一下今天的分享的提纲。我主要介绍架构以及如何成为架构师。

提到架构师，那我们不得不简单提一下什么是架构、架构是如何产生的。架构的产生在我看来，首先是源自于人类社会的一些分工，因为人在完成一些复杂任务的时候，我们的精力、能力和时间的局限性，导致我们必须把工作做一些拆分。在拆分之后，每个人都会对自己专精的事情有一些提升，这样生产力自然会得到提升。

那我们怎么定义架构呢？在我看来，架构其实很简单，就是把一个整体的工作切分成不同的部分，然后用不同的角色、不同的系统来完成这些分工，然后通过建立不同部分互相沟通、协作的机制，让这些被分开的部分又有机地结合到一起，成为一个整体，并且完成我们最终的大目标，这样就是一个架构。

那架构师在架构的过程中，他主要的工作是做什么？

提到架构师，我想先谈一下，架构师他并不等同于资深的程序员。架构师和程序员之间的区别，有点类似于工匠和架构人员的区别。工匠其实是做好自己的工作，并且把自己的工作做到极致。那架构师除了对自己的工作有足够的自信，还能够帮助别人来解决问题，而且还能帮助组织和整个系统来完成整体的工作。

既然提到架构师需要完成的不仅仅是自己的工作，那我们就来看看架构师具体需要做些什么？在我看来架构师工作的本质，其实就是做两件事情，一个是分，一个是合。分怎么分？分的依据是什么？这就要从架构师两个核心的工作开始说其，这两个工作一个是定义问题，一个是分解问题。

为什么我会先提到定义问题呢？因为我也发现，在工作中很多人拿到一个任务的时候，他其实拿到的只是我们想要的一个解决方案，比如老板可能需要我们去买一个锤子或一个榔头，但是究竟老板真实的需求是什么？可能经过询问，最后发现老板想要的只是把他手上的核桃给敲开，如果是这样的需求，可能我们不需要去买一个锤子。

所以我认为架构师在做架构之前，对问题的定义至关重要。我们需要发现利益相关方，从多个角度去认真理解真实的需求，同时我们要抽象出核心的概念以及核心的需求，同时要把一些非功能需求给定义出来——这些非功能性需求可能不是最核心的。

当架构师对问题进行明确的定义之后，那我们就要进入下一个阶段，就是分解问题。分解问题也就是对架构的切分，我们为什么要对架构进行切分呢？因为我们在某些利益相关点上，某些人的负载太重，或者在某些时间或空间点上负载太重，所以我们需要用单一职责原则，对模块、对架构进行一些切分，切分的本质是要平衡各方的利益。

对架构进行切分之后，必不可少地就是对架构进行实施。实施这个阶段，我们就需要对任务进行一些分解，在这个过程中我们必不可少地涉及到组织或人，这也是很多架构师可能会忽略的问题。实际上每一个架构的背后，都必不可少地涉及到人的问题或者组织的问题。

定义完架构师做什么之后，我下面给大家介绍一下架构师究竟长什么样。我觉得优秀架构师实际上就是四度、两性。

作为架构师，他需要在技术上有一定的广度和宽度。所谓的广度，是需要多领域的知识；所谓的宽度，是需要一定的技术前瞻性。另外从思维角度来说，架构师需要一定的高度和深度，高度是需要非常强的抽象思维能力，深度是能够分析到问题的本质。架构师的两性是架构师需要感性和理性，感性主要体现在，作为一个架构师，需要协调不同的开发力量、协调不同的业务部门，所以架构师需要非常强的沟通能力，不仅仅是能够作为一个资深开发，而且需要协调其他开发人员来做相关的工作。另外从理性的角度来说，架构师需要排除自己的感性因素，从理性的角度、从系统的角度去考虑，把各方的资源进行理性地平衡。

那刚才提到了架构师长什么样，架构师实际上具备四度两性这样的特征，是不是大家又开始懵了，觉得这样挺难的？这样的一些能力怎么去培养，下面我就从架构师的养成来给大家分享一下如何成为一个架构师。

首先，我觉得要成为一个架构师，必须要成为一个优秀并且务实的程序员，要重视代码的质量，以及项目的可维护性。要成为一个优秀的程序员，相比高性能、高并发这些很酷的事情，

其实简单清晰的设计以及可维护的代码这些，显得更加重要。

架构的抽象思维，实际上存在于工作的各个层次。日常的一些小工作，我们也可以通过训练架构思维，在函数、类、模块的各个层次，实现单一职责、最小支持、依赖注入这样一些原则，遵循以上设计原则来使用一些技巧。

架构师养成法则第二点，我是觉得所有的架构师都要养成完整的知识体系，尤为重要，比如说数据结构，比如说设计原则的一些分工，比如说一些设计模式对各种技术既要知其然又要知其所以然。因为扎实的基础知识在你找到问题的根源，会显得，这些都会帮你更好地去定位问题。

另外我认为建立完整的知识体系，要通过系统的学习和阅读，我们通过百度、谷歌，只能解决单一的问题，但是通过阅读、吸收前人的精髓，我们能够解决一类的问题。

架构师成长法则的第三点，我们需要从多个角度来理解业务需求，探寻解决的根本问题，学会平衡。项目的各方对同一需求的理解是不一样的，架构师不能像程序员一样，产品给什么需求我们就去做，而是要去分析需求的背后是为了解决什么问题，有没有更好的、更全面的解决这个问题的应对方案。

除了应对方案之外，每个项目实际上资源、人和时间都是不够的，架构师还需要去考虑到，从各个方面去平衡，去做出一些权衡，把核心的重要的功能甄别出来并且推迟一些不重要和不确定的功能。

那架构师成长法则的第四条，我觉得也是最关键的一条，也是很多程序员不具备的一条，那就是需要去练习高效、准确的沟通能力。从我个人经验来说，要尽可能用对方理解的话术来描述问题，保障我们双方能做同一频道进行沟通。很多技术人员和老板及业务人员沟通的时候，非常喜欢用一些专业术语，这个实际上是比较忌讳的。

最后我再给大家重新强调一下架构师养成的四大法则。首先是架构师要先成为非常优秀和务实的程序员，要对自己有一定的要求，重视代码的质量以及项目的可维护性；第二要建立完整的知识体系，对各种技术知其所以然。第三，要从多个角度理解业务需求，探寻要解决的根本问题，并且学会权衡。第四就是要练习高效准确的沟通能力。

今天我们的分享就到这里，接下来就是问答环节，我会在讨论区挑选出一些大家比较集中、共性的问题进行解答。

Paul：请问如何建立完整的知识体系呢？每一门语言都要求精通吗？ 

回答：关于如何建立完整的知识体系，我的理解是这样的，我们需要进行体系化的学习。以前我也习惯通过一些博客、SF、知乎这样的平台去搜取一些问题的解决方案。但是后来发现当下的问题解决了，但是当你遇到其他类似问题的时候，你还是没办法解决。所以我的建议是，大家对自己要解决的问题，以及未来的发展方向，能够有一个知识图谱，和一个对应的书目。然后通过这样的书目，我们再去进行系统化学习的时候，我们会发现知识点之间是相互串联的，再去解决问题的时候，比如解决一个系统的问题时候，我可以从服务器、代码甚至是从人性的设计角度，去考虑这样一个问题如何解决。

关于是不是每一门语言都需要精通？我的理解是这样的，架构师不一定需要掌握、精通每一门语言，但是他要具备快速掌握某一门语言的能力。我们要精通某一类语言，从而去衍生、掌握其他的语言。架构师其实他的能力范围不仅仅在语言，这位同学可能还限定在开发的思维，其实架构师他的能力不局限于语言，比如说他对服务器的掌握、对计算资源以及对数据库的掌控，都是我们在知识体系当中需要考虑到的。

小小程序猿：本来因为特别内向才学的程序员，如果往架构师方向转的话，是不是要经常去做沟通的一些事情？感觉不是很擅长，应该怎么办？

回答：性格内向但是又想成为架构师？我的观点是这样的，实际上并不是所有人都适合去做架构师，沟通是架构师一个重要的能力，但是沟通也是可以去培养的。我觉得这个朋友如果在技术上以及其他方面有自己追求的话，实际上可以去突破自己的沟通障碍，因为我们只有通过沟通才能挖掘出本质问题，针对本质问题来设计解决方案以及系统方案，同时去协调其他的一些开发比如说运维人员以及前后端，协调起来去解决整个系统的问题。所以我是觉得沟通很重要。

这位朋友如果是在沟通上，确实有一些难以克服的地方，同时对技术也有非常高的追求，也可以往技术专家的角色去培养，不一定每个人都要成为架构师。

任鹏举-Allen：架构师需要去跟客户沟通需求吗？

回答：有必要的话，架构师个需要去跟客户进行沟通。因为越是复杂的问题，经过越多的层级转述，失真的可能性越大。为了抓住关键的问题，必要情况需要跟直接客户进行沟通。

志强：产品经理，项目经理，架构师有什么不同？

回答：产品经理关注的是产品的表达、用户体验、商业逻辑。项目经理关注的是项目的安排、相关人员的协调。架构师关注的是如何依据技术资源，组织资源切分问题，形成子模块子系统，并将其有机结合起来。

产品经理定义方向与目标，项目经理对其进行推进，架构师对其系统可靠性负责。

paul：问请问架构师和技术专家有什么区别？

回答：架构师需对整体进行把控，他们可以不是某块具体技术的专家，但是必须熟知此技术或框架等能解决什么问题。

Black empire：问问罗老师能不能给提供一个架构师学习路线，和每一个阶段可参考的相关书籍？

回复：好的，关于书籍和前面一位同学关注的网站，我稍后可以整理分享。另外主办方送的人人都是架构师就不错哟。

豪哥：问听了罗老师的课，我对架构师的理解是：优秀程序员+需求分析师，这种理解对吗？

回复：应该说优秀程序员是基础，需求分析能力、系统方案提供和问题拆分能力，也极其为重要。

布布：问问架构师是否需要有整个项目的实现过程的技术经验？

回复：需要，架构并不是一次性的工作，贯穿在整个项目始末，有完整项目经验，对预知项目不同阶段会遇到怎样问题，怎样在不同阶段调整也很重要。

坚持：在技术方案选择时，与同事发生分歧时，如何处理？

回复：架构师不仅仅是一个头衔，也需要有实权。出现不可协调的分歧，一定以架构人员观点为准。因为他是上帝视角考虑全貌。所以架构师也并不容易，也需要真的具有技术说服力来避免此类问题，不到不可避免情况，切忌用权力来说服开发。

很多公司所谓架构师并不具备架构师的能力，只是在做系统架构的设计工作而已。

何锋：问请老师推荐些作为一个优秀的架构师应该掌握的工具，特别是针对需求梳理、拆分的时候，谢谢老师

回复：这个我感觉看个人喜好吧。我个人喜欢用markdown整理文字，用xmind之类画脑图，把问题列出。用omnigraffle来画uml、架构图那些。当然 一些在线的工具也是不错，百度脑图、processon这些。

今天分享先到这边，非常遗憾许多小伙伴的问题也没来得及回复，感谢大家聆听和交流。

主持人：好啦，最后请罗老师选三个优质问题，赠送《人人都是架构师》书籍。

罗承成嘉宾：恭喜paul、豪哥、Black empire三位问题比较具有代表性，也有自己思考。希望人人都是架构师能有更多启发，一起交流，共同进步！

主持人：恭喜这三位伙伴！感谢大家参与，下期再见！