本篇介绍的内容与代码质量有关。是作者在工作中遇到的Bug反思，分为原因分析、养成习惯、吸取经验三部分，以此避免再次犯错。同学们可以看一看，是否也犯过一样的错误。

原因分析

• 未考虑边界条件

  逻辑边界条件处理：重置值，截取字符串长度

  文本边界处理：空处理(null\undefined，使用??进行默认值处理)，超出处理(省略或换行，注意连续数字、字母)，宽度过长处理(设备兼容或字数限制)

• 未考虑初始化值

  对象赋值为{}或null；字符串赋值为""；数值赋值为-1

• 未考虑字段校验，如是否必填，值为数字时有无上下限

• 未考虑内部代码性能，在自动化测试中易被检测出

• 未考虑外界极端条件，如弱网加载图片

• 未充分自测，尤其是修改全局代码

• 未充分理解业务

• 对某个东西了解不够充分，像微信小程序api并非都promise化，如wx.showModal

• 人无完人，细节稍有遗漏

养成习惯

• 提交前检查代码，是否遗漏、写错
• 对问题会考虑更多，如值变化是否需要监听，接口或回调的触发时机

吸取经验

关于分页

• 对数据做增删改后，需刷新回到列表的第一分页。一般列表都是按更新时间做排序，此时顺序发生了改变，而且如果是删除操作，分页可能不存在，要回到第一分页
• 重新查询分页时需携带当前查询条件

关于兼容性

• 安卓系统4.4.4以上内置浏览器基本与操作系统无关，看Chrome最近版本是否支持即可
• 苹果内置浏览器依赖系统版本，看对应版本

关于增强型校验(只要有一个组件内容错误，则无法提交，只有全对才可提交)

• 客户端做增强型校验，服务端需要校验吗？需要，因为3种交互方式(URL、超链接、表单)中的URL存在风险，需提高安全性，防止暴力访问
• 服务端做增强型校验，客户端需要校验吗？需要，提高用户体验，减少服务器压力

彩蛋：从流程上保障质量

质量衡量指标

• Bug数
• 回滚数
• 线上故障数(重点关注影响面广或影响程度高的故障，以及低级错误和重复错误)

保障质量的工作流程(加粗字体是保障质量的体现)

• 需求阶段
  • 确定需求：产品、设计内部对齐、确定优先级、需求复用
  • 需求评审：产品、设计给出需求文档、原型、设计稿、Deadline(可选)
• 开发阶段
  • 开发评估：开发给出任务故事点
  • 技术评审：
    • 方案评审：开发给出技术设计方案(梳理功能，关键点的技术实现，确定影响范围)，或技术调研方案(可行性分析)
    • 接口评审：开发给出接口定义完成时间(前端较注重)、联调开始时间（前、后端两边提的较晚时间），告知QA提测时间
  • 开发编码实现，编写单元测试并执行，进行自动化代码检查
  • 测试用例评审，开发进行P0自测
  • 开发提PR进行CodeReview(推荐reviewer是做过这块业务或与之相关性较强的；提PR时清晰描述功能或问题)，以及提测
• 测试阶段
  • 测试环境：开发修复Bug，QA验证问题是否修复
  • 集成环境：P0功能（已有功能在本迭代执行，新功能在下迭代实现再执行）通过自动化端到端测试/流量录制回放回归，一般由测开负责
• 发布阶段
  • 产品、开发、测试准备上线清单，说明发版内容、提供代码仓库信息如分支、版本等等，运维根据清单进行发布
  • 灰度发布：功能回归
  • 全量发布

  发生事故：先回滚(项目、脚本)再修复，重走测试和发布

• 维护阶段
  • 查看业务日志埋点
  • 提供错误、性能监控
  • 提供反馈入口
  • 定期复盘