七牛云许式伟：我所理解的架构是什么

从软件工程提及

你们好！

我已经好久没有作技术类的演讲了，由于我最近确实比较忙，不多会出来。为何会忽然又想谈一下架构呢？这是我我的的宿愿，我是技术出身，虽然如今比较少写技术相关的东西，但我在公司内部作了不少分享，分享课里我讲的东西与架构相关的占三分之二，基本都是和架构相关的。

因此今天借这个机会谈一谈我本身理解的架构究竟是什么。

国内如今比较少真正意义上符合 “架构师” 这个词的定位的角色，咱们的教育和工做氛围很难出真正意义上的架构师，比较百里挑一。我本身理解的架构师是从软件工程概念开始的，也许你们都学过软件工程，但若是咱们把软件工程这门课从新看待，这门学科到底谈的是什么？是软件项目管理的方法论？

不管如何，软件工程是一门最年轻的学科，相比其余动辄跨世纪的天然科学而言，软件工程只有 50 年的历史。这门学科的实践太少了，任何一门学科的实践时间短的话，都很难沉淀出真正有创意的实践总结，由于这些经验总结老是须要不少代人共同推进来完成。

为何只有 50 年时间呢？咱们来看看 C 语言，通常意义上可能认为它是现代语言的开始。C 语言诞生于 1970 年，到如今是 49 年。再看 Fortran，它被认定为第一个高级语言，诞生于 1954 年，那时候主要面向的领域是科学计算。Fortran 的程序代码量不大，量不大的时候谈不上工程的概念。这也是为何软件工程这门学科很年轻，它只有 50 岁，在这样一个年轻的学科里咱们对它的认知确定仍是很是肤浅的。

我在极客时间里的课程里一上来就作了软件工程和建筑工程的对比。对比能够发现两者有很是大的区别，具体在于两点：

（1）快速变化。建筑工程在完工之后就结束了，基本上不多会进行变动，除非对它进行软装上的变动，软装更像是今天的软件。但其实软件工程里，软件生产出来只是开始，并且只要软件的生命周期没有结束，变动就一直存在，很像建筑里的软装同样，并且比软装变化剧烈得多。

（2）不肯定性。为何软件工程有很大的不肯定性？由于没有两我的的工做是同样的，虽然你们都在编程，可是编程的内容是不同的。每一个人昨天和今天的工做也是不同的，没有人会写如出一辙的代码，咱们老是不停地写新的东西，作新的工做。这些东西是很是不一样的，软件工程从事的是创造性的工做。

你们都知道创造是很难的，创造意味着会有大量的试错，由于咱们没有作过。这会致使软件工程有很是大的不肯定性。

以上这两点都会致使软件工程区别于传统意义上的全部工程，有很是强的管理难度。过去那么多年，工业界有很是多的工程实践，可是全部的工程实践对软件工程来讲都是不适用的，由于两者有很大的不同。

今天站在管理的视角再看软件工程，咱们知道管理学谈的是肯定性，咱们如何去创造肯定性是管理学中的追求，不然管理管什么呢？某种意义上来讲管理学的目的就是要抑制不肯定性，产生肯定性。好比说开发的工期，时间成本是否能肯定。其次，人力成本，研发成本和后期运维的成本是否是肯定性的。因此软件项目的管理又指望达到肯定性。这是一对矛盾。软件工程自己是快速变化的，是不肯定的。可是软件工程管理又但愿获得肯定性，这就是软件工程管理上的矛盾。咱们的目标是在大量的不肯定性中找到肯定性，这是我认为这件事情最核心的点。

程序员的三个层次

软件工程管理到底在管什么？和全部的管理活动同样 无非就是人和事。全部的工程项目都但愿找到最好的人，固然是在能给出的预算之内找到最好的人，有的人可能找不起。不一样项目最大的差异就是事，不一样的事在哪里？从作事的角度来说咱们招到的人可能会分三个层次（程序员三个级别），你们常常开玩笑说我是作搬砖的，因此第一个 level 我把他叫软件搬砖师，再而后是软件工程师、软件架构师。

