Node.js之絕對選擇(2018版)

   【這篇是很早期的文字，因爲引用較普遍，擔憂誤導，故按照如今的情形作一些修改】

    幾年前，徹底放棄Asp.net，完全脫離微軟方向。Web開發，在公司團隊中，一律使用Node.js、Mongodb、Git，替換Asp.net mvc、Sql server和Tfs。當時來看，這是高風險的決定。全部人都習慣了Asp.net，知識和技術積累也集中在這個方向。

    表面看來，僅僅是我我的對多年跟從微軟的厭煩，致使整個技術路線嘎然而止，從技術角度而言，團隊由此南轅北轍。幾年過去，各類辛苦和折騰，間或的彼此抱怨以後，咱們終於天經地義的，習慣了新的方向，沒有人再有回到Asp.net的意思，恍若隔世，但...必定要比較，今天顯然更爲輕鬆。 

    固然，最初並不是一切順暢，每一個選擇，每一方都是王婆婆，她的瓜絕對是舉世無雙滴。面對諸多王婆的時候，咱們也很可貴到客觀的比較，選擇每每須要本身來作。通過兩個項目，才真正讓一切順暢起來。其中所涉的編程方式、各種細節甚至由此引起的不一樣設計思惟，很明顯經歷了多處的反覆。這個沒有辦法，node.js相對較新，大規模在一些公司應用的情形並很少，這類文字固然也稀少，咱們很難找到其餘人概括的常規的團隊開發模式。

    我簡單的描述一下，對於以Node.js爲主的公司，嗯，僅僅侷限於中小型公司...或許有必定的幫助，少走些彎路。咱們最終的選擇是

    一、IDE：Webstorm，沒有其餘。

         visual studio code

    二、版本管理系統：Git，獨一無二。

    三、單元測試：jsamine，先後端共用。

          jest

    四、前端框架：Angular.js，讓ember.js和幾個老牌的框架性感的躺在牀上吧。

         react，最近五年的前端霸主

    五、服務端：純靜態頁面+極少使用Jade+REST

         單頁面應用，不須要JADE之類

    六、socket.io+獨立小模塊：固然，這幾乎是惟一可選的與客戶端雙向通訊的方式。但必定要注意，多數情形下，咱們只有不多的機會須要服務端推送，將這部份內容做爲獨立的小應用，是很是省事的作法。

    七、異步流程控制：Promise是惟一選擇，並且從一開始就要強制使用，毫不可忽略，這關係到設計思惟的巨大差別，甚相當繫到咱們是否真正可以在node.js方向堅持下來。咱們用Q.js，和前端Angular.js使用的微縮版Q.js保持一致，減小學習週期。

         es2016的async/await

    八、先後端共用代碼：只要前端有可能用到的代碼，必須以符合規範的方式，作到先後端共用。

 

    我知道多數的多數的，仍是多數的技術文章，說話都是不極端的、中庸的，在確定一到兩個選擇的時候，也會認同其餘的選擇，嗯，這當然是很成熟的文風，很厚道的人格。我呢，只會極端的就每一個選擇給出惟一的答案。

    不是由於我性情不成熟，嗯，好歹我也算是超級資深的架構師、高級程序員、過程管理大半個專家...啊，還有沒有其餘的光環和帽子可戴？

    既然咱們在集中選擇中左右碰撞後，得出告終論，咱們的選擇就是惟一的...多數狀況下，您看到這篇隨手的文字，就再也不須要將這個痛苦的過程，重複一遍。我覺的這是真正的厚道...那麼多客氣幹嗎？噢，這可能有點"大家不用思考，元首都幫大家思考過了"的意思，這點很差...我在下面將幾種主要選擇的理由，列出來...以免從天而降的、聚合成團隊的板磚。

1、IDE的選擇：WebStorm

    咱們最初遇到的問題，是語言，C#轉到js。 固然，這個事實上不是太大的問題，Asp.net方向的團隊，基本上每一個人都有相關語法知識。尤爲開心的是，node.js，在後端開發，不須要如前端開發通常，考慮瀏覽器差別。最初你們的共識是很簡單的思惟：js+node系統庫+諸多可選的包=C#+.net framework。額，固然，整個node.js佔據的空間大約只有十來兆，IIS和.net framework加起來是多少？幾十倍的體積差異，即便二者旗鼓至關，是否是該鄙視下，那過於吝嗇硬盤的一方？

    固然，要開始，第一個問題是IDE。最初，我一我的左右折騰，使用Visual studio+iisnode+Tfs，各類不便。1周後轉到Webmetrix，3天后灰溜溜的放棄。而後各類ide象流水般的試試...WebStorm最初也被排斥。

   在一個月黑風高的深夜，一雙迷茫的眼睛，盯着天花板。

   我從新撿起WebStorm，更精細的一步步嘗試它所宣稱的各種特性。語法自動感知、node.js的調試、Git集成、單元測試框架的集成....

   嗯，一切以外的選擇變成了浮雲。

 

