5月7日，「腾讯SNG & msup技术开放日」在深圳召开。壹佰案例采访了一些与会讲师，谈谈他们将在会上分享的内容。本次采访的是腾讯云平台产品技术负责人陈子舜。
壹佰案例：首先想请您介绍一下您目前的工作以及您关注的领域
陈子舜：我目前在腾讯云团队，负责平台产品线的管理工作，其中包括前端团队、团队的能力建设等工作。从技术角度来说，我现在更多关注前端的发展，包括前端的一些趋势和未来潜在的新技术。
壹佰案例：前端曾经被误解为「做网页」、「切图」的，但随着前端技术不断发展，我们也可以看到前端技术是现在发展最快的技术之一，类似AngularJS、React等框架层出不穷。现在的前端开发从简单的Web开发到Web富应用开发，您对这种前端技术的发展趋势是怎么看的？
陈子舜：我非常认同前端发展很快这个说法，但也要注意到前端技术的起步是相对比较晚的。从2004年谷歌出了Gmail提出Ajax开始，大家才意识到这个技术其实能解决很多问题，但是如果再往前看的话，终端的一些发展，包括整个计算机领域的发展，其实对客户端的要求，这个路径已经走了很长时间。
前端因为发展的比较晚，现在才走到“我要去做组件”，“我要去提出AngularJS”，“提出一些从前端Router”到“提出双向绑定等方式”，包括像React提供了一种组件的管理方式。以上的这些说法实际上并不新鲜，在客户端开发里，这些概念一直都有，只是前端基本上是按照客户端的发展路径不断快速的对齐现在的发展趋势。现在如果要看前端以后能往什么方向发展的话，我觉得更多可以参考客户端发展的路径。
壹佰案例：QQ空间的业务随着互联网的发展、用户数的增长，经过几次技术升级的过程，您能从前端的角度谈谈QQ空间这几次升级背后的故事吗？
陈子舜：
第一个阶段是我刚刚接触QQ空间的工作，这个阶段很重要的工作是什么呢？当时我们面临十万用户同时在线的台阶，而且对我们后台负载有很高的要求。所以在当时我们最主要的工作是：我们怎么样先扛住用户快速增长的阶段，能够给后台降低负载压力。因为2006年的前端开发模式，就是后台主页面的方式，我们发现如果按照这个方式做，后台压力很大，而且当时的后台也没有现在那么好的硬件条件。我们前端的团队当时也只有三个人，我们就想各种各样的办法来帮助后台减压。
怎么做呢？我们把一些逻辑代码提到前端来，刚好也有Ajax的一些技术可以去创新，我们可以用这种前端异步的方式把很多东西移到前端来。同时我们也更多考虑怎么去减少后台的请求，比如说文件合并、预加载等，实际上很多都是我们在当时的架构考虑到的事情。
当然还有后台请求过多的问题存在，不仅仅是页面请求，还包括后台CGI过多，因为空间分很多模块：个人中心、博客、留言、头像等所有信息都代表后面有相应的服务。
当时按架构去考虑我怎么样在后端部署一个统一的环境来配合后台，做好这种按照标区类的方式知道哪一个模块数据更新然后去动态拉取。其实这种逻辑在当时的前端是有些过于「重」的，但这也是一个标志性的，让我们度过了2006-2007年用户快速增长的阶段。
第二个阶段我们发现前端变得越来越重。那个时候前端的代码里面背负了很多历史问题，所以我们一直没有对它进行太多改动。后来当时我们决定花了很长时间对空间代码进行重写，需要重写的代码量在当时统计出来的数字是非常大的。
特别需要提到的是当时为了做到极致，减少请求，把很多逻辑层代码都拆分到很小的文件里面。所以在重构的过程中，我们也引入了一些模块化的管理方式。
坦白讲，比现在的模块化要引入的更早，但比较遗憾的是我们没有对外输出这些工具。举例来说，我们内部写了一些工具怎么把这个文件拆分，把目录变得更加合理；还有一些工具自动化去合并，进行程序压缩；也采用了自动化的方式，能够保证我们的代码管理和部署。我觉得第二个很重要的阶段就是我们怎么样对代码进行模块化管理。
第三个阶段是团队变得更大，团队规模从几个人变成十几个人的时候。那么怎么去做呢？这时候产品对前端的要求越来越高，需要你实现越来越多功能，而且跨团队的配合也越来越多，在我总结起来应该经历了一个叫技术规范化和标准化的过程。
在前面代码已经管理好了，模块已经做好了，那怎样提升效率，怎样让代码提交之后不会产生很明显的错误。
我们当时的用户挑战很多，比如浏览器兼容不行，当时其实有很多浏览器可以使用，比如火狐、Chorme这些版本都出来了，我们在浏览器测试上花了很多功夫，但是实际上还是没有达到要求。当时我们就在想，我们团队得有一个标准组件，有一个标准的框架来解决浏览器的兼容问题。
在当时的阶段，市面上能写的框架也不是很多，所以我们决定自己去写。为什么自己写呢？因为腾讯还是有一种喜欢自己造轮子的心，所以后来我自己就给团队做了一份这样的标准框架，在内部我们把它称之为QZFL，实现了规范化。
这个框架从1.0发展到2.0走了很长时间，也解决了大家在开发过程中的问题，例如我不需要再去关注一些常用前端组件的实现、一些功能的实现，只要关注业务逻辑就能好了。
在技术标准化方面我们引入了监控，引入监控后，我们可以对整个网络的环境以及前端的客户有了掌握，通过监控我知道前端的性能是如何的，知道我每一个请求的返回成功率是怎样的。监控发展到现在也拓展了很多新的维度，比如说我知道哪一个省份的用户比较慢；哪一个运营商网络比较慢；现在慢的用户大概的百分比是多少等等。
这些数据可以帮我们不断提升整体空间的运营水平、运营能力。我觉得这是一个很重要的标志，让我们走到了一个工业化的程度。这是我觉得空间现在做得比较成熟的很标志的一件事情。
壹佰案例：QQ空间相关的技术已经很成熟了，未来还会遇到哪些挑战？
陈子舜：QQ空间现在相对稳定，我也很难判断以后会遇到什么样的技术难点。我觉得真正的难点在于它能不能应对现在日益变化的用户需求，很难说某一个技术难点可以算作难点。而是我觉得QQ空间更多要应对的是现在终端用户习惯的变化，技术能不能及时更新，解决用户的问题。我们做很多事情还是以产品的价值为导向，我们要考虑通过技术手段解决具体的产品问题。
空间现在相对来说成熟，也是给我们团队一个很好的机会。因为客户访问量仍然非常大，也就是现在比较火的海量服务。海量服务的特点是你每做一件事情，你的判断都会影响大量用户的使用。所以对程序员有很高的要求，每一件事都要考虑得非常清楚才可以去验证实施。
其实QQ空间走到现在，还在做很多很前沿的尝试。比如说希望尝试HTTP2，空间的监控除了我们之前讲的这种地区性能、运营商性能的监控以外，自己本身的数据染色、数据采集等等这些能力其实也做得越来越深入了，同时空间的前端组件从浏览器到接入层都是一整套完整的解决方案，这是QQ空间成熟的表现。
壹佰案例：前端的工作中优化是非常重要的一个模块，在一些论坛上也会对优化有很多的争论，前不久就有用户在知乎上就QQ空间打开首页就加载100+的JS提出问题，在这个优化标准的问题上您怎么看，会不会以数字去衡量这些标准？
陈子舜：其实大家追求极致优化目标的衡量标准是唯一的，但是方案其实会随着业务而产生多样化的方案选择。其实空间一直以来都在做优化，我们对极致的做法可能和很多人的常见的理解是不太一样。
我们更喜欢不断尝试一些新方式，提出假设。我觉得前端的优化方式，都有一定的时效性和适用性。不见得说加载一百多个文件就是好或坏,当然我们也不否认现在加载一百多个文件确实不见得很好，可能是团队管理，或一些其他技术以外的原因。而最后我们其实都是需要拿出的数据衡量。
例如：哪怕真的加载了100个文件，有没有想过：其实这100个文件也许并没有使用户打开的页面变得很慢，而相反有办法可以让他感觉很快的？如果100多个文件并不是在你首屏显示的时候加载的，支撑首屏文件做好控制，其他都走了异步请求，文件多也不见得对你的业务有太大影响。
所以我们的判断在于用户看到的性能如何，他用这个功能的时候能不能快速获得想要的东西，这一切都是基于我们有可靠的数据分析后进行论证的。不断提出假设，设计方案，更有针对性的优化某一些地方，针对用户常见的一些问题，拿出去论证、验证，然后采用或推翻之前的假设。
也许你会觉得加载了100个文件有问题，但是从我们这边的数据看，可能这并不会真正的影响用户体验。简单来说，好比我们之前一直在说一些优化，要进行合并。经过几次架构升级，我们发现有一些文件我们把它合了又拆，拆了又合，合了又拆。这是因为我们随着客户的网络、硬件的变化，一直在进行调整。没有一个最终标准可以说按照这个标准就可以做到一劳永逸的优化。
壹佰案例：提到Web优化，有很多公司提出过一些黄金法则，例如Yahoo，您如何看待这些法则，腾讯内部有没有总结过类似的东西？
陈子舜：我们在技术总结方面的角度可能和其他公司不太一样。我之前也讲了一些优化的原则，我们的优化理念其实是类似国外「增长黑客」的理念，就是提出假设，设计方案，分析数据，验证，推翻假设的过程。
我们觉得标准的东西不见得能够通用，所以我们也没有对外推出一些黄金标准。举例来说Facebook也没有对外提供标准，在给我们分享Bigpipe的时候分享者最后说了一句话，“我现在做的优化可能也只适合Facebook用，不见得适合大家”。
在我看来，黄金法则是只告诉做法，但是并没有告诉大家为什么这样思考为什么要用这些做法，而现在雅虎很多的优化理论会有一些不合适的地方。甚至说的更直接一点，如果HTTP/2有一天火了，基本上这个雅虎的优化黄金法则就废掉了，那你还要去用吗？
所以优化是不断演进的，我刚刚也讲到，前端优化是有一定的时效性和适用性的。这样就对前端开发有更高要求，一定是一个懂思考的程序员，才能提出更多的假设，并知道怎么去论证。
所以，在腾讯我们不会看谁用了什么法则而去判断这个人能不能达到高级工程师的程度，而是看他的思考过程、思考逻辑，在解决这个问题的时候，你的思考逻辑是不是符合了这样的方式，你找到了创新点，更漂亮地解决了一个具体的性能优化的问题。
壹佰案例：前端性能优化对普通用户来说其实就是他打开这个网页更快了，但实际上在这个快背后是有很多可以做的技术工作。
陈子舜：没错，我们的性能优化目标是什么？刚刚讲得很清楚就是为了快。而快的目标是什么？比如我的页面打开时间是1秒钟，我们为这1秒钟打开花了很多工夫，不仅是前端压缩，不仅是前端文件合并，我会采用一些cache，我在业务用的一些网络延迟的手段、技术去让网页打开的更快。其实这里面前端考虑了非常多的问题。
另外随着发展，现在前端越来越重，对用户的CPU是不是一个消耗，对CPU的把控是不是有一个方法？我监控CPU的即时情况，能否保证首屏渲染的内容优先获得CPU资源，一些重资源可以延迟渲染，不要影响用户的打开，所以我们也尝试去通过对CPU资源的控制来提升性能。
另外也在思考在渲染方面我们是不是可以做得更深，我们要去研究浏览器的内核，考虑渲染方式，包括和我们的X5团队、浏览器团队也有很多交流。你会发现整个前端优化到最后，更多在于怎么能发现问题，包括推动技术环节的各个角色去解决大部分的事情。
然而现在很多前端开发，大多数认为只要运用了某某原则、某某法则就完成了性能优化这件事情。但是他没有想到，在整个页面打开的流程下面，会有很多基础环节。包括页面打开的JS问题，页面的请求，后端的性能，浏览器发生什么事情，都有可能成为你的优化点。性能优化其实是一个持续的技术运营。
最难的是，你怎么从各个环节发现可能存在的一些优化，提出假设之后，带领团队跟大家一起，把这种优化问题解决掉，这是程序工程师经常做的事情。
壹佰案例：提到带领团队，您经历了从3个人到几十个人的团队演变过程，也成了一个管理者，团队由小变大的过程中有没有一些好的管理经验分享给大家。
陈子舜：我带领了很多团队，在云之前我带的基本上都是新团队，我刚刚过去就是几个人，人少的时候时候我们先想办法扛住业务的需要。
接下来团队规模稍微大一些，我们需要建设一些管理的部分，来帮助这个团队有效运转，怎样管理工作流程、开发模式，包括团队之间合作的方式、流程的建设等。
到团队规模再大一些，要求再高一些，就看你对团队提出的标准。比如说代码规范、工程化管理，有更好的管理手段和工具引入进来，帮助团队更有效的完成目标。
我觉得这是整个管理的过程，就好像我们管理方法中一个团队的形成阶段和磨合阶段，以及团队自身的规范期阶段，最后产生团队的绩效，基本上都是按照这样的思考方式去做。
壹佰案例：您的团队中肯定有不少新人，随着前端的火热，也有不少人想去做前端，对于这些新人朋友，作为一个十年经验的前端前辈，有什么建议给他们？
陈子舜：前端其实和以前一样是很容易入门的一个技术，但这个技术的挑战也是太容易入门了，导致很多不是程序员的人过来做前端。要是真正喜欢做前端，想成为一个合格的前端开发，首先要是一个合格的程序员，而好的程序员是有一些要求的：
首先是计算机基础，掌握一些网络算法，对程序员来说这是根基，无论你是前端也好，还是后台也好，这些都是很重要的，这是计算机基础能力。
第二，程序员在编码过程当中是不断挑战新问题、不断提升代码的。同时好的程序员不会给后辈留下坑，他会考虑代码的可适用性，这种通用素质他会想得很好。
第三，作为程序员应该有严谨的思维逻辑。做任何事情、任何决策都需要数据论证，不会去猜测也不会轻易相信外界的一些黄金法则或建议。程序员懂得通过一个问题进行逆向思考，为什么会提出这样一个问题，一般都会有这样一种很叛逆的想法。
另外，程序员对新技术要保持好奇心，但不应停留在我用了哪些新技术，而是要思考为什么这个新技术会这么设计，最终解决什么问题，我觉得好的程序员在这方面会想得非常多。
在这些问题上，如果觉得自己都可以有这样的想法之后，你再去前端领域，再去前端做更多事，那你是一个好的前端程序员，而不仅仅是一个简单的前端开发的角色。
壹佰案例：在从新人成长为管理者的过程中，特别是经历过很多不同的业务，您是如何在快变的环境下学习并迅速融入新业务的？
陈子舜：我其实在腾讯做了很多业务，从QQ空间到做增值产品到现在在做云，在这个过程中我也在不断学习。在做任何业务之前，我首先要了解这一块业务是做什么的，这一块业务需要我的技术有什么样的变化。
从PC到手机终端的转变过程中，那我们就说我们要去拥抱H5，拥抱类似的开发能力，让自己也可以学习这一方面的知识，保证自己能够达到业务要求，可以帮助业务解决问题。
现在做云之后，发现做云对狭义的前端（只写JS）要求不像QQ空间那么高，反而对程序员思维逻辑，以及全栈的要求会更高，因为你首先要重新认识云的业务，重新理解业务对应的用户是谁，云的用户其实对应的是广大开发者；那广大开发者需要获得你什么样的帮助，你的产品可以给他什么样的支持，你怎么样做得更好。
然后就会思考我这个团队现在的一些技能能不能满足，我的团队需要做出变化，能够尝试更多，甚至是站在更广的层面思考这些开发者他们会遇到什么样的困难。
所以我这个团队基本上转变为全栈工程师的角色。到云之后，我们需要了解更全面的知识点。我们就要把自己打造成一个全栈工程师，从前端JS到后台NodeJS的能力，包括网络各个方面的东西，都要有很全面的把握，你打造出来的产品才可以解决更多客户的问题。
我觉得在业务上我的学习方法，都是从业务的客户需求出发，去考虑我的技术应该怎么做出调整和转型。
壹佰案例：腾讯如何看待前端，从公司层面会不会为大家制定能力模型？
陈子舜：我刚好是腾讯前端通道的负责人，其实通道的标准在去年我们也更新了一版，最早的晋升通道还是聚焦在前端JS这方面。你怎么解决问题，怎么做到性能优化，怎么去做好业务的可持续运营，这些都是前端通道的要求。但是因为市场发展很快，我们也做了一些拆分，拆分成什么样呢？
第一，前端的游戏方向。游戏的偏重在于要有更快的学习能力、学习要求，因为游戏技术变化也是非常快的，有很多新的游戏框架和引擎，包括H5本身也有很多游戏方案，你能不能快速学习。游戏还有一些新的要求，比如对安全的要求，因为会有很多人在写外挂，所以安全性的要求也是这个方向要考察的部分。
第二，前端的终端方向。对这个方向的要求会跟普通的前端开发不太一样，因为它得跨界，首先要对H5的能力有所了解，还要了解一些Native终端的知识。这样可以更好的解决用户的问题，所以都会有一些偏重。第三，全栈工程师，我们内部叫全端工程师，这个就是说，我们把Node.js和PHP这部分放进来了。我们为什么认为这个属于前端领域呢？因为从用户访问页面的「最后一公里」来看，用户打开浏览器到浏览器页面输出内容，这些事情都应该是由前端来覆盖的。输出页面的技术，我们通常叫接入层，或者叫接入web服务，接入web服务这方面我们在前端有一定的话语权，并且能够可控，我能够在上面开发我们的业务，这样做也可以减少我们和后台开发协同的成本。
同时我们在做新的优化，包括业务逻辑上更有可控性，而不像以前在空间的时候，比如说我们要做一个优化，要push后台其实是很难的事情，因为大家节奏可能会不一致，而且他也不一定理解你为什么要这样做。所以我们就提出了第三个叫做全栈工程师，这也是行业比较流行的概念。
第四，腾讯有一个更加特殊的领域叫体验工程师，也是一个专业化的前端团队。所以目前我们在通道里面分了四个方向，来覆盖整个公司全端团队他们所做的工作要求。而每一个方向也都由高级工程师制定的新的具体的要求，帮助大家不断成长，跟上行业对自己能力的要求。
壹佰案例：您对全栈如何看？
陈子舜：对全栈工程师我是这么看的，还是回到程序员的问题来讲，程序员不应该是一个挑活儿的角色，很多技术都该感兴趣。如果认为说多学几个语言、有一定的跨界就叫全栈工程师，那其实可能对全栈的理解就窄化了。
一个真正好的全栈工程师的概念是包括对覆盖的技术、对业务的理解、对各个角色的理解都应该有非常全面的认识。对全栈工程师来讲，他最大的特质是说他能够接受变化，遇到变化的时候，能够快速转变，可以解决具体问题，当然也要有一定的深度，这才是一个比较好的全栈。
从我本身来说，我自己虽然也说全栈，各种技术我都接触过，包括后台，包括Java，基本上都研究过一遍，当然我不能说所有的方面都有很深的了解，但是有一件事情我是能够深入了解的，其他事情你让我去做我也能够去完成，基本上就是适应性很强的一个程序员。
大家都知道国外的知名IT公司，都喜欢招全栈工程师，简单来说就是程序员不应该把某一个语言把自己框死，其实这个是现在在国内很多程序员很可怕的一个想法，大家把语言的level看的太高了，其实把语言作为一个工具，把自己从用这个工具的角色里面跳出来，让自己可以接触拥抱这个行业的变化，让自己在思路上能够却打开更多。
壹佰案例：React背后是Facebook，AngularJs背后是谷歌，似乎还没有很强的中国力量参与其中。您对中国未来前端发展，包括一些开源的力量，是怎么看的，未来有没有可能有中国的公司去做类似的事情？
陈子舜：没有能拿出一个框架来并不是中国的程序员能力不够，而是说是否有足够的管理机制、管理办法鼓励这些程序员，可以让他们不断提升，或者说不断投入在这个事情上面。
因为在我看来，国内很多的互联网公司还是在积极进取开疆扩土的阶段，无论是业务导向或运营导向都会要求程序员要去解决大量的眼前的问题。其实一个好的开源组件不仅仅是你做出来了，最重要的是你能不能把社区维护起来，能不能把大家对这个组件的热度维护起来。不能够持续地输出更新、保持迭代，这个是大部分国内的前端的框架和组件遇到的困难。
如果说这个问题可以解决，我相信国内还是会拿出一些蛮出色框架，让更多人去使用。据我所知，国内很多原来本身在一起给公司提供前端标准的团队慢慢也拆散了，我也希望有一天国内的公司可以做出一些调整，能够专门有一个团队，为了行业去提供和设计这样的一些技术能力。
但国内可能还不如国外有这种技术的氛围。我问过React的团队，我问他为什么Facebook愿意鼓励他们做这样的事，他们也讲到了一些点我觉得很有意思：因为开源React可以解决他们招聘的问题。
壹佰案例：通过开源React去解决招聘问题？
陈子舜：React在Facebook内部也酝酿漫长时间，甚至有一度停止更新，后来也是有志的程序员拿出来重新改良后推出。其实通过这个案例我们就可以看出做开源框架需要长期的投入。你做的React好用，让更多开发者去用，这些开发者肯定都懂得React，招聘后也减少人才培养的成本，同时很多人也会慕名而来，大家会抱着这样的想法，原来React是Facebook推出的，那我愿意去加入这个团队和他们一起工作。这也形成了一定的人才招聘的氛围。
本文转自“壹佰案例”公众号，原文链接
