我我的的前端開發技術路線變化圖（下）

寫這種綜述性質的文章是很是耗時的，連續寫4，5個小時還以爲沒有寫到位是很正常的事。然而要說寫完一篇這樣的文章就會有什麼特別的斬獲嗎？要我看，其實也沒多少，但一絲經驗的積累，確實仍是有的。所謂作事要善始善終，既然我已經決定要作一個表率，就必須堅持下去。我在沒有什麼觀衆的狀況下堅持畫畫了那麼久，況且如今所作的事有了幾個同窗、家長、甚至一些素昧謀面的網友的關注。任何一時的懈怠都是致命的。不爲別人，只爲我本身。

mega kill

接前篇，在2011年4月到10月間的MPX項目中我和侯振宇進行了本身的前端業務開發框架的研究與實踐，繼而意識到本身的薄弱和學習別人的重要性。因而在2011年11月開始的robin項目中，咱們將咱們的新思路運用了進去。robin項目是實驗室有史以來最大的項目，是WFS雲存儲系統的2.0版，包含全新的先後臺架構、界面設計、客戶端支持。既然是雲存儲系統，考慮到對外接口的問題，那麼後端必然是得采用咱們已經屢次實踐過的restful架構來作，前端必然依舊是包含大量業務邏輯的重型前端。吸收了以前項目中自制的前端業務框架的經驗教訓，咱們此次選擇了多種開源框架和類庫一塊兒完成整個架構：sea.js作前端模塊調度、underscore作前端模板、backbone來規範數據層和作數據與視圖的綁定（前端MVC）、jquery作底層輔助類庫，除此以外還稍微用了點flot.js、uploadify之類的功能類庫作相應的功能。

因而，項目的目錄大概像這個樣子：每一個模塊文件夾中都包含其所屬的js/css/html，全部模塊平級存放。還有一個系統模塊，它包含全部必需包含的主要類庫和框架，以及負責總調度的業務邏輯main.js。

 

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

--app |--system_module | |--main.js | |--thirdparty_js | | |--jquery | | |--backbone | | |--underscore | | |--sea | |--css |--moduleA | |--js | |--css |--moduleB | |--js | |--css

這套機制一開始運行的很好。2011年10月立項，11月開工，1月中旬演示版就出來了，整個設計+代碼開發工做只花了不到3個月的時間就完成了預約的功能。值得一提的是，backbone並非從一開始就加入的，而是11月下旬代碼開發了一小半的時候才加入的。當時這類的前端MVC框架並不止backbone一種，可是當咱們完成了原型後，意識到必須用一個框架來規範數據測層和作數據與視圖的綁定時，backbone小巧精悍的特質吸引了咱們，可讓咱們很容易地把它加入到原型中且少作傷筋動骨的改變。此外，backbone捆綁銷售的underscore實在是太好用了，甚至讓我往後以爲它比backbone要強悍的多。雖然如今隨着前端的大發展，Underscore的競爭對手愈來愈多愈來愈強大（好比lazy.js 和Lo-Dash），可是我依然對下劃線抱有敢情。

的確，選擇和學習這些框架都要成本，但這都值得。全部這一切都讓前端變得重要起來。前端不只體積愈來愈大，功能也愈來愈豐富，作了不少原來後臺腳本語言才作的事。其實MVC、數據與視圖綁定之類的東西，後端早玩爛了。現在，做爲前端開發者，愈來愈須要瞭解後端的知識；同時，後臺程序員也須要知道前端的基礎——分爲了兩個工種是爲了更有效率，而互相學習則是爲了進一步提升。我想將來一個前端工程師若是不知道設計模式之類的東西，確定只能在低層次的角色裏混。

unstopedable

