当前位置：首页 > news >正文

web前端团队开发code review方案最佳实践

news 2025/10/1 13:11:13

前言

原则上，代码审查（code review）是团队中每个成员都应参与的过程，而不仅仅局限于管理者。通过进行必要的代码审查，不仅可以减少线上问题的发生概率，同时也是团队成员相互学习和提升代码质量的良好契机。这样做的目的是构建一个更加健壮的系统，并促进知识在团队内部的流动。
建议实行代码审查（code review）的值班制度，每周由一名团队成员轮值负责。在轮值期间，所有需要上线至测试环境的业务代码均需提交给该值班人员进行审核。经值班人员确认无误后，再进行提测。值班人员的代码提交给上一周值班人员进行审核。这种机制能够明确责任分工，提高审查效率，同时确保代码质量得到有效把控。

codereview的方向

1.检查代码中使用数组方法时，相关数组是否有为空的情况，如


menuList.value.codeList.filter(i => i.id === 2); //codeList如果不存在，js会报错
res.data.bankCodeList.indexOf('CMB') //bankCodeList如果为空，js会报错

如上面的代码例子，如果数组方法前是空，那么js会报错，阻断后续代码的执行，在发现以上的问题时，要求开发者进行防御性编程，加上必要的判断，防止js报错

2.检查代码中判断逻辑是否存在为空的情况，如：


// 如果detail为空，那么js就会报错
if(res.data.detail.bankList) {....
}

如上面的逻辑判断，如果审核代码的时候发现可能存在为空的情况，要求开发者进行修改，加上?.或者逻辑与进行判断，以防js报错

3.判断代码是否存在冗余，若已有成熟组件或方法可用，应要求开发者优先使用现有资源，避免重复开发。例如，我们公司内部的组件库和函数库已提供了大量成熟的解决方案，应充分利用这些资源，提升开发效率和代码质量。

4.不建议开发者自行“造轮子”，例如某些功能在像 lodash 这样的成熟工具库中已经提供了完善的实现，我们可以直接使用这些现成功能，而不是重复编写类似的方法。（应相信权威工具的可靠性和性能）。如果发现某些功能在 lodash 或其他工具库中已有对应实现，应要求开发者优先采用这些工具库中的方法进行替换，以提升代码效率和可维护性。

5.在代码审核过程中，应要求开发者尽量降低代码的耦合性，除非有特殊必要。具体建议如下：

减少嵌套层级：if 判断的嵌套层数不应超过三层，原则上保持在两层以内为佳。如果嵌套超过三层，应将逻辑拆分为独立的方法或函数，以提升代码的可读性和维护性。
控制函数长度：单个函数的代码行数应尽量控制在 30 行以内。如果函数过长，说明其可能承担了过多职责，应将其拆分为多个小函数，每个函数专注于完成单一任务。

6.在代码设计中，应避免为了过度追求组件化而将业务逻辑割裂，导致后续维护成本增加。对于同一业务的逻辑代码，应尽量保持其完整性，集中放置在同一处，而非通过多次导出、包装后再导入的方式进行拆分。这种做法不仅会增加代码的理解难度，还可能导致逻辑分散，影响整体可维护性。

如果在代码审核中发现类似问题，应要求开发者对代码结构进行调整，确保业务逻辑的连贯性和清晰性，从而提升代码的可读性和维护效率。

7.每个js文件的代码行数应控制在 1000 行以内。如果文件代码量超过此限制，应要求开发者对代码进行必要的组件化拆分，以提升代码的可读性和可维护性。

特别是当主文件中存在大量与弹窗、抽屉等功能相关的代码时，应要求开发者将这些代码抽取为独立的子组件。这样不仅可以减少主文件的代码量，还能提高组件的复用性和逻辑清晰度，从而优化整体项目结构。

8.活用代码空行，逻辑块之间应有空行，dom模板之间有空行，样式块之间有空行。本条是建议，便于模块更清晰，也方便进行code review。如：

js函数逻辑块空行示例：

dom块空行示例：

css样式块空行：

9.在代码审核过程中，应重点关注代码是否存在优化空间。如果审核人发现代码逻辑、结构或性能方面有改进的余地，并具备更优的实现思路，应及时将优化建议反馈给开发者，要求其进行必要的调整和优化。

优化的方向可以包括但不限于：

提升代码的可读性和可维护性；
简化复杂的逻辑，减少冗余代码；
提高性能，减少不必要的计算或资源消耗；
遵循团队的最佳实践或设计规范。

通过提供具体的优化建议，不仅可以帮助开发者提升代码质量，还能促进团队整体技术水平的进步。
优化思路参考：JS的优化技巧https://blog.csdn.net/yxlyttyxlytt/article/details/133949260

10. 所有需求类代码在提测至测试环境前，需经过至少一位同学进行 Code Review，未经审核的代码，相关管理人员有权进行打回。

11.如值班同学因会议等原因未能及时响应，开发者可自行指定另一位前端同学进行审核，通过后方可进行提测。

12.提测merge时需按照以下格式进行提测：

title命名：【项目名】需求名
description: 需求jira链接或者蓝湖链接；标明后端、测试、cr负责人是谁

13.代码审核（Code Review）的核心目标是提升代码的健壮性，降低代码上线后出现问题的风险，而不是为了挑刺或制造矛盾。被审核的开发者应以虚心学习的态度接受他人的建议，将其视为改进和成长的机会，而非针对个人的批评。

在审核过程中，如果对某些意见存在疑问或分歧，不应争执或引发矛盾，而是可以通过友好的沟通进一步探讨。若仍无法达成一致，可寻求开发组长或者主管进行最终裁定，以确保问题得到公正、合理的解决。通过这样的方式，团队能够在协作中共同进步，同时营造积极健康的开发氛围。

拓展

为什么开发团队需要规范约束？？

开发团队需要规范约束，不是为了限制程序员的创造力，而是为了在多人协作的复杂环境中，建立一个共同的“交通规则”，从而极大地提升效率、质量和可维护性。

可以把一个开发团队想象成一支施工队。如果没有统一的图纸、材料标准和施工规范，有的工人用砖，有的用木头，门窗尺寸各异，最终建成的房子要么无法完工，要么就是危房。代码规范就是软件项目的“图纸和施工规范”。

以下是规范约束的几个关键作用，从不同维度详细解释：

1. 提升代码质量和可维护性

一致性：规范确保了代码风格、命名、结构的一致性。无论团队中的哪个成员来阅读或修改代码，都能快速理解，就像阅读一本由同一个人写的书。这极大地降低了“认知负荷”。
减少“屎山”：没有规范的代码会迅速腐化，变成无人能懂的“屎山”。规范是防止代码腐化的第一道防线，它强制开发者写出清晰、结构化的代码。
易于重构和调试：当代码结构统一时，查找Bug、重构代码或添加新功能会容易得多，因为你不需要在五花八门的写法之间不断切换思维。