前端代码Review，一次性掰扯明白！

主要Review的指标

前端代码Review主要关注以下几个方面：

1. 「代码质量」：代码是否简洁、易读、易维护。是否遵循了一致的编码风格和规范，例如ESLint、Prettier等。
2. 「功能实现」：代码是否实现了预期的功能，是否有潜在的bug或逻辑错误。
3. 「性能优化」：代码是否进行了必要的性能优化，例如避免不必要的渲染、使用了合适的数据结构和算法等。
4. 「安全性」：代码是否存在可能的安全风险，例如XSS攻击、CSRF攻击等。
5. 「可测试性」：代码是否易于测试，是否有单元测试和集成测试。
6. 「可读性」：代码是否易于理解，是否有足够的注释和文档。
7. 「可复用性」：代码是否有高度的模块化和复用性。
8. 「兼容性」：代码是否兼容不同的浏览器和设备。

「助记：功性读复全兼测」

功能Review

• 无需人为检测，但注释要写明白，TS类型要写清楚，让用的人如沐春风；
• 该匹配单元测试的建议「配套单元测试」，不落人以口实~

性能Review

前端代码中一些典型的、肉眼可见的需要性能优化的地方包括：

1. 「过度渲染」：如果你的应用在没有必要的情况下进行了过多的渲染，这可能会导致性能问题。例如，在React中，如果你的组件在「props没有改变」的情况下进行了重新渲染，那么你可能需要使用「shouldComponentUpdate/SCU」或「React.PureComponent」或「useEffect」来避免不必要的渲染。
2. 「大量DOM操作」：频繁的DOM操作是非常耗费性能的。如果你的代码中有大量的DOM操作，你可能需要考虑使用「虚拟DOM」或其他优化技术（例如「DocumentFragment」）。
3. 「大量的网络请求」：如果你的应用发送了大量的网络请求，这可能会导致性能问题。你可能需要考虑使用「缓存、预加载、懒加载」等技术来减少网络请求。
4. 「大型JavaScript文件」：如果你的JavaScript文件过大，这可能会导致加载和解析时间过长。你可能需要考虑使用「代码分割、懒加载」等技术来减小文件大小。
5. 「未优化的图片和媒体文件」：如果你的网站使用了大量的未优化的图片和媒体文件，这可能会导致加载时间过长。你可能需要考虑使用「图片压缩」、适当的「文件格式」、「CDN」等技术来优化你的媒体文件。
6. 「阻塞渲染的CSS和JavaScript」：如果你的CSS和JavaScript阻塞了页面的渲染，这可能会导致用户体验不佳。你可能需要考虑使用「非阻塞的加载技术」，如「异步加载」、「延迟加载」等。

非阻塞加载CSS和JS

阻塞渲染的CSS和JavaScript是一个常见的前端性能优化问题。当浏览器加载网页时，它会按照HTML文档的顺序解析每个元素。当遇到<link>或<script>标签时，浏览器会「停止HTML解析」，去下载和执行CSS或JavaScript文件，这就是所谓的"「阻塞渲染」"。

以下是一些优化阻塞渲染的CSS和JavaScript的策略：

1. 「异步加载JavaScript」：使用async属性可以使浏览器异步加载JavaScript，即在下载JavaScript文件的同时，浏览器可以继续解析HTML。但是，这可能会导致JavaScript在DOM还未完全解析时就开始执行，因此「只适用于那些不依赖DOM的JavaScript文件」。

<script async src="script.js"></script>

2. 「延迟加载JavaScript」：使用defer属性可以使浏览器延迟执行JavaScript，即在DOM解析完毕后，再执行JavaScript。这「适用于那些依赖DOM的JavaScript文件」。

<script defer src="script.js"></script>

3. 「内联关键CSS」：将关键的CSS（即渲染首屏内容所需的CSS）内联到HTML中，可以避免浏览器等待CSS文件的下载和解析。但是，这可能会增加HTML文件的大小，因此「只适用于小量的CSS」。

<style>
    /* Critical CSS */
</style>

4. 「媒体查询」：使用媒体查询可以让浏览器「只下载适用于当前设备的CSS」，从而减少不必要的下载；本质是「一种CSS的按需加载技术」

<link rel="stylesheet" media="(max-width: 600px)" href="mobile.css">

以上就是优化阻塞渲染的CSS和JavaScript的一些策略。

可读性Review

关注一下以下要点：

• 变量、函数、类、文件和文件夹的语义化命名；
• 注释
• 文档
• TS类型声明

