大家好，我是 Scott，2016 年 9 月 25 日在杭州大搜車總部舉行的杭州 Node Party 上分享了一個(gè)話題 - 《創(chuàng)業(yè)公司擼 Node》 ，分享之后我以文字的形式又記錄了一遍，分享給沒有與會(huì)的朋友，也方便大家通過搜索引擎者一些技術(shù)社區(qū)平臺(tái)來看到這篇文章。

寫在前面，感謝芋頭哥和大搜車，給了我這個(gè)機(jī)會(huì)跟大家在大搜車面基，說實(shí)話，從我出道以來，這還真的是我第一次正式在公開場合裝逼，尤其是當(dāng)著這么多大牛大咖的面兒裝逼。

今天跟大家分享的話題是，現(xiàn)階段下創(chuàng)業(yè)團(tuán)隊(duì)中對于 Nodejs 工程師的認(rèn)可程度，以及如果有一天你進(jìn)入了創(chuàng)業(yè)團(tuán)隊(duì)，在做技術(shù)選型的時(shí)候，基于什么標(biāo)準(zhǔn)來判斷，要不要使用 Nodejs 開發(fā)，以及如何跟進(jìn)技術(shù)的演變。

我特意加了前端逆襲這個(gè)小標(biāo)題，是為了在咱們現(xiàn)場做個(gè)小調(diào)查，請從前和現(xiàn)在做過前端開發(fā)的的同學(xué)舉一下手好么，看看多少人搞了前端現(xiàn)在也在搞 Node?，F(xiàn)場舉手的超過一半人數(shù)，前端這個(gè)職業(yè)真的是屌爆了。

ok，首先做一個(gè)自我介紹，我跟大家一樣，從前也是一名前端工程師，從 2010 開始，在阿里媽媽做了四年前端，后期做了不少廣告投放相關(guān)的前端頁面，跟后端的創(chuàng)意投放管理系統(tǒng)對接，制作和優(yōu)化廣告效果模板等等，大家如果去上 Youku, 微博，各種電影小說新聞媒體網(wǎng)站，應(yīng)該會(huì)有印象曾看過這樣滿屏滾來滾去的淘寶豆腐塊廣告。

哈哈，很不好意思，2014 年以前，你在全網(wǎng)看到的差不多有 70% 的豆腐塊廣告都是我做的，你在淘寶搜了鮮花啊，內(nèi)褲啊，硬盤啊，種子啊，再去訪問其他網(wǎng)站，都能看到豆腐塊里的類似商品，當(dāng)時(shí)我的工作就是開發(fā)這些模板的樣式，優(yōu)化這些模板的特效，測試在各種終端設(shè)備上的兼容性，數(shù)據(jù)方面需要跟各種算法引擎團(tuán)隊(duì)約定各種異步數(shù)據(jù)格式，業(yè)務(wù)上需要考慮復(fù)雜的參數(shù)加密解密二跳透傳，Cookie 的讀取定向等等來落地不同推廣場景下的異步交互方案，最終基于各種廣告系統(tǒng)接入和投放到目標(biāo)網(wǎng)站。

所以在最初我仍然是一個(gè)很純的前端工程師，后來怎么就開始折騰 Nodejs 了呢，我們可以看下上圖最右上角的這個(gè)輪播圖，它由上下兩部分組成，上面是輪播的商品列表圖，下面是推廣的商品關(guān)鍵詞，它倆是兩個(gè)獨(dú)立的數(shù)據(jù)接口，而且很可能是隸屬于兩個(gè)完全不同的數(shù)據(jù)引擎團(tuán)隊(duì)，從前端開發(fā)的角度呢，我需要發(fā)兩次請求來分別獲取和控制這兩個(gè)數(shù)據(jù)接口的展現(xiàn)，而從后臺(tái)開發(fā)的角度看，兩個(gè)接口最好相對獨(dú)立，互不影響，因此我們前端工程師，盡管很希望將兩個(gè)接口合并成為一個(gè)接口，卻很難推動(dòng)后端工程師團(tuán)隊(duì)為我們這樣某一個(gè)模板，專門開發(fā)一個(gè)接口出來，由這個(gè)接口統(tǒng)一獲取兩個(gè)接口數(shù)據(jù)合并后再交給前端展現(xiàn)，于是我們就很難從至少是請求個(gè)數(shù)這個(gè)層面，來優(yōu)化這個(gè)廣告的展現(xiàn)速度和展現(xiàn)完整度，有時(shí)候是圖片先出來，有時(shí)候是關(guān)鍵詞先出來，如果等待同時(shí)出來，萬一某一個(gè)接口掛了怎么辦，這時(shí)候再等待超時(shí)以后去獲取打底的接口或者類似接口，用戶早就離開了。