软件搬砖师能够有不少。但今天数量其实还不算太多，由于咱们知道这门学科只有 50 年的历史。可是好的一点是，产生软件搬砖师并不难，我作了一个长达四年的实践：从小学二年级开始教小学生编程。结论是作搬砖师不难，小学生也能作到。这是颇有意思的一件事情，编程并非很是复杂的学问，只要具有基本的逻辑能力，把常规的业务代码循序渐进地垒出来，基本上能够算打到搬砖师水准。我本身认为这并不难。

软件工程师会相对难一些，我心目中的软件工程师首先在代码上会很是追求可读性、可维护性。另外，毕竟咱们工程是群体协做，因此在群体协做上仍是有本身的方法论和思考。好比说代码评审、单元测试。在我看来搬砖师和工程师的区别有很大不一样。只要看他写的代码有没有注意可维护性，会和同伴交流的时候刻意去追求让同伴更好地理解本身的思想，是否是对单元测试比较抗拒，是否是比较乐意去作代码评审而且很是认同这件事情的价值，基本上经过这些事情就能够评判这我的是搬砖师仍是工程师。

软件架构师的能力要求

谈到软件架构师，因为我毕业后两年在从事架构性质的工做，所以对软件架构师的特性有一些总结。首先在用户需求上，有判断能力和预见能力，此处的判断能够理解为对需求的鉴别，虽然这可能与产品经理最为相关，但架构师须要具有本身的判断力，固然这也包括对将来需求的预见能力；产品迭代上，有规划能力，判断需求哪些应该先知足，哪些后知足。架构师应该源于程序员，但不该局限于程序员视角。系统设计上，有分解和组合能力。技术选型上，有决策力。技术选型应该被认为是架构的一部分，咱们很是反对开发人员随意选用开源组件，这是一件须要认真探讨的事情。人力资源上，有统筹能力，通俗地讲是 “看菜作饭（看人下菜）”。

综上不难看出，架构师对综合能力要求比较高。这是由于我认为架构师须要对软件工程的结果负责，在不肯定性和快速变化中寻找肯定性。全局看软件发布流程，其比较重要的子过程有：需求分析（需求梳理 => 产品定义），系统设计（子系统划分 => 模块定义），模块设计（模块详细设计），编码实现，单元测试，代码评审，集成测试，灰度发布，正式发布等一系列过程。虽然有些过程看起来不属于架构师的范畴，可是这些活动过程属于软件工程的一部分，架构师同样须要全面参与把控。若是没有架构师把控就没有人观察获得全貌。正由于如此，软件架构师的要求相对较高。

如上所言，软件架构师须要具有产品经理的部分能力，由于须要对用户需求进行分析，并进行判断和预判，以及对产品迭代优先级进行把控。我本身习惯用以下图片表达软件架构师和产品经理之间的关系：

我认为，产品是“桥”，链接了两端，分别是用户需求和先进的技术。我一直认为，用户需求的变化很是缓慢，那么为何产品会产生迭代？这是由于技术在迭代。本质上讲，产品迭代是技术迭代致使的需求知足方式的变化，因此产品其实是一种需求知足的方式。

从这个意义上讲，架构师更可能是从技术方案的角度看产品，而产品经理更可能是从用户需求来看，但两者必定会碰头，只要能力提高到角色所指望的样子，越厉害就越具有两侧的能力。因此我认为，产品经理和架构师是一体两面，本质上对人的能力、诉求是相通的。产品经理在作产品架构，架构师在作技术架构，但最终目的同样。

从产品和需求视角看架构师

若是展开讲解产品定义过程，首先须要进行需求梳理，关心用户反馈。可是，不少用户反馈并不表明其根本性需求。有不少用户反馈需求的时候，每每已经带着他本身给出的解决方案。这种需求反馈已经属于二次加工的需求，而非原始需求。这个时候咱们要多问多推敲，把它还原到不带任何技术实现假设的根源需求。