复用性Review

正在review的这段代码可复用性如何，高的话是否可以：

• 封装为函数
• 封装为类
• 封装为指令
• 封装为hook
• 封装为组件
• 封装为模块

安全性Review

在前端代码的安全性Review中，主要关注以下几个方面：

1. 「跨站脚本攻击（XSS）」：检查代码中是否正确地「对用户输入进行了转义」，以防止插入恶意的JavaScript代码。例如，当使用React时，它默认会转义所有的用户输入，但如果你使用dangerouslySetInnerHTML（或Vue中的v-html），则需要特别小心。
2. 「跨站请求伪造（CSRF）」：检查是否「在所有的POST请求中使用了CSRF令牌」，以防止攻击者伪造用户的请求。
3. 「点击劫持」：检查是否使用了适当的HTTP头，如X-Frame-Options，来防止点击劫持攻击。
4. 「内容篡改」：检查是否所有的HTTP请求都使用了「HTTPS」，以防止混合内容问题，这可能会导致用户的数据被窃取（传输过程中被抓包）。
5. 「输入验证」：检查是否在客户端和服务器端都进行了输入验证，以「防止注入攻击」，图形或字符「验证码、短信验证、CSRF-token」等的本质都是加入「随机真人校验机制」，狠重要！
6. 「敏感信息泄露」：检查代码中是否有可能泄露敏感信息的地方，如在「URL、错误消息或日志」中包含敏感信息。
7. 「依赖的安全性」：检查所有的「第三方依赖」是否都是最新的，是否有「已知的安全漏洞」。

点击劫持

X-Frame-Options 是一个「HTTP响应头」，用于控制网页是否可以被其他网页通过、或等元素嵌入。这个响应头的主要目的是为了防止点击劫持/Clickjacking攻击。

X-Frame-Options有三个可能的值：

1. 「DENY」：此页面不能被嵌入到任何其他页面中。

X-Frame-Options: DENY

2. 「SAMEORIGIN」：只有同源的页面（即，URL的协议、域名和端口都相同）才能嵌入此页面。

X-Frame-Options: SAMEORIGIN

3. 「ALLOW-FROM」 uri：只有指定的页面可以嵌入此页面。但是，这个值「已经被废弃」，不再被大多数现代浏览器支持。

X-Frame-Options: ALLOW-FROM https://example.com/

如果没有设置X-Frame-Options头，或者设置的值不是上述三个值之一，那么任何页面都可以嵌入此页面。因此，为了防止点击劫持攻击，建议「总是设置X-Frame-Options头」。

兼容性Review

在前端代码的兼容性Review中，主要关注以下几个方面：

1. 「浏览器兼容性」：检查代码是否能在所有支持的浏览器中正常工作。这包括检查是否使用了某些浏览器可能不支持的JavaScript特性或CSS属性，以及是否正确地使用了polyfill和前缀。
2. 「设备兼容性」：检查代码是否能在所有支持的设备中正常工作，包括不同的操作系统、屏幕大小和分辨率。
3. 「响应式设计」：检查代码是否适应了不同的屏幕大小，包括手机、平板和桌面。
4. 「无障碍性」：检查代码是否遵循了无障碍性标准，如WAI-ARIA，以确保所有用户，包括那些使用辅助技术的用户，都能使用你的应用。
5. 「国际化和本地化」：检查代码是否支持多种语言和地区，包括正确地使用了日期、时间和数字的格式。
6. 「性能」：检查代码在「低性能的设备或网络环境下」是否还能正常工作。

即充分考虑「不同浏览器、不同设备、不同屏幕、不同国家、不同人群」；

什么是polyfill

• Polyfill是一段代码（通常是JavaScript），用于为旧的或不支持某些特性的浏览器提供这些特性的实现。Polyfill的目的是让开发者能够使用新的、更高级的API，而不用担心兼容性问题。
• 例如，Array.prototype.includes是一个新的JavaScript特性，用于检查数组中是否包含某个元素。但是，这个特性在IE浏览器中是不支持的。为了在IE中也能使用这个特性，我们可以使用一个polyfill，如下：

if (!Array.prototype.includes) {
  Array.prototype.includes = function(element) {
    return this.indexOf(element) !== -1;
  };
}    