但是這樣一個(gè)模板在全網(wǎng)的每天為阿里帶來的收益，是非常巨量的，而它的生命周期也許只有 2 周，2 個(gè)月就撤下去換別的模板了，所以從維護(hù)的角度上，后端工程師的確也很難及時(shí)跟進(jìn)前端和產(chǎn)品層面頻繁的改動(dòng)，而從收益方面，就需要跟后端工程師努力的溝通解釋，非常費(fèi)勁，協(xié)作成本居高不下。

但是現(xiàn)在有了 Nodejs 后，我們設(shè)想一下，如果把 Node 作為接口這一層，由它來決定調(diào)用哪幾個(gè)接口，合并哪幾個(gè)接口，哪些接口使用哪些打底數(shù)據(jù)，是不是這樣的場景就迎刃而解了呢，關(guān)于這個(gè)我就不再探討了，可能會(huì)涉及到公司保密協(xié)議，因?yàn)槲液髞韽陌⒗镫x職出來創(chuàng)業(yè)了。

創(chuàng)業(yè)以后，開始了我的職業(yè)轉(zhuǎn)型，這近 3 年時(shí)間，我一直在創(chuàng)業(yè)公司用 Nodejs 開發(fā)產(chǎn)品，我也就從一個(gè)標(biāo)準(zhǔn)的前端開發(fā)工程師逐步切換為一個(gè)會(huì)使用 Nodejs 的開發(fā)工程師，中間費(fèi)了不少力氣，想了解我的技術(shù)成長路線的，可以看上一篇文章 - 4 年前端狗，2 年 CTO，進(jìn)入一個(gè)新的 領(lǐng)域，作為新人是要踩很多坑的，有的是有必要踩，有的沒必要踩，我就把自己的一些心得整理做成視頻，放到了慕課網(wǎng)上。

地址見這里：http://www.imooc.com/u/108492/courses?sort=publish

如果是剛?cè)胄械男氯丝梢匀タ纯?，里面知識(shí)點(diǎn)也許有點(diǎn)陳舊，講解也未必很嚴(yán)謹(jǐn)，可以選擇性的理解流程和項(xiàng)目思路。

那么現(xiàn)在，我是 CampusRoom 這個(gè)網(wǎng)站的技術(shù)負(fù)責(zé)人，大家可能都沒聽過 CampusRoom, 沒關(guān)系，估計(jì)部分同學(xué)聽說過 Moveha，創(chuàng)業(yè)這幾年中，無論是 CampusRoom，Moveha，還是微信服務(wù)號(hào)，包括其他的一些內(nèi)部的外部的，做了沒上線，上線了又下線的大小項(xiàng)目，統(tǒng)統(tǒng)都是用 Nodejs 來搭建的，整個(gè)創(chuàng)業(yè)團(tuán)隊(duì)也充分體驗(yàn)到了使用 Nodejs 建站或者啟動(dòng)一個(gè)項(xiàng)目時(shí)候敏捷所帶來的高效率，其中有一個(gè)小案例，近幾年，一些歐美國家不是太安全，我們?yōu)榱俗寣W(xué)生和家長能對當(dāng)?shù)氐木幼…h(huán)境有一個(gè)安全方面的了解，就用 Nodejs 很快速的搭建了一個(gè)爬蟲小系統(tǒng)，爬取一些州和城市的警署犯罪數(shù)據(jù)，然后合理的分類和評(píng)級(jí)打分后，給出一個(gè)數(shù)據(jù)可視化的效果，這個(gè)功能的產(chǎn)品價(jià)值可能是很大的，然而實(shí)現(xiàn)成本是非常非常小的，效果見下圖：

以上都是從我自身，從我們公司來來感受 Nodejs 的開發(fā)效率和對公司的價(jià)值，但是整個(gè)業(yè)界對于 Nodejs 的態(tài)度又是怎樣的呢，他們的接受度又是如何呢，我們再舉個(gè)例子，大家可能看到過 CNode 論壇上的這個(gè)招聘貼，我截圖了有贊的和大搜車的，最后一個(gè)就是我發(fā)的，也就是 Moveha 公司的招聘，哦，說一句，Moveha 是 CampusRoom 的前身，CampusRoom 是從 Moveha 孵化出來的，我要說的重點(diǎn)是，我發(fā)的這個(gè) Node 工程師招聘貼，是論壇里最先被加精的招聘帖子，也是閱讀量最高的帖子，現(xiàn)在有 4 萬多個(gè)閱讀量，400 多個(gè)評(píng)論，這個(gè)帖子給我?guī)砹?100 多份簡歷，現(xiàn)在我們公司的所有工程師都是從這個(gè)帖子招過來的。

