作为一名贼粗心的人，命运使然做了前端。

代价就是，起初一年bug数在公司创新高（其中至少一半是前人遗产，我特么的。。。），之后慢慢有所好转。

如今工作两年半，bug的出现率直线下降，并不是我这个人变得细心了，而是这份工作更得心应手并且“稳重”了一些。

就我自己来说，还没做到bug数喜人的少的地步，只能说马马虎虎的数量，毕竟我也不是一个优秀的前端哇（假装哭唧唧，其实只是不想那么累没有那么没人性的努力）。多与产品和后端沟通，需求稍微有不清楚的或者文档写的不够清楚的，确认后再写，自测的时候再遛一遍文档。再加上我本人记性还可以，出过的bug下次再写的时候会有意去关注一下，避免出现以前出现过的bug。我们后端和产品都是很好的人，提测前会集体点一点，发现问题会互相告知，以此来减少测试小姐姐暴走的概率。其实就是职责互相分摊了一下，他人更容易发现自己写的的bug。

设计稿的话我们项目组已经抛弃设计师，嫌弃他们拖慢项目时间，其实就是用户夺命催，功能开发出来已经很难了（比如让我们半个月做一整套系统这种啥b要求），再去计较这个table的颜色一会要这个灰一会要那个灰（表示用户的电脑贼渣看起来根本就是乌突突一片说了无数遍设计不理啊）那个select的啥啥的基本不可能（用的antd,样式改起来很烦的，再加上设计团队给的所谓标准并不让客户满意，所以被我们团队直接舍弃）。于是前端说了算，全部都走的ant配置之后的样式，一切样式以开发方便+用户用着舒服+开发人员看着也舒服为基准。如此样式问题很少，而且经过一年多的摸索和讨论，我们前端团队已经弄出来了几乎一整套封装好的组件，功能和样式基本统一，不放飞自我的时候还是比较可控的。

再有就是从开发的角度上来说，组件化以及公用方法和hooks提取使用是一个减少bug的有效方法，只要统一，任何bug都是小意思。试错到一定程度，自然就是一个大致可以的成品了。仿照ts做一些propstype的限定也有用，可以避免一些乱七八糟的问题。

最后说一下，心态很重要。有bug不可怕，不要纠结也不要烦，有问题就解决问题（毕竟老子是被测试组约谈过的女汉子，心态真的太重要了），如果记忆力不好就养成写工作日记的习惯，将bug和解决方法都记下来。

秒开云-奥利给！