前端工程质量保障体系实践
元数据
前端工程质量保障体系实践
- 书名： 前端工程质量保障体系实践
- 作者： 曾静益
- 简介： 本书从前端开发的完整生命周期角度进行讲解，帮助读者了解前端的工程搭建、版本控制、代码质量、组件建设、测试保障、持续集成、系统部署、页面监控、请求监控、资源保障，以及工程质量优化的相关手段。读完本书，读者可以清楚地了解在不同的阶段有哪些保障工程质量的措施。 本书第1章介绍前端的发展历史，讲述前端如何从后端中独立出来，并逐步走向工程化。第2章讲解在前端项目启动前需要做的准备工作。第3章介绍如何规范使用 Git 进行版本控制，从而有效提高多人协作的开发效率。第4章系统地介绍对代码质量进行工程化管理的方法。第5章从组件规范、目录结构、样式主题、国际化、组件测试、文档管理、构建打包及发布规范8个方面介绍高质量的组件是如何建设的。第6章介绍前端工程中测试环节涉及的内容。第7章介绍持续集成中保障质量的手段。第8章主要介绍如何部署稳定、高效的系统。第9章介绍性能监控、异常监控、白屏监控、卡顿监控及用户行为监控等常用的页面监控手段。第10章讲解请求监控的常用手段与识别以及防御爬虫的方法。第11章介绍资源保障的必要性和通用手段。第12章讲解 webpack 在打包构建中常用的优化手段。
- 出版时间 2022-06-01 00:00:00
- ISBN： 9787121435799
- 分类： 计算机-编程设计
- 出版社： 电子工业出版社
- PC地址：https://weread.qq.com/web/reader/1b4325b0813ab7030g013e9d
高亮划线
01 前端工程质量相关前驱知识
📌 1997年6月，ECMA以JavaScript语言为基础制定了ECMAScript 1.0标准规范。ECMA以JavaScript语言为基础制定了ECMAScript标准规范ECMA-262。JavaScript是ECMAScript规范最著名的实现语言之一，除此之外，ActionScript和JScript也都是ECMAScript规范的实现语言。自此，各浏览器厂商开始逐步落实ECMAScript规范。
⏱ 2024-02-07 19:05:36 ^3300024803-7-4371-4575
📌 1999年12月，ECMAScript 3规范发布，在此后的10年间，ECMAScript规范基本没有变动过。ECMAScript 3成为当今主流浏览器使用和实现范围最广的语言规范基础。1996年，微软推出用于异步数据传输的ActiveX，随即各大浏览器厂商仿造其实现了XMLHttpRequest，也就是AJAX（Asynchronous JavaScript and XML）的雏形，它改变了前端页面要想获取后台信息必须刷新整个页面的局面。这时的网页开始逐步脱离后端的模板渲染，通过AJAX自行拉取数据进行渲染，再结合JavaScript和CSS进行页面逻辑和样式的实现。前
⏱ 2024-02-07 19:07:50 ^3300024803-7-4977-5266
📌 2004年6月，Mozilla基金会和Opera软件公司在万维网联盟（W3C）主办的研讨会上提出了一份联合建议书，其中包括Web Forms 2.0的规范草案，建议投票表决W3C是否应该扩展HTML和DOM，从而满足Web应用中的新需求。最后以8票赞成、14票反对否决此建议，这引起一些人的不满。不久，部分浏览器厂商宣布成立网页超文本应用技术工作小组（WHATWG），以继续推动该规范的开发工作，该组织再度提出Web Applications 1.0规范草案，后来这两种规范合并形成HTML 5。2007年，HTML 5被W3C接纳，成立了新的HTML工作团队。2008年1月22日，第一份正式草案发布。
⏱ 2024-02-07 19:12:29 ^3300024803-7-6811-7113
📌 2008年，Chrome发布，其JavaScript引擎V8的高效执行能力引起了Ryan Dahl的注意。2009年，Ryan利用Chrome的V8引擎打造了基于事件循环的异步I/O框架——Node.js。Node.js具有以下特点。
• 基于事件循环的异步I/O框架，能够提高I/O吞吐量。
• 单线程运行，避免了多线程变量同步的问题。
• 使得JavaScript可以编写后台代码，前后端编程语言统一。
⏱ 2024-02-07 19:22:45 ^3300024803-7-9246-9539
📌 。针对这一问题，开源社区制定了三种模块加载方案——CommonJS、AMD、CMD，为了兼容这三种模块的加载方案又开发了UMD，它是一种兼容的写法，主要通过判断module、define.amd、define.cmd等关键词执行对应的加载方案。直到ES6诞生，ES6从语言标准的层面上实现了模块功能，完全可以取代CommonJS和AMD规范，成为浏览器和服务器通用的模块解决方案。
⏱ 2024-02-07 19:24:20 ^3300024803-7-10127-10346
📌 2021年10月，微软发布TypeScript公开版。TypeScript是由微软开发的自由和开源的编程语言，为开发大型应用而设计 ^3300024803-7-10805-10870
- 💭 这里应该是笔误，typescript 第一版发布于2012年10月，另外在之前 facebook 就发布了 flow 作为 js 的静态代码检查工具 - ⏱ 2024-02-07 19:32:29
📌 浏览器的沙箱机制让很多桌面应用程序具备了传统PC Web页面没有的功能。传统的桌面GUI应用程序由于对操作系统存在依赖，所以难以跨平台。2013年，Atom编辑器问世，它的底层框架Electron也逐渐被熟知。在2014年春季被开源时，Electron还叫作Atom Shell，直到2015年4月，它才被正式更名为Electron。它可以用于构建具有HTML、CSS、JavaScript的跨平台桌面应用程序，并通过将Chromium和Node.js合并到同一个运行环境中来实现这一点，应用程序可以打包到Mac、Windows和Linux系统上，进一步延伸了前端的能力。
⏱ 2024-02-07 20:26:07 ^3300024803-7-12347-12633
📌 服务端：Node.js、Deno等。
• 跨平台开发：React Native、Weex、Taro、mpvue、Electron等。
• 打包构建工具：webpack、Gulp、Rollup、ESbuild、Parcel等。
• CSS预编译语言：Less、Sass、Stylus等。
• 前端开发框架：React、Vue、Angular、San等。
• 状态管理：MobX、Redux、Flux等。
• 请求库：Axios、Fetch、Request等。
• 基础组件库：Ant Design、Element UI、Vant等。
• 可视化：Three.js、D3、G2等。
• 测试工具：Jest、Mocha、Karma等。
• IDE：Atom、VS Code、Sublime Text、Web Storm等。
• 代码质量：JSLint、CSS Lint、ESLint等。
• 包管理工具：NPM、yarn、pnpm等。
⏱ 2024-02-07 20:26:50 ^3300024803-7-12872-13965
📌 2017年，一篇名为“pix2code：Generating Code from a Graphical User Interface Screenshot”的论文横空出世，立刻引发了广泛关注。pix2code将设计图与对应的DSL描述通过深度神经网络进行训练，给出一张新图并通过推理得出一个新的DSL描述，再通过代码生成器变成目标平台上的代码。
⏱ 2024-02-07 20:30:34 ^3300024803-7-14670-14872
📌 前端工程质量保障就是以前端工程化为前提，建立一套有计划、有系统的方法。简单来说，前端工程质量保障是一套体系化的解决方案而不是某种技术，它能够覆盖前端的研发生命周期，包括工程搭建、功能研发、测试保障、发布上线、运行维护。具体到不同生命周期的不同环节，可以有不同的表现形式。例如，在功能研发的编码环节，它可以是编码规范，一套良好的编码规范可以有效增强团队开发协作效率、提高代码质量。比如，使用语义化的HTML标签，符合团队的文件命名规范，可隔离的CSS命名规范（例如BEM）等。
⏱ 2024-02-07 20:33:03 ^3300024803-7-16597-16834
📌 代码质量一般指代码本身的质量，包括复杂度、重复率、代码风格等。代码是团队的共同财产，代码质量是团队技术水平和管理水平的直接体现。代码质量下降通常会自成因果，导致恶性循环。
• 破窗效应：在烂代码上继续生产烂代码，开发人员的心理负担会小很多。
• 传染性：烂代码传递着一种不在意质量，只看业务成果的负面信息，会伤害团队的技术热情和工作氛围，导致更多烂代码出现。
⏱ 2024-02-07 20:34:38 ^3300024803-7-18549-18788
📌 代码质量过硬则能带来以下好处。
• 在发生问题时，能够帮助开发人员快速理解和定位。
• 可以加快应用的迭代速度，不必花费过多的时间来修复Bug和优化代码逻辑。
• 能够帮助新的项目开发成员更快、更容易地融入项目开发中。
• 便于项目组不同开发成员之间快速做好承接。
• 有效促进团队间交流合作，提升开发效率。
对于软件项目来说，代码质量代表着项目的有序程度，烂代码增加是项目无序性上升的表现。在无外力影响的情况下，烂代码只会越来越多。为了保证项目质量不持续下降，需要主动采用技术或者管理手段来缓解甚至抑制烂代码越来越多的趋势。
⏱ 2024-02-07 20:35:40 ^3300024803-7-18817-19258
📌 代码质量可以采用传统的业界标准进行衡量，比如编码规范、可读性、可维护性、代码重复率及可测试性。
• 编码规范：主要包括是否遵守了最佳实践和团队编码规范，是否包含可能出问题的代码，以及可能存在的安全漏洞。编码规范有助于提高团队协作的效率以及代码的可维护性。
• 可读性：Code Review是一个很好的检测代码可读性的手段。如果同事之间可以轻松地读懂彼此写的代码，就说明当前工程的代码可读性很好；反之则说明代码可读性有待提高。遵守编码规范也能让开发人员写出可读性更好的代码。
• 可维护性：代码的可维护性是由很多因素协同作用的结果。代码的可读性好、简洁、可扩展性好，就会使得代码易维护；更具体地讲，如果代码分层清晰、模块化好、高内聚低耦合、遵从基于接口而非实现编程的设计原则等，就可能意味着代码易维护。除此之外，代码的易维护性还与项目代码量的多少、业务的复杂程度、用到的技术的复杂程度、文档是否全面等诸多因素有关。
• 代码重复率：遵守DRY（Don’t Repeat Yourself）原则，尽量减少重复代码的编写工作，复用已有的代码。定期对项目进行代码重复度检测是一件很有意义的事，可以帮助开发人员发现冗余代码，进行代码抽象和重构。重复的代码一旦出错，就意味着大量的工作和持续的不可控。如果代码中有大量的重复代码，就要考虑将重复的代码提取出来，封装成公共的方法或组件。
• 可测试性：代码的可测试性同样可以反映代码质量的好坏。代码的可测试性差，比较难写单元测试，基本上就能说明代码设计得有问题。
根据以上5个原则，可以在不同阶段进行应对和治理。在开发时，在团队中建立代码规范制度，例如，代码缩进、注释风格等。在代码提交时，基于代码规范使用自动化工具进行代码质量检查，例如，代码规范、圈复杂度、代码重复率等。在代码评审时，从业务逻辑角度入手，评估需求还原度，针对异常边界情况提出疑问，帮助代码编写人员进行自我审查。
⏱ 2024-02-07 20:36:59 ^3300024803-7-19632-20748
📌 前端的系统部署起初是一个非常简单的流程——直接将静态文件提交到服务器即可。随着互联网的发展，企业为了提升用户体验，开始追求交付质量、性能及系统稳定性。例如，为了提升网站性能，把静态资源和动态网页分集群部署，静态资源会被部署到CDN节点上；为了控制新功能上线的影响面，做代码灰度、A/B分流；当新功能上线出现缺陷时，要能够快速进行代码回滚。
⏱ 2024-02-07 20:51:51 ^3300024803-7-24323-24492
📌 页面监控包括性能监控、异常监控、白屏监控、卡顿监控、用户行为监控
⏱ 2024-02-07 20:53:01 ^3300024803-7-25071-25103
📌 [1]Mr.食蚁兽.前端发展简史[CP/OL].（2017-06-01）.[2021-8-23].http://www.360doc.com/content/17/0601/20/35378950\_659102709.shtml.\[2]Adam浩淼.前端开发发展简史\[CP/OL].（2018-11-30）.\[2021-6-25].https：//www.cnblogs.com/AdamFamily/p/10045436.html.\[3]黯羽轻扬.React Native从诞生到现在[CP/OL].（2019-08-25）.[2021-6-25].https：//mp.weixin.qq.com/s？__biz=MzIwMTM5MTM1NA%3D%3D&chksm=8ef1cd7bb986446d7b7ba537b26224d71395e1cd5aa6dc8ccc02f50e4a45faa948e8bf8084dc&idx=1&mid=2649473262&sn=2abb0a0af ac13f346b13b23c57af26e0＃rd.[4]大前小白.Electron简介[CP/OL].（2021-04-30）.[2021-6-26].https：//blog.csdn.net/weixin_45195200/article/details/116298179.[5]甄焱鲲.初识前端智能化[CP/OL].（2019-02-18）.[2021-6-29].https：//zhuanlan.zhihu.com/p/96960041.[6]Jtag特工.前端智能化漫谈（1）-pix2code[CP/OL].（2019-07-25）.[2021-6-30].https：//blog.csdn.net/lusing/article/details/97273669.[7]曾经沧海.代码质量管控的四个阶段[CP/OL].（2017-09-11）.[2021-6-30].https：//blog.csdn.net/lusing/article/details/97273669.
⏱ 2024-02-07 20:58:14 ^3300024803-7-27654-28740
02 工程搭建
📌 前端路由能够借助浏览器的能力，在不向服务端发起请求的前提下，根据浏览器的URL映射页面UI，实现页面无刷新跳转，这种方法大大改善了用户体验。前端路由已经成为前端应用中的标准配置。第一种路由方案是哈希路由（Hash Router）。在2014年之前，大家基本都是通过这种方案来实现前端路由的。[插图]在以上代码中，＃后面的内容属于hash值，hash值变化不会导致浏览器向服务器发出请求。如果浏览器不发出请求，就不会刷新页面。每次hash值变化都会触发hashchange事件。通过hashchange事件，开发人员可以获取hash值的变化情况，从而根据不同的hash值展示不同的页面UI。第二种路由方案是浏览器路由（Browser Router）。2014年后，HTML 5发布了新的标准。history新增了pushState和replaceState两个方法，使用这两个方法改变URL的path部分不会引起页面刷新。history提供类似hashchange事件的popstate事件。需要注意的是，调用history.pushState或history.replaceState不会触发popstate事件。只有对浏览器进行操作时，才会触发该事件，例如，单击浏览器的回退按钮（或者在JavaScript代码中调用history.back或history.forward方法）。针对这种情况，开发人员可以通过拦截pushState、replaceState的调用来监测URL变化。第三种路由方案是内存路由（Memory Router）。该方案较少使用，一般适用于非浏览器环境（例如，React Native、测试等），内存路由会将虚拟URL的访问历史记录保存在对象内存中。内存路由通过模拟浏览器的历史栈将URL和页面UI映射起来。
⏱ 2024-02-08 09:13:55 ^3300024803-8-22329-23409
03 版本控制
📌 subject是针对本次commit改动主题的简短描述，一般不会超过50个字符，通常有以下约定。• 必须以动词开头。• 使用第一人称现在时，比如change，而不是changed或changes。• 第一个字母必须小写。• 结尾不能添加句号（.）。
⏱ 2024-02-08 09:40:21 ^3300024803-9-6985-7233
📌 BodyBody是对subject的详细描述，可以有多行，每行不超过100个字符，具体要求如下。• 必须以动词开头。• 使用第一人称现在时，比如change，而不是changed或changes。• 应该详细说明代码变动的动机，以及与以前行为的对比。
⏱ 2024-02-08 09:40:42 ^3300024803-9-7281-7535
📌 FooterFooter部分只适用于补充描述两种情况：不兼容式变更（Break Change）和关闭issues。不兼容式变更（Break Change）：如果当前代码与上一个版本不兼容，则Footer部分必须以“BREAKING CHANGE：”开头并紧跟一个空格或者两个换行符，后面是对变动内容的描述、变动理由及迁移方法。
⏱ 2024-02-08 09:40:55 ^3300024803-9-7583-7811
📌 关闭issues：如果当前commit针对某个issue，那么可以在Footer部分使用快捷语法关闭对应的issue。
⏱ 2024-02-08 09:41:10 ^3300024803-9-8251-8310
📌 TBD（Trunk-Based Development）的中文名称为主干开发模式
⏱ 2024-02-08 09:42:55 ^3300024803-9-9309-9349
📌 在实际项目的开发维护中，需求在构建初期被切分成多个子需求，各个子需求的成果都需要经过测试，具备可视、可集成和可运行使用的特征，这就是敏捷开发。由于团队需要协作完成某一功能需求或者分别完成不同的功能需求，因此根据不同的功能需求创建对应开发分支的模式应运而生，其中最具有代表性的就是Git-Flow模式。
⏱ 2024-02-08 09:44:38 ^3300024803-9-10902-11052
📌 GitHub-Flow是简化版的Git-Flow，它更加轻量，仅保留了master和feature分支，是一种以部署为中心的分支管理模式，通过简单的功能和规则，持续、高速、安全地进行部署。
⏱ 2024-02-08 09:47:12 ^3300024803-9-14024-14118
📌 GitLab-Flow与GitHub-Flow在开发流程上的区别并不大，只是GitLab-Flow将pull request改成了merge request，而merge request的用法与pull request类似，都可以作为CR的沟通方式。两者最大的区别体现在发布流程上，GitLab-Flow引入了对应生产环境的production分支和对应预发环境的pre-production分支。
⏱ 2024-02-08 09:49:17 ^3300024803-9-15761-15960
📌 [插图]
⏱ 2024-02-08 09:52:48 ^3300024803-9-19190-19191
📌 [2]Vincent Driessen.A successful Git branching model[CP/OL].(2010-01-05).[2021-07-18]https://nvie.com/posts/a-successful-git-branching-model/.\[3]Zhang Liaoyuan.How to Select a Git Branch Mode?[CP/OL].(2021-02-03).[2021-07-23]https://www.alibabacloud.com/blog/how-to-select-a-git-branch-mode\_597255.
⏱ 2024-02-08 09:54:44 ^3300024803-9-25645-25972
04 代码质量
📌 主观指标指代码评审人员给出的主观判定。它们可以有效地评估代码在特定业务场景下的质量可靠性，但是需要耗费人力去进行代码评审（Code Review，CR），并且对CR人员的能力素质有一定要求。
⏱ 2024-02-08 09:56:40 ^3300024803-10-900-995
📌 CR有两个要点：一是要统一团队规范，否则即使对于同一个问题，不同人员给出的建议也可能不同，很难做到有效统一；另一点是要把评审做到位，避免形式主义。
⏱ 2024-02-08 09:57:10 ^3300024803-10-995-1068
📌 第一，可扩展性。指代码为了应对将来的需求变化而需要具备的扩展能力，当新的功能需求出现时，无须或仅需少量修改代码，也无须对整个系统进行重构或者重建。
⏱ 2024-02-08 09:58:37 ^3300024803-10-1108-1181
📌 第二，可读性。指开发人员能否通过阅读代码快速明白当前函数的功能，这将有助于协同式开发、后续功能迭代以及重构等工作的推进。
⏱ 2024-02-08 09:58:46 ^3300024803-10-1510-1570
📌 因为主观指标需要依赖评审人员的素质并占用人员的时间，所以当评审人员的素质不达标或者人员的时间短缺时，很难起到预期的作用。因此，软件工程师们建立了客观指标来衡量代码质量，让计算机代替评审人员对代码进行质量评估。
⏱ 2024-02-08 09:59:09 ^3300024803-10-1885-1989
📌 第一，圈复杂度（Cyclomatic complexity），也被称为条件复杂度——用来衡量模块判定结构的复杂程度，数量上表现为线性无关的路径条数，即合理地预防错误所需测试的最少路径数。
⏱ 2024-02-08 09:59:21 ^3300024803-10-2031-2124
📌 第二，千行代码Bug率，它由代码行数和Bug数两个指标共同组成，计算公式：千行代码Bug率=Bug数量/（代码行数/1000）。一般来说，千行代码Bug率的数值越小代表代码质量越好。
⏱ 2024-02-08 09:59:33 ^3300024803-10-2222-2313
📌 第三，代码重复率。一个项目在不断开发迭代、功能累加的过程中，重复代码的出现是不可避免的，其出现的原因大多数是复制、粘贴代码。
⏱ 2024-02-08 09:59:46 ^3300024803-10-2342-2404
📌 在目录结构的设计上，开发人员可以遵循领域驱动设计（Domain Driven Design，DDD）原则。
⏱ 2024-02-08 10:02:00 ^3300024803-10-7740-7793
📌 SonarQube提供了一系列的指标帮助开发人员了解项目的代码质量现状。可靠性（Reliability）：只要有一个次要Bug，项目评级就为B；只要有一个重要Bug，项目评级就为C；只要有一个严重Bug，项目评级就为D；只要有一个阻断性Bug，项目评级就为E。安全性（Security）是衡量代码漏洞数量的标准，从低到高分为A、B、C、D、E 5个等级：没有漏洞，项目评级为A；只要有一个次要漏洞，项目评级就为B；只要有一个重要漏洞，项目评级就为C；只要有一个严重漏洞，项目评级就为D；只要有一个阻断性漏洞，项目评级就为E。可维护性（Maintainability）可以被用来衡量代码质量。SonarQube建立了一套公式：可维护性数值=技术债务成本/项目代码总开发成本，将可维护性进行了量化，从低到高分为A、B、C、D、E 5个等级，A到D的默认值分别为0.05、0.1、0.2、0.5，只要超过0.5评级就为E。技术债务成本指修复当前不规范的代码需要投入的时间，项目代码总开发成本指从零开始重写代码所需的成本。SonarQube默认的开发一行代码的成本为30分钟，如果总代码行数为100行，那么项目代码总开发成本为3000分钟，假设技术债务为300分钟，则可维护性数值为0.1，对应的可维护性评级为B。覆盖率（Coverage）由条件覆盖率和行覆盖率共同组成，即单元测试覆盖的源代码行数占总代码行数的比率。重复（Duplications）：SonarQube会扫描项目中代码的重复情况，开发人员可以通过该指标查看到代码的重复密度、重复行数、重复文件块及重复文件数量等信息。大小（Size）：该指标直观反映当前项目的代码体量。通过该指标可以查看到新增代码行数、总代码行数、方法数、目录数、文件数以及注释行数等信息。复杂度（Complexity）：指代码的圈复杂度，复杂度越高代表代码越难以阅读和维护。代码中的条件分支越多，代码的复杂度就越高，测试和维护越困难。问题（Issues）：将项目中扫描出来的问题进行归类，按处理状态划分为新增的违规、违规、待处理的问题、重开的问题、已确认问题、误判的问题、不需要修复的问题。以上几个指标在一定程度上能够反映当前项目的代码质量，SonarQube还会根据问题给出相关的建议。
⏱ 2024-02-08 21:11:51 ^3300024803-10-21002-22221
读书笔记
01 前端工程质量相关前驱知识
划线评论
📌 2008年12月，Google发布Chrome浏览器，加入了“第二次浏览器战争”。Chrome使用Safari开源的WebKit作为布局引擎，并研发了高效的JavaScript引擎V8。 ^281576162-7OO3wJ3zV
- 💭 webkit 内核是 Safari 开源的
- ⏱ 2024-02-07 19:18:33
划线评论
📌 2021年10月，微软发布TypeScript公开版。TypeScript是由微软开发的自由和开源的编程语言，为开发大型应用而设计 ^281576162-7OOb1eSPb
- 💭 这里应该是笔误，typescript 第一版发布于2012年10月，另外在之前 facebook 就发布了 flow 作为 js 的静态代码检查工具
- ⏱ 2024-02-07 21:12:57