如上图所示，根源需求可能会有很是很是多的技术方案能够知足它。咱们上面示意图中的小圆点是一个个用户反馈的需求。在用户提这些需求的时候，每每可能会带着他熟悉的技术方案的烙印。

产品都是经过提供相应的技术方案在知足用户的根源诉求，但技术一直在迭代进步，从而致使原有的解决方案过期落后，这种状况下须要新的解决方案出现。若是对用户反馈的需求所有知足，产品就会变得十分庞大，编程一个四不像的东西。

其次，在这个过程当中，有些用户需求是稳定的，有些是变化的。举例来讲，计算机系统结构从计算机诞生以后到如今没变过，但电子设备的形态发生了很大变化，从最先的大型机，到我的电脑，到笔记本，到手机，再到手表，形态变化剧烈。但为何计算机系统结构可以适应需求而不用改变架构，这实际上是很是值得思考的事情，其根源就是对变化点的抽象，找到系统需求的变化点，预见变化并作对应的开放式设计。本质上讲，架构师关心产品的核心根源就是预测变化。

最后，理清产品边界。一样以计算机为例，通过多轮迭代，多样化外设（键盘等）变化较大，但 CPU、内存演进较小，因此在变化点上作相应的开放式设计是必要的。一样的，须要与合做伙伴作边界设定，把变化开放出去让合做伙伴作，只有这样的产品才能达到较好效果。

从产品和解决方案角度来看，产品每每须要适应不少行业，但这个过程会让产品变得很是庞大。在我看来，产品应该为行业解决方案提供能力，行业解决方案优先选择合做伙伴作，以更加开放的心态看待这件事情，避免把行业方案视做产品的一部分。

梳理需求中比较关键的点是市场策略，须要解决的需求有很是多现成的方案，但哪些方案是主流的，哪些是最关键的都须要思考。虽然不能放大产品需求覆盖面，但也须要为某些关心既有市场的玩家作桥梁，这些桥梁也是产品的功能点。我倾向于认为关键市场可能会把既有玩家的能力适配到产品上做为很重要的功能，可是大部分市场主流方案咱们仍是提供“桥”，而不是本身解决掉。

从技术视角看架构师

以上是从产品和需求维度看架构师，从技术视角看，架构师很重要的能力是具有技术的全局视角，所谓的技术全貌是指从底到上的核心骨架，好比最底下的硬件结构、操做系统、编程语言，甚至浏览器等，只有掌握每一层的核心思想，才能在架构设计中没有技术盲点。

从培养架构师的角度来看，为何真正意义上的架构师比较难找？这是由于须要构建两个层次的能力：

一、懂用户、懂市场，有必定市场洞察能力。做为技术人员，可能会不自觉、甚至不肯意和用户打交道，更但愿坐在家里安静码代码。可是，做为架构师，不和用户打交道，成长会比较受限，不接触用户就没法理解用户需求，亲自和用户打交道倾听来的需求和探讨彻底不同。所以，架构师要尊重用户反馈，并学会思考需求分析和推演，这比技术能力更重要。架构的第一步就是需求分析，若是需求分析没作好，后续天然没办法作得很极致。

二、创建技术上的全局视角。

以上两点是架构师最核心的两个能力。

最后，我要介绍下，最近我在极客时间上开设了架构课，到如今为止恰好第一章所有发布。专栏内容的结构基本是相互交织的两条线索：

一、信息世界的构建过程，从底层硬件到操做系统逐层递进，还原信息世界的构建历程，主要关注宏观结构及需求变化，每一层都经历了哪些变化；

二、架构方法论。若是咱们纯讲架构方法论，容易过分抽象，好比什么开闭原则、单一职责原则之类。因此咱们要结合信息世界的构建过程讲，它自己就是最宏大的架构实践案例。

以上就是个人演讲内容，谢谢你们。

 出处：https://www.infoq.cn/article/scbBuLydXi00sZ4v*UyN