在看完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，個人感覺是，清楚充分地理解需求，功能實現只是水到渠成的事。此外，在具體的開發中，產品沒法在第一遍設計需求的時候徹底考慮周全，那咱們在開發的時候若是能作到預判產品未說起的隱藏需求，我想這對於開發效率的提高是顯而易見的。好比上面提到的新增角色字數過多。