共计 5578 个字符，预计需要花费 14 分钟才能阅读完成。
杨永林，人称“教主”，八年前端开发经验，原新浪微博前端技术专家，现任链家网前端总架构师。长期研究 Web 访问性能优化和前端框架搭建。作为初始团队成员，教主参与了新浪微博所有 PC 版本的开发，其中 4~6 版以架构师的身份设计了微博 PC 版的前端架构。在新浪微博任职期间，教主设计实现了流水线加载技术与模块化代码组织，达到了在提高访问性能的同时极大降低了开发成本的目的。主要研究方向是 Web 访问性能优化与框架组织。在国内为数不多地实现了 BigPipe 技术，极大地提升了微博的访问速度。同时，微博的前端代码基础包、前端框架和构建工具均出自教主之手。2015 年年底，教主加入链家网，负责前端的整体架构工作。在 8 年的前端开发生涯中，教主是如何一步一步地成为知名前端架构师的呢？为何选择加入了链家网呢？
您在微博和链家都是前端架构师，能说说前端架构师这个工种具体是做什么的吗？
杨永林：我对架构师所担任的职责的认识是一步步变化，慢慢深入的。
在刚参加工作的时候，我觉得架构师就是代码写得又快又好的人，是工程师的晋级版本。
工作过一些年以后，我发现仅仅提高自身的开发效率是远远不够的，团队需要整体的提升。发现这一点后，我开始制作并完善各种开发工具，编写开发框架。
最近几年，随着迭代开发了一些产品本，我又发现之前能够提升效率的框架工具很有可能在后来成了产品发展的绊脚石。这时，我开始考虑架构设计的指导原则，开始考虑取舍。一些在短期内能够提升效率但不符合原则的东西，我就选择不做或者想办法在原则的指导下进行改进。比如我相信可变化的代码才是有生命力的代码，在架构设计上我也会趋向于让项目的代码可以一点一点的变化演进，不是那种一言不合就重构到状态。所以我认为前端架构师就是那种在前端领域提出开发的指导原则，在原则下设计开发框架和开发工具，让更多的开发者可以协同工作的人。
您在新浪微博的时候设计了前端架构，能否介绍一下包括了哪些组成部分，有什么关键技术？
杨永林：主要是代码基础包，页面加载框架和前端构建工具。
早期前端开发面临两个主要问题是浏览器兼容和 API 不够丰富，基础包一般都是用来解决这两个问题。当时新浪有一个自己的 Sina 包，但是代码比较零散，模式也不统一，各产品线有自己的扩展，同样的功能可能有多种实现，不太好维护。后来我用业余时间开发了一个带有命名空间管理功能的基础包，特点就是简单清晰，易于使用，被团队采纳作为了微博的基础包使用至今。
页面加载框架是被需倒逼着产生的，2010 年微博业务膨胀，页面展示的内容越来越多，这使得页面响应速度也变得越来越慢。我所在的团队接到的需求是要求在内容变多的情况下将响应速度变得更快。
这个时候 Facebook 推出了 BigPipe 技术，我们觉得这个理念正好能够解决我们应对的问题，所以决定实施，但当时 Facebook 只是分享了他们的做法，并没有提供实现，所以对我来说也是巨大的挑战。我当时将页面划分成多个独立的子模块，模块是完全可以自主运行的，模块可以嵌套，所以页面就是一批模块的树形堆叠。服务端用 Chunked 的方式将模块的信息以 JavaScript 代码块的方式传输到页面，而前端需要做的很重要的工作是管理每个模块的生命周期。
我很荣幸那时能有机会和团队成员一起开发了这个加载框架，我们可能是国内第一个在大型互联网应用上全面使用这项技术的。之后的一年我一直致力于此项技术的优化工作，比如支持服务端乱序输出，保证服务端可以使用并行策略，压缩，减少前置依赖条件等，并在 2013 年与 @Laruence（鸟哥）合作实施了 CBigPipe（并行的 BigPipe）技术，进一步提高了这项技术的性能。微博的 V5 版的加载性能也达到了顶峰，页面的加载速度几乎相当于静态网页。
前端构建工具是这几年才开始流行，其实早在 2008 年的时候，新浪就已经使用前端小文件开发，使用构建工具进行开发，测试和上线。现在想想应该是比较超前了，不过那时的版本是需要 PHP、Python 和 Java 环境，团队维护起来比较困难，而且使用的是字符串替换方案，功能比较有限。2012 年我将这个工具进行了改造，使其仅需要 Node 环境，同时支持开发、测试部署和打包上线。由于使用了 UglifyJS，有了语法树，我加了一些以前没有的功能，比如预编译的模版引擎、支持模版嵌套和母模版、代码健康度检测、冗余模块分析等。
前端构建工具前后有 Grunt/Gulp、Webpack、npm scripts 等，您对这些工具有什么看法，哪个更好？如何选择适合公司产品的工具？应从哪些方面考虑？
杨永林：我觉得这些工具有效地解决了前端开发效率的问题，它们的出现都是对技术的推动，如果在我做工具的时候有这些项目的出现，会减少我很多的工作量。至于哪个更好，我觉得，你能掌握哪个，哪个就是最好的。因为说到底，工具是为你的业务服务的，你可能需要对它做些改造或者是写一些扩展，在这个时候你发现你对他的熟悉变的很重要。构建工具的迁移成本还是挺高的，我不太推荐频繁地变更它，所以最好不要追着流行走，还是要根据自己团队的特点，因地制宜地选择一款合适的。如果不是超大型的应用，其实 build 的结果的影响并没有太大的差异，与其想着哪个更好哪个更牛逼，不如将其中一个玩熟玩透。
如何保证团队成员不会踩到同样的坑？在设计框架和构建工具时有无这方面的考虑？请举例说明。
杨永林：首先，制定规范、分享经验是免不了的，但纸上得来终觉浅吧，很多时候，亲身踩一次坑，得到的经验才会深刻。而我所要做的是在团队成员踩到坑的时候降低这件事造成的后果。比如我提供的开发环境是可以完全模拟线上环境的，测试代码和线上保持一致，很多意外情况都可以在开发、测试期被发现。同时，制定的开发规范要由工具检测来保证，不符合规范的代码不能够打包上线。对于规范代码可以使用工具计算出业务影响范围，能有效保证测试覆盖面。总的来说，踩坑不要紧，架构来帮你兜底，爬出坑的过程就成为了团队成员所得到的财富。
您认为对 Web 访问性能的优化需要关注哪些方面？其中，最值得关注的点是什么？为什么？
杨永林：我觉得性能优化需要方方面面都要兼顾，包括网络时间、服务器计算时间、页面请求数、下载量、页面载入模型等。而这里面任何一项的性能提升可能都需要你修改大量代码或者调整架构来实现，但是得到的效果可能就是一点点。因此很少见到银弹，一般都是一点一点地做出来的。我这里谈两个我觉得比较值得关注但很容易被忽视的点吧。
一是你所服务产品的形态，用户关心什么，这是一些工程师比较容易忽略的。有些产品需要用户打开时很快，有些需要用户使用时流畅；有些产品用户可以容忍看旧数据，而有些则必须是新内容；有些产品用户一天打开很多次，而有些看一次就关掉了。这些产品需求的差异都会影响你的决策。
二是评测标准，用什么来测量性能的好坏。一些人认为请求数或者请求量减少了，访问就快了，其实这是不一定的，有可能你花了很大精力做的事情在用户看来并没有什么太大变化。所以，找一个评测标准让每一个优化在数据上有所体现是很重要的。
度量前端性能的指标有哪些？如何对 Web 访问性能进行监控？
杨永林：我所服务的产品一般都关注访问性能，也就是用户看到内容的快慢，所以我们一般用首屏时间来评估，一般的性能检测服务商都能提供这个指标。
选这个指标有两点考虑：一是因为它并不是一个技术指标，而是一个感知指标，所以更接近人类的感受。二是旁路检测，它并不在系统内，不是系统汇报上来的数据，这样就有效的规避了幸存者偏差的问题。当然它也有些不足：一是数据采样小，二是可以被欺骗。所以可能需要一点儿统计学功底和性能监控的正确认识。
在监控的过程中，一是要关注长期趋势的变化，如果不是突发状况，单点的数据的绝对值是没有意义的，要收集长期的数据，分析其中的变化，当有变更的时候尤其要关注数据的变化。二是关注最差 25% 的状况，有些人，会在公司内网刷自己的产品，感觉挺快，其实不论你用什么手段，只要网快，用户的体验都不会太差，体验的差异在于最差那部分用户。三是从不同维度分析数据，如地区、网络、时段、运行环境等。
前端工程师如何成为前端架构师，除了编程能力和架构知识，还需要培养哪些能力？
杨永林：我想，大部分领域的架构师工作都是差不多的，就是搭建一个解决问题的框架，让团队成员能在框架下良好的配合工作，完成产品的开发需求。
我们知道，解决一个问题的手段有很多，在这个过程中取舍就很重要了，我们也知道，没有银弹，很少能遇见那种全面优势的解决方案，大部分方案都是牺牲掉一部分东西来换取一部分东西。因此，作为架构师，不仅要对各个技术方案的特点、成本要熟知（也就是编程能力和架构知识），还要学会如何选择。显然，架构师需要根据产品的特点和发展方向做出决定，在前端领域的架构要能让配合的团队对接的顺畅。那么在这个过程中，良好的沟通能力、同理心、利他的思维方式，就显得很重要了。因为我们不仅要完成开发任务，也要思考在自己的领域内如何帮助项目解决问题。
据说有些同事在对技术的讨论中以“击败”您为荣，您是如何看待的？这对团队及其个人的发展带来了哪些影响？
杨永林：这是我一个毛病，喜欢给别人的方案着茬。我觉得这是一个思辨的过程，通过从不同角度分析问题，去挑战解决方案的合理性，才能让问题解决的更稳妥。在知识的获取中也是这样，一次一次地去问为什么，去追根溯源，才能让知识体系更牢固。
我很喜欢在团队内扮演一种“反派”的角色，从反面的角度分析问题，去挑战别人的方案。其实，我不是真的去否定他，而是希望他的方案是经过反复推敲、深思熟虑产生的，这样的方案会更健壮。时间长了，他们会觉得我是一个爱抬杠的人，就会做足准备来“挑战”我。能把我说得接不上话来，他们会觉得很开心。这个结果是我想看到的，因为这说明团队成员在解决问题时进行了充分的思考。
您为什么放弃了在之前新浪微博的元老级身份，而选择加入链家网？
杨永林：这可能源自我对工作的看法吧，我觉得人生活在社会上，工作是在为社会创造价值和财富，这和他具体从事哪种职业没有直接关系。现在行业里有一种风气，就是觉得程序员写好代码就好了，不用关心自己做的事情是什么。甚至社会上也给程序员打一些什么“木讷”、“情商低”之类的标签。我觉得不应该是这样的，程序员也是社会人，也有他的社会责任，也有家庭责任，也需要陪伴他的伴侣，照顾他的小孩，不是每天只是面对代码而不管其他的事。人不要因为群体印象就把自己限制住，人的生活就应该是多种多样、丰富多采的，人生应该是有意义的。
就我个人而言，在过去的几年，我所服务的产品不仅加深了人们之间的沟通和理解，也使得国家的信息变得更透明。而我所做的工作对这样的一个产品做出了贡献，可以说我的工作让世界变得美好了那么一点点。这让我觉得我的人生增添了那么一点意义。而当我搭建起前端框架后，我个人能起的作用变得越来越小，我能继续创造的价值也越来越少，所以需要另一个平台来继续发挥我的能量。
这时我有机会接触到链家网，这家公司致力于解决人们的居住问题，它让中国最大的市场变得透明、有序。我觉得链家网做的是很有意义的事，同时，它仅仅用了不到两年的时间，就集结了一批各领域的牛人，维护了国内规模最大的房地产交易系统，用技术手段让房屋的买卖变的更轻松、透明、快捷。在与链家网的接触中，我感受到了那种积极解决问题的活力和务实做事的态度。再加上链家网中大部分技术人，在之前也都是各个大型互联网公司的中坚力量，我想没有什么比与志同道合的人来一起改变世界更令人激动的了。此时，鸟哥专门来邀请我加入链家网，我就毫不犹豫地同意了。
教主答群友问：Q：您对初级前端人员有什么好的建议吗？A：多尝试一些解决方案，多想想这些方案的特点，对别人的方案深究原理。Q：前端学习方面有什么书籍可以介绍吗？A：现在前端书籍都挺多挺好多呀，我一般推荐高级程序设计，图解 CSS3。Q：您在担任架构师这个角色中遇到的最严重的线上事故是什么？当时是怎么解决的？A：工作这么多年，在前端应该就只有一次 B 级故障，做非前端的时候倒是通过大篓子，因为上线速度比较快，而且大问题也都是很明显的解决方案，所以就是快速上线了。这个要感谢测试同学，很给力，避免了很多线上故障。Q：学前端是否去参加商业培训更见效？亦或是这种商业培训反而更会僵化思维？这样流水线培训出来的学员在企业认可度如何。A：我没参见过商业培训，也不太好评价，我是觉得被灌输的知识可能不如自己躺坑得来的扎实吧。企业认可这方面，我基本只看能力。Q：对于您来说技术比较重要还是产品比较重要？因为刚才您说是因为觉得链家的“产品”比较有意义才考虑去的，那能理解为你觉得产品比技术更重要吗？A：我所说的产品不是“产品人员”，是公司的产出的服务。显然对于一家公司来说，产品是最重要的，技术是如何实现产品的手段啊。Q：您觉得什么样的代码才算是可变化的代码？这方面又做出了哪些实践？有哪些系统化的产出？A：我说变化的代码其实代码是可控的，可以方便的去调整项目，可以一步一步的改造项目而不是重构，我做开发一致遵循这个理念。Q：前面提到搭建团队可用的框架，但我感觉这个工作量非常巨大而且需要很多改进和测试，教主当时有同感吗？怎么解决这么大的工作量问题？A：我可能比较幸运，曾经有一段时间来调整结构，我是这样想的，每当我向前迈一步的时候，我就是在进步，所以我没有急于让架构搭建一次到位，我会想好调整的步骤，每一步都会让架构进步，把大问题拆解成小问题一步一步做。Q：小公司开发前端，由于缺少项目管理经验，导致许多冗余性的工作，请问教主在管理方面有何建议？A：这个不同公司的情况都不一样吧，不太好建议。Q：多尝试一些解决方案和“一步一步逐步改进产品”是否矛盾？A：不矛盾啊，多尝试不代表多实施啊。
