這篇文章不僅僅從代碼本身來考慮如何優化編碼，也從代碼的設計階段來考慮，包括書寫API文檔，同事的review，使用JSLint。這些習慣都能幫助你編寫更加高質量的、更易于理解的、可維護的代碼（讓你的代碼在多年之后仍使你引以為傲）。

　　優秀的Stoyan Stefanov在他的新書中（《Javascript Patterns》）介紹了很多編寫高質量代碼的技巧，比如避免使用全局變量，使用單一的var關鍵字，循環式預存長度等等。

　　這篇文章不僅僅從代碼本身來考慮如何優化編碼，也從代碼的設計階段來考慮，包括書寫API文檔，同事的review，使用JSLint。這些習慣都能幫助你編寫更加高質量的、更易于理解的、可維護的代碼（讓你的代碼在多年之后仍使你引以為傲）。

　　編寫可維護的代碼

　　軟件的BUG修復需要花費大量的精力。尤其當代碼已經發布之后，隨著時間的增長，維護的成本愈發的高。當你一發現BUG的時候，就立即去修復，這時候你的代碼還是熱乎的，你也不需要回憶，因為就是剛剛寫好的。但是當你做了其他任務，幾乎完全忘記了這份代碼，這時候就需要：

　　· 重新學習和理解問題

　　· 理解代碼是如何解決問題的

　　另外一個問題是，在大項目或者大公司里面，經常是解決BUG的人不是產生BUG的人，而且也不是發現BUG的人。所以減少理解代碼的時間就是最重要的問題，無論這個代碼是你自己以前寫的還是團隊中的其他成員寫的，因為我們都想去搞搞新的有意思的東西，而不是去維護那些個陳舊的代碼。

　　還有一個開發中的普遍問題就是，往往讀代碼的時間比寫代碼的時間還要多。有時候你鉆研一個問題，可以花整整一個下午的時間來考慮代碼的編寫。這個代碼當時是可以工作的，但是隨著開發的進行，其他東西發生了很大的變化，這時候也就需要你自己來重新審查修改編寫代碼。比如：

　　還有BUG沒有解決

　　添加了新的功能

　　程序需要在新的環境中運行（比如一個新上市的瀏覽器）

　　代碼有問題

　　代碼需要重寫因為修改了架構甚至要使用另一個語言

　　因為這些原因，也許你當時一個下午寫好的代碼，后面需要花費幾周的時間來閱讀。所以編寫可維護的代碼對于軟件的成功至關重要。