此文 3 年前撰寫，內容比較保守落後，參考價值有限，轉載至此作紀念，大家可以加 Scott 微信: codingdream 成為朋友圈的朋友，聊南聊北，哈哈哈。
前言
大家好，我是 Scott，2016 年 9 月 25 日在杭州大搜車總部舉行的杭州 Node Party 上分享了一個話題 - 《創業公司擼 Node》 ，分享之後我以文字的形式又記錄了一遍，分享給沒有與會的朋友，也方便大家通過搜尋引擎者一些技術社群平臺來看到這篇文章。
寫在前面，感謝芋頭哥和大搜車，給了我這個機會跟大家在大搜車面基，說實話，從我出道以來，這還真的是我第一次正式在公開場合裝逼，尤其是當著這麼多大牛大咖的面兒裝逼。
某天當你進入創業團隊
今天跟大家分享的話題是，現階段下創業團隊中對於 Nodejs 工程師的認可程度，以及如果有一天你進入了創業團隊，在做技術選型的時候，基於什麼標準來判斷，要不要使用 Nodejs 開發，以及如何跟進技術的演變。
我特意加了前端逆襲這個小標題，是為了在我們們現場做個小調查，請從前和現在做過前端開發的的同學舉一下手好麼，看看多少人搞了前端現在也在搞 Node。現場舉手的超過一半人數，前端這個職業真的是屌爆了。
我的職業轉型
ok，首先做一個自我介紹，我跟大家一樣，從前也是一名前端工程師，從 2010 開始，在阿里媽媽做了四年前端，後期做了不少廣告投放相關的前端頁面，跟後端的創意投放管理系統對接，製作和優化廣告效果模板等等，大家如果去上 Youku, 微博，各種電影小說新聞媒體網站，應該會有印象曾看過這樣滿屏滾來滾去的淘寶豆腐塊廣告。
哈哈，很不好意思，2014 年以前，你在全網看到的差不多有 70% 的豆腐塊廣告都是我做的，你在淘寶搜了鮮花啊，內褲啊，硬碟啊，種子啊，再去訪問其他網站，都能看到豆腐塊裡的類似商品，當時我的工作就是開發這些模板的樣式，優化這些模板的特效，測試在各種終端裝置上的相容性，資料方面需要跟各種演算法引擎團隊約定各種非同步資料格式，業務上需要考慮複雜的引數加密解密二跳透傳，Cookie 的讀取定向等等來落地不同推廣場景下的非同步互動方案，最終基於各種廣告系統接入和投放到目標網站。
所以在最初我仍然是一個很純的前端工程師，後來怎麼就開始折騰 Nodejs 了呢，我們可以看下上圖最右上角的這個輪播圖，它由上下兩部分組成，上面是輪播的商品列表圖，下面是推廣的商品關鍵詞，它倆是兩個獨立的資料介面，而且很可能是隸屬於兩個完全不同的資料引擎團隊，從前端開發的角度呢，我需要發兩次請求來分別獲取和控制這兩個資料介面的展現，而從後臺開發的角度看，兩個介面最好相對獨立，互不影響，因此我們前端工程師，儘管很希望將兩個介面合併成為一個介面，卻很難推動後端工程師團隊為我們這樣某一個模板，專門開發一個介面出來，由這個介面統一獲取兩個介面資料合併後再交給前端展現，於是我們就很難從至少是請求個數這個層面，來優化這個廣告的展現速度和展現完整度，有時候是圖片先出來，有時候是關鍵詞先出來，如果等待同時出來，萬一某一個介面掛了怎麼辦，這時候再等待超時以後去獲取打底的介面或者類似介面，使用者早就離開了。
但是這樣一個模板在全網的每天為阿里帶來的收益，是非常巨量的，而它的生命週期也許只有 2 周，2 個月就撤下去換別的模板了，所以從維護的角度上，後端工程師的確也很難及時跟進前端和產品層面頻繁的改動，而從收益方面，就需要跟後端工程師努力的溝通解釋，非常費勁，協作成本居高不下。
但是現在有了 Nodejs 後，我們設想一下，如果把 Node 作為介面這一層，由它來決定呼叫哪幾個介面，合併哪幾個介面，哪些介面使用哪些打底資料，是不是這樣的場景就迎刃而解了呢，關於這個我就不再探討了，可能會涉及到公司保密協議，因為我後來從阿里離職出來創業了。
創業以後，開始了我的職業轉型，這近 3 年時間，我一直在創業公司用 Nodejs 開發產品，我也就從一個標準的前端開發工程師逐步切換為一個會使用 Nodejs 的開發工程師，中間費了不少力氣，想了解我的技術成長路線的，可以看上一篇文章 - 4 年前端狗，2 年 CTO，進入一個新的 領域，作為新人是要踩很多坑的，有的是有必要踩，有的沒必要踩，我就把自己的一些心得整理做成視訊，放到了慕課網上。
地址見這裡：www.imooc.com/u/108492/co…
如果是剛入行的新人可以去看看，裡面知識點也許有點陳舊，講解也未必很嚴謹，可以選擇性的理解流程和專案思路。
那麼現在，我是 CampusRoom 這個網站的技術負責人，大家可能都沒聽過 CampusRoom, 沒關係，估計部分同學聽說過 Moveha，創業這幾年中，無論是 CampusRoom，Moveha，還是微信服務號，包括其他的一些內部的外部的，做了沒上線，上線了又下線的大小專案，統統都是用 Nodejs 來搭建的，整個創業團隊也充分體驗到了使用 Nodejs 建站或者啟動一個專案時候敏捷所帶來的高效率，其中有一個小案例，近幾年，一些歐美國家不是太安全，我們為了讓學生和家長能對當地的居住環境有一個安全方面的瞭解，就用 Nodejs 很快速的搭建了一個爬蟲小系統，爬取一些州和城市的警署犯罪資料，然後合理的分類和評級打分後，給出一個資料視覺化的效果，這個功能的產品價值可能是很大的，然而實現成本是非常非常小的，效果見下圖：
市場對於 Nodejs 工程師的需求
以上都是從我自身，從我們公司來來感受 Nodejs 的開發效率和對公司的價值，但是整個業界對於 Nodejs 的態度又是怎樣的呢，他們的接受度又是如何呢，我們再舉個例子，大家可能看到過 CNode 論壇上的這個招聘貼，我截圖了有讚的和大搜車的，最後一個就是我發的，也就是 Moveha 公司的招聘，哦，說一句，Moveha 是 CampusRoom 的前身，CampusRoom 是從 Moveha 孵化出來的，我要說的重點是，我發的這個 Node 工程師招聘貼，是論壇裡最先被加精的招聘帖子，也是閱讀量最高的帖子，現在有 4 萬多個閱讀量，400 多個評論，這個帖子給我帶來了 100 多份簡歷，現在我們公司的所有工程師都是從這個帖子招過來的。
在這個帖子前後 - 2014 年秋季，在論壇或者社群中，很多公司對於 Nodejs 工程師的認知包括他們的價值定位其實是不夠清晰的，從招人的風氣中就能看出來，在我發這個帖子以前的時候，很多公司跑到 CNode 上發帖，都是姿態比較高，一副你愛來不來的樣子，對自己公司團隊文化介紹的三言兩語模稜兩可，薪資區間從來不敢放，自從我發這個帖子之後，逐漸的論壇的招聘貼開始接地氣了開始有誠意了，薪資夠不到 20K 的公司甚至都不好意思上來發帖了，從這件事情上就能反映出工程師社群的結果導向，玩虛的根本不行，結果好市場認同自然容易被人接受，CNode 上面大量的招聘也從側面證明了，這三四年以來，Nodejs 工程師越來越被認可，越來越被重視，一個職位到底含金量高不高，其實不是你說了算，也不是我說了算，而是這個市場說了算。
我們再來看下 indeed 上面統計的職位需求變化的趨勢，第一個圖是 Nodejs 的需求量變化，第二個是 Fullstack 的需求量變化：
這兩個職位，即便是在今天，現在依然處在井噴暴漲的階段，整個市場已經對 Nodejs 工程師有了足夠的認可，所以大家的職業黃金期真的是已經到了，再過兩三年，Nodejs 工程師就會真的遍佈大街小巷各種公司，現在是跟上這個大潮的最佳時期。
那為什麼這麼多公司對 Nodejs 工程師這麼認可呢，特別是中小型團隊，特別是創業團隊，為什麼明明可以選擇 PHP，可以選擇同樣敏捷的 Ruby，可以選擇更加成熟，程式設計師相對更容易招聘的 Java，Python，卻非要費勁巴力的去招聘緊缺的 Nodejs 工程師呢，尤其是具備前端工程師能力的 Nodejs 工程師呢？
答案非常簡單，就是因為利用 Nodejs 開發一個新專案，會非常的高效敏捷，無論從最終的使用者體驗，還是上線後的產品迭代節奏，使用 Nodejs 都有巨大的成本優勢。
而成本對於創業公司來講，是非常敏感的事情，現在市面上成千上萬家嗷嗷待哺的創業公司，其實跟屌絲無異，不是沒錢，就是沒人，沒錢，沒人也就罷了，很多 CEO 還想要有好的使用者體驗，還想要有更短的研發週期，更快的迭代節奏。
說白了，也只有通過這種快速迭代和小步快跑，才能跟同類產品的大公司競爭中拿到時間差優勢，最快的拿到使用者反饋和市場反應，最終才能在競爭中和夾縫中殺出一條血路，現實的確是如此殘酷。快速的推出產品，熬過最艱難的階段，找準了產品的盈利點，抓住了目標使用者群，有了可以拿到桌面上的各種資料，自然更有優勢融資，那時候再去改進優化技術棧甚至更換開發語言也完全有足夠的緩衝餘地。
所以我們 Nodejs 工程師的核心價值，尤其對於創業公司，就是能夠快速產出，迭代的速度更快，前端後端可以通吃，為創業公司節省巨大的人力成本，這就是為什麼在市場上，Nodejs 這麼受歡迎的原因，創業公司選擇我們，不僅因為它能最快速的滿足初創團隊的場景，也是因為 Javascript 也是唯一的能跨越前後端，用一種語言搞定產品實現的選擇了，關於 Nodejs 的適用場景，它的優勢劣勢，它的開發和維護成本，相信大家做了這麼久都有自己的見解，不再過多贅述，我們且往下看。
究竟什麼樣的創業專案，比較適合 Nodejs 呢，或者說， Nodejs 作為創業團隊立項時候所考慮的技術選型，有它適用的邊界麼，如果有，邊界在哪裡，有哪些衡量的標準。如果在創業公司，我們需要確定用 Nodejs 開啟一個專案，那麼以怎樣的標準，或者說怎樣的準則來衡量， Nodejs 怎麼用，框架怎麼選，版本如何跟進呢？
太多的問號在腦海中迴盪，我個人認為，可以簡化為如下三個問題，就能解決從決策到執行的流程：
一、要不要用 Nodejs
首先第一個，什麼樣的創業專案，適合用 Nodejs，哪些又不適合用，我們從這三個因素來衡量：
1. 期望的迭代節奏
任何一個產品，立項之初，都有它特殊的商業背景和商業目標，在這個背景和目標下，會給予對它的一些期望，希望它以怎樣形式，多長時間開發上線，上線後，以多長的週期進行版本的更新迭代，這些都很好理解，如果是一個展示型的，扔上去不需要怎樣去增加功能，也不需要多麼頻繁的改版升級，那麼就沒必要一定要使用 Nodejs，用 PHP，Ruby 統統沒問題。
2. 團隊工程師能力
我們知道，就像這世界的大部分事物一樣，工程師的能力也是大概符合正態分佈，除去特別弱的，比如 3 年前的我，除去特別強的，大部分工程師其實都處在中間的這個地帶，就像現在的我，對於 Nodejs 及周邊生態的掌握可能比較好，但不是特別特別好，而 Nodejs 又是一個新的職業方向，火熱的市場上根本沒有足夠時間來沉澱，於是大部分的創業團隊是並沒有足夠資深的 Nodejs 工程師，這意味著我們在快速開發的時候，往往也面臨著更高的業務風險，一旦 Nodejs 用的姿勢不對或者技術選型失誤，會給業務帶來災難性的打擊。
這一點其實被很多公司所忽視，整個團隊在當下與未來半年的一個規模，團隊成員的技術背景，自我學習的能力，對於新技術升級的接受程度，如果是不能很好的駕馭 Nodejs 而且自學能力又偏弱的話，就需要慎重考慮一下。
3. 跟產品的匹配程度
其實創業類的產品，往往很少有上來就規模化，高難度的，所以許多型別都適合，我們與其想那些可以用 Nodejs 開發，不如反過來看，那些型別的不太適合用 Nodejs 開發，排除掉這些場景，剩下的都可以評估一下用 Nodejs 是不是可以。
我這裡羅列了幾種，其實大家照著這個方向走，未必只有這 4 點：
- 極高併發數
- 密集 CPU 運算
- 高安全高可靠性
- 記憶體精密控制及釋放
併發數本來是 Nodejs 的強項，高吞吐量，但是如果上來就是要應對爆發式井噴的場景，需要堆機器的時候，顯然這些非 Nodejs 領域內軟實力會過度消耗工程師的時間成本，這一點一旦工程師的學習能力跟不上來，就會反過來制約業務的發展，如果非要給一個數字的話，可以以 10 萬作為一個衡量點，併發大於 10 萬的，都要慎重評估一下。
而對於大迴圈的資料結構，需要長時間的運算的，對 CPU 強依賴，導致時間片釋放遲緩的場景就儘量不要用 Nodejs 來做，可以交給 Scala，可以交給 Go，甚至可以交給 Java 和 C++ 來做。
舉一個例子，比如有旅遊路線的實時計算，對使用者的出行路線進行推薦，需要基於多維度不同權重的因子進行演算法推演，考慮進去使用者的性別，喜好，預算，期望的出行方式，天氣，當地景點的分佈，目的地有沒有類似 G20 的大會等等各種因素，背後則可能依靠一些大資料做支撐，這時候使用者不可能等待太久，而是希望馬上拿到路線報告，這些場景下我們處於中段能力值附近的工程師就不要逞強，避免使用 Nodejs。
安全可靠也同理，一些支付或者銀行對接從場景，服務的穩定性非常之高，不能有任何可能異常導致的程式掛起，引起資料不一致，這種如果其他語言已經具備很好的線上解決方案的話，那麼 Nodejs 就可以只做它擅長的方面，把這些交給其他更專業的技術來實現，Nodejs 只呼叫介面就行。
一個專案做大了之後，程式碼中會有更多的隱患或者風險，一個疏忽就可能導致記憶體洩露，而如果業務層面是對記憶體非常敏感的，由於記憶體使用不精細導致對外的服務質量不平穩，這些都是業務不能接受的，那麼這樣的場景也要慎重權衡一下。
其實，考慮到創業團隊特定的起步方式，不平衡的工程師能力，產品迭代的節奏，只要是一些略苛刻的場景，都應該要多思考一下，用 Nodejs 除了效率，能帶來的價值能否高過帶來的挑戰和風險，如果答案是否定的，我們就要慎重使用 Nodejs。
我們始終需要去找到一個在工程師能力，Nodejs 滿足和匹配業務的程度，以及公司的產品節奏之間找到這個平衡點，而且這個平衡點會隨著業務的膨脹，團隊的成長而不斷的變化，在變化之中我們需要不斷的評估，去反思。
那麼我們回到產品本身，一旦我們排除掉這些場景以後，我們就可以大膽使用 Nodejs 了，或者說，不是我們，而是更多已經大力度投入到 Nodejs 陣營中的先驅者和執行者們，比如下圖：
太多全球的大公司，已經在使用 Nodejs 了，就連 微軟這樣印象中比較封閉刻板的軟體帝國，都已經對 Nodejs 有著很大的投入，對開源有很大的包容度，推出了很多 Nodejs 好用的工具和服務，甚至要 Fork 一個 Nodejs 推出新的引擎。
甚至更另類一點的，發射太空任務的 NASA 都要用 Nodejs 來開發一些應用或者是執行一些系統，甚至是 2016 年 Github 上評選的，最受歡迎的專案中，有將近一半都是 Nodejs 相關的專案，或者有用到 Nodejs 做一些構建工作。
總結起來就是一句話，Nodejs 上天入地，剛前剛後，流行只是我們看到的現象，背後是它較低的使用門檻，較小的協作成本，以及更好的開發體驗，和不錯的效能表現。
二、扔掉歷史包袱
雖然有這麼多我們樂於看到的方面，作為一個工程師，我們依然需要謹慎對待，當我們確定使用 Nodejs 以後，如何選擇版本或者語法層面的一些程式設計習慣，畢竟 JS 程式設計始終太靈活，有許多問題大家糾結好多年，而 JS 的快速進化也帶來更多的程式設計方向，站在這個十字路口，往前一步未必是大海，往後一步也未必是懸崖，但是前進總比後退要更能接近未來。
舉一個簡單的例子，讓很多工程師頭痛了很多年的例子，就是 Callback， 這是個老生常談的問題了，不同的團隊不同的專案歷史背景不同的技術風格，顯然對於 Callback 的態度和選擇是不同的，比如芋頭哥在大搜車，對於 Callback 的態度是相對寬容的，因為幾十萬行的歷史程式碼，說實話交給我維護，我也不敢亂來。
那麼我個人的看法呢，Callback 顯然是不爽的，是反人類的，我的觀點是，初創團隊，如果沒有歷史包袱或者歷史包袱不大的話，堅決丟掉，可以直接上 Promise，因為包袱只要背在身上，只會越來越重，越來越不敢扔掉。
如果再激進一些，可以將 Promise 和 Generator Function 混用； 如果再激進一些，就結合 Babel 來使用 async/await;
我們來看一個例子，通過這個搜尋框，輸入學校或者城市，可以搜學校周邊或者城市周邊的房子。
搜尋實現的路徑，我這裡做了最大的簡化，只有兩種，在以後繼續升級的產品形態中，會更加複雜，比如有精確查詢和模糊查詢，有除了城市和學校以外的經緯度直接查詢，有標題查詢，也有郵編號碼查詢等等，他們的搜尋顯然都是非同步的。
那麼這個簡化的例子，第一條路，輸入學校，搜尋學校，拿到學校以後搜尋周邊房源。第二條路，搜尋城市，搜尋到城市以後，搜城市裡面的大學，再搜城市裡面的房源。
由於我們不知道使用者輸入的是學校的型別，還是城市的型別，我們需要兩個都查，以學校的結果為主。
如果用 Callback 的方式開發，很容易就寫出這樣的程式碼，通過巢狀就強行鎖定了搜尋的優先順序，以及併發和非併發的次序，當然每一個非同步查詢都要處理一個後置的錯誤物件判斷，這些錯誤不能進行合併，要分別處理 5 次，有的會中斷流程，有的也許不會，加上如果使用 eslint，這裡的 err 都需要單獨命名，不可以重名，單從維護的角度看，如果以後要調整這裡的搜尋優先順序，就會很頭痛，相信這些事情大家都有遇到過，我們再來看第二段程式碼，這一段我們使用了 Promise 和 Generator Function 結合以後的一個升級版本。
很顯然，這個升級直接就解決了 Callback 的幾個痛點，首先是邏輯可以分拆開來，升級維護更方便，如果先以城市為第一優先順序搜尋，直接把底下程式碼整塊扔上來就行了，另外，錯誤的捕獲可以合併起來，當然也可以做更精細的控制，同時呢，比如搜尋城市大學和城市房源它倆是可以並行的，我們就用 Promise 和 Generator 就能很自然的做到這件事，當然用 callback 也可以集合 eventproxy 或者 async 做流程控制，但是也會進一步引入程式碼的複雜度。
其實只要解決掉 Callback 的問題，我們就已經往前邁了很大很大一步了，因為我們引入了 Promise ，引入了 Generator Function，甚至可以突進到 await 和 async，這意味著底層的 Nodejs 的版本也會有更大的升級，帶來更多程式設計思路的變化。
三、Nodejs 跟進升級
那麼說到 Nodejs 的版本，我的觀點是，我們需要保持對 Nodejs 大版本的跟進，因為站在 2016 年的這個節點上，其實 Nodejs 已經經過了 7 年之癢，後面的日子比前面的幾年要幸福太多了，這個我可以從自身的一些經驗來說下吧：
我從 2013 年開始兼職創業做我們公司的專案，那時候的 Nodejs 版本是 0.8，我一直使用到 2014 年 7 月份，才從 0.8 升級到了 0.10，然後又使用到了 2015 年春節，沒有忍住，從 0.10 升級到了 0.12，一直使用到 2016 年 1 月份，再次升級到了 4.x，現在仍然保持在 4.x 的版本狀態，我經歷了這幾次大的版本週期，感覺是這樣的。
從 0.10 到 0.12 是一個比較大的飛昇，從 0.12 到 4.x 是一個巨大的飛昇 從 4.x 到 6.x 也將是一個巨大的飛昇，當然了， Nodejs 有它特殊的歷史程式，比如 0.10 的版本中，有一個重大的安全漏洞，不升級都不行，在 4.x 推出以前，Nodejs 社群還分出來 io.js 陣營，結結實實的對抗了很長時間，再往後面合併後就正常化了，只要官方推了 LTS 版本，在首個 LTS 版本之後，可以觀望一個月左右，就可以考慮升級了。
當然，在 LTS 版本升級之前的至少 1 個月，我們本地的開發環境，就應該已經切換到了這個大版本了，在我們本地來開發來測試。
升級到 6.x
接下來，我們都會面臨 6.x 版本甚至是即將釋出的 7.x 版本，官方也羅列了一些重大的變化，我談下我覺得需要關注的點。
1. V8 升級到 5.0.x
每一次版本的升級，都不可例外的，會優化提升整體的效能，包括安全方面的增強，文件的完善，測試用例的覆蓋，但是都沒有重大的引擎升級來的給力，作為一個 Javascript 執行環境，Nodejs 是依賴於 Chrome V8 引擎進行程式碼解釋，所以 Chrome V8 的能力基本上限定了 Nodejs 的能力，那麼這次，相比較於 4.x，6.x 的底層引擎 v8 升級到 5.0.x，這意味著，由於底層 v8 自身的很多缺陷和 Bug 都已經通過大升級而一下子就修復了，所以整個 6.x 的表現會跟 4.x 有很大不同。
2. 覆蓋 93% 的 ES6 特性
6.x 覆蓋 93% ES6 特性，則代表我們可以大膽的使用 es6 的幾乎全部特性了，比如 解構，剩餘引數，類啊，super 關鍵字啊，我們知道，往往我們在使用一個庫或者框架的時候，甚至是語言，常常用到的總是那 5 成，6 成，頂天了 7 成的 API，就能完全滿足我們的業務需要，那麼 ES6 的覆蓋率如此之高，我們的確可以敞開胸懷，去擁抱 ES6.
3. 模組載入比 4.x 快 4 倍
模組載入比 4.x 快 4 倍 ，如果你是一個專案負責人，或者技術組長，那麼這個對於你來講肯定是有意義的，我們線上應用啟動，或者重啟的時間會變得更短，讓我們的線上服務對使用者來說，切換更加的平滑，由重啟引起的波動也感知更小。
然而我們除了從語法層面去避免歷史疑難雜症以外，我們更需要關注 Nodejs 版本本身帶來的巨大差異和變化，來看一下 Nodejs 這張表，從現在到 2018 年，我們自身的技能是不斷增長的，同時我們對於 ES6 的使用和了解會越來越深入，那麼我們就應該選擇一個未來的版本來切入技能棧，說句老實話，接下來兩年我們會持續的在 6.x 的版本上跑我們的專案，那麼接下來幾個月就是升級線上版本的緩衝期。
搭積木一樣搭建 Nodejs 應用
當我們把上面的問題都考慮清楚，剩下的事情就變得簡單很多，到了 2016 年，我們並不像是在 2014 年之前那樣，處在大躍進的年代，太多的變化導致太多的不穩定性，現在社群的生態環境已經相當完善。
從靜態資源、Web 框架，模板輸出，資料庫中介軟體到第三方通訊，訊息推送各種 SDK 和 CDN 內容分發，都有太多優秀的庫可以使用，我們做一些適當的定製和改造便可以拎到專案中大膽使用。
然而當我們把魔爪伸向後端，使用 Nodejs 搭建企業級應用的時候，我們抓過來的不僅是更多的價值體現，我們也抓過來更多的職責和信任，後端底層乃至團隊規範都需要我們花費更多的時間去了解對接的方式，接入的階段，不需要精通，但需要備份為基礎的常識，這些軟實力，是我們成為一個優秀 Nodejs 工程師的必備要素。
最後，我來對創業公司中使用 Nodejs，做一個小總結，我們在妥善處理了 運維、叢集管理、效能調優等等這些傳統語言已經做的非常棒非常成熟的領域，在大部分的創業公司，都可以由前端團隊推動，來使用 Nodejs 去接管資料訪問層與渲染層的事情，等到公司規模上來以後，就可以依靠更資深的工程師以及原來團隊的沉澱，來做 比如日誌、監控系統、分散式服務接入這些事情，Nodejs 的落地需要前端工程師，需要 Nodejs 工程師，更需要強大的運維之錘，瞭解除了 JS 以外的更多技能，比如資料庫，比如系統的設計，比如介面服務，比如團隊規範協作流程等等等等，在大公司可以紮根一個方向挖下去，在小公司則需要放眼天下，籌備未來。
無論是怎樣的技術背景，如果有一天你進入創業公司，在立項之初，你都可以先大膽的來做一個假設或者推演，假設說把賭注押到 Nodejs 上，會不會拿到一個更快更好的結果，如果是，請毫不猶豫的選擇 Nodejs。