前端開發過程的工業化

（臨時寫的，待補充）

基於Web的前端開發有三大要素：介面結構、業務邏輯、修飾，對應到實現技術，分別是DOM結構（也就是HTML）、JavaScript、CSS，三者共同構成完整的Web。

三者之中，DOM結構最為核心，因為它表達了整個介面的語義。在分工良好的前端開發過程中，邏輯和互動是分離的，分別使用JavaScript和CSS來共同操作、修飾DOM結構。

所謂的工業化，最本質的含義是良好的協作關係，完善的流程，先進的工具。工業化的目標也很明確，就是提高效率。那麼，在前端開發的過程中，有哪些地方是可以提高效率的呢？

首先我們想到的就是複用。複用的意思是，某一塊東西多次出現，不必為它重複勞動，做一份，然後其他地方拿來用。

HTML部分的重用，現在方案很成熟，那就是模版。我們把要重用的HTML片段做成模版，藉助於一些流行的模版庫，就可以把它們放置到介面的各種需要的地方去了，模版除了可以是靜態內容，也可以跟一些模型資料繫結。

JavaScript部分的重用，經歷了幾個階段。最初的階段，大家把公用的js程式碼從頁面中抽取，放在單獨的檔案，哪個頁面需要就引入進來，然後，經歷了全域性變數衝突的痛苦，大家意識到要引入名稱空間的機制，再後來，require等按需載入手段被發明出來，對指令碼部分的控制更加精細化了。

CSS部分，也經歷了原始階段到模版生成，現在的LESS、SASS等技術，起的就是這樣的作用。

以上，我們看到了目前Web前端三個核心部分的複用狀態。稍等，這裡面有沒有什麼值得注意的地方？CSS這個部分，有些特別，特別在哪呢？它可以有一個編譯生成的階段，但HTML跟JS方向沒有，我們來看看這個生成過程有什麼好處。

在我看來，LESS這類機制最大的好處是讓樣式變得可管理、易維護了，比如說，它可以有變數，當要改整體風格的時候，可以直接把這些變數一改，生成的CSS檔案就自動搞好了，這個非常方便，我們HTML跟JS的部分能不能學學？

先看JS吧，我們看看JS開發過程中有可能碰到一些什麼問題。假設現在我們都符合AMD這樣的規範，寫了ABC三個模組，A跟B依賴於C，於是在A裡面require一下C，在B裡面也這麼做，問題來了，如果C被修改了，修改C的人從哪裡知道自己被誰引用了，有可能造成他們出問題？嗯，我們可以做專案內搜尋，然後可以通知A跟B的開發人員，或者跑一下它們的單元測試。

但，如果依賴你的模組不在你的專案裡，怎麼辦？有什麼辦法去通知這些模組的開發人員，讓他們關注一下可能受影響的功能？傳統方式可能就在版本的變更說明裡寫一下吧，但是這個，很多人真的不看。我們把問題簡化一下，用大阿里來舉例（舉例之前先膜拜一下），大家知道阿里有KISSY框架，各其他產品依賴於它，如果KISSY裡面某模組產生了變更，即使只改了個名字，可以用什麼辦法來通知所有依賴它的產品開發人員呢？很難，對吧？

再舉個例子，這些模組的名稱空間由誰來負責規劃？如果多個產品裡面存在相同命名路徑的模組，單獨運營的時候沒問題，突然有一天某兩個產品整合部署，模組衝突了怎麼辦？這些都是問題。

所以，從很多角度，我都認為需要有那麼一個手段，把JS程式碼集中管理起來，包括命名規則和依賴關係，這樣，無論是模組的變更還是產品程式碼的釋出，甚至混淆和壓縮釋出過程，都可以在這裡面做。從功能來講，版本伺服器已經不能滿足需求了，必須有一個附加的管理系統。

另一方面，HTML模版也有類似的問題，一個模版被別人引用，如果自己的佈局有所調整，怎麼能夠讓引用它的介面都驗證一下是否影響體驗？所以它同樣需要有依賴關係管理。

好了，我們得出了一個初步結論，我們需要一個統一的平臺，管理和釋出HTML、JS和CSS。但是，把這些零散的改進功能放在一起，是不是算工業化了？遠遠不是，這思路才達到電影《國產007》裡面“要你命3000”這樣的效果，我們需要更多。

統一的Web開發平臺應當做到極致，它的管理功能，應當能把雲端服務之外的一切靜態資源全部管理起來，包括字型、圖片等資源，國際化語言字串，還有介面片段和邏輯的繫結關係。除此之外，需要管理程式碼的單元測試，能夠在釋出之前做全量的單元測試，也需要能夠管理API文件。

傳統的API文件是靜態生成的，並不重視互動。這種文件，用的時候會看看，但是看到問題了想要反饋就有些麻煩，而文件的維護人員在接到反饋之後怎樣能儘快更新，也是一個問題。如果這些文件都是類似部落格那種形式，或者像github裡面markdown的文件，而且文件下面還能評論交流，那該多好呢？

除了文件之外，我們經常也有程式碼片段需要分享，或者就是直接可執行的示例，前者就像gist，後者就像jsfiddle和jsbin，如果這些也能整合到平臺中，就更好了。

無論是文件還是示例，甚至是被管理的程式碼模組和介面片段，都應當允許評論，並且這些是一個統一的外掛模組，除了當作評論，應該可以當作微博來使用，類似，文件模組除了寫文件之外，也應當可以當部落格使用。

有了這些，整個平臺就生動活潑起來了，然後我們就可以給它新增更有價值的特性。比如說，可以新增視覺化的介面模版建立過程，視覺化的介面流設計，整個就完全變成一個二次開發平臺，當在這個平臺上做的基礎部件達到一定程度之後，再新做一個功能就有很多的東西可用，有可能幾步拖拉設定，就能把需要的功能開發出來，從這個角度，開發的效率大為提高。另外一個角度，因為我們整合了邏輯的單元測試，所以可靠性也大幅提高了。

這時候回頭一望，可靠、高效，不就是我們想要的結果嗎？