如何組織大型JavaScript應用中的代碼？

摘要：我們常常看到Web應用中將JavaScript、CSS、圖片檔案分別按檔案類型區分，這一習慣在過去的Web開發情境中尚可勝任。但隨著Web App的發展，JavaScript應用越來越複雜，開發人員需要更清晰地、高效的檔案結構。

本文作者Cliff Meyers是一個前端工程師，熟悉HTML5、JavaScript、J2EE開發，他在開發過程中總結了自己在應對JavaScript應用越來越龐大情況下的檔案結構，深得其他開發人員認可。以下為CSDN編譯：

地板上堆放的衣服

首先，我們來看看angular-seed，它是AngularJS應用開發的官方入門項目，其檔案結構是這樣的：

• css/
• img/
• js/
  • app.js
  • controllers.js
  • directives.js
  • filters.js
  • services.js
• lib/
• partials/

看起來就像是把衣服按類型堆在地板上，一堆襪子、一堆內衣、一堆襯衫等等。你知道拐角的那堆襪子裡有今天要穿的黑色羊毛襪，但你仍需要花上一段時間來尋找。

這種組織方式很淩亂。一旦你的代碼中存在6、7個甚至更多的控制器或者服務，檔案管理就會變得難以處理：很難找到想要尋找的對象，原始碼控制中的檔案也變更集變得難懂。

襪子抽屜

常見的JavaScript檔案結構還有另一種形式，即按原型將檔案分類。我們繼續用整理衣服來比喻：現在我們買了有很多抽屜的衣櫃，打算將襪子放在其中一個抽屜裡，內衣放在另一個抽屜，再把襯衫整齊地疊在第三個抽屜……

想象一下，我們正在開發一個簡單的電子商務網站，包括登陸流程、產品目錄以及購物車UI。同樣，我們將檔案分為以下幾個原型：models（商務邏輯和狀態）、controllers以及services（HTTP/JSON端點加密），而按照Angular預設那樣非籠統地歸到“service”架構。因此我們的JavaScript目錄變成了這樣：

• controllers/
  • LoginController.js
  • RegistrationController.js
  • ProductDetailController.js
  • SearchResultsController.js
• directives.js
• filters.js
• models/
  • CartModel.js
  • ProductModel.js
  • SearchResultsModel.js
  • UserModel.js
• services/
  • CartService.js
  • UserService.js
  • ProductService.js

不錯，現在已經可以通過樹形檔案目錄或者IDE快速鍵更方便地尋找檔案了，原始碼控制中的變更集（changeset）也能夠清楚地描述檔案修改記錄。雖然已經獲得了極大的改進，但是仍有一定的局限性。

想象一下，你現在正在辦公室，突然發現明天有個商務出差，需要幾套乾洗的衣服，因此給家裡打電話告訴另一半把黑色和藍色的西裝交給清潔工，還有黑紋領帶配灰色襯衫、白襯衫配純黃領帶。如果你的另一半並不熟悉衣櫃，又該如何從三條黃色的領帶中挑出你的正確需求？

模組化

希望衣服的比喻沒有讓你覺得過於陳舊，下面舉一個執行個體：

• 你的搭檔是新來的開發人員，他被要求去修補這個複雜應用中的一處bug。
• 他掃過這些檔案夾，看到了controllers、models、services等檔案夾整齊地排列著，但是他仍然不清楚對象間的依賴關係。
• 處於某些原因，他希望能夠重用部分代碼，這需要從各個檔案夾中搜集相關檔案，而且常常會遺漏某些檔案夾中的對象。

信或不信，你確實很少會在新項目中重用很多代碼，但你很可能需要重用登陸系統這樣的整個模組。所以，是不是按功能劃分檔案會更好？下面的檔案結構是以功能劃分後的應用結構：

• cart/
  • CartModel.js
  • CartService.js
• common/
  • directives.js
  • filters.js
• product/
  • search/
    • SearchResultsController.js
    • SearchResultsModel.js
  • ProductDetailController.js
  • ProductModel.js
  • ProductService.js
• user/
  • LoginController.js
  • RegistrationController.js
  • UserModel.js
  • UserService.js

雖然現實世界中有空間限制，難以隨意整理服裝，但是編程中類似的處理卻是零成本的。

現在即使是新來的開發人員也能通過頂級檔案夾的命名理解應用的功能，相同檔案夾下的檔案會存在互相依賴等關係，而且僅僅通過瀏覽檔案組織圖就能輕易理解登入、註冊等功能的原理。新的項目也可以通過複製粘貼來重用其中的代碼了。

使用AngularJS我們可以進一步將相關程式碼群組織為模組：

12345678910111213

var userModule = angular.module('userModule',[]);  userModule.factory('userService', ['$http', function($http) {  return new UserService($http);}]);  userModule.factory('userModel', ['userService', function(userService) {  return new UserModel(userService);}]);  userModule.controller('loginController', ['$scope', 'userModel', LoginController]);  userModule.controller('registrationController', ['$scope', 'userModel', RegistrationController]);

如果我們將UserModule.js檔案放到user檔案夾，它就成了這個模組中使用到的對象的“manifest”，這也是適合RequireJS或者Browserify中放置某些載入指令的地方

如何處理通用代碼

每個應用都會有某些代碼廣泛使用在多個模組中，我們常常使用名為“commom”或者“shared”的檔案夾來存放這些功能代碼。又該如何處理這些通用代碼呢？

1. 如果模組中的對象需要直接存取幾個“通用”對象，為這些對象提供幾個Facade（面板模式）。這有助於減少每個對象的依賴者，而過多的關聯對象通常意味著糟糕的代碼結構。
2. 如果“通用”模組變得過於龐大，你需要將它按功能領域細分為多個子模組。確保每個應用模組只使用它需要的“通用”模組，這即是SOLID中“介面隔離原則”的變種。
3. 在根範圍（$rootScope）添加實體，這樣子範圍也可以使用，適合多個控制器都依賴同一個對象（比如“PermissionsModel”）的情況。
4. 在解耦兩個不明確互相引用的組件時，請使用事件。Angular中Scope對象的$emit、$broadcast以及$on方法使得這種方式變得現實。控制器能夠觸發一個事件來執行某些動作，然後再動作結束後收到相應地通知。                                                            
                                                                                                                                                                                                                                                                  
                          原文連結：CLIFF MEYERS