項目中如何有效率的開發js？

01-21

java程序員，在寫前端。
項目的主體是h5+aj
目前項目中有一堆js，好幾個js文件都寫到2000行以上。
如果分多個js文件，那麼html文件中
必定會有一堆&，怎樣才能有效管理？

最近在重構一個後端 Java 開發人員遺留下來的前段項目。

首先是簡單的回答

前端早已經工程化，你見到的大型網站 JSCSS 文件都是存儲在 CDN（Content Delivery Network）上的。之所以 js 文件幾千甚至幾萬行，是因為那是利用 Gulp、Webpack 等工具打包（如compress、uglify和minify）後的結果，並不是開發人員寫的源文件。淘寶網等將部分 js/css 代碼寫入 &/& 標籤，那是為了減少 JS/CSS 文件請求，還有一種情況是為了減少首次數據請求（即將首次服務調用返回的 JSON 直接寫入頁面的 & 里）。

接下來將正式答案分為代碼分離（Code-splitting）和Git 代碼倉庫兩部分。

相信你在寫 Java 項目時，也是最起碼從 Project、Package、Class 這三個層級去設計的，前端工程項目也是一樣的。

那麼，前端工程化需要進入 BAT 後才能學習到嗎？當然不是，BAT 使用的也都是來自開源界的成熟技術，絕大多數的知識內容在網上都能學習到。事實上，不掌握 Babel、Webpack、Gulp 等基礎技術，怕是簡歷都曬不過，連前端入門的門兒都看不見。

1. 代碼分離 Code Splitting

1.1 工程 Project

通常來說，一個小型前端項目，只需要一個工程就可以了，工程中通常包括

package.json 不論是 Node.js 還是 HTML5 前端項目都需要有一個 package.json；
.editorconfig 用來約定多人開發時的書寫習慣（換行符號、Tab 大小、是否保留文件最後一個空行等）；
.eslintrc 這個不用說了，推薦使用或繼承 airbnb 的 ESLint 配置；
webpack.config.js 現在很少有前端項目不用 Webpack 的，所以這個文件不能少，在我們的實踐當中其實還需要 webpack.config.dev.js、webpack.config.production.js 這三個文件，他們分別適合於開發調試和生產環境；
src 目錄，這個目錄存放的是所有的 js、html、css/less/scss 源文件，當然還有圖片、字體等資源文件；
build 目錄，這個目錄存放的是壓縮、編譯、轉譯後的 js、css 及資源文件（即生產環境），這個目錄將被上傳至你的 CDN；
以上是最最基本的一個工程，當然還應該有雲端持續集成工具的配置文件（如 travis.yml 等）、.babelrc 編譯運行時配置文件以及一定會有的 node_modules 目錄等。
這裡要說明的是，像 BAT 的中型項目通常不會只有一個工程，而是被細分為若干的小工程，包括 Node.js 寫的服務層工程、通用類庫 npm 工程、工具類工程等，這裡就不一一細述了。

1.2 入口 Entry

接下來是決定有幾個入口，這裡借用的也是 Webpack 的概念，不過在使用 Webpack 之前大家也基本這樣稱呼。簡單來說，可以將入口理解成你有幾個頁面（如果你沒有用前端路由的話），每一個獨立頁面需要至少一個入口。有一種特殊的入口，通常前端開發人員會叫它 common 或者 vendor，這是將一些通用的組件或第三方的類庫組裝在一起。對於 Webpack 來說，每一個 entry 最終會被編譯打包成一個 js 文件（通常還有一個 css 文件以及相關的資源文件）並被放入到 build 目錄中。

1.3 包 Package

如果你是一個 Java 程序員那麼你肯定對 Package 的概念十分熟悉，沒錯現代化的前端工程也有包的概念，也就是 src 的目錄結構。就 React 項目來說

實例中，entry-a目錄 是一個 entry，也是最外層的包，這裡你可能會很驚訝的發現前端工程的包中竟然是可以由「-」的，是的，這是前端工程中的 package，不是 JavaScript 的 package，習慣上最外層的包會用「-」分隔；
actions 目錄存放的是 Redux 的 action；
api 目錄存放的是和服務端交互的 Restful 服務代理（agent），即每一個服務端服務會有一個對應的代理方法，推薦使用 Axios、Fetch、Zepto 或 jQuery，有興趣的話也可以看一下阿里巴巴的 natty-fetch；
components 目錄存放的是 React 組件，每一個組件又是一個獨立的目錄，這其中除了 index.jsx 外，還可以放置 less、圖片等相關資源文件；
containers 目錄存放的則是 connect 過後的 Redux React 組件；
store 目錄存放的是 Redux 的 store 以及 middleware、enhancers 等；
以上是一個典型的 React、Redux 工程中一個 entry 的包結構，實際工程要比這個複雜得多。

