沉魚，螞蟻集團體驗技術部的高級前端專家。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 個管理者，這就意味著管理崗畢竟是很少的。