在這個(gè)帖子前后 - 2014 年秋季，在論壇或者社區(qū)中，很多公司對于 Nodejs 工程師的認(rèn)知包括他們的價(jià)值定位其實(shí)是不夠清晰的，從招人的風(fēng)氣中就能看出來，在我發(fā)這個(gè)帖子以前的時(shí)候，很多公司跑到 CNode 上發(fā)帖，都是姿態(tài)比較高，一副你愛來不來的樣子，對自己公司團(tuán)隊(duì)文化介紹的三言兩語模棱兩可，薪資區(qū)間從來不敢放，自從我發(fā)這個(gè)帖子之后，逐漸的論壇的招聘貼開始接地氣了開始有誠意了，薪資夠不到 20K 的公司甚至都不好意思上來發(fā)帖了，從這件事情上就能反映出工程師社區(qū)的結(jié)果導(dǎo)向，玩虛的根本不行，結(jié)果好市場認(rèn)同自然容易被人接受，CNode 上面大量的招聘也從側(cè)面證明了，這三四年以來，Nodejs 工程師越來越被認(rèn)可，越來越被重視，一個(gè)職位到底含金量高不高，其實(shí)不是你說了算，也不是我說了算，而是這個(gè)市場說了算。

我們再來看下 indeed 上面統(tǒng)計(jì)的職位需求變化的趨勢，第一個(gè)圖是 Nodejs 的需求量變化，第二個(gè)是 Fullstack 的需求量變化：

這兩個(gè)職位，即便是在今天，現(xiàn)在依然處在井噴暴漲的階段，整個(gè)市場已經(jīng)對 Nodejs 工程師有了足夠的認(rèn)可，所以大家的職業(yè)黃金期真的是已經(jīng)到了，再過兩三年，Nodejs 工程師就會(huì)真的遍布大街小巷各種公司，現(xiàn)在是跟上這個(gè)大潮的最佳時(shí)期。

那為什么這么多公司對 Nodejs 工程師這么認(rèn)可呢，特別是中小型團(tuán)隊(duì)，特別是創(chuàng)業(yè)團(tuán)隊(duì)，為什么明明可以選擇 PHP，可以選擇同樣敏捷的 Ruby，可以選擇更加成熟，程序員相對更容易招聘的 Java，Python，卻非要費(fèi)勁巴力的去招聘緊缺的 Nodejs 工程師呢，尤其是具備前端工程師能力的 Nodejs 工程師呢？

答案非常簡單，就是因?yàn)槔?Nodejs 開發(fā)一個(gè)新項(xiàng)目，會(huì)非常的高效敏捷，無論從最終的用戶體驗(yàn)，還是上線后的產(chǎn)品迭代節(jié)奏，使用 Nodejs 都有巨大的成本優(yōu)勢。

而成本對于創(chuàng)業(yè)公司來講，是非常敏感的事情，現(xiàn)在市面上成千上萬家嗷嗷待哺的創(chuàng)業(yè)公司，其實(shí)跟屌絲無異，不是沒錢，就是沒人，沒錢，沒人也就罷了，很多 CEO 還想要有好的用戶體驗(yàn)，還想要有更短的研發(fā)周期，更快的迭代節(jié)奏。

說白了，也只有通過這種快速迭代和小步快跑，才能跟同類產(chǎn)品的大公司競爭中拿到時(shí)間差優(yōu)勢，最快的拿到用戶反饋和市場反應(yīng)，最終才能在競爭中和夾縫中殺出一條血路，現(xiàn)實(shí)的確是如此殘酷?？焖俚耐瞥霎a(chǎn)品，熬過最艱難的階段，找準(zhǔn)了產(chǎn)品的盈利點(diǎn)，抓住了目標(biāo)用戶群，有了可以拿到桌面上的各種數(shù)據(jù)，自然更有優(yōu)勢融資，那時(shí)候再去改進(jìn)優(yōu)化技術(shù)棧甚至更換開發(fā)語言也完全有足夠的緩沖余地。

