前端架构碎碎念

前言

最近看了一些关于前端架构相关的书籍和博客，觉得有点自我膨胀了，竟然想对着前端架构这一说法指指点点。从跨入这个行业开始，就觉得架构师就是位于技术金字塔的顶端的那拨人，是引导行业或团队技术走向的那拨人。然而从行业上对前端架构的定义和必备的技能来看，觉得前端架构就是一个伪概念，又或是拔高自己身份的幌子。

类比于建房子，考虑到人文因素，会有中西风格；考虑到地理位置，会有南北之分；考虑到简易方便，还会有组合式集装箱房屋。设计师会运用自己专业知识并集合各种因素，设计出符合当前环境的房屋。而架构师也是如此，他们需要从业务、技术等角度构造出合理的组织架构。前端技术不断发展演进，从模块化的摸索，到 MV* 的实践，再到当今组件化的盛行。这些技术人不断折腾，不断改进前端架构，使之更符合这个时代。在市场的筛选下，最终也留下了最适合当前的前端技术方案。不过，大部分前端架构师并不具备这种能力，充其量就是经验丰富的包工头，某种前端技术方案的践行者。

设计师怎么练成的，我们不知道。但是类比包工头，我们还是知道前端 Leader 应该做什么。

开工前的前期准备

这里的前期准备，指的是从零启动一个项目，我们需要做的准备工作。而最能体现整个项目的技术含量的活估计有大半在这里了。作为一个包工头，不是说我能把砖砌得有多好，而是足够了解现有的资源和工作流，并搭建好基础设施，为日后项目高效推进起个好头。

在很早以前，数据和视图耦合，那时候没有前端的什么事，最多作为页面仔为后端提供模板，或者说画几个展示用的静态页面。之后 ajax 的兴起，让数据和视图的关系开始松绑，前端在数据的赋能下，迎来了一次大发展。人要与数据交互，必然要通过某个媒介，而前端在获取部分数据的权限后，又反过来促进了人与数据的互动关系。即使后面的 Node，我也认为是前端为争取操作数据权限而做的努力。毕竟，这个年代数据才是王道。

视图怎么获取数据？视图怎么展示数据？视图怎么更好得获取数据？视图怎么更好得展示数据？（...没想那么多...）

架构设计

从早期的服务端直出到现在的服务端渲染，视图的渲染兜兜转转貌似又回到的起点。但此非彼，不可同日而语。ajax 被 Google 使用后，随之而来的是前后端的分离。前端应用也是跟随时代而呈现不同的架构设计，比如多页面应用、单页面应用、同构渲染、微前端等。它们的出现是为了解决某些问题而给出的技术方案，所以说即使过时，却依然有其价值。

多页面应用，相对来说，比较简单。简单的多页面应用，比如静态页面，这里可能压根没 JS 的事。复杂点的多页面应用，可能要引入模板引擎，路由等。要是觉得原生操作 DOM 不方便，可以使用 jQuery。多页面应该在项目启动的时候，会加载需要的资源，由于浏览器缓存策略，第二次加载相同的资源时，可能就不需要重复请求了。在结合一点 MV* 模式，快和单页面应用没什么区别了。只是现在流行的单页面不需要直接操作 DOM ，而是交给框架底层处理了。

以上的应用说来说去可能都是同一个应用，在某些场景，就需要聚合多个前端应用，有路由分发的方案，有 iframe 作为容器的方案等。

前端规范

「书同文，车同轨」

既然是包工头，自然不大可能是一个光杆司令。制定规范，不仅可以使成员代码风格趋于统一，同时也可以使新手养成良好的编码习惯。对于前端来说，HTML、CSS、JS 分别代表了结构层、表现层和行为层。在代码层次上，它们都有自己的一套标准，可以结合各自 lint工具 + Prettier 轻松规范代码。从组件规范角度，还包括 UI 组件规范、模块化规范、项目组件化设计方案等。

编辑器最好也能够统一下，如果能够摸索出能够提高效率的一系列使用方法，同步给全组成员就更好了。

自动化构建

都 9102 年，自动化构建已成为现代前端工程不可或缺的一个环节。自动化构建可以做很多事，比如文件编译，资源合并，压缩优化等。构建工具很多，但所做的事基本上是差不多的，读取入口配置文件 ➡ 生成模块依赖图 ➡ 加载模块 ➡ 模块文件编译处理 ➡️ 模块文件合并 ➡️ 文件资源优化 ➡ 输出最终资源。

不论是生产环境还是开发环境，都需要构建工具的参与。生产环境侧重于性能，比如文件压缩优化，去除无用代码注释等。测试环境侧重于开发体验，比如模块热替换，生成 sourcemap 等。像之前的代码规范，也可以借助构建工具自动化格式化代码，或提示错误。

项目代码示例

