@主要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：
- 首先，安装
core-js和@babel/preset-env：
npm install --save core-js
npm install --save-dev @babel/preset-env
- 然后，在你的
.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测试可能会更复杂，包括测试更多的用户交互和应用状态。
功性读复全兼测! OVER，收工干饭！