所以我們 Nodejs 工程師的核心價(jià)值，尤其對于創(chuàng)業(yè)公司，就是能夠快速產(chǎn)出，迭代的速度更快，前端后端可以通吃，為創(chuàng)業(yè)公司節(jié)省巨大的人力成本，這就是為什么在市場上，Nodejs 這么受歡迎的原因，創(chuàng)業(yè)公司選擇我們，不僅因?yàn)樗茏羁焖俚臐M足初創(chuàng)團(tuán)隊(duì)的場景，也是因?yàn)?Javascript 也是唯一的能跨越前后端，用一種語言搞定產(chǎn)品實(shí)現(xiàn)的選擇了，關(guān)于 Nodejs 的適用場景，它的優(yōu)勢劣勢，它的開發(fā)和維護(hù)成本，相信大家做了這么久都有自己的見解，不再過多贅述，我們且往下看。

究竟什么樣的創(chuàng)業(yè)項(xiàng)目，比較適合 Nodejs 呢，或者說， Nodejs 作為創(chuàng)業(yè)團(tuán)隊(duì)立項(xiàng)時(shí)候所考慮的技術(shù)選型，有它適用的邊界么，如果有，邊界在哪里，有哪些衡量的標(biāo)準(zhǔn)。如果在創(chuàng)業(yè)公司，我們需要確定用 Nodejs 開啟一個(gè)項(xiàng)目，那么以怎樣的標(biāo)準(zhǔn)，或者說怎樣的準(zhǔn)則來衡量， Nodejs 怎么用，框架怎么選，版本如何跟進(jìn)呢？

太多的問號(hào)在腦海中回蕩，我個(gè)人認(rèn)為，可以簡化為如下三個(gè)問題，就能解決從決策到執(zhí)行的流程：

首先第一個(gè)，什么樣的創(chuàng)業(yè)項(xiàng)目，適合用 Nodejs，哪些又不適合用，我們從這三個(gè)因素來衡量：

1. 期望的迭代節(jié)奏

任何一個(gè)產(chǎn)品，立項(xiàng)之初，都有它特殊的商業(yè)背景和商業(yè)目標(biāo)，在這個(gè)背景和目標(biāo)下，會(huì)給予對它的一些期望，希望它以怎樣形式，多長時(shí)間開發(fā)上線，上線后，以多長的周期進(jìn)行版本的更新迭代，這些都很好理解，如果是一個(gè)展示型的，扔上去不需要怎樣去增加功能，也不需要多么頻繁的改版升級(jí)，那么就沒必要一定要使用 Nodejs，用 PHP，Ruby 統(tǒng)統(tǒng)沒問題。

2. 團(tuán)隊(duì)工程師能力

我們知道，就像這世界的大部分事物一樣，工程師的能力也是大概符合正態(tài)分布，除去特別弱的，比如 3 年前的我，除去特別強(qiáng)的，大部分工程師其實(shí)都處在中間的這個(gè)地帶，就像現(xiàn)在的我，對于 Nodejs 及周邊生態(tài)的掌握可能比較好，但不是特別特別好，而 Nodejs 又是一個(gè)新的職業(yè)方向，火熱的市場上根本沒有足夠時(shí)間來沉淀，于是大部分的創(chuàng)業(yè)團(tuán)隊(duì)是并沒有足夠資深的 Nodejs 工程師，這意味著我們在快速開發(fā)的時(shí)候，往往也面臨著更高的業(yè)務(wù)風(fēng)險(xiǎn)，一旦 Nodejs 用的姿勢不對或者技術(shù)選型失誤，會(huì)給業(yè)務(wù)帶來災(zāi)難性的打擊。

這一點(diǎn)其實(shí)被很多公司所忽視，整個(gè)團(tuán)隊(duì)在當(dāng)下與未來半年的一個(gè)規(guī)模，團(tuán)隊(duì)成員的技術(shù)背景，自我學(xué)習(xí)的能力，對于新技術(shù)升級(jí)的接受程度，如果是不能很好的駕馭 Nodejs 而且自學(xué)能力又偏弱的話，就需要慎重考慮一下。

3. 跟產(chǎn)品的匹配程度

其實(shí)創(chuàng)業(yè)類的產(chǎn)品，往往很少有上來就規(guī)?；唠y度的，所以許多類型都適合，我們與其想那些可以用 Nodejs 開發(fā)，不如反過來看，那些類型的不太適合用 Nodejs 開發(fā)，排除掉這些場景，剩下的都可以評(píng)估一下用 Nodejs 是不是可以。

