引言

一圖勝千言，給大家先看一張代碼量的對比圖：

代碼量隨時間的變化

得出結論：

• 糟糕的代碼設計會讓我們在前期寫很少的代碼，就能實現很多需求，但是后期，代碼量隨時間的變化會發生指數級的增長，我們將會有很繁重的任務。
• 優秀的代碼設計會讓我們在前期做很多的操作，但是后期的時候，只需要很少的代碼就能實現需求，代碼量增長的速度也會很慢，我們會有很多的空閑時間做自己喜歡的事。

所以，我相信不會有人喜歡做繁重的任務，為了寫出優秀的代碼，我們除了要養成良好的編程習慣外，還要不斷的去學習更優秀的代碼結構和編程方式。

在分享自己的技術經驗之前，先告訴大家，我不會寫諸如 縮進層級，行的長度，換行空行，注釋，文檔注釋，花括號對齊方式 等方面的規范，不是因為它們不重要，而是因為這不是決定代碼質量的核心因素，而且沒有統一規范，各大公司采用的標準都有差異，所以這些因素不在本篇文章的范圍內，如果大家需要，我會在后期文章中專門寫一篇關于這些規范的文章，有需要的請私信我。

進入正題

我會從 2 個方面（編程習慣，代碼結構）來概述 。

編程習慣

• 異常處理
  如果你沒有使用異常處理的習慣，這可能是因為你并未真正的理解它的作用。當你正確使用異常處理之后，你會發現你的代碼最顯著的變化就是：少了 很多的 if-else 語句 。雖然在 JS 中，只有錯誤（Error），沒有異常（Exception），但是我們很多人還是喜歡將之成為異常( 我覺得并沒什么不好，反而 會更形象)，js 把 異常分為以下6種：

  EvalError: raised when an error occurs executing code in eval()
  RangeError: raised when a numeric variable or parameter is outside of its valid range
  ReferenceError: raised when de-referencing an invalid reference
  SyntaxError: raised when a syntax error occurs while parsing code in eval()
  TypeError: raised when a variable or parameter is not a valid type
  URIError: raised when encodeURI() or decodeURI() are passed invalid parameters

  但是很多人都以為只能使用這6種異常，不符合項目中的需求，所以就不使用異常處理了，但其實我們完全可以根據自己的項目去自定義一些異常，我建議大家在錯誤消息中包含函數名稱以及失敗的原因，這樣會十分利于你的代碼調試，如圖：

  自定義異常處理
  
  

  為了便于統一管理，我建議大家自己建立一個異常模塊，需要的時候，直接引入這個模塊，如圖：

異常模塊

大家如果不習慣使用 異常處理 的話，我的建議是從你的下一個項目開始，你就試著去用異常處理，你會發現你的代碼非常優雅，省去很多的 if-else，十分干凈利落。

• 事件處理

  有經驗的開發者一定會知道，隨著項目內容增多的時候，代碼里面的事件處理程序會特別多，如果沒有良好的管理，應用邏輯會和事件處理程序緊密的耦合在一起，而且這時的代碼會有很大的冗余。為了解決這種問題，我建議大家采用以下3個方法：

  1. 隔離應用邏輯：將應用邏輯從所有事件處理程序中抽離出來是最佳的方法，因為你不知道接下來什么時候還會觸發同一段的邏輯。
  隔離應用邏輯
  2. 禁止分發對象：既然應用邏輯和事件處理程序是完全隔離的，那么應用程序中就不能有任何與事件有關的代碼，所以，應用邏輯不能依賴于 event 對象來實現某一功能。
  禁止分發對象
  3. 定義事件注冊模塊：整個時代都在提倡 js 代碼統一模塊化管理，所以，為了方便管理，我們有必要定義一個事件注冊模塊，用來統一完成事件的注冊( 綁定 ) 和 移除
  事件注冊模塊

• 配置分離
  每一次修改源代碼，都會有引入 bug 的風險，且只修改一些數據也會帶來許多意外的風險，因為數據是不影響指令正常運行的，精心設計的應用應該把關鍵數據從源碼中抽離出來，這樣，我們每次修改時，只需要修改抽離出的那部分代碼就行了，這樣既簡單方便又降低了很多風險。什么是配置數據呢？就是在應用中寫死了的那些值，如圖的代碼：

  "/write.php"就是配置數據

  "/write.php"就是配置數據，想象一下，這只是一個文件中的代碼，如果有100個文件中有這樣的代碼，假設某天，網站的 write.php 改成了 compose.php ，那么你就要將 "/write.php" 改100次 ！ 所以，無論是從安全上講還是從可維護上講，我們都很有必要抽離出配置項，并且定義在 Config 配置模塊中。（需要自己自定義一個 Config 配置模塊，代碼就不用演示了吧。。。）

• 其他

  1. 將 CSS 代碼從 JS 代碼中抽離出來（推薦 使用 class 類名作為 CSS 和 JS 通信的橋梁）
  2. 將 JS 代碼從 HTML 標簽中分里出來( 不要使用<span onclick="dosomething()" ></span>）。
  3. 將 HTML 從 JS 中抽離出來 。這里特別說一下，有些人可能會習慣了在 JS 代碼中 這樣寫：$( "p" ).append( '<h2>大家好</h2>' )，這樣并不是不可行，但是當需要插入大量的 HTML 標簽時，代碼就會變得十分丑陋而且難以維護，我們可以使用以下方法來解決這個問題：
  • 使用 Jquery 的 load( "路徑" ) 方法 從服務端加載 。
  • 使用<script type="text/html"> 在這里書寫你的 HTML 代碼 </script>。

結束

我突然發現本篇內容寫的有點多了，所以 “代碼結構” 這部分只能留到下一篇文章再講了，我擔心文章太長會讓人沒有耐心 ，其實就連本篇，我都感覺很多東西還沒講，但是因為長度原因，只能先擱置了。再說一下，下一篇文章，我再將本篇沒有講的 “代碼結構” 部分好好講一講。

有什么地方不完善，出錯，或者是漏掉的，請大家給我留言，私信，我會及時修改的。在編程的道路上，希望大家都堅持下去，加油，共勉！！！