前端架构碎碎念

前言

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

类比于建房子，考虑到人文因素，会有中西风格；考虑到地理位置，会有南北之分；考虑到简易方便，还会有组合式集装箱房屋。设计师会运用本身专业知识并集合各类因素，设计出符合当前环境的房屋。而架构师也是如此，他们须要从业务、技术等角度构造出合理的组织架构。前端技术不断发展演进，从模块化的摸索，到 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 有想法。