搬砖快四个月了，把所有指向我的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")

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

一一过完这些bug，我的感受是，清楚充分地理解需求，功能实现只是水到渠成的事。此外，在具体的开发中，产品无法在第一遍设计需求的时候完全考虑周全，那我们在开发的时候如果能做到预判产品未提及的隐性需求，我想这对于开发效率的提升是显而易见的。比如上面提到的新增角色字数过多。