• 这段代码首先检查Array.prototype.includes是否存在。如果不存在（即，浏览器不支持这个特性），那么就给Array.prototype添加一个includes方法，这个方法的行为和原生的includes方法一样。
• 在实际开发中，我们通常不会自己写polyfill，而是使用已经存在的polyfill库，如core-js或polyfill.io。
• 需要注意的是，虽然polyfill可以让我们在旧浏览器中使用新特性，但是它也有一些缺点。首先，polyfill会增加代码的大小，可能会影响网页的加载速度。其次，polyfill可能无法完全模拟新特性的行为，特别是一些复杂的或与性能相关的特性。因此，在使用polyfill时，需要权衡其利弊。

配置polyfill

• 安装polyfill库通常是第一步，但是你可能还需要进行一些配置，以确保polyfill能够在你的代码中正确地工作。
• 具体的配置步骤取决于你使用的polyfill库和构建工具。
• 以core-js和babel为例，你可以按照以下步骤来配置polyfill：

1. 首先，安装core-js和@babel/preset-env：

npm install --save core-js
npm install --save-dev @babel/preset-env

2. 然后，在你的.babelrc文件（或者babel的配置文件）中，添加@babel/preset-env预设，并设置useBuiltIns和corejs选项：

{
  "presets": [
    [
      "@babel/preset-env",
      {
        "useBuiltIns": "usage", // 或 "entry"
        "corejs": 3 // 指定 core-js 版本
      }
    ]
  ]
}    

• 这里的useBuiltIns选项有两个可能的值："usage"和"entry"。如果设置为"usage"，那么babel会「自动检测」你的代码中使用了哪些新特性，然后只包含这些特性的polyfill。如果设置为"entry"，那么你需要在你的代码的入口文件中，「手动导入」所有需要的polyfill：

import "core-js";

以上就是配置polyfill的一个示例。需要注意的是，这只是一个基本的配置，实际的配置可能会更复杂，取决于你的具体需求和环境。

可测试性Review

在前端代码的可测试性Review中，主要关注以下几个方面：

1. 「单元测试」：检查代码是否易于进行单元测试。这包括检查函数「是否是纯函数」（即，相同的输入总是产生相同的输出，没有副作用），以及「是否避免了全局状态」。
2. 「集成测试」：检查代码是否易于进行集成测试。这包括检查组件「是否正确地使用了props和state」，以及「是否避免了直接操作DOM」。
3. 「端到端测试」：检查代码是否易于进行端到端测试。这包括「检查页面是否有易于定位的元素」（如有特定id或data-test属性的元素），以及「是否有清晰的用户流程」。
4. 「测试覆盖率」：检查代码的测试覆盖率是否足够。这包括检查「是否所有的函数和分支都有对应的测试」。
5. 「模拟和打桩」：检查代码是否易于进行模拟和打桩。这包括检查函数「是否避免了直接调用复杂的依赖」（如网络请求或数据库操作），以及「是否提供了足够的接口来替换这些依赖」。
6. 「错误处理」：检查代码是否正确地处理了可能的错误。这包括检查是否有「错误处理函数或catch块」，以及「是否有对应的错误测试」。

端到端测试

• 「端到端（End-to-End，E2E）测试」 是一种测试方法，用于测试应用的整个工作流程，从用户界面到数据库，确保所有部分都能正确地协同工作。
• 在React应用中，我们可以使用Cypress或Puppeteer等工具来进行E2E测试。以下是一个使用Cypress进行E2E测试的基本步骤：

1. 安装Cypress：首先，你需要在你的项目中安装Cypress。你可以使用npm或yarn来安装：

npm install cypress --save-dev

yarn add cypress --dev    

2. 编写测试：然后，你可以在cypress/integration目录下编写你的E2E测试。以下是一个简单的测试示例，它测试了用户是否能正确地登录：

describe('Login Test', function() {
  it('Successfully logs in', function() {
    // 访问登录页面
    cy.visit('/login')

    // 输入用户名和密码
    cy.get('input[name=username]').type('testuser')
    cy.get('input[name=password]').type('testpassword')

    // 点击登录按钮
    cy.get('button[type=submit]').click()

    // 检查是否跳转到了主页
    cy.url().should('include', '/home')

    // 检查是否显示了欢迎信息
    cy.get('h1').should('contain', 'Welcome, testuser')
  })
}) 

3. 运行测试：最后，你可以使用Cypress的CLI来运行你的测试：

npx cypress open

这将会打开Cypress的测试运行器，你可以在这里选择你要运行的测试。

以上就是在React应用中进行E2E测试的基本步骤。需要注意的是，这只是一个基本的示例，实际的E2E测试可能会更复杂，包括测试更多的用户交互和应用状态。