Node.js之絕對選擇(2018版)
【這篇是很早期的文字，由于引用較廣泛，擔心誤導，故按照現在的情形做一些修改】
幾年前，完全放棄Asp.net，徹底脫離微軟方向。Web開發，在公司團隊中，一概使用Node.js、Mongodb、Git，替換Asp.net mvc、Sql server和Tfs。當時來看，這是高風險的決定。所有人都習慣了Asp.net，知識和技術積累也集中在這個方向。
表面看來，僅僅是我個人對多年跟從微軟的厭煩，導致整個技術路線嘎然而止，從技術角度而言，團隊由此南轅北轍。幾年過去，各種辛苦和折騰，間或的彼此抱怨之后，我們終于天經地義的，習慣了新的方向，沒有人再有回到Asp.net的意思，恍若隔世，但...一定要比較，今天顯然更為輕松。
當然，最初并非一切順暢，每個選擇，每一方都是王婆婆，她的瓜絕對是舉世無雙滴。面對諸多王婆的時候，我們也很難得到客觀的比較，選擇往往需要自己來做。經過兩個項目，才真正讓一切順暢起來。其中所涉的編程方式、各類細節甚至由此引發的不同設計思維，很明顯經歷了多處的反復。這個沒有辦法，node.js相對較新，大規模在一些公司應用的情形并不多，這類文字當然也稀少，我們很難找到其他人歸納的常規的團隊開發模式。
我簡單的描述一下，對于以Node.js為主的公司，嗯，僅僅局限于中小型公司...或許有一定的幫助，少走些彎路。我們最終的選擇是
1、IDE：Webstorm，沒有其他。
visual studio code
2、版本管理系統：Git，獨一無二。
3、單元測試：jsamine，前后端共用。
jest
4、前端框架：Angular.js，讓ember.js和幾個老牌的框架性感的躺在床上吧。
react，最近五年的前端霸主
5、服務端：純靜態頁面+極少使用Jade+REST
單頁面應用，不需要JADE之類
6、socket.io+獨立小模塊：當然，這幾乎是唯一可選的與客戶端雙向通信的方式。但一定要注意，多數情形下，我們只有很少的機會需要服務端推送，將這部分內容作為獨立的小應用，是非常省事的做法。
7、異步流程控制：Promise是唯一選擇，而且從一開始就要強制使用，絕不可忽略，這關系到設計思維的巨大差異，甚至關系到我們是否真正能夠在node.js方向堅持下來。我們用Q.js，和前端Angular.js使用的微縮版Q.js保持一致，減少學習周期。
es2016的async/await
8、前后端共用代碼：只要前端有可能用到的代碼，必須以符合規范的方式，做到前后端共用。
我知道多數的多數的，還是多數的技術文章，說話都是不極端的、中庸的，在肯定一到兩個選擇的時候，也會認同其他的選擇，嗯，這固然是很成熟的文風，很厚道的人格。我呢，只會極端的就每個選擇給出唯一的答案。
不是因為我性情不成熟，嗯，好歹我也算是超級資深的架構師、高級程序員、過程管理大半個專家...啊，還有沒有其他的光環和帽子可戴？
既然我們在集中選擇中左右碰撞后，得出了結論，我們的選擇就是唯一的...多數情況下，您看到這篇隨手的文字，就不再需要將這個痛苦的過程，重復一遍。我覺的這是真正的厚道...那么多客氣干嘛？噢，這可能有點"你們不用思考，元首都幫你們思考過了"的意思，這點不好...我在下面將幾種主要選擇的理由，列出來...以避免從天而降的、聚合成團隊的板磚。
一、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集成、單元測試框架的集成....
嗯，一切之外的選擇變成了浮云。
二、版本管理系統：Git
選擇Git，最初是因為Tfs不再可用，我們已經告別了偉大的Visual Studio 20XX。那么...風評最好的，顯然是Git，GitHub已經成長到讓其他的開源社區瞠目結舌的地步，甚至Tfs也不得不支持Git。這不免太庸俗：人人一邊倒的說一個東西好，這東西就是好。
但是，但是那個但是...這東西用起來比Tfs麻煩許多噢，我們都不算是喜歡一個個敲命令的人吧？我本人率先使用，然后培訓其他人，先行的過程雖然持續三天...但是：
1、分布式確實是最人性的做法：不再需要家中和公司服務器同步來同步去，不在同一城市也不再是問題。
2、分支成為主要的思維...前提是合并、沖突驚人的簡易。
3、最為欣喜的是，結合WebStorm，幾乎達到了VS中使用Tfs的效果，我們已經有幾年不再手工輸入命令了。
那么，你還需要考慮別的？
三、單元測試：Jasmine
這個選擇，純粹是由于我天生的懶惰。 前端Angular.js，單元測試用karma...jasmine，我開始嘗試在服務端使用jsmine，到解決了與ide集成、Promise測試之后，我們還需要用不同的方式來做單元測試嗎？
四、異步流程控制：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了。
五、前端框架：Angular.js
前端框架，近年如同地下世界的老鼠，數量十分龐大。
Angular.js、微軟的Knockout、某人推崇為第一的ember.js....等等等等。
我測試過多種之后，選擇angular.js，這是入門簡易，但學習曲線陡峭的框架。理由：我比較后，發現angular.js的代碼量比多數的框架，精簡許多，在理想和現實中折中得相當平衡。結合REST，我們幾乎可以方便的制作全靜態的應用，當然，每個地方都是無刷新的。
沒有草稿，隨手而寫，好象也沒有什么修改。其他的幾個選擇，相對而言更好理解一些，不羅嗦。使用mongodb或許是一個錯誤...不支持事務，是個很要命的問題。但也堅持很久了...我們的團隊，始終是不能回避nosql的，而nosql的第一選擇，目前仍然是mongodb，至少從思維方面，大家目前已經非常熟悉和習慣。node.js真正的在企業中作為主力方向，國內估計并不太多，很多資料匱乏。我建了119874409群，歡迎諸位同好交流。
node.js的年齡，已經十歲，似乎并不容易成為真正的主流之一，但我本人，仍然很看好今后的發展，考慮到其輕松跨平臺、獨特的異步模式、與C++天然的親和，甚至在桌面開發、安卓平臺上的一些嘗試，node.js極可能成為重要的技術方向之一。
浙公網安備 33010602011771號