robin項目一開始其實運行的還好，截止2012年1月咱們你們都還很滿意。可是自從2012年3月之後，狀況就不一樣了。但在不斷地新加需求和修改bug中，系統原有的架構變得愈來愈混亂。這不只體如今後臺愈來愈多功能大同小異的API接口上，也反映在前端愈來愈混亂的目錄層次上。咱們的系統從一開始就不是一個能經受起不斷變化的需求的架構，並且就以實驗室的學生而言，精力也不容許咱們在不斷知足新需求的同時再進行重構。老闆們都等着你趕忙提交新功能呢，結果你2個禮拜什麼新功能都沒作，就跟老闆說你把代碼重構了讓結構更清晰云云，放在大公司人多也就罷了，一個實驗室就這麼兩個能幹活的人你給我說這個？！問題就積累的下來，但此乃人力之所限，不得已而爲之。

就拿上面提到的這個前端文件目錄來講吧，這種主從式的結構一開始看似還行，可是隨着新功能的不斷加入，就會有愈來愈多的第三方類庫引入。例如一個顯示樹形列表的treejs庫，你是放在system_module裏面仍是單獨做爲一個平級module來存放？既然treejs不是哪裏都要用，那就做爲平級module存放吧。最後結果，就是平級module愈來愈多，第三方類庫的module與功能邏輯module混在一塊兒，什麼小蝦小魚甚至沒用的module都在一塊兒，你還不敢刪，誰知道刪了會不會出錯？因此，不得不說以前的目錄結構並不是一個好的目錄結構。如今我推薦的改進目錄結構是下面這個樣子：

 

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16

--src    |--lib(thirdParty)    |   |--moduleA    |   |    |--js    |   |    |--css    |   |    |--subModuleC    |   |    |   |--moduleB    |      |--common    |   |--moduleC    |   |--moduleD    |-system    |   |--moduleE    |   |--moduleF    |   |--moduleG

這種目錄結構將第三方模塊和通用模塊、邏輯模塊劃分開，每類中再建子模塊。其實這就是典型的服務器端框架目錄劃分。這種目錄結構適合在開發時使用，在部署的時候經過grunt等工具將css,js分別打包壓縮分裝到指定目錄（一般另建build目錄）。第三方模塊最好不要直接使用，而是將其中有用的模塊用grunt打包壓縮到common下的指定目錄去調用，這樣能夠避免第三方代碼升級、修改第三方代碼等問題帶來的錯誤；同時經過邏輯模塊中入口函數的調用參數的不一樣，很容易直到哪一個是沒人要的小魚小蝦，能夠或刪或改。經過gruntjs也能夠很容易地分塊測試邏輯模塊。若是項目比較小，則能夠化簡一些，放大common模塊的包含範圍，不作src目錄和build目錄的區分便可。總而言之，這就是一個典型的前端學習後臺進行目錄劃分的例子。

不過遺憾的是我沒有時間和精力來把robin這麼重構一遍了。只但願下個項目能儘可能好一些。（哈，那時候我還會寫代碼嗎，個人本職是寫論文呀~）

《軟件工程》一書一開始就指出，軟件生命週期中最重要的階段是設計、編碼、測試和維護，其中維護要佔1半以上的時間。我當時不理解，如今徹底理解了。robin往後的維護從2012年3月一直持續到如今。新功能加了3次，各類定製版作了5回。可知折騰一個易於擴充易於修改的架構多麼重要！

wicked sick

2012年9月底，我去新浪雲事業部實習。每週在那邊作三天，回實驗室作2天。一開始也就作些小魚小蝦的活，後來越作越多，臨走前幾周更提了一個建議：前臺採用angularjs做爲開發框架。他們很快就接受了。由於他們也想作restful的總體架構，也須要前端有高效率的開發模式。