我這里羅列了幾種，其實(shí)大家照著這個(gè)方向走，未必只有這 4 點(diǎn)：

極高并發(fā)數(shù)

密集 CPU 運(yùn)算

高安全高可靠性

內(nèi)存精密控制及釋放

并發(fā)數(shù)本來是 Nodejs 的強(qiáng)項(xiàng)，高吞吐量，但是如果上來就是要應(yīng)對爆發(fā)式井噴的場景，需要堆機(jī)器的時(shí)候，顯然這些非 Nodejs 領(lǐng)域內(nèi)軟實(shí)力會(huì)過度消耗工程師的時(shí)間成本，這一點(diǎn)一旦工程師的學(xué)習(xí)能力跟不上來，就會(huì)反過來制約業(yè)務(wù)的發(fā)展，如果非要給一個(gè)數(shù)字的話，可以以 10 萬作為一個(gè)衡量點(diǎn)，并發(fā)大于 10 萬的，都要慎重評(píng)估一下。

而對于大循環(huán)的數(shù)據(jù)結(jié)構(gòu)，需要長時(shí)間的運(yùn)算的，對 CPU 強(qiáng)依賴，導(dǎo)致時(shí)間片釋放遲緩的場景就盡量不要用 Nodejs 來做，可以交給 Scala，可以交給 Go，甚至可以交給 Java 和 C++ 來做。

舉一個(gè)例子，比如有旅游路線的實(shí)時(shí)計(jì)算，對用戶的出行路線進(jìn)行推薦，需要基于多維度不同權(quán)重的因子進(jìn)行算法推演，考慮進(jìn)去用戶的性別，喜好，預(yù)算，期望的出行方式，天氣，當(dāng)?shù)鼐包c(diǎn)的分布，目的地有沒有類似 G20 的大會(huì)等等各種因素，背后則可能依靠一些大數(shù)據(jù)做支撐，這時(shí)候用戶不可能等待太久，而是希望馬上拿到路線報(bào)告，這些場景下我們處于中段能力值附近的工程師就不要逞強(qiáng)，避免使用 Nodejs。

安全可靠也同理，一些支付或者銀行對接從場景，服務(wù)的穩(wěn)定性非常之高，不能有任何可能異常導(dǎo)致的進(jìn)程掛起，引起數(shù)據(jù)不一致，這種如果其他語言已經(jīng)具備很好的線上解決方案的話，那么 Nodejs 就可以只做它擅長的方面，把這些交給其他更專業(yè)的技術(shù)來實(shí)現(xiàn)，Nodejs 只調(diào)用接口就行。

一個(gè)項(xiàng)目做大了之后，代碼中會(huì)有更多的隱患或者風(fēng)險(xiǎn)，一個(gè)疏忽就可能導(dǎo)致內(nèi)存泄露，而如果業(yè)務(wù)層面是對內(nèi)存非常敏感的，由于內(nèi)存使用不精細(xì)導(dǎo)致對外的服務(wù)質(zhì)量不平穩(wěn)，這些都是業(yè)務(wù)不能接受的，那么這樣的場景也要慎重權(quán)衡一下。

其實(shí)，考慮到創(chuàng)業(yè)團(tuán)隊(duì)特定的起步方式，不平衡的工程師能力，產(chǎn)品迭代的節(jié)奏，只要是一些略苛刻的場景，都應(yīng)該要多思考一下，用 Nodejs 除了效率，能帶來的價(jià)值能否高過帶來的挑戰(zhàn)和風(fēng)險(xiǎn)，如果答案是否定的，我們就要慎重使用 Nodejs。

我們始終需要去找到一個(gè)在工程師能力，Nodejs 滿足和匹配業(yè)務(wù)的程度，以及公司的產(chǎn)品節(jié)奏之間找到這個(gè)平衡點(diǎn)，而且這個(gè)平衡點(diǎn)會(huì)隨著業(yè)務(wù)的膨脹，團(tuán)隊(duì)的成長而不斷的變化，在變化之中我們需要不斷的評(píng)估，去反思。

那么我們回到產(chǎn)品本身，一旦我們排除掉這些場景以后，我們就可以大膽使用 Nodejs 了，或者說，不是我們，而是更多已經(jīng)大力度投入到 Nodejs 陣營中的先驅(qū)者和執(zhí)行者們，比如下圖：

太多全球的大公司，已經(jīng)在使用 Nodejs 了，就連 微軟這樣印象中比較封閉刻板的軟件帝國，都已經(jīng)對 Nodejs 有著很大的投入，對開源有很大的包容度，推出了很多 Nodejs 好用的工具和服務(wù)，甚至要 Fork 一個(gè) Nodejs 推出新的引擎。