项目在正是启动之前，需要验证程序是否按照自己的预期去执行。验证可行后，并按照自己定义的一系列规范编写示例代码，这样有助于其他成员了解该项目的规范。同时，对内组织技术培训，介绍系统的架构和注意事项。

其实，技术验证的过程不应该放在整个开发流程中。工作之余，我们可以多接触新的技术和尝试新的架构设计。在未知的领域，我们无法准确评估时间，临时磨枪可能会导致整个项目的延期。

开工

技术是为业务服务的，项目启动了，意味着开始偿还业务债了。而前端 Leader 职责也开始发生变化，不仅仅从事技术活，还要参与到团队管理、项目管理等非技术活。项目进入正轨后，人人都成为了螺丝工，技术上的难题基本上很少再会遇到。但是这并不代表整个开发过程会变得一帆风顺。

沟通协调

「凡事有交代，件件有着落，事事有回音」

不管是普通成员，还是团队 Leader，都应该具备这样的做事风格，对自己和别人都有个交代。

前端在整个研发队伍中，是一个比较尴尬的存在。尤其在比较重视业务的团队里，好事没捞到，麻烦事却不断找上门。比如页面抛异常，测试伙伴第一个就找前端。产品伙伴不靠谱，频繁找前端。遇到不靠谱的后端小伙伴，联调测试时也会跑来质疑前端。最后可能领导跑来找你谈话，说你们前端团队怎么老是出问题。讲真，这话没法接。感觉前端就是一个接锅侠，时间长了，对团队士气有很大的影响，这也是前端 Leader 需要解决的问题。

对于产品，需求评审严格把关，对于不合理或不紧急的需求，延迟或降低其优先级。对于测试伙伴，对其进行技术培训，了解开发者工具的简单使用，和常见异常报错分析科普。对于后端，制定相关约束。以上规范要形成文档保存，方便后来者。

当然诸如此类的问题会有很多，对于问题要敏感并及时发现，分析导致问题的根源，最后对症下药逐步解决问题。事情说得很简单，但事实上，人们习惯于存在问题的现状而不自知或发现问题却习惯于有问题的现状。

提升团队能力

众人拾柴火焰高，只有大伙儿力往一处使，才能产生 1 + 1 > 2 的效果。可是编码并不是力气活，成员的参差不齐，很大的程度上会拖团队的后退。比如，一个新手的代码提交不规范，很可能导致某些人的哀嚎。

代码审查，是一个提高自己编码能力的好机会。之前的 Lint 规则可以很好地校正代码风格，而在代码审查中，就可以发现逻辑上的问题或知道可以让代码更出彩的方法。

代码重构算是一种提升编程能力的方式，不过有很多人对代码重构有着很大的误解，也不见得项目中对重构的重视。重构可以本着小步快走的原则，增加程序的可读性和可维护性。何时去重构？需要重构的标准的是什么？如果程序冗长啰嗦看不懂，那就重构它。如果一段程序过分依赖于注释，那就重构它。如果你想添加新功能，却无从下手，那就重构它。只要是可读性差，可维护性差，你都有理由去重构它。

代码审查还有一个好处就是，可以帮助我们熟悉业务。如果项目业务很复杂，至少要保证有两个人对同一模块有足够的了解。

新人培训和技术分享，新人刚接入项目时，有必要对其进行基础的技术培训，如业务培训、技术栈相关知识培训、调试能力培训等，这些都要有相关的文档。这些看着无关紧要的培训，对于新手来说，往往是一大助力。

技术分享，并不指望一次简单的分享就让所有的成员学会一项技能，不过这对团队的技术视野和团队技术氛围会有很大帮助。对于技术分享的人，有不同的说法，有人主张新人主持分享，这样可以加快新人融入团队，老人也可以一旁补充说明。而有些人，则认为让最擅长的人去做擅长的事。不知道孰好孰坏，不予置评。

我认为团队能力还应该包括存续能力，也就是即便成员流动快，新到位的成员也能很快接入项目。这就需要各种文档记录，新人培训文档，技术架构文档，业务文档，技术分享文档，开发规范文档，工作交接文档等。

前后端联调

后端由本地开发环境部署到测试环境，按正常的节奏来，前后端联调会很顺利。然而，实际开发中，联调的占比会很大。主要的原因有，

1. 前后端沟通效率低，有问题相互质疑。
2. 后端自测力度不够，考虑不周全。
3. 接口协议变动频繁。
4. 接口文档不详实。

...

最简单粗暴的方法就是引入接口管理平台，引入绩效考核制度。

持续化集成 持续化交付 持续化部署

这一块就不是前端自己能够决定的事情了，有条件的话可以自己搭建代码托管平台，使用 gitlab ，现在人家提供一条龙服务，可以尝试一波。

结语

和代码打交道不可怕，和人打交道也不可怕，可怕的是这个前端 Leader 有想法。