沉魚，螞蟻集團體驗技術部的進階前端專家。2007 年畢業于浙江大學，2008 年加入阿裡，之後又入職了螞蟻集團。他先後作為 Node Web 架構 Chair 的核心開發、Basement Baas 服務的技術負責人、九色鹿的技術負責人以及現在雲鳳蝶的技術負責人。她今天帶來的話題是《我做前端這 10 年來的感悟》。那麼接下來，我們把時間交給我們的沉魚小姐姐。
一、關于我
剛剛主持人已經給我做了一個簡單的介紹，那這個地方我就不多講了。我的經曆也比較簡單，現在是在螞蟻集團的體驗技術部做企業級應用設計研發平台 —— 雲鳳蝶的技術負責人。其實我做前端不止 10 年了，已經有 12 年了。這 12 年裡發生了挺多的事情，是以也借着這個場合，跟大家一起回顧一下，這段時間裡前端的整體發展。
二、前端簡史
我們來看一下前端簡史。這一小段的内容，其實并不是從很客觀的角度去看前端的發展，更多是結合我個人的工作經曆來講這些事情。
1、2009 年
先看一下 2009 年，國内成立了第一個前端團隊。大家剛剛如果有留意到主持人的介紹的話，會發現其實我是 2008 年入職淘寶的。那麼那個時候我的主管是怎麼發現我的呢？我當時在一家公司裡面工作，工作之餘還寫部落格，還會畫一些跟程式員相關的有趣的小漫畫。我估計大概是因為漫畫吸引了非常多的人的目标，然後就這樣進了淘寶。大家可以看一下左邊這張圖，是 2008 年中秋節時淘寶網的首頁截圖。在這張圖上，我基本上是達到了人生的巅峰。大家不要誤會哈，這不是我作為一個前端的巅峰，而是我作為設計師的一個巅峰。當時才剛剛流行做節日 Logo 沒有多長時間，那段時間正好我們的設計師沒空，這個時候我們的部門老闆就說了，沉魚你會畫漫畫對吧？那你要不要給我們畫個中秋節 Logo 呀？我想來想去，那就畫吧！畫了之後這個 Logo 就真的上線了，被非常多的人看到。這個絕對是我在前端這個行業裡面，作為設計師的一個高光時刻了。
大家可能也覺得奇怪，你一個前端，你幹嘛畫畫？實際上 2008 年我入職淘寶網的時候，淘寶是沒有一個專業的前端團隊的，所有的前端同學都在體驗技術部，Title 應該是叫互動設計師，我們跟設計師是在一個大團隊的。實際上那個時候很多的頁面布局還使用 table 這樣古老的技術，使得我們的設計師中也有不少人能夠自主做一些網頁。那個時候前端的同學更多的是專注在像淘寶首頁這樣一些比較重要的頁面上，而一些活動頁面之類的，就會由設計師同學從頭至尾地完成。直到 2009 年年初的時候，我們公司才正式劃撥出了一個前端團隊，據我所知也是國内第一個前端團隊。于是 2009 年我們才正式有前端這個行業。
大家看一下右邊的這張圖，是我剛剛截的淘寶網現在的首頁。如果我們仔細地看一下這兩張頁面，會發現除了頁面變得更寬了、能适應更大的螢幕了、設計也更符合當下的審美了，似乎并沒有發生什麼太大的變化。如果單從這兩個頁面來看的話，确實是這樣，雖然我們使用了各種各樣的新技術讓頁面浏覽起來更加順暢。但實際上前端的發展遠不止于此。
2、2008 年 ~ 2012 年
其實任何一個行業在最初時期的發展都是非常慢的，是以在 2008 年到 2012 年這 4 年期間，前端的整體工作都非常的簡單，我們可以簡單地歸結成為“浏覽器大戰”和“前端架構”這兩個關鍵詞。
“浏覽器大戰”可能對于一些比較新的同學來說，都已經不是很有體感了，因為現在 Chrome 一統天下，包括 2018 年微軟也宣布了使用 Chromium 作為他們的浏覽器的核心，是以 PC 時代的浏覽器的相容性問題已經徹底解決了。但是在當時，大家對浏覽器的相容性問題是非常頭疼的。大家看一下左邊這個圖，有 10 來種浏覽器，這還不是一個完全枚舉。是以對于那個時候的前端同學來說，最頭疼的事就是要處理前端相容性的問題。而要命的是，當時 IE 仍然是市場上的主流，而且它作為一個主流，卻又特别的不标準，性能也很差。是以 Diss IE 也成為當時程式員的一個日常活動。中間這幅圖當時是比較流行的一幅程式員漫畫，大家可以看一下 IE 大概慢到了什麼樣的程度。因為當時的條件特别的惡劣，是以程式員在不斷地跟這些我們現在看來有些可笑的問題做着鬥争。
那個時候也是非常拓荒的時期，我們還缺乏一些基本的基礎設施，前端架構就是非常重要的基礎設施。那個時候，國内各大廠商都在開發自己的前端架構，在淘寶我就參與了 Kissy 的開發工作；實際上百度、360 以及新浪都有自己的前端架構。當時這些大廠之間的前端交流是非常頻繁的，是以在有一次交流之後，我回來就畫了右邊這幅漫畫，調侃了一下當時各大廠的前端架構，沒想到當時這幅漫畫就成為了一個爆款，特别多的程式員看了這個漫畫。我們也覺得這種狀态好像不是很正常，但是當時的前端并不像現在這樣，有這麼開闊的行業視野，是以大家在這個局裡面困了挺久的。大家也看到，2008 年到 2012 年是整整 4 年時間，這 4 年不能說毫無發展，但是發展得真的非常慢。
3、2013 年
轉機出現在 2013 年之後，我覺得整個前端行業走上了一個快車道。大家可以看一下左邊的這張截圖，一看就非常土，2009 年的一個手機淘寶頁面，當然我當時有參與它的開發。這麼土的一個頁面 —— 我們剛剛說 PC 時代結束了相容性的問題，而移動時代其實才剛剛開始 —— 哪怕是 2009 年這麼土的一個頁面，它也有非常多得相容性問題要考慮，可能都是大家意想不到的。比如說，那個時候所謂的智能手機，其螢幕寬度差異是非常大的，我們為了確定每一行的文案都不折行，實際上需要采集當時市面上所有主流手機的螢幕尺寸，然後去做文案字數的适配。實際上在 2020 年，手機淘寶已經發展得非常好了，它跟 PC 沒有什麼太多的差別。
但我們的發展過程也不是一帆風順的，特别是在早期的很長一段時間裡，手機淘寶的地位可能都類似于一個附屬品，或者說一個補充的存在。直到 2013 年，整個公司都覺得這樣下去不行了，我們必須要加速移動業務的發展。是以當時出了一個非常有名的事件，叫做阿裡的“無線 All In”事件。當時公司調派了非常多的人員、資源去做無線手機淘寶。那一仗算是打勝了，勝得比較驚險。
但是要說業務真正地漲起來、形成 Mobile First 這樣的使用者心智，可能也要到 2015 年左右了。當時有一件印象特别深的事情，因為我們的内網裡有非常多的人，好幾萬人，是以大家也經常會在上面做一些自己的産品營銷，幾萬人也是不能忽視的對吧~ 是在 2012 年還是 2013 年的雙 11 大促的時候，無線手機淘寶的 PD 就在内網發言說今年雙 11 大家都來用無線淘寶吧。因為那個時候，不知道大家還有沒有印象，秒殺特别火，就是一塊錢秒一個特别貴的東西。我們無線淘寶的 PD 說來用無線淘寶的頁面吧，咱們伺服器水位低，秒殺一定不會卡。是以大家可想而知，在那個時候，哪怕是我們做成了“無線 All In”的那個時候，使用者量也還沒有大到一定的程度，但是趨勢已經非常明顯了。而現在，大家基本上已經全部都是人手一個手機這樣的情況了。在這個事情裡面，我們很容易就能看到，哪怕我們在今天看來是一些巨變的事件的發生，也不是一朝一夕的事情。就像我們在 2009 年的時候，就已經開始做手機淘寶了，到 2013 年無線 All In，再到市場完完全全以無線為主，這中間有足夠多的時間去做出反應。是以很多的時候，我們隻要踏準了時代發展的脈搏，就有足夠的時間去做相應的對策。
那麼為什麼說在無線端，浏覽器相容性的問題才剛剛開始呢？是因為一開始的時候，我們做的是 Native App，這個時候 iOS 跟 Android 的程式員是非常稀缺的。很多前端在這段時間裡就轉做了 iOS 跟 Android 開發。但是這兩個領域吧，它們的人員培養成本非常高，而且研發成本也不低。在現在這樣飛速發展的時代，如果所有的東西都用這兩個技術去開發的話，成本是非常高昂的。是以慢慢地 H5 又重新走上了曆史的舞台。因為 Web 技術的成本特别低，是以我們嘗試在無線的 App 裡面加入 H5 的頁面，來處理一些非核心頁面的研發。慢慢地，小程式又出現了，這個時候大家就已經知道了，今天的無線，真正重要的無線流量的入口沒幾個，而小程式就是非常重要的一個入口。于是 Web 研發技術又重新回到了曆史的舞台。當然最核心的那些 App 以及最核心的那些頁面還是會用原生的 iOS 跟 Android 來開發。
大家可以看到，這個頁面下面還放了一個 PWA，不知道有多少同學見過它，或者對它有體感。它是一個希望能用 Web 技術做 Native 應用的解決方案，是 Google 家的産品。到目前為止還沒有看到 PWA 特别大規模流行的趨勢，但它其實已經出來蠻多年了，大家可以關注一下。這幾個技術的此消彼長，其實是蠻有意思的事情。
4、2015 年
時間飛快地來到了 2015 年，由于之前“無線 All In”的事情，從很多團隊調派了人手，集中人力去做了這麼一件大事，是以作為團隊留守的一些成員來說是比較傷的，因為業務被裁撤，人員也減少了。但是我們團隊有一部分同學留下來了，我是其中之一，我們仍然在摸索 PC 端的一些可能性。這個時候其實新一代的研發架構已經逐漸地生長起來了，最早的是 2010 年的 Angular 以及 2013 年 React.js 和 Vue.js。在這幾個架構當中，我們并沒有猶豫太久。在 2015 年的時候我們團隊就決定要使用 React。原因比較簡單，因為 React 可能比 Angular 好用，比 Vue 靈活。但是這個不牽涉語言之争，僅僅是我們團隊的一個選擇哈。
在那個時候，我們并沒有太長的時間去喘息或者迷茫，很快我們又忙起來了，為什麼呢？因為 2015 年被稱為 toB 元年，那一年發生了很多的事情，我們就發現其實 toB 的業務也非常地繁茂、非常地有前景。是以這個時候我們也釋出了我們第一個 toB 的 UI 元件庫 —— Ant Design，簡稱 AntD。它從最初的一個非常單一的 toB 元件庫發展到今天，已經集合了可視化解決方案、業務場景化模闆以及 Mobile 元件庫，變成了一個非常大的家族。在去年的時候，我們的 GitHub 倉庫的 Star 數也已經超過了 Google 的 Material Design，成為了 GitHub 上同類開源項目當中 Star 數最高的項目。Ant Design 對我們來說其實還是做得挺艱難的，從 2015 年開始一直到現在，我們還是在大力維護它。
這個項目的 Owner 就在我們隔壁組，叫偏右。我有的時候也會調侃他說，你說你們的 Ant Design 這麼多人用，它的競争力到底是什麼？他就非常幹脆地甩給我兩個字：好看。沒錯，很多時候我們常常強調要有大局觀、要有全局的視野，但是細節也不能忽視，這個東西它真的好用，能契合到我們工作當中的一些場景，就非常地有生命力。
除了剛才提到的 toB 的前端架構，那段時間大資料也開始嶄露頭角了，是以相關的可視化的圖形庫也非常多，包括百度的 Echarts，螞蟻的 DataV。最早的時候大家可能會用這些圖表來做一些可視化的使用者行為分析，包括 CNZZ 還有 Google Analytics 這樣的東西。但是慢慢地行業就逐漸向深水區發展了。
在 Keynote 的右上角是我們的一個業務分析場景，這個場景特别複雜，可能會有數十萬個節點要去操作，這樣複雜的場景，又給技術帶來了新的挑戰，比如說：數十萬的節點的計算如何保證性能，如何呈現能保證向使用者有效地傳遞資訊等等，這些新的問題都有待我們去解決。實際上我們的業務越來越複雜的話，就會推動技術進一步的發展。
而 Keynote 的右下角是一張非常漂亮的大圖，是可視化發展的另一個分支，這個分支比較高端，叫大屏。大屏上的東西特别漂亮，一般來說大家會在企業的接待處或者政府機關看到這種大屏，它其實是有幾面牆那麼大的。它對視覺的要求是非常高的，大家可以看到它非常精細。最近也在流行一個形容這一類大屏的詞，叫做數字孿生，就是用數字化去打造一個跟我們生活當中一模一樣的城市，通常都會用于做交通管控或者金融管控，這種時候大屏就會非常有用。這類大屏之是以足夠特殊，就是因為普通的電腦根本就跑不起來，它是需要有特殊的機器來承載的。
剛剛說的這兩件事，其實我是一行代碼都沒參與，都是我們隔壁組的同學做的事。
那這段時間我幹嘛去了呢？我去做了這件事。因為随着 2009 年 Node.js 的釋出，前端逐漸有了一些想象力，就是能夠去做一些後端的事。倒不是說沒有 Node.js 就做不了，你可以用 PHP，也可以用 Java，但是對于前端來說 Node.js 有天然的親和力，因為用 Node.js 的話，你的前後端語言是一樣的，有很多問題你自己就可以解決。
雖然 Node.js 一直都被作為一個玩具般的存在，但實際上它已經發展了很長的一段時間，包括 2010 年的時候 Express 架構釋出、socket.io 釋出，2011 年的時候 LinkedIn、Uber 上船，2013 年的時候 Ebay上船。2013 年還發生了一件比較特殊的事情，那就是激進派的 Web 架構 Koa 誕生了，它的誕生給大家帶來了一些新的思路和啟發。是以我們團隊在 2014 年的時候就開始計劃要去做一個 Node.js 企業級的 Web 架構。
大家看中間的這一張圖，這是我們當時的代碼送出的記錄圖，可以看到至今還是非常活躍的。這個架構叫做 Chair，我在這個架構裡面主要是參與打通跟現有技術體系的連通的這一部分。下面的叫做 egg，是 Chair 的一個開源版本，也就是說對于其他公司的同學來說，如果他想用這個東西的話，他可以基于 egg 來做自己的企業級 Web 架構。那麼在這個架構上，我們的第一仗是什麼呢？在當時流量最 Top 的支付寶收銀台頁面上，我們把它用上去了。
實際上這個過程是非常坎坷的，首先有非常多的技術問題要去解決，比如性能、安全性。比如說你說性能不好對吧？實際上 Node.js 非常擅長的就是 IO 密集型的處理，是以我們可以去做 Benchmark，看看到底是 Java 的性能好，還是 Node.js 的性能好，這些問題都是相對容易解決的。比較難的是，當時我們是沒有一個配套的研發流程的；我們也需要融入現有的研發體系，因為現有的研發體系完全是寄生在 Java 之下。其實很長一段時間裡，前端都沒有自己的釋出流程，前端同學寫完了一個模闆語言之後，他需要把腳本送出到倉庫裡面，由 Java 的同學去做最後的釋出。另外還有一個更深遠的問題，那就是要考慮相關研發人員的培養。因為大家都知道，在大學裡面大家都是受過相關技能教育的，是以對于學 C、學 Java 的同學，他可能從學校一畢業出來就帶着這樣的技能；但是到現在為止 Node.js 也不是一門大學裡的常駐課程。是以這個非常難。
當時這件事難點非常多，但是其他的就不細講了，就講講當時我參與的那部分工作。當時我主要是做了兩類工作。
一類是跟現有的 Java 服務打通的工作，跟 Java 服務打通是非常麻煩的事情，你經常需要去解析它的 RPC 請求，你需要知道它的協定是什麼…… 是以在這段時間裡，我寫了很多的協定解析代碼，包括一些像 Java IO 這樣的協定解析，讓它能夠真正地跟 Node.js 端連通起來，讓我們能夠真正地連上生産端的各種各樣的服務。
另外一個當時非常現實的困難就是，我們除了現在在 Keynote 上看到的這個支付寶收銀台頁面，實際上還有大量的業務，如果我們希望這個東西能夠大量使用的話，我們不能把這個業務裡面的代碼全部推倒，都重新手寫一遍，我們不能這樣折騰這個業務。當時我們在 Java 體系裡面使用的是一個叫 Velocity 的模闆，這個模闆它壞就壞在它太靈活、太進階了，它跟現在的 Vue 這樣的模闆語言是完全不一樣的東西。它可以說是非常接近程式設計語言的一個模闆語言。那怎麼辦呢？當時我們就寫了一個轉換解析器，把 Velocity 的模闆語言轉換成了 nunjunks 的模闆，實際上 Velocity 模闆語言的能力是 nunjunks 的超集，我們在轉換過程中，還做了非常多的功能檢查，在轉換完成後，還會提示開發者在這個過程中發現了多少問題是需要人工轉換的。
通過這樣一系列的努力，我們能夠真正地在既有體系裡面跑起來了。是以如果大家做一個新東西時希望證明自己的話，最好的方式就是去做一個标杆項目。當時我們拿流量最高的支付寶收銀台頁面去做，還好最後做成了。2014 年的種子在後面就開花結果了，到了 2015 年的時候，這個架構基本上受到了比較廣泛的認可。
其實 2015 年還發生了很多的事情，大家可能也不是很記得。其實 2015 年也是釘釘釋出的第一年，在這一年裡，有一個關鍵詞叫做 Electron，Electron 是一個能讓 Web 開發的同學用 Web 開發相關的技術做 Native 應用的一種技術，它最早其實是 GitHub 的 Atom 編輯器的副産品 —— 它一開始确實是個副産品，而後面就變得獨立起來了。
在這方面有兩個我覺得比較好的應用：一個是支付寶的小程式 IDE，它最早也是用 Electron 來開發的；一個就是我們的釘釘。大家都知道其實很多開發釘釘的同學，早期都是做“來往”的，是以裡面有非常多前端的同學。後來大家轉向釘釘之後，要做 Native 的App，大家是沒有那麼多的經驗的，人又特别缺乏，我們又希望能夠盡快做一版出來校驗一下，看看是不是能得到市場的認可。是以那個時候一幫前端同學就用 Electron 技術把釘釘的第一版給做出來了。雖然最終釘釘的版本還是換成了 Native 的版本，但是實際上 Electron 的版本也運作了很長一段時間，直到最後被大家回報有比較多的性能問題。但是實際上這也是見仁見智的，很多時候大家在說了一大串性能有問題的時候，我們經常會舉一個例子：你去看看 VS Code，VS Code 慢嗎？VS Code不慢，VS Code 可是用 Electron 來做的。是以很多時候我們也要看這個技術到底被用得怎麼樣，這也是很重要的。
2015 年還發生了這件事，如果不提那就肯定是漏掉了。Alpha Go 掀起了一場全民人工智能的浪潮，這波浪潮直到今天還在繼續。其實早在 2015 年的時候，我們就有一些團隊在跟進這個領域了，但是這裡我要說的是，人工智能研究和人工智能應用完全是兩件事。如果想要做人工智能研究的話，基本上除了重新回去讀個書可能還有點機會之外，剩下的應該就沒機會了。因為這個行業的競争其實非常激烈，絕對得是人中龍鳳 —— 這個詞用得一點都不誇張，一定是人中龍鳳才能來做這件事。
但人工智能應用會越來越廣泛，它的門檻也會越來越低。我們在這方面做了一些應用上的嘗試，包括 2015 年阿裡的智能設計平台，以及 2018 年的智能設計稿轉代碼平台。這兩個平台都是貼着營銷大促這個場景在跑，因為當時在雙十一或者 6.18 大促期間的 Banner，或者這種推薦産品的圖，它們的量級已經達到了上億級别，這已經根本不可能靠人工去做了，是以我們隻能向技術要産能。是以大家想到了這樣一些辦法。還有一個就是我們團隊現在在做的，螞蟻企業級應用設計研發平台。可能大家會說，這看起來不就是一個 IDE 嗎？它是怎麼個人工智能法呢？這裡我們先按下不表，待會再說。
5、2018 年
2015 年真的是技術發展非常蓬勃的一年，當然雖說很多技術可能在更早的時間 —— 比如說 2008年、2009 年 —— 就已經出現了，但是對于我而言，我覺得特别重要的那些技術，可能都是在 2015 年、2016 年那兩年感覺到的，那個時候技術真的是出現了一個大爆發，而且出現了非常多的能很好地落地到業務裡的應用。這些技術現在仍然還在發展，但是近幾年非常繁榮的可能是我們的 Web IDE 和 Web Editor。
這是我截的一個我們公司内部的一些相關産品的圖，非常多，至少有 10 個，肯定還有很多我不知道的，就像前一個分享講師講的他們的 IDE，那個我就不知道。
大家可以從左到右看一下，最早的是大屏可視化資料分析類的産品，這個是跟着大資料的浪潮來發展起來的；然後到中間人工智能的這一波浪潮，Data Works 大資料開發以及 Pai 人工智能可視化開發；到第三列的支付寶小程式 IDE 和我們的 H5 & 小程式建站 IDE，最年輕的兩個 IDE 是我們的 Cloud IDE 也就是雲 IDE，以及雲鳳蝶企業級應用設計研發平台。
除了這些程式向的 IDE 之外，還有一些其他的複雜 Editor 的出現，即下面以語雀為例的富文本編輯器以及電子表格等。是以如果我們今天回頭來看整個前端的發展，會發現實際上是非常迅猛的。很多工作年限比較短的同學，甚至都無法想象在 2008 年我們前端面臨的是那樣的一個場景。是以業界不是有句名言嘛，說凡是能用 JavaScript 做的東西，最終都會用 JavaScript 做一遍，包括現在的 IDE 都是用 JavaScript 在寫了，是以還挺神奇的。
6、2020 年
大家可能會說，你們前端這麼牛，你們怎麼不上天？其實确實上天了，大家可以看一下，2017 年 NASA 就已經上船 Node.js 了；在剛剛過去的 Space X 的發射中，大家也發現他們使用了前端的相關技術來做觸控大屏。當然這條推文僅供大家娛樂一下，因為這條推文其實并不是 Space X 的從業人員發的，而是 Google 的一個程式員發的。這裡引發了大家比較多的讨論，我覺得有些回複比較有趣：有人說 node_modules 有沒有讓飛船超重啊？大家可以看一下截圖的回複中間，有一個老爺爺，它其實是 JavaScript 的創始人，他仍然很活躍，經常做的事情之一就是反駁别人說 “JavaScript 就是個玩具語言”。這一頁給大家娛樂一下。
發展到現在，其實我們會發現，首先前端的領域性越來越廣了，在最初的前端行業裡面，大家所要知道的東西就是 CSS、JavaScript、HTML，以及一些周邊的東西，但是并沒有像現在這樣有那麼多重要的東西能夠去玩；另外一個是，它的難度确實是越來越高了，大家會發現整個前端的工作是一路向上延續的，從寫頁面到寫編輯器，到移動端的浏覽器核心，一路在向上，在向上的過程中對事情有更多的把控力。這兩個趨勢非常明顯。那麼對于我們而言，我們要想的是，我們作為今天的前端，是不是可以滿足于做的那些頁面？答案肯定不是，我們要去看前端的後續發展中下一個浪潮在哪裡，我們要踏對浪潮的脈搏，可能才會有更好的下一輪發展。
這個大概是我對前端過去這 12 年的簡單總結。這個總結其實是非常個人的，有一些關鍵技術也沒有出現在今天的分享當中，比如說 IoT，比如說 Web Assembly 等一些技術，相關的同學也可以去關注一下。
三、專注當下
講完曆史，總還是要講一講當下。我當下在做的工作也比較有趣，叫做雲鳳蝶，是螞蟻的企業級應用設計研發平台。
1、雲鳳蝶是什麼
大家可以看一下螢幕上的截圖，左邊是我們的設計界面，右邊是我們的編碼界面。看起來這個東西真的是有點平平無奇對不對？它看起來就是一個很普通的 IDE。沒錯，如果從外觀上來看确實是這樣，但是我希望大家不要以貌取人 —— 不要以貌取 IDE。在接手這個産品的時候，我們其實是有明确的問題要解決的。
2、問題與挑戰
那問題是什麼呢？就是在螞蟻，中背景應用是最主要的業務之一，占比大概 1/3。1/3 是什麼概念？今天在螞蟻裡，整個正式的前端研發以及合作夥伴的總數應該已經超過了 1200 人，大概是這樣的一個量級，1/3 就是四百多人，四百多人大概在幹這個事，是以我們是急需要去在這方面提效的。但是提效隻是其中的一個方面。
大家可以看一下左邊的這張漫畫，說的就是前端學習曲線，我覺得社群裡有一位同學畫得特别好，一開始是最簡單的，等到發展到後面這個人已經吃不消了，能看到有那麼多的技術棧，這從很大程度上來講也确實是事實。我們說今天的前端技術雖然發生了很大的變化，整體的技術難度也變大了，招到好一些的前端同學是非常難的事情，是以我們希望能夠降低門檻。
剛剛提到的是高效能，而另外一個就是高品質。這個可能大家不是很了解，因為一般來說中背景業務能跑就行了。螢幕中間就是一個非常典型的例子，也是我們公司内部的一個中背景産品的截圖。但是我們剛剛提到過一點，即 2015 年是 toB 業務的元年， toB 的業務在最近幾年是越來越受重視的，包括螞蟻的很多重量級的業務也都是 toB 類的業務，包括螞蟻區塊鍊、Ocean Base、mPaas 等一些平台，所有這些會讓我們對中背景的整體品質提出更高的要求。
當然其本身的業務也非常複雜，複雜到什麼程度？我之前跟一個同學聊天，說到他們負責的一個簽約類的産品，其中的簽約表單，大家可以想象一下有多少字段 —— 800 個字段！800 個字段，我覺得作為一個人其實都很難填完，這 800 個字段，大家想象一下怎麼在頁面上合理地顯示出來？是以複雜度也是非常高的。就這樣的背景下，我們決定要去做雲鳳蝶這樣一個産品，解決這類的問題。
關于這個産品，我們最初想了很多問題，大家回想一下剛剛我說的 Web IDE 的那一頁，十幾個 IDE 中有一個叫 Cloud IDE，有一個叫雲鳳蝶的 IDE，這兩個是成對的。Cloud IDE 是一個 Pro Code 的 IDE，大家可能覺得這個才是正統，那雲鳳蝶是什麼？—— 雲鳳蝶是程式設計界的拼多多。一說到拼多多，大家都覺得很“Low”對不對？其實我也被這個事很困擾了很長時間，因為大家都覺得這個雲鳳蝶好像挺牛的，裡面有挺多核心技術的，但是一說到要招人？“不來不來，我要去Cloud IDE。”大概是這樣的狀态，就讓人很苦惱。但是慢慢地也就釋然了。為什麼？因為我發現最近拼多多市值過千億了，這件事還是挺厲害的，而且我查了一下，黃峥算是我的師兄 —— 都是浙大畢業的。
行！我就做程式設計界的拼多多也沒問題！因為很多時候越 “Low”越有市場，當然這個“Low”不是說逼格 Low，而是說我們能不能真正切準使用者的訴求，知道他們的痛點，然後把解決問題的方式、難度降到最低，這樣的話我們能夠最大限度地覆寫非常多的閱聽人，這個可能才是産品本身的價值所在。在這樣的前提下，我們定了一些原則。首先這個東西一定要足夠簡單、足夠“Low”，我們要讓非常多的人能夠用這個産品；但同時它的功能要足夠強大，不然沒有辦法覆寫商業級産品對品質的要求；另外一個就是，無論是什麼樣的重複性工作，終歸是髒活累活，我們希望這樣的髒活累活能夠更多地交給機器去做，而人應該去做一些更有創造力、更有挑戰的事情；再就是我們現在可能還處于孵化過程的一些能力，那就是它不僅僅是一個前端的 IDE，我們希望它是一個集設計、前後端一體化的設計研發平台。
當我們把産品定位想清楚了之後，做起來就不糾結了。而且事實證明我們想的這個東西确實能給大家帶來一些驚喜。今天因為時間的原因，不會跟大家非常細地去講這個産品我們打算怎麼去設計、它未來的發展是怎麼樣，而是跟大家講講我們在做這個産品的過程中的一兩點思考。
3、思考一：像做PPT一樣做應用
首先大家都知道，可視化建站或者說可視化拖拽這個概念其實并不新鮮了，在八幾年、九幾年的時候，就已經開始有第一代産品在嘗試了，但是無論怎樣，幾十年過去了，還有很多産品前赴後繼地來做這件事，這說明了什麼？說明兩個問題：一個是這個問題沒有被徹底解決，否則就不會有那麼多後來者；另外一個就是這個領域可能真的是有需求的，不然也不會有那麼多人去做。
那麼我們希望它到底“Low”到什麼程度，它的門檻要低到什麼樣的程度才能讓設計師和 PD 這樣的角色能參與進來呢？我們首先定下來的原則就是，我們要像做 PPT 一樣去做應用。什麼叫像做 PPT 一樣去做應用呢？大家可以看一下左邊這個小圖，這個是市面上常見的一些同類産品的拖拽方式，這個拖拽方式是基于 Flex 布局的技術，是以當你拖出來一個東西到畫布裡面去的時候，通常隻能上下位添加或者左右位添加。當你想要對這裡面的東西做一些排版的時候，實際上是要經過一系列非常複雜的操作，才能夠把它擺到想要的位置，這是現有的一些産品。
那麼在雲鳳蝶上怎麼做這件事呢？大家看一下，這個真的是像做 PPT 一樣做應用，就是想擺哪就擺哪，沒有什麼布局的概念。實際上這個技術并不算是雲鳳蝶的首創，因為在一些手機端的可視化建站産品當中，已經使用了這個技術，但是在手機端做這個事難度就低很多了。為什麼說它難度很低？首先它不需要去考慮彈性布局的問題，因為手機端雖然說螢幕尺寸有一些差異，但隻要做一個全螢幕的等比縮放這事就解決了，根本不存在布局問題。而沒有布局問題的話，我們也不需要去識别這些元素之間的父子關系。但是這兩個問題在 PC 端都是非常大的問題，經常會有人開玩笑說，把一個專業的開發擋在前端門外的往往都是 CSS。這雖然是一句玩笑話，但也足以說明布局問題的複雜性。是以我們在布局的時候，需要考慮的問題非常多。最終我們決定用這種非常簡單的方式來讓大家使用。比較眼尖的或者說經驗比較豐富的同學可能會看出來，這個像做 PPT 一樣的體驗，效率是沒有左邊這張小圖的高的，但是實際上是有解法的，而且我們正在解。
這就是我們整個産品的底座，它奠定了整個産品的基調。那麼結果如何呢？結果就是大家确實買單了，不僅有前端的同學來用，還有後端的同學，更神奇的是，我們還發現有人拿我們這個做線上 PPT，很神奇，我們看了一下，做的還蠻好的。是以說，當你的産品力達到一定程度的時候，大家對這個産品的想象力可能會超乎大家最初對它的期望。
4、思考二：開放的元件體系
另外一個點就是豐富的精品 UI 資産。大家都知道我們在做應用研發的時候，最重要的兩個東西是什麼？一個是 UI 元件，另外一個是資料連接配接。UI 資産其實就是 UI 元件這方面，通常來說同類産品做這個選擇都會非常艱難，要麼就是一個封閉的資産體系，也就是說我有 100個 元件，你就隻能用這 100 個元件，而好處是這 100 個元件我會把體驗打磨得非常好，而一旦元件不滿足要求，那完蛋，隻能退到 Pro Code。還有另外一種嘗試叫做開放的組建體系，雲鳳蝶是走了這條路。
說到開放的元件體系，什麼叫開放？意思是說凡是在 Pro Code 的世界裡開發的元件，都可以通過簡單的導入操作在雲鳳蝶裡面使用。這個聽起來非常的好，對不對？我們沒有必要重複造輪子，所有在 Pro Code 世界裡非常好的東西，我們都能拿過來用。但實際上要讓使用者能夠用得這麼簡單，難度是非常大的，因為一個小小的 npm 元件的導入，就有非常多的工作要做。比如說元件規範是什麼？如何解析這個 npm 元件？解析後要不要做建構？建構！因為我們不可能像 Pro Code 裡一樣，在使用者釋出的時候說，等一等我跑個 10 分鐘建構。一般來說我們希望它是秒級釋出的，是以我們需要提前把建構的工作做好。再比如一個 npm 元件的屬性編輯怎麼做？這些其實還都隻解決了我們手工操作的問題。我們最終希望，一個 Pro Code 的同學，他每天寫這些元件、釋出這些元件，我們能不能讓他發的時候就直接發到我們這個平台上來，這樣的話無論是用 Pro Code 寫代碼，還是用雲鳳蝶做搭建，它都可以用，這是一個非常好的想法，是以我們最近也在做研發鍊路的打通。
在元件的世界裡面，其實有一個最讓大家頭疼的事情就叫做版本更新，很多産品的版本碎片化非常嚴重，包括我們自己的 Pro Code 的很多元件庫也是這樣。在雲鳳蝶中我們就定了一個原則，那就沒有版本碎片，我們是強制使用者更新的，我們用了一個 Codemod 技術，把所有的元件無縫更新了，使用者看到提示的時候，隻需要無腦點更新就可以。這其實是非常好的嘗試，我們在這些嘗試的過程當中，也跟 Pro Code 的同學有一些交流、溝通，甚至有一些反哺。比如說後續 Pro Code 的同學可能也會嘗試做版本的 Codemod，我們也能反推 Pro Code 的一些元件規範的提升。這個時候開放的元件體系就真正地把 Pro Code 跟 Low Code 融合在一起了，我們能夠共享其中的産出。
5、思考三：資料驅動的智能研發
OK，說到了第三點，就是基于資料連接配接的智能研發，因為髒活累活、重複工作沒有人想做第二遍，但現狀是 —— 我不知道小廠怎麼樣 —— 反正我們大廠這類問題蠻多的，大家可能每天都在跟表單、表格做鬥争，我指的是中背景業務線的同學們。往往我們面臨的業務還蠻複雜，有時候要做一個表單的話，往往是以星期為機關去計算開發工作量的。但實際上摸着良心問一問，做這個東西能有多大成就感？可能大家也覺得沒有那麼多成就感，對不對？畢竟還有那麼多好玩的事。
是以我們就希望讓機器去承擔這一類重複勞動，包括設計。大家可以看一下我們現在在做的一個能力：這是一個表單，選擇了一個 API 之後，你可以選擇要填寫的字段，然後它會根據 API 的元資訊以及它的 API結 構自動生成這個表單。當然這是一個非常簡單的示範，大家可以看到，該有的校驗、排版之類的全部都是機器一鍵自動生成的。
是以這能給我們的整個研發帶來非常多的便利、節約非常多的時間。但是它做起來也是非常坎坷的，因為大家都知道，一旦說到智能化，大家的想法是非常多的，有些人覺得是個銀彈，也有人覺得不那麼靠譜。是以我們最初在決策到底用哪種智能化的方式的時候，也是經曆過非常多的掙紮的。我們到底是從 API 直接到産物，還是去解析設計稿到産物？
最終我們決定從 API 到産物。為什麼？因為中背景應用研發的設計是有一定的規範性的，我們并不會每天看到很多花裡胡哨的中背景研發，而且在表單、表格這樣的主流場景當中，涉及的規範性就更加明顯了，沒有那麼多的設計創新。另外，在 API 上有中繼資料的話，就有非常多的業務資訊，這些是通過圖檔生成代碼無可比拟的優勢。而且還能省略設計師的設計工作。是以我們最後決定，直接就從資料接口生成産物。而在使用哪種 AI 技術上面，當時大家也是有過一些争議的，最後我們還是使用了專家系統這樣的比較簡單的方式，這個方式的效果是比較好的。
大家可以看一下，這張圖是我們去年下半年的時候做的第一版技術原型，左邊的是人工設計的版本，右邊是雲鳳蝶設計研發的版本，大家會有比較明顯的體感，會發現雲鳳蝶的版本更加精緻一些。确實是這樣，不是說人工設計的品質不好，而是 toB 的業務更多是理性的設計，要去做這個東西的話，往往可能有三、四百條設計規則在那等着你，作為一個人，是不擅長去記這些東西的，而這些恰恰是機器擅長做的。
比較搞笑的是，我們從去年年初的時候開始孵化，上半年産出的結果非常矬，後來下半年的時候，覺得這樣下去不行了，得改進。然後就跟設計師一起想，我們才能怎麼做到最好，把這事給做好。當時在會議室裡，我們就說這事要定個目标對吧？總得定個目标。沒人發言，那我就說我們要不就定這樣一個目标，我們把目标定成，産出結果比一般的人工設計師品質要高。這個時候大家都不說話了，都覺得這可是設計啊，這玩意怎麼可能比人工設計要高，頂多接近它。沒辦法，後來我們就說，那我們先接近人工設計的标準吧，後來過了一段時間，我們把技術原型做出來，也就是大家在 Keynote 上看到的這張圖，頓時整個項目組的人都非常受到鼓舞。于是我們覺得，比人工設計的水準要高絕對是 OK 的。後來事實證明确實是這樣，我們在業務當中确實很快就得到了業務的認可。是以很多時候，大家想一些東西時，還是需要更大膽地去想。即便是設計這樣非常有難度的東西，這些在我們看來最不可程式化的東西，也許也是有迹可循的。
6、思考四：混合模式
第四點講一講 Pro Code 跟 Low Code 的混合研發。很多時候像雲鳳蝶這樣的 Low Code 産品，雖然我們想了非常多的創新點，想了非常多的解決使用者痛點的點，但無論怎樣，“你就是個拼多多，我就愛用天貓，我就不用你拼多多”。怎麼辦？這就不是技術問題了，這是一個使用者信心建立的過程。
我們就做了一套方案，基于微前端的架構，把 Pro Code 和 Low Code 的應用給聯合起來，作為一個開發者，他隻需要随心地去選擇合适他自己的研發方式就可以了。
我們看到下面這個是雲鳳蝶自己的一個産品頁面，左邊是我們的 IDE，是用 Pro Code 研發的，右邊代表了所有一系列除 IDE 的其他頁面全部都是用雲鳳蝶自舉的。這個時候确實也不适合用某種單一的研發方式來完成我們的研發工作，而兩者混合可能确實是最好的解決方案。這個解決方案實際上也解決了使用者信心的問題。
比較有趣的地方是，一開始使用者對我們信心不足，然後我們做了這個混合研發的架構，一段時間之後我們發現雲鳳蝶的智能表單、表格太受歡迎了，Pro Code 的同學也不想自己寫了，他們說雲鳳蝶能不能做元件級的混合呀，在雲鳳蝶上的某個元件，能夠嵌到 Pro Code 的代碼裡面去，Pro Code 的 npm 包也能嵌到雲鳳蝶裡面來？OK，這個事可以做，這個事做完之後就變成了什麼？對你來說你無需考慮要選擇哪種研發方式，而是考慮哪種研發方式對你的業務确确實實是最合适的。那些正常的工作，可能确實用雲鳳蝶就非常地快，能又快又好地做完。
雖然最初是因為使用者信心不足，我們來做的這個事，但其實我們發現，當使用者真正接受我們之後，100% 地使用雲鳳蝶來研發的項目是非常多的。除了像雲鳳蝶這樣本身有那麼一兩個很特殊的 IDE 類的複雜度很高的頁面，其他的頁面都非常适合用雲鳳蝶這樣的産品來研發。
7、對未來的思考
今天我在這裡講講可能覺得還挺順理成章的，但實際上過程是比較坎坷的，還不斷地被拷問、被質疑，走到現在可能才剛剛好一些。而對于企業級應用研發 —— 我們内部經常會說中背景應用，這一類其實大家都知道，就像水面下的冰山，往往一個對外的頁面對應的是好多個内部的系統，是以内部系統的量級是非常高的。而如果它有比較高的品質，其實對員工的工作效率有很大的幫助。
左邊這張圖就說明了适用雲鳳蝶的範圍，我們把一個公司裡面的應用分位兩個次元來看，一個是它面向的使用者規模，從小到大是團隊級、部門級、企業級到 toC；另外一個次元是它的互動特殊性。黃色區域都是非常适合用雲鳳蝶這種研發方式來做的。雲鳳蝶其實在上面還有一部分是混合研發的，就是剛剛和大家講過的。
那麼對于未來的企業研發模式，我們認為它是怎麼樣的呢？就是右邊這張圖，上面是現狀，有大量的 Pro Design、Pro Code。雲鳳蝶去年下半年發了第一個版本之後，去年大概有差一點不到 20% 的業務是由雲鳳蝶來承載的。這對雲鳳蝶來說非常不容易，我剛剛講了，我們上面有 OB 這樣的業務在，是以要承載很多複雜應用的研發是很大的一個挑戰。在去年資料裡，有 40% 的産物是通過機器來做設計研發的，大概 60% 是人工。
我們希望未來大概是下面這張圖的樣子，首先 Pro Code 跟 Low Code 是能夠進一步融合的，它們之間能産生實實在在的關聯。比如說能把 Pro Code 産出的元件放到雲鳳蝶裡使用，同時雲鳳蝶也有非常多的天然優勢，它能夠非常精準地收集使用者的需求以及使用者的使用資料，能夠給 Pro Code 的同學非常多的回報，能促成一個良性循環，慢慢地 Pro Design 和 Pro Code 的這些同學會去處理越來越複雜的場景，對于正常的研發工作來說，我們會慢慢收口到像雲鳳蝶這樣的平台上面，并且未來在雲鳳蝶上可能有 70% 的工作是由機器去完成的，剩下的 30%，一部分是設計師來參與，一部分是工程師來參與。我們希望雲鳳蝶能夠為中背景應用研發提效，讓大家有更多的時間和機會去參與更加有挑戰的事情。
好，這就是我近期的一些工作和有趣的事情。
四、一些感悟
接下來跟大家講講做前端的一些感悟吧，比較少哈。
1、認識自己
第一個是知道自己有什麼、要什麼、可以舍棄什麼。在大家的提問裡面，很多的同學都會關注自己要不要走管理，要不要學這個、學那個。實際上問題很簡單，那就是你要什麼、可以舍棄什麼。在我看來，管理是一件九死一生事情 —— 九死一生這詞不嚴重。為什麼我說它九死一生呢？因為至少 10 個人以上的團隊才需要一個兼職的管理者，30 個人以上的團隊可能才需要一個全職的管理者。當你進到管理行列的時候，完全是在另外一個賽道，可能跟你做技術的時候是兩碼事。比如說要考慮到大家怎麼開心地工作、團隊怎麼建立、末位怎麼汰換、怎麼給團隊立下發展方向、怎麼向上溝通彙報。這個時候很多同學可能會說，我們團隊發展得比較快，沒有人帶團隊，那我就得帶；或者說我不帶團隊的話我技術不行，我怎麼辦呢？大家自己想清楚自己要什麼就好了，如果僅僅是因為覺得不帶團隊了可能就沒有前途了之類的，其實并沒有這個必要。我們團隊就有非常多的高 P 的獨立研發者在公司裡面工作，工作得非常好、非常開心，他們也沒有帶團隊，這其實是看個人的發展的。而且如果帶團隊讓你感覺很痛苦的話，可能确實不帶團隊會比較好一些，這是第一點。
2、發現和定義問題
第二點就是學會發現問題、定義問題，至于怎麼解決可以慢慢學。作為程式員，我們很多時候都是解決問題的角色，我們學的都是解決問題的方式方法。但是很多同學 —— 特别是有了一些工作年限的同學，他們在工作的過程當中會慢慢地發現，很多時候發現問題和定義問題會更加重要。打個簡單的比方，剛剛我在說為什麼要去做雲鳳蝶？因為我們有一千多人的前端，有 1/3 在做中背景應用，急需解決研發效能的問題以及門檻的問題。那麼說 1/3 的人在做這個事，其實還是挺有體感的，但是如果你跟老闆說，我覺得現在前端研發的同學效能太低了，這句話可能很難讓老闆 Get 到這個事。是以怎麼去描述問題很重要，包括怎麼去發現問題，因為很多的時候越往前走，你會發現問題就不那麼明顯了，甚至有可能很多時候大家都覺得這不是一個問題，直到你做出來了，他們才說原來你這個真的是很能解決問題的東西呀。這個過程當中，你可能經常會被别人 Diss 或者會被懷疑，但是如果真的想清楚這事應該怎麼做的話，可以堅定一些。
3、注重基礎
第三個是形成自己的知識體系，注重基礎知識的積累。這是我覺得對工作年限比較短的同學來說最重要的事情。對于程式員來說，我們還是要去把本職工作做好，把基礎打好，因為如果基礎不好的話，走到管理崗可能也隻是一種偶然，很難走長遠。在知識體系裡面，有一些是基礎知識，有一些是應用級别的知識，應用級别的知識就是你可能花兩三個月、快的話兩三個星期也能上手的這類。但要能識别出來哪些是基礎的、哪些是應用的。對于基礎知識可能往往要花非常多的心力或者精力去學習，但是一旦你學會了之後，它可能會讓你在很長一段時間裡都能受益。
4、無心插柳
第四點就是學點無用的東西、做點無用的事，見見無用的人。這個可能跟前面的鳗魚小姐姐的說法有一定等同，就是你現在做的這些無用的事，在未來總會連成一串。确實是這樣，我回想了一下，在 2015 年參與開發 Chair —— 就是我們螞蟻的 Node Web架構 —— 這個項目的時候，我做的幾項工作。第一個是打通了跟現有 Java 服務體系，能做成這件事，來源于我工作了之後還花了比較多的精力去學 Java。另外一個就是把當時 Java 的 Velocity 模闆用機器編譯成了 nunjunks 模闆，這個正好是因為之前學了那本龍書 —— 叫《編譯原理》的那本龍書，學完了之後正好就用到了，這個東西如果要想現學的話可能就比較難了，因為我當時斷斷續續看了半年。這個倉庫大家可以看一下，右邊有一張截圖，就是我當時的一些習題記錄放在了 GitHub 上，很多同學在進入阿裡之後就慢慢地不怎麼更新了，我也是一樣的，沒辦法，工作太忙了。但是這個倉庫的 Star 數是一直在漲的，因為你可能找不到第二份習題答案。今天趁着這個大會也想呼籲一下今天的聽衆同學，如果有同學對這個東西比較有興趣的話，也歡迎成為這個倉庫的維護者，因為我實在是忙到無力維護這個東西好多年了，但是我不斷地看到有人在用，不斷有人提 PR，我覺得荒廢掉挺可惜的。
5、追求極緻
第五點就是追求極緻，最難的路可能是最好走的。如果我們選擇了一條比較容易的路，我們往往會面臨低品質的競争；但是如果我們選了一條比較難的路，可能隻是開始比較艱難，但是會越走越開闊。就像開始講到雲鳳蝶在選擇可視化搭建的畫布基礎的時候，我們選擇了一個看起來可能最難的自由拖拽的畫布，因為我們希望使用者能夠有一個像做 PPT 一樣的應用研發體驗，這個确實有非常多的技術難點要解決，當然這個過程當中 Bug 也搞了不少，也被使用者罵了不少，但是做到今天，我們真正覺得這條路是走對了，而且我們不斷地得到使用者的認可。
五、書籍推薦
按照大會的慣例，需要給大家推薦一本書。我先說一下，如果大家覺得大學沒有學好，那可能是因為教材比較渣，一定不要覺得是自己比較渣。這個我是深有體會的，因為很多大學的課程我在工作了之後又重新學了一遍，學的時候我就換了教材。
這是我給大家推薦的幾本書。為什麼是幾本書呢？因為這些書其實是有一定的關聯性的。上面的三本是《微積分》、《線性代數》跟《機率論》，這個可能是我們所有同學在讀大學的時候基礎的三門課程。下面是大家可能會覺得現在比較熱門的、同學們也比較想去了解的，是《資料挖掘》以及《人工智能》。很多時候大家會看到有一些所謂的人工智能的入門書之類的，我建議大家如果真的對這兩個東西感興趣的話，可以看一看這兩本書。這兩本書都非常厚，但是《人工智能》這本書非常全面地講述了人工智能領域所有的東西，當然有一些東西可能在今天看來比較過時，但仍然建議大家讀一讀，耐心一點把這本書讀完。這本書讀完了之後，對人工智能能帶來哪些好處，或者說哪個方案會比較靠譜一些，你就會有比較堅定的自己的看法，包括你要跟相關的同學去溝通，你是不會發怵的。然後另外一個就是《資料挖掘》，現在大家都用資料說話嘛，是以資料挖掘也很重要。這本導論好就好在非常淺顯易懂，基本上所有的方式方法你都能看得懂、用得着。是以這兩本書非常推薦。
那為什麼還推薦了上面的那一排基礎書呢？因為在人工智能領域有一些基礎的算法，可能讓大家覺得最頭疼的就是這些東西，正好上面的那本《線性代數》對應了人工智能行業非常多的基礎算法，可以說是非常合适的一本人工智能算法基礎的入門書。如果大家有興趣的話，建議也看一看這本。包括上面的《機率論》也是一樣的，因為在資料挖掘的時候，機率有非常大的作用。好了，這就是今天我推薦的一些書，不要被這些書吓到，雖然看着都很厚，但是其實看着還挺有趣。
六、加入我們
好，到了最後了，這就是今天來跟大家聊的最大的動力，是以希望大家有什麼問題的話也歡迎跟我交流，
七、Q & A
1、比較糾結，自己作為前端，不懂服務端的東西，而且平時工作也不太會涉及到服務端，自己想學一些服務端，但是又不知道如何下手，常常會陷入深深的自我懷疑，請問沉魚小姐姐有沒有一些好的建議？
如果是早期的前端，可能基本上都是從自我懷疑當中走過來的。我剛才講過沒有 Node.js 的時代，大家對服務端是很難插上手的。雖然可能有一部分同學會寫 PHP，但是如果 PHP 沒有用在你公司的生産環境裡面，那也沒有太多的用武之地。
我覺得比較靠譜的、比較有可操作性的兩個建議是：
第一，看看你公司的整個服務端的架構是什麼，然後可以學一學跟公司服務端架構貼近的東西，比如說你的公司用的是 Java —— 可能大部分公司都是用 Java，有一些創新公司會用 Node.js，那麼那就學學 Java 呗。學一門語言在我看來是應用級别的東西，是以應該不會特别難才對。找到一些機會，然後學它、用它。
第二，我們要注重基礎能力的培養，比如說你學 Java，到底知不知道一個 HTTP 請求是什麼？HTTPS 請求跟它的差別是什麼？最新的 HTTP2、HTTP3 到底是什麼東西？因為這些東西包括多程序、多線程之類的，可能才是語言下面真正常用的那些知識。很多的同學在學語言的時候覺得暈，不是暈那個語言，而是因為那個語言下面那個知識可能不是很牢固。是以第二個建議就是去學習一下這些相關的知識。
然後第三個建議就見仁見智了，去更有挑戰的地方。
2、你是如何掌握自己的時間的？如何掌握自己去學這麼多東西？對于前端團隊人比較少的情況，一般都是業務來推動開發，這種情況下應該如何去處理，逐漸讓技術跟業務互相推動？
“掌控自己的時間”，首先還是不得不說一下，跟今天其他的分享嘉賓相比較而言，我的工作年限可能确實是比較長的，是以我就有更多的時間來學東西。你工作五、六年你肯定沒有那麼多時間學。另外一個，我确實比較珍惜早晨的時間，我通常會比較早就起。如果平時我們公司 9:00 上班的話，我可能 6:30 到 8:00 左右之間，大概會有一個半小時的時間會持續地學習一些東西，這段時間一定是不會被幹擾的，是非常高效的一段時間。當然現在說起來有點臉紅，因為幾年前我生了我們家寶寶，這個對女生來說确實會有一些影響，但是也沒有太多的辦法，隻能不斷地校準自己的時間。
“對于前端人數比較少的團隊來說，通常都是業務推動開發”，對于大的前端團隊來說也是這樣的，沒有太多的差別。隻是大家在這個場景下怎麼去看待業務，比如你能不能在現有的業務裡面看到一些更遠的東西，這個很重要。其實我所在的團隊可能是螞蟻特别大的一個前端團隊，但是也有一些團隊是前端是比較大的，比如說我剛剛說的有一個大資料開發的 IDE，那個團隊的同學，其實也是很厲害的，跟業務的大小有一定關系，但也并不是絕對的，有一些小團隊他們可能做出來的東西也是很厲害的。另外如果說，你實在覺得沒有太多的發揮之處了，比如說你每天在家掃地，掃地機器人這玩意你要是能想到可能特别牛，如果要是想不到的話，可能還是在家每天掃地，覺得沒有什麼價值感，可能确實得停下來想想自己想做的這個事的價值到底是什麼。最後如果覺得還是想不清楚，跟别人聊了也很迷茫的話，建議去看一看其他團隊，那些你覺得做得特别好的、有活力的團隊，他們是怎麼做的，或者說換個環境也是 OK 的。
3、為什麼是 API 到産物，而不是 UI 到産物？B 端跟 C 端的産品又有什麼樣的差別？
在我們公司内部有一個叫做 API 平台的東西，集合了公司所有能用的 API 以及一些 API 的元資訊，這個元資訊雖然說不全，但是在雲鳳蝶裡面是能夠補全的。元資訊是什麼？比如有一個叫做 userId 的字段，它可能是員工 id，當你有這樣一些元資訊的時候，你對 API 的了解就會更加豐富一些，你從這個 API 生成的産物，第一，它是集合了我們設計團隊對整個設計規則的了解，也就是機器來做設計；第二，因為我們知道 API 上很多的元資訊，是以更加能了解業務，能做出來直接可以做最後傳遞的東西。如果說是 UI 到産物的話，那麼你缺失了非常重要的業務資訊，你隻能根據它長什麼樣把這個頁面切出來，但實際上沒有辦法完成功能的閉環，同時你還需要設計師先去做設計的工作。但問題也分具體場景，就是我剛才強調說，中背景研發不是對設計品質要求不高，而是對設計的特殊性、互動的特殊性要求不那麼高，因為表單你不要做出一個花來對吧？這個時候 UI 到産物，它也有很多的應用場景，比如說我們在做一些促銷的時候，推薦寶貝、推薦産品這樣的東西，它的邏輯可能是偏少的，更多偏展示，這個時候 UI 到産物就比較好用。
B 端和 C 端的産品差別，籠統一點來說，我覺得 B 端的産品更多是完成功能性的需求，對于設計的特殊性要求是沒有那麼高的，但是并不意味着我們對品質的要求就低。因為你看我們有那麼多對外的商業的 toB 的産品，那就必然意味着它的要求是很高的。而且 B 端的邏輯可能複雜到難以想象，很多時候做 C 端的同學會覺得 B 端非常簡單，就是做表單、表格，但是當你面臨 800 個字段的表格、表單的時候，你要怎麼搞？這個事情可能在 C 端是很難想象的。對于 C 端來說，它同樣有非常多的挑戰，比如說設計的新穎性、先進性，包括 C 端的體量非常大，這個體量可能是 B 端沒有辦法去比的，這就得具體問題具體看了。
4、身邊的程式員是否都大部分都堅持了本行？有沒有其他人轉行的？轉行的同學又是去做了什麼？
我認識的大部分人可能都還是比較 Geek 的，是以很多人都還堅持在寫代碼的一線，包括一些高 P 的同學，也都在每天寫代碼。但是也有轉行的，不是說程式員這條路一定要一條路走到黑，大家可以根據自己的規劃去走。比如說我們有認識的一些同學可能覺得，沒問題，我到 P6、P7，我掌握了整個前端研發一些基礎的東西之後，我出去創業，也有這樣的同學，其實過得還挺好的，可能比我們要滋潤很多。但這個就看個人選擇了。還有一些做管理的，确實是少數，因為像剛剛說的，那個比例在那，比如說 30 個人才有 1 個管理者，這就意味着管理崗畢竟是很少的。