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

@主要Review的指标

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

1. 代码质量：代码是否简洁、易读、易维护。是否遵循了一致的编码风格和规范，例如ESLint、Prettier等。

2. 功能实现：代码是否实现了预期的功能，是否有潜在的bug或逻辑错误。

3. 性能优化：代码是否进行了必要的性能优化，例如避免不必要的渲染、使用了合适的数据结构和算法等。

4. 安全性：代码是否存在可能的安全风险，例如XSS攻击、CSRF攻击等。 5. 可测试性：代码是否易于测试，是否有单元测试和集成测试。

5. 可读性：代码是否易于理解，是否有足够的注释和文档。

6. 可复用性：代码是否有高度的模块化和复用性。

7. 兼容性：代码是否兼容不同的浏览器和设备。

助记：功性读复全兼测

@功能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>

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

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

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

<style>
    
</style>

1. 媒体查询：使用媒体查询可以让浏览器只下载适用于当前设备的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

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

X-Frame-Options: SAMEORIGIN

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

X-Frame-Options: ALLOW-FROM https:

如果没有设置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

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

{
  "presets": [
    [
      "@babel/preset-env",
      {
        "useBuiltIns": "usage", 
        "corejs": 3 
      }
    ]
  ]
}    

• 这里的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    

1. 编写测试：然后，你可以在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')
  })
})    

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

npx cypress open

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

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

功性读复全兼测! OVER，收工干饭！