一個周天的下午，如坐鍼氈。為什麼？因為明天週一了.... 要上班了，可能發bug要挨批評了。部落格在git上維護：歡迎stargithub.com/MirroZhou/B…
最近的兩次Bug:
- 做A需求的時候，看到以前的一段程式碼寫的很難看，很不好維護，我忍不了了。所以麻（shou）利（jian）的修改了，然後我就狗帶了~
- 做B需求的時候，要修改以前的程式碼，我在已有的函式上加了一個引數。然後我又狗帶了~
發bug就像無孔不入的蟲子，你以為你堵住了這個洞，但是它有在另外一個洞生長飛進來，防不勝防！
總結：導致發bug的原因往往不在新的功能和新的需求，而在你修改了以前的程式碼！！這些牽涉到的修改點，測試並不會去很仔細的測啊！！！！
以下是我們高工嚴厲指出並給我的建議並加上我的個人總結，與大家分享，定期踩坑更新（我希望再也不要更新了！！！）。
1. 修改前與原作者溝通
如果原作者還在，可以和原作者聊一下，最好他能講一下程式碼結構，可以減少很多看程式碼的時間
2. 仔細閱讀修改段落的上下文，並Get以下重點：
- 包括引數命名模式
- 註釋風格等程式碼風格（分號啊，空行啊，空格啊.....）
- 引數定義位置（一般都在頂部）
- 函式定義方式（函式宣告方式or 函式表示式方式）
- 程式碼結構（MVC分塊）
get之後就按照已有的風格進行修改，也許你是一個很有風格的碼農，你可以改變其他人一起用這個風格~
3. 開始修改了，以下雷請掃：
-
定義一個新的變數（函式）： 記得檢查變數作用域並全域性搜尋~ 不要自信的覺得你和別人定義的不一樣。
-
修改已有的函式引數： 不要修改引數順序！！！！這樣就算有些呼叫的地方你沒有看到，也會降低很多的bug率。
4. review一遍程式碼，這裡分為自己review和邀請其他人review。
- 自己review:
- 看是否有啥異常沒有處理。前端經常犯錯就是容錯性不夠好，畢竟從發起後臺請求到你拿到資料，過程是多麼艱辛。
- 修改了哪些點，儘可能記下來會影響哪些模組！！
- 他人review: 對於新人來很有用啊~
5. 提交測試
把自己會影響的模組列出來發給測試，這樣他才知道重點啊~尤其是在寫新需求夾帶修改舊程式碼的時候！！ 這個很重要！！！ 如果有接入前端錯誤監控的話，關注一下報錯內容。我們專案是有接入Badjs錯誤監控的。
6. 釋出之後，你的產品有論壇或者群嗎？
有的話直接加上去，觀察使用者反饋。往往這些地方是bug反饋最及時的~~~~~
總結完了，忐忑的去吃雞然後默默等待明天批評。