甚至更另類一點(diǎn)的，發(fā)射太空任務(wù)的 NASA 都要用 Nodejs 來開發(fā)一些應(yīng)用或者是運(yùn)行一些系統(tǒng)，甚至是 2016 年 Github 上評(píng)選的，最受歡迎的項(xiàng)目中，有將近一半都是 Nodejs 相關(guān)的項(xiàng)目，或者有用到 Nodejs 做一些構(gòu)建工作。

總結(jié)起來就是一句話，Nodejs 上天入地，剛前剛后，流行只是我們看到的現(xiàn)象，背后是它較低的使用門檻，較小的協(xié)作成本，以及更好的開發(fā)體驗(yàn)，和不錯(cuò)的性能表現(xiàn)。

雖然有這么多我們樂于看到的方面，作為一個(gè)工程師，我們依然需要謹(jǐn)慎對待，當(dāng)我們確定使用 Nodejs 以后，如何選擇版本或者語法層面的一些編程習(xí)慣，畢竟 JS 編程始終太靈活，有許多問題大家糾結(jié)好多年，而 JS 的快速進(jìn)化也帶來更多的編程方向，站在這個(gè)十字路口，往前一步未必是大海，往后一步也未必是懸崖，但是前進(jìn)總比后退要更能接近未來。

舉一個(gè)簡單的例子，讓很多工程師頭痛了很多年的例子，就是 Callback， 這是個(gè)老生常談的問題了，不同的團(tuán)隊(duì)不同的項(xiàng)目歷史背景不同的技術(shù)風(fēng)格，顯然對于 Callback 的態(tài)度和選擇是不同的，比如芋頭哥在大搜車，對于 Callback 的態(tài)度是相對寬容的，因?yàn)閹资f行的歷史代碼，說實(shí)話交給我維護(hù)，我也不敢亂來。

那么我個(gè)人的看法呢，Callback 顯然是不爽的，是反人類的，我的觀點(diǎn)是，初創(chuàng)團(tuán)隊(duì)，如果沒有歷史包袱或者歷史包袱不大的話，堅(jiān)決丟掉，可以直接上 Promise，因?yàn)榘ぶ灰吃谏砩?，只?huì)越來越重，越來越不敢扔掉。

如果再激進(jìn)一些，可以將 Promise 和 Generator Function 混用；
如果再激進(jìn)一些，就結(jié)合 Babel 來使用 async/await;

我們來看一個(gè)例子，通過這個(gè)搜索框，輸入學(xué)?；蛘叱鞘校梢运褜W(xué)校周邊或者城市周邊的房子。

搜索實(shí)現(xiàn)的路徑，我這里做了最大的簡化，只有兩種，在以后繼續(xù)升級(jí)的產(chǎn)品形態(tài)中，會(huì)更加復(fù)雜，比如有精確查詢和模糊查詢，有除了城市和學(xué)校以外的經(jīng)緯度直接查詢，有標(biāo)題查詢，也有郵編號(hào)碼查詢等等，他們的搜索顯然都是異步的。

那么這個(gè)簡化的例子，第一條路，輸入學(xué)校，搜索學(xué)校，拿到學(xué)校以后搜索周邊房源。第二條路，搜索城市，搜索到城市以后，搜城市里面的大學(xué)，再搜城市里面的房源。

由于我們不知道用戶輸入的是學(xué)校的類型，還是城市的類型，我們需要兩個(gè)都查，以學(xué)校的結(jié)果為主。

如果用 Callback 的方式開發(fā)，很容易就寫出這樣的代碼，通過嵌套就強(qiáng)行鎖定了搜索的優(yōu)先級(jí)，以及并發(fā)和非并發(fā)的次序，當(dāng)然每一個(gè)異步查詢都要處理一個(gè)后置的錯(cuò)誤對象判斷，這些錯(cuò)誤不能進(jìn)行合并，要分別處理 5 次，有的會(huì)中斷流程，有的也許不會(huì)，加上如果使用 eslint，這里的 err 都需要多帶帶命名，不可以重名，單從維護(hù)的角度看，如果以后要調(diào)整這里的搜索優(yōu)先級(jí)，就會(huì)很頭痛，相信這些事情大家都有遇到過，我們再來看第二段代碼，這一段我們使用了 Promise 和 Generator Function 結(jié)合以后的一個(gè)升級(jí)版本。

