【前端开发小妙招】如何将bug扼杀在提测前？

一、背景

好久没有写文章了，最近都在疯狂业务输出中。但是在日复一日的业务开发中，我们是否能总结一定的规律，从而提高我们的开发效率呢？只要我 fix 得够快，测试提的 bug 就追不上我！
针对开发工期拍得较长的需求，我们当然是有足够的时间去对照需求文档或者测试用例，进行查缺补漏。同样的，也有时间去 review 我们的代码，思考如何写得更加优雅。
但是，现实总是残酷的。往往你觉得需要 5 天才能完成的需求，只拍了 3 天。这个时候，我们能怎么办？要么，就是砍功能。要么就是砍交互细节。如果不想在提测后，一天收到超过 10 个 bugfix 提醒，就来看看这篇吐血总结吧！

二、缺陷分类

我把自己在测试阶段经常会收到的 bug 分成了两大类：1. 设计缺陷 2. 界面优化 。
这两大类的 bug 的提出，往往是需求文档上并未覆盖，但对于用户体验有一定影响的。我们是否能把这些问题前置到需求评审或者开发过程呢？

三、对症下药

a. 设计缺陷

1. 确认所有操作在不同步骤/角色中是否需要展示
   举个例子：在一个工单流程，不同的角色在不同阶段进入同一个页面的时候，能看到的按钮都是不同的。需求文档中是否已经思考到所有按钮的在不同情况的可见性呢？我们可以试着把所有按钮拎出来，以表格的形式去分析，按照一个完整工单流程的思路，去思考每个按钮的可见性。这样做，一方面可以让我们提前在需求评审中，抛出疑问给到PM去完善他的需求文档。另一方面，则是可以方便我们去写公共函数控制按钮的可见性。
2. 提交操作前，需要做哪些校验（特别注意卡片列表、单个输入框等非表单的情况）
   例子：如在卡片列表里，未进行任何卡片的勾选，其实是不能进入到下一步的，这个情况下我们应该给出相关的提示。
3. 明确无数据时的展示形式
   无数据时，我们可以做的展示形式多种多样，如：占位图/不展示/显示0/显示’-'/…，在开发前我们可以先沟通好需要那种形式更佳。

b. 界面/交互优化

1. input 框的内容提交时去掉前后的空格
   相比起在v-model后加上trim，这种强制不让用户以空格结束。我更倾向于使用loadsh等库的trim方法，在提交表单的时候，再对用户输入的内容进行输入内容前后的空格去除。
2. 使用面包屑支持回到上一级菜单
   有时候我们打开一个详情页，往往会需要回到上一级菜单。相比起写函数去手动回到上一级，我更倾向使用面包屑的方式去回到上一级，这样做样式上更为统一，逻辑上也更加清晰。
3. 多选框需要加上折叠标签的属性，出现样式问题
   这个问题主要是为了避免在选中多个内容之后，select框的高度变化，导致UI上的展示不佳。
4. 在 drawer/dialog 等组件中使用表格时，注意打开组件时便要重新获取数据
   重新获取数据的问题，不仅仅需要提交成功后进行。在打开一个组件式进行也是尤为重要。
5. 增加分割线，让列表数据展示更清晰
   很多时候，做点小的列表，可能没有UI出设计图。那这个时候个人就要有一定的设计sense，增加分割线，让数据不要混成一团。
6. 善用 badge 展示新消息
   往按钮，标签上的右上角添加小红点的交互相信大家都不会陌生。往往也容易是设计上可能会遗漏的点。

总结

这篇文章，看起来可能更像是PM、设计师的总结。但是于个人而言，如果我们能站在合作伙伴的角度有更多的思考，便能惯性地注意到很多细节。而这些细节，往往也是最后决定一个产品是否能做得好的关键因素。
尽早地发现问题，提出问题，解决问题，愿每个前端人都能按时下班！