1 设计方案相关
1.1 复用
功能、组件是否可以提取公共方法？是否重复造轮子？同一代码不应该重复两次以上。
1.2 可拓展
当需求发生改动，是否能够使用少量的改动达到我们的目标，适应未来的变化？
1.3 过度设计
很多时候由于早期为了能够拥有更好的扩展性，进行了很多抽象和封装，使其复杂化，造成了过度设计，是否设计了很多实际场景还遥不可及的实现。
1.4 依赖倒置
模块之间的依赖是否合理？一旦模块发生修改，影响面是否能得到有效的控制？
2 可维护性
2.1 命名
首先格式（中划线、小驼峰、大驼峰、下划线）需要符合规范，不管是文件命名或者变量命名，尽可能符合其功能特性，能够通过命名知道它的含义，无须增加注释去特意说明。
使用下划线场景：临时变量，接口字段key，
使用小驼峰：组件内部data、props，html中组件标签
2.2 注释
是否在关键代码（if判断、函数等）内增加注释说明？是否符合正确的规范？
2.3 复杂度
降低复杂度，
圈复杂度原理和实践：juejin.cn/post/684490…
函数应该做一件事，做好这件事，只做这一件事。 — 代码整洁之道
2.4 不合理的代码
每个项目都有一些难以维护的旧代码，在这个基础上继续添加代码，也许可以很快的解决当下问题，但对于日后来说，只会让它更加难以维护。及时对不合理的旧代码进行重构和优化就显得尤为重要
2.5 无用代码
代码中是否存在任何没有定义或没有引用到的变量、常数或数据类型，无用需要删除
3 健壮性
3.1 攻击：XSS、CSRF等
前端安全系列（一）：如何防止XSS攻击？tech.meituan.com/2018/09/27/…
前端安全系列（二）：如何防止CSRF攻击？tech.meituan.com/2018/10/11/…
3.2 逻辑边界处理
是否有考虑到代码的边界逻辑？交互逻辑是否全面？
3.3 异常错误处理
一旦抛出异常或者错误，页面或者运行的代码是否会崩溃？
3.4 兼容性
多端兼容？是否有浏览器版本兼容？手机机型兼容？历史数据兼容？接口兼容？
3.5 数据展示、校验、转换
对于关键数据，尽可能直接展示后台返回数据，前端不建议计算
4 功能范围
4.1 影响范围
底层架构、组件或者方法的修改，是否确认影响范围，每个受影响的依赖都能正常使用。比如公共组件是否有评估到每个引用的组件和页面的正常回归使用。
4.2 修改范围
是否属于本次迭代正常上线的功能范围，有没有对本次范围进行变更，是否通知到测试同学。
5 监控/埋点覆盖
5.1 数据上报功能
记录用户操作行为，有关用户操作行为的都要上报
6 合规
6.1 敏感信息展示
敏感数据是否需要掩码处理
6.2 敏感信息明文上报
敏感信息是否需要加密处理，后台进行解密等
6.3 敏感信息存储
是否有将用户敏感信息存在不安全的地方，比如web storage等
7 性能
7.1 图片
是否都有用cdn，是否都控制图片大小，在保证清晰的情况下尽可能压缩图片大小
7.2 http请求
页面初始化请求过多？白屏时间过长？初始化加载数据是否在合理范围内？
7.3 懒加载
是否可以通过懒加载或者按需加载进行优化？
7.4 缓存数据
需要重复加载数据时，可以通过缓存数据减少请求。
\