很顯然，這個(gè)升級(jí)直接就解決了 Callback 的幾個(gè)痛點(diǎn)，首先是邏輯可以分拆開來，升級(jí)維護(hù)更方便，如果先以城市為第一優(yōu)先級(jí)搜索，直接把底下代碼整塊扔上來就行了，另外，錯(cuò)誤的捕獲可以合并起來，當(dāng)然也可以做更精細(xì)的控制，同時(shí)呢，比如搜索城市大學(xué)和城市房源它倆是可以并行的，我們就用 Promise 和 Generator 就能很自然的做到這件事，當(dāng)然用 callback 也可以集合 eventproxy 或者 async 做流程控制，但是也會(huì)進(jìn)一步引入代碼的復(fù)雜度。

其實(shí)只要解決掉 Callback 的問題，我們就已經(jīng)往前邁了很大很大一步了，因?yàn)槲覀円肓?Promise ，引入了 Generator Function，甚至可以突進(jìn)到 await 和 async，這意味著底層的 Nodejs 的版本也會(huì)有更大的升級(jí)，帶來更多編程思路的變化。

那么說到 Nodejs 的版本，我的觀點(diǎn)是，我們需要保持對 Nodejs 大版本的跟進(jìn)，因?yàn)檎驹?2016 年的這個(gè)節(jié)點(diǎn)上，其實(shí) Nodejs 已經(jīng)經(jīng)過了 7 年之癢，后面的日子比前面的幾年要幸福太多了，這個(gè)我可以從自身的一些經(jīng)驗(yàn)來說下吧：

我從 2013 年開始兼職創(chuàng)業(yè)做我們公司的項(xiàng)目，那時(shí)候的 Nodejs 版本是 0.8，我一直使用到 2014 年 7 月份，才從 0.8 升級(jí)到了 0.10，然后又使用到了 2015 年春節(jié)，沒有忍住，從 0.10 升級(jí)到了 0.12，一直使用到 2016 年 1 月份，再次升級(jí)到了 4.x，現(xiàn)在仍然保持在 4.x 的版本狀態(tài)，我經(jīng)歷了這幾次大的版本周期，感覺是這樣的。

從 0.10 到 0.12 是一個(gè)比較大的飛升，從 0.12 到 4.x 是一個(gè)巨大的飛升
從 4.x 到 6.x 也將是一個(gè)巨大的飛升，當(dāng)然了， Nodejs 有它特殊的歷史進(jìn)程，比如 0.10 的版本中，有一個(gè)重大的安全漏洞，不升級(jí)都不行，在 4.x 推出以前，Nodejs 社區(qū)還分出來 io.js 陣營，結(jié)結(jié)實(shí)實(shí)的對抗了很長時(shí)間，再往后面合并后就正?；耍灰俜酵屏?LTS 版本，在首個(gè) LTS 版本之后，可以觀望一個(gè)月左右，就可以考慮升級(jí)了。

當(dāng)然，在 LTS 版本升級(jí)之前的至少 1 個(gè)月，我們本地的開發(fā)環(huán)境，就應(yīng)該已經(jīng)切換到了這個(gè)大版本了，在我們本地來開發(fā)來測試。

接下來，我們都會(huì)面臨 6.x 版本甚至是即將發(fā)布的 7.x 版本，官方也羅列了一些重大的變化，我談下我覺得需要關(guān)注的點(diǎn)。

1. V8 升級(jí)到 5.0.x

每一次版本的升級(jí)，都不可例外的，會(huì)優(yōu)化提升整體的性能，包括安全方面的增強(qiáng)，文檔的完善，測試用例的覆蓋，但是都沒有重大的引擎升級(jí)來的給力，作為一個(gè) Javascript 運(yùn)行環(huán)境，Nodejs 是依賴于 Chrome V8 引擎進(jìn)行代碼解釋，所以 Chrome V8 的能力基本上限定了 Nodejs 的能力，那么這次，相比較于 4.x，6.x 的底層引擎 v8 升級(jí)到 5.0.x，這意味著，由于底層 v8 自身的很多缺陷和 Bug 都已經(jīng)通過大升級(jí)而一下子就修復(fù)了，所以整個(gè) 6.x 的表現(xiàn)會(huì)跟 4.x 有很大不同。

2. 覆蓋 93% 的 ES6 特性

