编写代码前，如何规避尽可能多的前端bug？

        当我们开始听需求评审，了解一个业务需要实现的样子时，最基础的功能，无外乎是增删改查。那么，我们就从这些简单操作中，去探寻如何减少bug的产生！

当产品给我们一个对于内容管理做增删改查的需求时，首先需要考虑什么呢？思考三秒钟......

 

第一：增。

        我建议先关注页面布局，再关注其中的表单字段；由大到小，易于掌控整个页面的构成。在未来即使有需求变动，也不会影响大的布局；当然，如果变动都影响到页面构造了，直接回怼：排期！！！

        整体布局时，我们需要知道这是单独页面，还是类似面包屑页面，别问我怎么知道的（呜呜呜呜......）；问清楚后，我们需要关注，表单字段是一行一个还是一行多个，字段之间是否有联动，是否有隐藏占位之类影响布局情况的；之后我们就可以明确是原生div的去布局，还是使用UI组件去做。
        在选择布局实现时，也得考量该UI组件能否实现，是否符合现有需求。
        在关注表单字段时，首先要知道各个字段的单独校验规则，是否必填，是否有长度限制，是否需要联动反显，什么情况下清空字段等等。在这之后，隐藏的bug就来了，此处用el-form举例：对于字段的label和value框的展示，有时label是四个字或更少，不会影响到展示效果，当变成超过五个字时，容易导致label换行或者这字段整体挤压布局空间，这点需要注意。
        在提交表单前，处理form字段的逻辑，最好用其他对象接一下formData，防止修改或者赋值过程中，把表单展示的value给修改了。
        最后就是事先和后端伙伴定义传参方式和结构，是json字符串格式，还是form表单格式，很重要；切记一定要在明确需求后，就去商量怎么传参，这样会提高联调效率，以及后续由于传参约定有误，导致的bug修复问题。
        做好以上这些，增的流程内，可减少90%以上的bug产出。其他类似样式问题、逻辑问题也会少很多。

第二：删。

        删时注意有无提示，删除是否需要重置页面，是否需要更新对应缓存；然后调用删除接口后，清除对应需要清空的字段，防止重复传参。

第三：改。

        修改的第一步是反显，对于反显而言，在使用UI组件时，表单中input框直接赋值即可；select框是需要对应的id和集合中匹配上的，另外，需要避免未找到集合中的名称时的反显处理，这儿也可能被提bug；另外对于反显的单选或多选，这种布尔类型的，一定注意返回参数是否是布尔值，有时可能是包在字符串里面的，也容易导致反显不出来；对于富文本这种插件，反显只需要拿传递过去的值，用本身插件的回显形式就行，附件这种一样；其他类似的反显方式，都是遵循对应的组件展示规则即可。反显完成后，和增的其他操作类似。

第四：查。

        查一般分为两部分：一为查询内容的组件，一为显示的区域。查询内容一般也为form表单形式，其中各校验规则需要注意，另外，对于查询条件的默认值也要确认好；显示区域多为表格或者文本展示，需要注意的是，展示的列项宽，表格样式，是否多选，是否格局查询条件显隐某些列等。有导出功能的，需要了解导出是否需要合并表格等。
        

        以上操作，最好考虑防抖，避免多次请求，导致数据重复处理。
        简单的增删改查，通常不注意时，也会出现很多bug，所以锻炼要从小处入手，逐步提升！希望看到的小伙伴都能写出高质量代码！！！

人生海海，码途徐徐，在每一段经历中，留下成长的印记，爱自己爱生活爱思考！