2、版本管理系統：Git

   選擇Git，最初是由於Tfs再也不可用，咱們已經告別了偉大的Visual Studio 20XX。那麼...風評最好的，顯然是Git，GitHub已經成長到讓其餘的開源社區瞠目結舌的地步，甚至Tfs也不得不支持Git。這難免太庸俗：人人一邊倒的說一個東西好，這東西就是好。 

   可是，可是那個可是...這東西用起來比Tfs麻煩許多噢，咱們都不算是喜歡一個個敲命令的人吧？我本人率先使用，而後培訓其餘人，先行的過程雖然持續三天...可是：

   一、分佈式確實是最人性的作法：再也不須要家中和公司服務器同步來同步去，不在同一城市也再也不是問題。

   二、分支成爲主要的思惟...前提是合併、衝突驚人的簡易。

   三、最爲欣喜的是，結合WebStorm，幾乎達到了VS中使用Tfs的效果，咱們已經有幾年再也不手工輸入命令了。 

    那麼，你還須要考慮別的？

 

3、單元測試：Jasmine

    這個選擇，純粹是因爲我天生的懶惰。 前端Angular.js，單元測試用karma...jasmine，我開始嘗試在服務端使用jsmine，到解決了與ide集成、Promise測試以後，咱們還須要用不一樣的方式來作單元測試嗎？

 

4、異步流程控制：Promise,Q.js

    茴香豆的茴，有N種寫法。因此，專家告訴咱們，處理異步流程，除了回調函數方式外，還有事件方式、訂閱發佈模式、Promise。個人答案只有一個，Promise,in Q.js。 在咱們第一個項目中，咱們避免使用太多第三方庫，全部異步流程的處理，均老老實實的用嵌套得暈死的回調函數處理。這個，雖然折磨了你們，但很明顯是每一個人能夠快速的理解、快速作到的。不過，第一個項目中，遇到有十幾個步驟的複雜計算的時候，層層嵌套幾乎令咱們團隊出現一位精神失常者...爲了不家長打上門來，老將出馬...我用了一個通宵，在async.js(一個幾乎居壟斷地位的異步流程庫)、Q.js以及其餘一些方式中徜徉。

    很慚愧的說，Promise的理解看似輕鬆，但在兩個小時的時間裏，我發覺本身很難真正的理解，這是不多見的事情，我照着鏡子，看着那一貫自覺得性能不錯的人類腦殼，沮喪的嘆息。在項目進度的壓力下，我選擇了async.js...

    以後的空閒時間，我終於通過兩次波折，完全的理解Promise的概念、使用的細節。在第二個項目開始以前，我用2天的時間在團隊傳播，並訂下了很是不近人情的編程規範：本項目不容許出現回調函數方式、不容許使用async、只准使用Q.js Promise。全部不符合此規範的代碼將被退回，全部於此有關的問題我會隨時解答。

    緣由是什麼？若是沒有Promise，node.js的編程將是一個異常枯燥、乏味、不可靠、江湖風格的苦差。我上升到這個高度，估計會面對有一千個番茄加兩千個雞蛋，但，信者得永生。扁平的流程處理，統一的編程模式，鏈式的編程風格，無與倫比的異常處理。async.js實現的異步流程，全部的代碼是相關的。Promise則能夠作到各步驟全不相關，嗯，想到了最基本的"封裝"了吧？這就是全部的理由，之因此選擇Q，也是下降學習的難度---咱們在angular.,js前端，已經模糊的使用微縮版的q.js了。

5、前端框架：Angular.js

    前端框架，近年如同地下世界的老鼠，數量十分龐大。

    Angular.js、微軟的Knockout、某人推崇爲第一的ember.js....等等等等。

    我測試過多種以後，選擇angular.js，這是入門簡易，但學習曲線陡峭的框架。理由：我比較後，發現angular.js的代碼量比多數的框架，精簡許多，在理想和現實中折中得至關平衡。結合REST，咱們幾乎能夠方便的製做全靜態的應用，固然，每一個地方都是無刷新的。

 

    沒有草稿，隨手而寫，好象也沒有什麼修改。其餘的幾個選擇，相對而言更好理解一些，不羅嗦。使用mongodb或許是一個錯誤...不支持事務，是個很要命的問題。但也堅持好久了...咱們的團隊，始終是不能迴避nosql的，而nosql的第一選擇，目前仍然是mongodb，至少從思惟方面，你們目前已經很是熟悉和習慣。node.js真正的在企業中做爲主力方向，國內估計並不太多，不少資料匱乏。我建了119874409羣，歡迎諸位同好交流。

    node.js的年齡，已經十歲，彷佛並不容易成爲真正的主流之一，但我本人，仍然很看好從此的發展，考慮到其輕鬆跨平臺、獨特的異步模式、與C++自然的親和，甚至在桌面開發、安卓平臺上的一些嘗試，node.js很可能成爲重要的技術方向之一。