6.x 覆蓋 93% ES6 特性，則代表我們可以大膽的使用 es6 的幾乎全部特性了，比如 解構(gòu)，剩余參數(shù)，類啊，super 關(guān)鍵字啊，我們知道，往往我們在使用一個(gè)庫或者框架的時(shí)候，甚至是語言，常常用到的總是那 5 成，6 成，頂天了 7 成的 API，就能完全滿足我們的業(yè)務(wù)需要，那么 ES6 的覆蓋率如此之高，我們的確可以敞開胸懷，去擁抱 ES6.

3. 模塊加載比 4.x 快 4 倍

模塊加載比 4.x 快 4 倍
，如果你是一個(gè)項(xiàng)目負(fù)責(zé)人，或者技術(shù)組長，那么這個(gè)對于你來講肯定是有意義的，我們線上應(yīng)用啟動(dòng)，或者重啟的時(shí)間會(huì)變得更短，讓我們的線上服務(wù)對用戶來說，切換更加的平滑，由重啟引起的波動(dòng)也感知更小。

然而我們除了從語法層面去避免歷史疑難雜癥以外，我們更需要關(guān)注 Nodejs 版本本身帶來的巨大差異和變化，來看一下 Nodejs 這張表，從現(xiàn)在到 2018 年，我們自身的技能是不斷增長的，同時(shí)我們對于 ES6 的使用和了解會(huì)越來越深入，那么我們就應(yīng)該選擇一個(gè)未來的版本來切入技能棧，說句老實(shí)話，接下來兩年我們會(huì)持續(xù)的在 6.x 的版本上跑我們的項(xiàng)目，那么接下來幾個(gè)月就是升級(jí)線上版本的緩沖期。

當(dāng)我們把上面的問題都考慮清楚，剩下的事情就變得簡單很多，到了 2016 年，我們并不像是在 2014 年之前那樣，處在大躍進(jìn)的年代，太多的變化導(dǎo)致太多的不穩(wěn)定性，現(xiàn)在社區(qū)的生態(tài)環(huán)境已經(jīng)相當(dāng)完善。

從靜態(tài)資源、Web 框架，模板輸出，數(shù)據(jù)庫中間件到第三方通信，消息推送各種 SDK 和 CDN 內(nèi)容分發(fā)，都有太多優(yōu)秀的庫可以使用，我們做一些適當(dāng)?shù)亩ㄖ坪透脑毂憧梢粤嗟巾?xiàng)目中大膽使用。

然而當(dāng)我們把魔爪伸向后端，使用 Nodejs 搭建企業(yè)級(jí)應(yīng)用的時(shí)候，我們抓過來的不僅是更多的價(jià)值體現(xiàn)，我們也抓過來更多的職責(zé)和信任，后端底層乃至團(tuán)隊(duì)規(guī)范都需要我們花費(fèi)更多的時(shí)間去了解對接的方式，接入的階段，不需要精通，但需要備份為基礎(chǔ)的常識(shí)，這些軟實(shí)力，是我們成為一個(gè)優(yōu)秀 Nodejs 工程師的必備要素。

最后，我來對創(chuàng)業(yè)公司中使用 Nodejs，做一個(gè)小總結(jié)，我們在妥善處理了 運(yùn)維、集群管理、性能調(diào)優(yōu)等等這些傳統(tǒng)語言已經(jīng)做的非常棒非常成熟的領(lǐng)域，在大部分的創(chuàng)業(yè)公司，都可以由前端團(tuán)隊(duì)推動(dòng)，來使用 Nodejs 去接管數(shù)據(jù)訪問層與渲染層的事情，等到公司規(guī)模上來以后，就可以依靠更資深的工程師以及原來團(tuán)隊(duì)的沉淀，來做 比如日志、監(jiān)控系統(tǒng)、分布式服務(wù)接入這些事情，Nodejs 的落地需要前端工程師，需要 Nodejs 工程師，更需要強(qiáng)大的運(yùn)維之錘，了解除了 JS 以外的更多技能，比如數(shù)據(jù)庫，比如系統(tǒng)的設(shè)計(jì)，比如接口服務(wù)，比如團(tuán)隊(duì)規(guī)范協(xié)作流程等等等等，在大公司可以扎根一個(gè)方向挖下去，在小公司則需要放眼天下，籌備未來。

無論是怎樣的技術(shù)背景，如果有一天你進(jìn)入創(chuàng)業(yè)公司，在立項(xiàng)之初，你都可以先大膽的來做一個(gè)假設(shè)或者推演，假設(shè)說把賭注押到 Nodejs 上，會(huì)不會(huì)拿到一個(gè)更快更好的結(jié)果，如果是，請毫不猶豫的選擇 Nodejs。