angularjs其實2012年4月我就開始用了，是侯振宇憑着本身對技術的敏感先發現而後推薦給個人。這跟咱們使用backbone時候的種種不爽有關。雖然backbone小巧強悍，可是用它寫的代碼，仍是少不了jquery等的配合，數據層和視圖層之間的交互仍是比較複雜。而2012年剛好是前端框架大爆發的一年，各路諸侯爭先發布和升級了各類前端開發框架，而且batman.js, angular.js, ember.js , knockout.js等等，無一不與數據層和視圖層之間的交互有關。MVVM架構成了時髦——我無心比較這些框架的好壞，我以前不少篇文章都有講過了（前端框架的總結與推薦）。但我得說，這MVVM的框架用起來實在太舒服了，以致於一用它我就把backbone扔到腦後不再想了。以致於從那時起我成了angularjs的堅決支持者。2012年11月到2013年1月我寫了很多angularjs的代碼。這段時間侯總也從後端轉向了前端（我認識的不少後端程序員如今都很喜歡搞前端了，這是爲毛？），他還幫助angularjs社區翻譯angularjs的開發指南。後來侯總跟着我新浪實習所在的部門的人一塊兒去搞創業公司unitedstack去了。一開始用得就是angularjs，直到2013年7月份換成avalon.js（他們真的很能折騰，很能重構，創業公司跟大學實驗室區別太大了）。

monster kill

2013年3月到5月我蟄伏了一段時間考博。考完了之後一切生活依舊。不一樣的是我有幸主導了實驗室新項目park的開發。該項目從產品層次來講是個典型的CRUD應用，故而我絕不猶豫地採用了grunt + boilerplate + angularjs + bootstrap + D3 + requirejs 的架構來實現它。原本我還想更激進一些，打算用nodejs作後端，搞express+nodejs+angularjs+mongoDB這麼一套時髦的玩意。可是開發產品歷來不是什麼技術新就用什麼，一般是新技術與舊基礎之間的妥協。畢竟實驗室的人員不是創業公司的員工，沒有那麼大的能力和精力來實踐一套沒用過的玩意。新技術一開始都要趟地雷的，沒那個精力就別折騰。考慮到實驗室傳統上後臺仍是用php+mysql的方案，那麼仍是用老方案來吧。前端用angularjs. 新項目從2013年7月開始作，作到10月一期基本完成。仍是restful架構，後臺用php開發框架codeigniter,前端以angularjs爲主。前端的相關內容，我已發4篇angularjs項目實戰的文章來說了。故而這裏不作贅述。期間發現angularjs上手很快，但精通很難。事實上，它不適合js基礎較爲薄弱的人（例如把本身定位爲修頁面的前端工程師），反卻是後臺程序員學它很快。期間種種，再撰文吧。

事實上，自2012年起，這前端就一直風起雲涌，大量開發框架、設計思想層出不窮。nodejs更是包打天下，php能幹的，我JS也全能幹，還乾的更多。讓人以爲前端大有可爲。我就想用js從頭打到尾，用express+nodejs+angularjs就是實現這個理想的現成方案。除了這個方案，還有meteorjs這樣的一站式先後臺解決方案。我擦，ruby on rails的飯碗都要被搶啦！這有篇老外的文章：Why Meteor will kill Ruby on Rails 你們能夠略做一觀。

最後關於meteor,  這裏引用一下侯總對meteor的介紹：Meteor是一個基於nodejs、webSocket、mongoDB的總體開發框架，在它的實現中，先後端的數據模型已經幾乎沒有差異。前端對數據模型進行任何改動，只要調用「save」方法，全部數據就自動存到服務器端的mongoDB中了——終於能夠忘了主動發送請求給服務器，終於能夠忘了服務器要和前端實現幾乎同樣的數據模型層。而任何前端「訂閱的」後端數據出現改動，前端數據模型也會立刻自動獲得了更新——終於能夠忘了主動輪詢，終於能夠忘了拿到後端數據再解析成前端模型。除了先後端模型的雙向自動綁定，Meteor同時還實現了數據到前端模板的自動更新。 不過，Meteor的模板在處理視圖到模型的改動時擴展性不如AngularJS。所以，將AngularJS和meteor結合是最好的選擇。到這裏，快速Web開發模型終於完成：

 

新技術老是層出不窮，要遇上必須保持一顆永不磨滅的好奇心。哪怕是之後不作前端開發，咱們已經享受了求知的過程。就像下面這個圖同樣，這就是人生。