前端架构师

前　言
像架构师一样思考，突破技术瓶颈

透过工程基建，架构有迹可循。
前端开发是一个庞大的体系，纷繁复杂的知识点铸成了一张信息密度极高的图谱。在开发过程中，一行代码就可能使宿主引擎陷入性能瓶颈；团队中的代码量呈几何级数式增长，可能愈发尾大不掉，掣肘业务的发展。这些技术环节，或宏观或微观，都与工程化基建、架构设计息息相关。
如何打造一个顺滑的工程化流程，为研发效率不断助力？如何建设一个稳定可靠的基础设施，为业务产出保驾护航？对于这些问题，我在多年的工作中反复思考、不断实践，如今也有了一些经验和感悟。
但事实上，让我将这些积累幻化成文字是需要一个契机的，下面我先从写本书的初心及本书涉及的技术内容谈起。
【一】求贤若渴的伯乐和凤毛麟角的人才
作为团队管理者，一直以来我都被人才招聘所困扰。经历了数百场面试，我看到了太多千篇一律的“皮囊”。
?我精通Vue.js，看过Vue.js源码 = 我能熟记Object.defineProperty/Proxy，也知道发布/订阅模式。
?我精通AST = 我知道AST是抽象语法树，知道能用它做些什么。
?我能熟练使用Babel = 我能记清楚很多Babel配置项，甚至默写出Babel Plugin模板代码。
当知识技术成为应试八股文时，人才招聘就会沦为“面试造火箭，工作拧螺丝”的逢场作戏。对于上述问题，我不禁会追问：
你知道Vue.js完整版本和运行时版本的区别吗？
如果你不知道Vue.js运行时版本不包含模板编译器，大概率也无法说清Vue.js在模板编译环节具体做了什么。如果只知道实现数据劫持和发布/订阅模式的几个API，又何谈精通原理？
请你手写一个“匹配有效括号”算法，你能做到吗？
如果连LeetCode上easy难度的编译原理相关算法题都无法做出，何谈理解分词、AST这些概念？
如何设计一个C端Polyfill方案？
如果不清楚@babel/preset-env的useBuiltIns不同配置背后的设计理念，何谈了解Babel？更别说设计一个性能更好的降级方案了。
另一方面，我很理解求职者，他们也面临困惑。
?该如何避免相似的工作做了3年，却没能积累下3年的工作经验？
?该如何从繁杂且千篇一律的业务需求中抽身出来，花时间总结经验、提高自己？
?该如何为团队带来更高的价值，体现经验和能力？
为了破局，焦虑的开发者渐渐成为“短期速成知识”的收藏者。你以为收藏的是知识，其实收藏的是“知道”；你以为掌握了知识，其实只是囤积了一堆“知道”。
近些年我也一直在思考：如何抽象出真正有价值的开发知识？如何发现并解决技术成长瓶颈，培养人才？于是，我将自己在海外和BAT服务多年积累的经验分享给大家，将长时间以来我认为最有价值的信息系统性地整理输出——这正是我写这本书的初心。
【二】从前端工程化基建和架构设计的价值谈起
从当前的招聘情况和开发社区中呈现的景象来看，短平快、碎片化的内容（比如快速搞定“面经题目”）很容易演变成跳槽加薪的“兴奋剂”，但是在某种程度上，它们只能成为缓解焦虑的“精神鸦片”。
试想，如果你资质平平，缺少团队中“大牛”的指点，工作内容只是在已有项目中写几个页面或配合运营活动，如此往复，技术水平一定无法提高，工作三四年后可能和应届生并无差别。
这种情况出现的主要原因还是大部分开发者无法接触到好项目。这里的“好项目”是指：你能在项目中从0到1打造应用的基础设施、确定应用的工程化方案、实现应用构建和发布的流程、设计应用中的公共方法和底层架构。只有系统地研究这些内容，开发者才能真正打通自身的“任督二脉”，实现个人和团队价值的最大化。
我将上述内容总结定义为：前端工程化基建和架构设计。
这是每位开发者成长道路上的稀缺资源。一轮又一轮的业务需求是烦琐和机械的，但工程化基建和架构设计却是万丈高楼的根基，是巨型航母的引擎和发动机，是区分一般开发者和一流架构师的分水岭。因此，前端工程化基建和架构设计的价值对于个人、业务来说都是不言而喻的。
【三】我理解的“前端工程化基建和架构设计”
我们知道，前端目前处在前所未有的地位高度：前端职场既快速发展着，也迎接着优胜劣汰；前端技术有着与生俱来的混乱，也有着与这种混乱抗衡的规范。这些都给前端工程化基建带来了更大的挑战，对技术架构设计能力也提出了更高的要求。
对于实际业务来说，在前端工程化基建当中：
?团队作战并非单打独斗，那么如何设计工作流程，打造一个众人皆赞的项目根基？
?项目依赖纷繁复杂，如何做好依赖管理和公共库管理？
?如何深入理解框架，真正做到精通框架和准确拿捏技术选型？
?从最基本的网络请求库说起，如何设计一个稳定灵活的多端Fetch库？
?如何借助Low Code或No Code技术，实现越来越智能的应用搭建方案？
?如何统一中后台项目架构，提升跨业务线的产研效率？
?如何开发设计一套适合业务的组件库，封装分层样式，最大限度做到复用，提升开发效率？
?如何设计跨端方案，“Write Once，Run Everywhere”是否真的可行？
?如何处理各种模块化规范，以及精确做到代码拆分？
?如何区分开发边界，比如前端如何更好地利用Node.js方案开疆扩土？
以上这些都直接决定了前端的业务价值，体现了前端团队的技术能力。那到底什么才是我理解的“前端工程化基建和架构设计”呢？
我以身边常见的一些小事儿为例：不管是菜鸟还是经验丰富的开发者，都有过被配置文件搞到焦头烂额的时候，一不小心就引起命令行报错，编译不通过，终端上只显示了短短几行英文字母，却都是warning和error。
也许你可以通过搜索引擎找到临时解决方案，匆匆忙忙重新回到业务开发中追赶工期。但报错的本源到底是什么，究竟什么是真正高效的解决方案？如果不深入探究，你很快还会因为类似的问题浪费大把时间，同时技术能力毫无提升。
再试想，对于开发时遇见的一些诡异问题，你也许会删除一次node_moudles，并重新执行npm install命令，然后发现“重启大法”有时候真能奇迹般地解决问题。可是你对其中的原理却鲜有探究，也不清楚这是否是一种优雅的解决方案。
又或者，为了实现一个通用功能（也许就是为了找到一个函数参数的用法），你不得不翻看项目中的“屎山代码”，浪费大把时间。可是面对历史代码，你却完全不敢重构。经过日积月累，“历史”逐渐成为“天坑”，“屎山代码”成为业务桎梏。
基于多年对一线开发过程的观察，以及对人才成长的思考，我心中的“前端工程化基建和架构设计”已不是简单的思维模式输出，不是“阳春白雪”的理论，也不是社区搜索即得的Webpack配置罗列和原理复述，而是从项目中的痛点提取基础建设的意义，从个人发展瓶颈总结工程化架构和底层设计思想。基于此，这本书的内容呼之欲出。

