引言

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

代碼量隨時間的變化「原創」

得出結論：

• 糟糕的代碼設計會讓我們在前期寫很少的代碼，就能實現很多需求，但是後期，代碼量隨時間的變化會發生指數級的增長，我們將會有很繁重的任務。

  
  

• 優秀的代碼設計會讓我們在前期做很多的操作，但是後期的時候，只需要很少的代碼就能實現需求，代碼量增長的速度也會很慢，我們會有很多的空閒時間做自己喜歡的事。

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

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

進入正題

我會從 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、禁止分發對象 3、定義事件註冊模塊。

1. 隔離應用邏輯：將應用邏輯從所有事件處理程序中抽離出來是最佳的方法，因為你不知道接下來什麼時候還會觸發同一段的邏輯。

2. 禁止分發對象：既然應用邏輯和事件處理程序是完全隔離的，那麼應用程序中就不能有任何與事件有關的代碼，所以，應用邏輯不能依賴於 event 對象來實現某一功能。

3. 定義事件註冊模塊：整個時代都在提倡 js 代碼統一模塊化管理，所以，為了方便管理，我們有必要定義一個事件註冊模塊，用來統一完成事件的註冊( 綁定 ) 和 移除
   

隔離應用邏輯

禁止分發對象

事件註冊模塊

• 配置分離

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

  什麼是配置數據呢？就是在應用中寫死了的那些值，如圖的代碼：

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

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

• 其他

  ①：將 CSS 代碼從 JS 代碼中抽離出來（推薦 使用 class 類名作為 CSS 和 JS 通信的橋樑）

  ②：將 JS 代碼從 HTML 標籤中分裡出來

  ( 不要使用<span onclick="dosomething()" ></span>）。

  ③：將 HTML 從 JS 中抽離出來 。這裡特別說一下，有些人可能會習慣了在 JS 代碼中 這樣寫：

  $( "p" ).append( "<h2>大家好</h2>" )，這樣並不是不可行，但是當需要插入大量的 HTML 標籤時，代碼就會變得十分醜陋而且難以維護，我們可以使用以下方法來解決這個問題：

  1）使用 Jquery 的 load( "路徑" ) 方法 從服務端加載 。

  2）使用 <script type="text/html"> 在這裡書寫你的 HTML 代碼 </script>，這樣，瀏覽器就不會將它識別為 HTML 代碼，你就可以在 JS 中 通過調用 這個<script>標籤，實現優雅的生成 HTML 代碼了。

結束

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

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