【51CTO.com快譯】一位前端開發者分享她的工作流與理想工具集選項。每個新項目總會帶來一段令人興奮的旅程，但糟糕的規劃也可能毀掉這一切。人們往往將前端開發工作流程視為繁瑣且優先級較低的任務，但由此帶來的後果往往會在生命周期當中出現。
事實上，工程技術的本質就是提升產品水準、從以往錯誤中總結經驗，而後制定出一套精簡的實施流程。我們應當將這些原則運用到流程當中，從而在項目開始時即建立起可供每位開發者使用的規則、工具與技術選項。如此一來，產品本身亦將更加靈活、可擴展且易於維護。
作為一名前端工程師，我總會在開始新項目前確保工作流程的明確性與組織性。下面，我將與大家分享自己的整個設計過程。
1. 設置一套任務運行器
有些朋友可能不太熟悉任務運行器，這實際上就是一種用於自動執行重複任務的軟體。其適合處理的任務包括JavaScript壓縮、文件連接、複製文件/目錄、執行腳本以及編譯CSS文件。任務運行器通常立足於命令行，允許開發者「觀察」特定文件或者目錄的變化，而後在適當時運行任務。
在這方面，我個人推薦Grunt與Gulp。關於二者孰優孰劣的問題，恐怕很大程度上取決於使用習慣。Grunt以配置為核心，較為笨拙緩慢，但卻易於上手且擁有龐大的技術社區。Gulp需要更為複雜的操作流程，但速度卻更好。
下面來看二者的優劣總結：
Grunt
+ 易於上手
+通過配置實現更高控制水平
+發展歷史更久，社區規模更大，插件選項更多
–非流式文件I/O使其速度較慢
Gulp
+ 需要配置的部分較少
+ 處理速度更快
+流式機制，允許異步文件處理
+ 代碼編寫需求更低
–API較為有限
Grunt與Gulp都運行在Node.js之上，因此團隊中的每位開發者都需要首先安裝Node.js。
另外一種適合由任務運行器負責的任務為編譯模板語言，例如Jade。
2. 定義CSS流程
接下來，大家需要選擇一種CSS方法，答案可以是BEM、SMACSS或者Atomic CSS。具體選擇同樣取決於您的個人喜好。我自己使用的是BEM，其易於學習且能夠在大型團隊中用於高效處理各類應用組件。
在決定了CSS的編寫規則之後，大家應當考慮如何編寫CSS代碼。結合當下趨勢，大家都在利用Sass或者Less編寫更為簡潔的CSS代碼。然而，CSS4很可能在不久的將來徹底取代這些「語言」。
考慮到預處理機制會給構建流程增加額外的時間投入，因此應當討論其是否必要。例如，如果大家選擇使用BEM，則可能不再需要使用Sass或者Less中的嵌套功能優勢。
使用Compass等Sass庫能夠顯著提升Sass的功能性，引入包括sprite-map生成、跨瀏覽器混合、文件讀取以及數學輔助函數等，這一切都能讓開發者在其CSS中實現更多效果。不過需要注意，使用Sass與Compass的前提是要求每位開發者預先安裝Ruby。
另外，大家可以利用postcss等JS插件對CSS進行後處理。作為可擴展插件，postcss允許大家自動根據瀏覽器支持需求添加瀏覽器前綴、檢查CSS、壓縮文件並生成sprite等。我也在使用postcss，這裡向大家強烈推薦。
3. 制定JavaScript規則
這也是開始新項目中最令人興奮的部分，正確處理亦能夠切實降低後續的技術債務。大家可以整理出一些嚴格的要求，包括JS如何編寫、使用哪套框架以及設計模式等。
編寫哪種風格的JavaScript？ES 5、ES 6+、TypeScript還是其它？
這是個大問題，而且往往很難找到惟一的正確答案。
ES5
ES5的優勢在於，它能夠幫助所有開發者更為順暢地使用JavaScript，面對易於理解的結構並掌握如何使用各類動態語言特性。對於經驗豐富的開發者而言，其不會帶來任何學習曲線，且全部主流JS MVC框架皆能夠支持ES5。
當然，其最大缺陷在於迫使開發者繼續編寫平淡無奇的陳舊JavaScript代碼。其冗長、鬆散且面向對象的傳統語言特色使其無法吸引使用C#、Java以及Ruby等語言的開發者。根據我的個人經驗，JavaScript會給新手軟體開發者帶來陡峭的學習曲線。
「Undefined不是函數？？這是什麼意思？？！」——每位軟體開發者肯定都有過這樣的疑問。
ES6+
ES6代表著JavaScript的未來——或者會是ES7？總之，利用現代語言標準編寫代碼以應對未來需求絕對是個正確的選擇。ES6提供一系列極具吸引力的語言特性：類、接口、Lambda函數、模塊導入/導出功能以及其它多種能夠在「真正的」程式語言中發現的元素。
ES6的缺點在於，大家仍然需要將代碼轉譯為ES5以獲得更為廣泛的瀏覽器、伺服器與作業系統支持。這雖然不是什麼大問題，且相信能夠在不久的將來得到解決，但就目前來講其仍在構建流程中增加了額外的步驟。另外，其確實會帶來學習曲線，但這同時也是提升開發團隊技能水平的好機會。
TypeScript
TypeScript是微軟針對JavaScript自身不足給出的解決辦法。其優勢包括ES6+中包含的一切提升，同時亦面向Visual Studio提供工具，且受到Angular v2的大力支持。TypeScript旨在通過添加更多現代語言特性以實現JavaScript的可擴展性，同時幫助開發者更輕鬆地立足.NET開發環境。
在缺點方面，大家仍然需要將TypeScript轉譯為ES5，且面對相關學習曲線。
而這就引發了下一個問題。
我們該使用哪套JavaScript框架？
目前市面上的JavaScript框架不計其數，因此我們幾乎很難確定下惟一最佳的一款。相反，我們在這裡選擇了最出色的三種，分別為Angular、Ember與Backbone。三者皆擁有相對悠久的發展歷史，因此成熟度更高且具備規模可觀的社區資源庫。另外，三者分別採用區別明顯的方式構建應用程式。下面來看它們的優缺點：
Angular
Angular v2是我個人的首先方案，其具備與Angular v1相同的出色體驗，我也期待著能在下一個項目中使用其最新版本。
+ 極高的原型設計與構建速度
+ 為TypeScript與Dart提供說明文檔
+ 可輕鬆配合Jasmine與Karma實現測試驅動型開發
+ 大量獨有功能
– 大量獨有功能
– 要求開發者必須遵循Angular獨有的方式進行開發
Ember
良好的中間性選項。
+ 組件驅動型特性
+ 獨有功能少於Angular，但多於Backbone
+ 使用handlebars模板引擎
+ CLI
+ 可經由CLI輕鬆實現測試
Backbone
老派而又純粹的框架
+ 幾乎不具備任何獨有功能
+ 可對設計模式、代碼樣式以及架構進行全面控制
+ 部分極具影響力的應用與網站皆運行於Backbone之上
+ 可選擇您偏好的模板引擎
+ 基本上屬於簡潔版HTML，無需額外屬性
– 要求使用大量樣板代碼
– 不存在依賴性，但可配合Marionette等視圖框架提升使用體驗
– 總體代碼編寫量要求更高，但亦可藉此實現更佳優化
– 自帶測試環境
總結
通過以上探討，下面我來匯總自己理想中的最佳前端開發流程：
Grunt負責任務運行 Sass負責CSS預處理 Postcss負責後處理 編寫TypeScript 利用 AngularJS進行構建
【51CTO譯稿，合作站點轉載請註明原文譯者和出處為51CTO.com】
點讚 0