快速发展的红利、优胜劣汰的挑战、与生俱来的混乱、同混乱抗衡的规范……这些都是前端从业者无法逃避的现状。有人说，做好业务支撑是活在当下，而做好技术基建是活好未来。当业务量到达一定量级时，成为“规范制定者”，成为“思考者”，像“架构师”一样思考问题，才能最终成为“优胜者”。本书内容不是简单的思维模式输出，不是纯粹“阳春白雪”的理论，也不是社区搜索即得的 Webpack配置罗列和原理复述，而是从项目痛点中提取出的基础建设的意义，以及从个人发展瓶颈中总结出的工程化架构和底层设计原理。本书不仅能帮助开发者夯实基础，还能为开发者实现技术进阶提供帮助和启发。

侯策，就职于某内容社区类互联网上市公司，具有多年海内外工作经验，曾先后就职于法国ENGIE集团、Google、百度等知名企业。擅长前端工程化体系搭建及基础建设架构设计。深入了解前端各类技术框架和相关技术栈，具有丰富的高流量产品稳定性建设及性能和用户体验优化经验，在业务提效和质量保障方面亦有深厚积累，在跨端开发（包括小程序矩阵开发）、富文本编辑器、Node.js、React等技术方向有较强的业内影响力。在技术氛围打造、团队成员培养、技术体系建设、新技术落地、难点攻坚、历史包袱重构等方面均有丰富的实践经历。著有《React状态管理与同构实践》《前端开发核心知识进阶：从夯实基础到突破瓶颈》等多部技术图书。

1.选取了30个非常典型的前端基础建设和架构设计相关主题，内容新颖、重点突出、不落俗套。读者可以根据需求直接选择自己感兴趣的内容阅读。
2.一改市面上一些前端技术书以框架或包为中心的“重技巧却少思考”的现状，将前端开发实践理论化、系统化、范式化、路径化，读者可以从中学到一套行之有效的方法论！