2.4 函数使用

2.4.1 缺少抽象小函数（或小组件）的习惯
翻车指数：★★★★★说明：评审中经常会有觉得函数/组件小不愿意去抽象、或者说还没有被复用就不去抽象的情况。

案例




危害

大函数/组件容易导致代码分层不明确，不利于团队合作分工，导致更复杂的状态管理，导致代码复用变得困难。

建议

函数/组件抽象不仅可以是为了复用，也可以是为了使我们的主干逻辑或主干架构足够清晰，让代码易读易维护！

2.4.2 创建不必要的包裹函数
翻车指数：★★★★说明：通常是出现创建了不必要的包裹函数的现象，导致更深的函数嵌套。

案例



危害

增加不必要的代码，提高维护和检索代码的成本

如果函数发生改变，其包裹函数也要改变

建议

遵循函数为一等公民原则，包括作为参数传递给另外一个函数，从另外一个函数返回，赋值给变量，或者添加自身的属性方法... 可以像对待JS中的其他任何数据类型一样对待函数。

bad：getNotification被另外一个匿名函数包裹起来了
const { data } = useRequest(() => {

 return services.UserController.getNotification();

});

good：将getNotification直接传递给useRequest
// 函数被赋值给services.UserController.getNotification后，它并不只可以被执行，也可以被当做参数传递给另外一个方案

const { data } = useRequest(services.UserController.getNotification);

2.4.3 把控不好的函数层级
翻车指数：★★★★说明：通常是在主函数中定义很多的子函数，但大部分子函数又是不依赖主函数上下文的

现场



危害

主函数逻辑不够清晰，阅读者没法由浅入深地去了解你的程序，最终导致代码难以阅读和理解。

建议

去思考函数层级是否合理，看到长函数要有优化重构的意识，避免嵌套过深的函数。

2.4.5 函数存在副作用
翻车指数：★★★

现场



危害

以上案例将user信息挂载到了全局window对象，容易导致命名冲突变量相互覆盖等问题，同时让调用方“倍感意外”。副作用本身虽不是毒药，但不要滥用副作用。

建议

好的习惯是尽可能设计纯函数，掌握好它对于理解和使用很多框架非常有帮助（比如react），它能带来以下优点：

可测试

可缓存，提升性能，相同的输入总是对应相同的输出。比如在react中使用memo；

易组合，纯函数的返回结果仅依赖入参，这意味着函数间无耦合，方便互相组合出功能更强大以及适用更多场景的纯函数；

可并行处理

2.5 不好的编程习惯

2.5.1 过度使用可选链
翻车指数：★★★★★说明：很多同学会认为使用可选链会让代码更加健壮，但大部分时候这是你对自己代码不够了解的体现。

现场




危害

过度使用?会使程序更加难以理解和调试，不知道程序内对象的一些真实是否可空的情况导致维护者写后续代码非常艰难，同时会把一些bug在开发阶段掩盖。

建议

使用可选链之前一定要经过思考和了解你取值的对象是否可能为空，否则一定不要使用可选链。

2.5.2 React中直接操作state
翻车指数：★★★

现场



危害

破坏了React中状态的不可变性，使得状态的改变可能无法正确被追踪，状态的变化变得不可预测，甚至导致组件无法被正确渲染。

建议

始终将状态（state）视为不可变对象，所有的状态更新都应该通过setState进行（创建新的状态对象），永远不要修改现有状态对象的属性。

2.5.3 if条件不清晰
翻车指数：★★★★★

案例




危害

可合并的if分支（案例1），通常多个条件检查命中后要执行相同的逻辑块，可以合并为一个单一的表达式，提高代码可读性；

空的if代码块（案例2），空代码块通常可以被视为“死代码”，即不会被执行的代码，这增加了程序的复杂度且没有任何收益，并可能导致混淆和误解，谨记No Dead Code。

建议

尽管大部分时候我们的if条件检查在逻辑上是正确的（测试能够通过），但在写完代码后还是应该先做一遍自查，看看有没有可优化的空间，以提高代码的可读性和可维护性。

2.5.4 在末端关注不必要的上层逻辑分支
翻车指数：★★★说明：通常是上层函数该处理好的逻辑分支流转到了函数/组件末端，导致逻辑分支需要成倍数地去增加。

案例




建议

可以参考初始化时分支模式的思想，一旦上层的逻辑分支没有规划好会导致越往末端的代码要做的重复判断越多，app入口、容器代码当成我们的初始化代码，做好上层的逻辑分支判断。

2.5.5 组件互斥属性值的使用
翻车指数：★说明：对不熟悉的组件有时候会凭经验去试各种api，最终遗留了互斥的属性值。

案例



建议

使用公共组件还是要避免反复去“试api”的方式完成功能，没有把握的api最好是去翻找官方文档或者看组件的类型定义。

2.6 缺乏服务端思维

2.6.1 接口评审只听不评
翻车指数：★★★★★说明：团队系分环节中的接口评审一直存在，但经常会流于形式，前端同学们容易听确不评，接口初版即终版，里面问题情况较多，下面列举几个常见的。

案例


危害

传递冗余字段（案例1），通常后端为了少几个通过唯一键去取数据的逻辑，甚至会认为这是出于接口性能考虑，会在一些写接口中设计冗余的字段，千万别掉入这个陷阱，它危害巨大：

数据一致性风险：冗余数据会带来数据同步问题，前端如果传递了不一致数据会导致后端数据错误。

耦合性增加：冗余字段增加了前后端之间的耦合性，违反了服务的独立性和单一责任原则。

增加前端复杂性：你需要组装额外的数据、管理额外状态，这增加了前端代码的复杂性。

重复定义单一数据源（案例2），通常这会导致数据一致性问题，当数据源更新需要多端发布，前后端也当共享单一的数据源，通过接口获取数据。

千奇百怪的bool值（案例3），依赖存在一致性问题，有使用"yes"、"no"的就有使用字符串"true"、"false"的，或者使用"y"、"n"的，bool类型是多数编程语言中的基本数据类型，具有明确的意义，而字符串则可以包含任意值导致类型不明确，带来额外性能开销的同时更加容易出错。

建议

提高api设计、系分参与度，带着更适合用户界面的前端设计在系分评审中多学、多听、多问，去了解服务端工作原理的同时寻找最适合前端的接口模型，提升前端在团队中解决问题的能力。

2.6.2 用展示字段去做业务逻辑的条件表达式
翻车指数：★★★

案例




危害

带来极大的稳定性风险，展示字段有其不稳定性容易变更，比如案例1如果业务提示消息改变这个逻辑就走不通了，从而引发系统问题。

建议

业务逻辑应该基于正确的数据模型，而不是用户界面的表示，切勿将数据和表示逻辑混淆