在看完139个bug后，我...

搬砖快四个月了，下午把全部指向个人139个bug都过了一遍，发现的一些事实是90%以上的bug都是因为对业务需求理解不够到位而致使的，而因为对语言语法的掌握问题致使的bug仅占极少数的部分。

下面分享一些代码编写层面的典型bug。（前面的数字是bug编号，能够忽略）

3089 XXX.forEach() is not a function，此类bug几乎没有前端儿没有遇到吧。相似的，还有can not read property xxx of undefined和can not read value of filterCourse[0]。这些因为JavaScript语言设计上的问题是没法在代码编写中发现的，只能依靠开发人员在开发过程当中考虑更全面一点。这也是TypeScript近来大火的缘由，把JavaScript的动态类型变为静态类型。

3251 toFixed()方法的返回值是由定点表示法表示给定数字的字符串，若是将返回值直接用于数值比较那会出现真值异常问题。而字符串的比较是基于各字符ASII值来进行的。好比下例中，9的ASII值比1的大，所以"90" > "100"的真值为true。但直接使用字符串进行比较得到的真值并不必定都是错的，好比下面的"1" > "22"。并且若是是在项目公用工具函数中使用toFixed()方法且没对返回值进行处理，那影响的面是很是广。

// e.g 直接使用字符串比较
"90" > "100" // true
"1" > "22" // false

// e.g 转换为Number类型比较
Number("90") > Number("100")
复制代码

下图就是我在生产环境中遇到的bug,需求是当前分数超过虚线则显示绿色，但因为"100" > "88"为fasle，所以颜色显示有问题。

3278 新增角色字数过多报错，先后端字段长度未约定一致。这种bug就典型的是由于先后端沟通不充分而进行开发致使的了。诸如新增角色的需求，在产品提出需求时未必可以注意到如此小的点；后端在设计表结构时按照以往开发经验进行长度限制；而后后端给到前端通常就只有关于某接口的介绍(诸如url、请求类型和参数)。在获取用户所填写角色名时，后端和产品都未说起长度，若是前端此时不够敏感以致于没有找各方确认，那此时bug就出现了。

一一过完这些bug，个人感觉是，清楚充分地理解需求，功能实现只是水到渠成的事。此外，在具体的开发中，产品没法在第一遍设计需求的时候彻底考虑周全，那咱们在开发的时候若是能作到预判产品未说起的隐藏需求，我想这对于开发效率的提高是显而易见的。好比上面提到的新增角色字数过多。