來源：kejunz 的分享（@kejunz）
總結一年的工作心得，三個概念越來越清晰：技術、工具、工程。搞清楚才知道空白、著力點在哪裡。
純粹的技術約等於規範，HTML/HTML5、CSS/CSS3、Javascript之類的語言規範，以及瀏覽器的具體實現。工具是技術之上封裝的各種通用庫和框架，比如jQuery、Backbone、requireJS等等。對待技術和工具，技術自然是最基礎的，工具是照著“說明書”就可以很快上手，對工具不必太執念，否則會很快遇到成長的“天花板”。技術和工具很容易混淆，例如在簡歷上常常可以看到精通xxx，後面一串工具名，確實很唬人。可惜我們的筆試題會揭穿他們對技術掌握程度的真實情況。
工程簡言之是一個產品的開發過程。與技術、開源工具所具有的通用性不同，每個產品的開發過程都有其工程上的特點。從工程需求出發，設計工具鏈、設計程式碼架構才是正確的思路。相反，看到一個“時髦”的工具就加進來，不能更好達到工程的目的，甚至複雜化，事得其反。所有開源工具都源於作者的實際需求，需求不同，工具的適用性不同需要審慎考量。
工程需求是出發點。記得我剛來豆瓣時，便急於想建立一個UI庫，最終的效果並不好。UI庫的想法是對的，但做為切入點早了。應該首先分析產品前端開發的工程需求到底是什麼。
以我今年的工作為例，工程上有兩個顯著特點：快速迭代和多版本並存。硬體要追求完美，是因為它犯錯的代價太大。web產品相比，可以及時在下一次上線中得到修正。所以對於web開發，工程上的關鍵問題其實是：迭代轉的是不是足夠快。程式碼的維護難度是主要限制條件。
如何把維護難度降下來。維護難度跟程式碼質量、複雜度、業務耦合度等因素相關。關於程式碼質量控制，首先建立規範統一程式碼風格，在此之上可以有自動化的檢查工具，同時離不開人為的code review。控制單位模組的複雜度和解耦跟程式碼組織方式相關。對於現在的前端開發來說，程式碼的組織方式是一個重要話題，前端社群裡熱議的AMD、包管理工具、自動化構建工具都是為了解決這個環節的問題。靈感也多源於java、ruby、nodejs等這些server端語言。如何選擇工具，或是自主開發工具？還是要回到具體的工程需求上。
案例分析：臨時在導航上加一個提示框。技術實現毫無難度，工程上就不那麼簡單了。也許面臨下面的問題：
1. 導航是跨產品線的
2. 各產品可能是在不同的程式碼倉庫
3. 它是臨時的
4. 只有首次註冊的新使用者才能看到
5. 它有多個版本
如果正巧碰上導航正在A/B測試情況又複雜一些了。
傳統做法：
1. 導航模組雖說是全域性的，可以把提示框的html部分寫在裡面。它相關的css和js要分別部署到全域性的css和js檔案中。這樣帶來的問題：模板裡可以判斷是否出現提示框，css和js則無法做這樣的判斷。提示框下線時，要找到三個檔案刪程式碼。
2. 如果有的產品在不同程式碼倉庫中，重複1的各種麻煩。
3. 如果類似的臨時需求多了，維護成本將驟增。
4. 提示框不顯示的情況下，與它相關的css和js冗餘在全域性檔案裡。
5. 多版本維護的複雜度加倍。
相似的場景在開發中十分普便。通過加人解決？隨著需求增加，人力永遠不夠。我們跟工具團隊合作改造模板系統比較完美的解決了這個問題。
提示框做為一模組檔案，內部包含了相關的html/css/js。引用它之後，模板系統在渲染時，會自動做以下處理：
1. 收集。將頁面中各個模板中的css和js分別收集起來。
2. 去重。去掉重複的引用。
3. 生成外部檔案。
當模組出現時，css和js分別自動併入外部檔案。去掉模組時，相關的程式碼自然移除，非常方便。
上述包含的細節就不展開了。css的引用支援sass和source map，js目前支援匯入。後續還有完善的空間，不過已經可以解決不少工程上的問題。《打造facebook》一書中說facebook會集合公司裡最好的工程師開發工具。我們恰好也是這樣。