前言:接下来会开启一个小程序最佳实践的知识小册,从小程序作为切入点,但绝不限于此。将涵盖几大篇章『命名篇』、『单测篇』、『代码风格篇』、『注释篇』、『安全生产篇』、『代码设计篇』、『性能篇』、『国际化篇』和『Why 小程序开发最佳实践』。每一篇都会包含正面和反面示例以及详细的解释。
文中示例都是在 CR 过程中发现的一些典型的问题。希望大家能通过该知识小册提前规避此类问题,让我们的 CR 关注点更多聚焦在业务逻辑而非此类琐碎或基本理念的缺失上而最终形成高质量的 CR。
能私有不公共(Private over Public),公共 API 意味着对稳定性和对代码质量更高的要求,需要足够健壮,要考虑所有场景,需要单测以及充分的覆盖率来保障;不利于重构,不能轻易被删除和修改(Code should be easy to delete),需要考虑兼容性,让开发者战战兢兢如履薄冰。
『能力越大责任越大』。如果你不想考虑更多的场景,仅满足当前需求请将其私有。
函数可提高可读性和可复用性,符合 DRY 原则。好的函数都是有迹可循的,坏的函数各有各的坏。
[建议]:三个以及三个以上参数需采用对象参数形式,其次让相似功能的参数分组可让函数逻辑更清晰。
str是目标主体,是必选项,其他参数,是可选配置项,混为一体缺乏重点,逻辑混乱
[建议] 有副作用的函数容易引发不可预期的问题导致运行时隐患,且无副作用的函数更易测试,其次建议将副作用隔离。
拆分成两个方法,让getGuideCount精兵简政,职责更单一,消除其副作用,让incrementGuideCount去专职去做有副作用的更新操作(隔离副作用)。额外获得好处消除res.data和null的重复判断,