【這篇是很早期的文字，由於引用較廣泛，擔心誤導，故按照現在的情形做一些修改】
幾年前，完全放棄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極可能成為重要的技術方向之一。