1.4 模塊 Module

每一個 js/jsx 文件就是一個模塊，而在 Webpack 及 CSS 模塊化中，每一個 css/less/scss 也是一個模塊。

我個人的習慣是：

每一個模塊文件平均 100 行以下，且不超過 400 行；
每一個模塊文件只放一個 class，盡量做到只 export default 而不是多個（如果你寫的是一個類庫除外）；
每一個 class 盡量控制在 120 行內；
每一個方法盡量控制在 20 行內；
凡是不滿足以上條件，請參考《重構》一書的要求拆封代碼，在 Webpack 的幫助下，你不需要擔心源代碼文件的個數；
代碼注釋多多益善，不受以上限制，對自己要求嚴格的，可以考慮 JSDoc。

2. Git 代碼倉庫 Repository

要想提高前端項目開發效率、維護效率，就不得不談到 Git 的組織。

待補充中，如果你們贊的話，我就多寫一點啦

不要直接在HTML用&引入直接編寫的「源代碼」，你所寫的JavaScript代碼最好要經過一些處理，比如：

lint，檢查低級錯誤；
babel，這樣可以讓你寫ES6、ES Next的代碼；
uglify或者minify，把你的代碼縮小
bundle，把多個文件合併為一個文件，這樣你就只用一個&了。

以上都是行業中的最佳實踐，沒有什麼充分理由，最好還是跟隨最佳實踐。

1. 看看你當前的項目是否適合使用前端自動化工具，如gulp,webpack等，如果可以的話，你可以搭建一下自動化的開發環境，將功能眾多，體積龐大的js按照功能模塊拆分，獨立開發，然後利用工具合併，壓縮，檢查，polyfill，做版本以後更新。

2.如果當前項目不太適合的話，就比較考研你的js功底了，使用面向對象的方法，一個功能模塊是一個對象，然後DOMContentLoaded的時候去初始化這個對象，實現需求。

舉個例子！

評論回復就可以看成是一個功能模塊，定義一個叫做comment的對象，首先得有數據，那麼肯定有一個load的方法，用來從伺服器獲取數據，有了數據就得有地方存儲，開一個叫做list的數組用來存放評論回復的數據吧，有了數據就還得有一個渲染數據到頁面的render方法，將數據渲染到頁面了，然後應該還有評論的功能，就叫他userComment吧，這個方法負責將用戶評論的內容，時間，用戶信息等存放到這個數據中，然後重新觸發render方法進行渲染，回復也是同樣的道理，這樣處理下來，評論回復這個對象應該就是這個樣子的。

const comment ={

load(){

// ajax獲取數據後存放到list，以後調用render方法進行渲染。

list(){},

render(){

// 遍歷當前的list，生成dom結構

userComment(){

// 根據傳入的參數，向list數據插入數據，重新渲染頁面

userReply(){

// 同評論

}

document.addEventListener("DOMContentLoaded",()=&>{

comment.load() //載入數據

},false)

這可能會涉及到分頁或者其他的功能，那個時候只需要向comment對象上添加方法，完成功能即可。

這樣做的好處就在於功能邏輯清晰，易於維護，減少看不懂代碼的情況，可以有效的解決題主的問題！

還有一些其他的方法，先看看有沒有人看，如果有人看了再來更新！

JavaScript經過這些年的發展也有了很多工程化的最佳實踐。

一個Java程序從源碼到可執行的程序需要編譯再在jvm上執行，現在JavaScript也推薦這樣子的過程，使用webpack，babel，minify等工具將源代碼轉為瀏覽器可以使用的文件，而不是直接在html的script標籤里寫。這樣子的好處是，瀏覽器沒有實現JavaScript的特性也可以提前使用，比如題主需要的模塊化功能。

...aj是什麼，你聽說過ts嗎，聽過webpack嗎，nodejs和npm呢？有的公司認為前端無所謂就讓實習生去搞心真是大啊，想想我司主站一個遺留下的幾萬行的JS傳了幾年，每次改東西都尼瑪用查找的方式去定位，最近終於被人接鍋給模塊化了,喜大普奔喜大普奔。