鏈家網前端總架構師楊永林：個人8年架構師成長之路

楊永林，人稱「教主」，八年前端開發經驗，原新浪微博前端技術專家，現任鏈家網前端總架構師。長期研究Web訪問性能優化和前端框架搭建。
做爲初始團隊成員，教主參與了新浪微博全部PC版本的開發，其中4~6版以架構師的身份設計了微博PC版的前端架構。在新浪微博任職期間，教主設計實現了流水線加載技術與模塊化代碼組織，達到了在提升訪問性能的同時極大下降了開發成本的目的。主要研究方向是Web訪問性能優化與框架組織。在國內爲數很少地實現了BigPipe技術，極大地提高了微博的訪問速度。同時，微博的前端代碼基礎包、前端框架和構建工具均出自教主之手。
2015年年末，教主加入鏈家網，負責前端的總體架構工做。
在8年的前端開發生涯中，教主是如何一步一步地成爲知名前端架構師的呢？爲什麼選擇加入了鏈家網呢？

您在微博和鏈家都是前端架構師，能說說前端架構師這個工種具體是作什麼的嗎？

楊永林：我對架構師所擔任的職責的認識是一步步變化，慢慢深刻的。

在剛參加工做的時候，我以爲架構師就是代碼寫得又快又好的人，是工程師的晉級版本。

工做過一些年之後，我發現僅僅提升自身的開發效率是遠遠不夠的，團隊須要總體的提高。發現這一點後，我開始製做並完善各類開發工具，編寫開發框架。

最近幾年，隨着迭代開發了一些產品本，我又發現以前可以提高效率的框架工具頗有可能在後來成了產品發展的絆腳石。這時，我開始考慮架構設計的指導原則，開始考慮取捨。一些在短時間內可以提高效率但不符合原則的東西，我就選擇不作或者想辦法在原則的指導下進行改進。好比我相信可變化的代碼纔是有生命力的代碼，在架構設計上我也會趨向於讓項目的代碼能夠一點一點的變化演進，不是那種一言不合就重構到狀態。因此我認爲前端架構師就是那種在前端領域提出開發的指導原則，在原則下設計開發框架和開發工具，讓更多的開發者能夠協同工做的人。

您在新浪微博的時候設計了前端架構，可否介紹一下包括了哪些組成部分，有什麼關鍵技術？

楊永林：主要是代碼基礎包，頁面加載框架和前端構建工具。

早期前端開發面臨兩個主要問題是瀏覽器兼容和API不夠豐富，基礎包通常都是用來解決這兩個問題。當時新浪有一個本身的Sina包，可是代碼比較零散，模式也不統一，各產品線有本身的擴展，一樣的功能可能有多種實現，不太好維護。後來我用業餘時間開發了一個帶有命名空間管理功能的基礎包，特色就是簡單清晰，易於使用，被團隊採納做爲了微博的基礎包使用至今。

頁面加載框架是被需倒逼着產生的，2010年微博業務膨脹，頁面展現的內容愈來愈多，這使得頁面響應速度也變得愈來愈慢。我所在的團隊接到的需求是要求在內容變多的狀況下將響應速度變得更快。

這個時候Facebook推出了BigPipe技術，咱們以爲這個理念正好可以解決咱們應對的問題，因此決定實施，但當時Facebook只是分享了他們的作法，並無提供實現，因此對我來講也是巨大的挑戰。我當時將頁面劃分紅多個獨立的子模塊，模塊是徹底能夠自主運行的，模塊能夠嵌套，因此頁面就是一批模塊的樹形堆疊。服務端用Chunked的方式將模塊的信息以JavaScript代碼塊的方式傳輸到頁面，而前端須要作的很重要的工做是管理每一個模塊的生命週期。

我很榮幸那時能有機會和團隊成員一塊兒開發了這個加載框架，咱們多是國內第一個在大型互聯網應用上全面使用這項技術的。以後的一年我一直致力於此項技術的優化工做，好比支持服務端亂序輸出，保證服務端可使用並行策略，壓縮，減小前置依賴條件等，並在2013年與@Laruence（鳥哥）合做實施了CBigPipe（並行的BigPipe）技術，進一步提升了這項技術的性能。微博的V5版的加載性能也達到了頂峯，頁面的加載速度幾乎至關於靜態網頁。

前端構建工具是這幾年纔開始流行，其實早在2008年的時候，新浪就已經使用前端小文件開發，使用構建工具進行開發，測試和上線。如今想一想應該是比較超前了，不過那時的版本是須要PHP、Python和Java環境，團隊維護起來比較困難，並且使用的是字符串替換方案，功能比較有限。2012年我將這個工具進行了改造，使其僅須要Node環境，同時支持開發、測試部署和打包上線。因爲使用了UglifyJS，有了語法樹，我加了一些之前沒有的功能，好比預編譯的模版引擎、支持模版嵌套和母模版、代碼健康度檢測、冗餘模塊分析等。

前端構建工具先後有Grunt/Gulp、Webpack、npm scripts等，您對這些工具備什麼見解，哪一個更好？如何選擇適合公司產品的工具？應從哪些方面考慮？

楊永林：我以爲這些工具備效地解決了前端開發效率的問題，它們的出現都是對技術的推進，若是在我作工具的時候有這些項目的出現，會減小我不少的工做量。至於哪一個更好，我以爲，你能掌握哪一個，哪一個就是最好的。由於說到底，工具是爲你的業務服務的，你可能須要對它作些改造或者是寫一些擴展，在這個時候你發現你對他的熟悉變的很重要。構建工具的遷移成本仍是挺高的，我不太推薦頻繁地變動它，因此最好不要追着流行走，仍是要根據本身團隊的特色，因地制宜地選擇一款合適的。若是不是超大型的應用，其實build的結果的影響並無太大的差別，與其想着哪一個更好哪一個更牛逼，不如將其中一個玩熟玩透。

如何保證團隊成員不會踩到一樣的坑？在設計框架和構建工具時有無這方面的考慮？請舉例說明。

楊永林：首先，制定規範、分享經驗是免不了的，但紙上得來終覺淺吧，不少時候，親身踩一次坑，獲得的經驗纔會深入。而我所要作的是在團隊成員踩到坑的時候下降這件事形成的後果。好比我提供的開發環境是能夠徹底模擬線上環境的，測試代碼和線上保持一致，不少意外狀況均可以在開發、測試期被發現。同時，制定的開發規範要由工具檢測來保證，不符合規範的代碼不可以打包上線。對於規範代碼可使用工具計算出業務影響範圍，能有效保證測試覆蓋面。總的來講，踩坑沒關係，架構來幫你兜底，爬出坑的過程就成爲了團隊成員所獲得的財富。

您認爲對Web訪問性能的優化須要關注哪些方面？其中，最值得關注的點是什麼？爲何？

楊永林：我以爲性能優化須要方方面面都要兼顧，包括網絡時間、服務器計算時間、頁面請求數、下載量、頁面載入模型等。而這裏面任何一項的性能提高可能都須要你修改大量代碼或者調整架構來實現，可是獲得的效果可能就是一點點。所以不多見到銀彈，通常都是一點一點地作出來的。我這裏談兩個我以爲比較值得關注但很容易被忽視的點吧。

一是你所服務產品的形態，用戶關心什麼，這是一些工程師比較容易忽略的。有些產品須要用戶打開時很快，有些須要用戶使用時流暢；有些產品用戶能夠容忍看舊數據，而有些則必須是新內容；有些產品用戶一天打開不少次，而有些看一次就關掉了。這些產品需求的差別都會影響你的決策。

二是評測標準，用什麼來測量性能的好壞。一些人認爲請求數或者請求量減小了，訪問就快了，其實這是不必定的，有可能你花了很大精力作的事情在用戶看來並無什麼太大變化。因此，找一個評測標準讓每個優化在數據上有所體現是很重要的。

度量前端性能的指標有哪些？如何對Web訪問性能進行監控？

楊永林：我所服務的產品通常都關注訪問性能，也就是用戶看到內容的快慢，因此咱們通常用首屏時間來評估，通常的性能檢測服務商都能提供這個指標。

選這個指標有兩點考慮：一是由於它並非一個技術指標，而是一個感知指標，因此更接近人類的感覺。二是旁路檢測，它並不在系統內，不是系統彙報上來的數據，這樣就有效的規避了倖存者誤差的問題。固然它也有些不足：一是數據採樣小，二是能夠被欺騙。因此可能須要一點兒統計學功底和性能監控的正確認識。

在監控的過程當中，一是要關注長期趨勢的變化，若是不是突發情況，單點的數據的絕對值是沒有意義的，要收集長期的數據，分析其中的變化，當有變動的時候尤爲要關注數據的變化。二是關注最差25%的情況，有些人，會在公司內網刷本身的產品，感受挺快，其實不論你用什麼手段，只要網快，用戶的體驗都不會太差，體驗的差別在於最差那部分用戶。三是從不一樣維度分析數據，如地區、網絡、時段、運行環境等。

前端工程師如何成爲前端架構師，除了編程能力和架構知識，還須要培養哪些能力？

楊永林：我想，大部分領域的架構師工做都是差很少的，就是搭建一個解決問題的框架，讓團隊成員能在框架下良好的配合工做，完成產品的開發需求。

咱們知道，解決一個問題的手段有不少，在這個過程當中取捨就很重要了，咱們也知道，沒有銀彈，不多能碰見那種全面優點的解決方案，大部分方案都是犧牲掉一部分東西來換取一部分東西。所以，做爲架構師，不只要對各個技術方案的特色、成本要熟知（也就是編程能力和架構知識），還要學會如何選擇。顯然，架構師須要根據產品的特色和發展方向作出決定，在前端領域的架構要能讓配合的團隊對接的順暢。那麼在這個過程當中，良好的溝通能力、同理心、利他的思惟方式，就顯得很重要了。由於咱們不只要完成開發任務，也要思考在本身的領域內如何幫助項目解決問題。

聽說有些同事在對技術的討論中以「擊敗」您爲榮，您是如何看待的？這對團隊及其我的的發展帶來了哪些影響？

楊永林：這是我一個毛病，喜歡給別人的方案着茬。我以爲這是一個思辨的過程，經過從不一樣角度分析問題，去挑戰解決方案的合理性，才能讓問題解決的更穩妥。在知識的獲取中也是這樣，一次一次地去問爲何，去追根溯源，才能讓知識體系更牢固。

我很喜歡在團隊內扮演一種「反派」的角色，從反面的角度分析問題，去挑戰別人的方案。其實，我不是真的去否認他，而是但願他的方案是通過反覆推敲、深思熟慮產生的，這樣的方案會更健壯。時間長了，他們會以爲我是一個愛擡槓的人，就會作足準備來「挑戰」我。能把我說得接不上話來，他們會以爲很開心。這個結果是我想看到的，由於這說明團隊成員在解決問題時進行了充分的思考。

您爲何放棄了在以前新浪微博的元老級身份，而選擇加入鏈家網？

楊永林：這可能源自我對工做的見解吧，我以爲人生活在社會上，工做是在爲社會創造價值和財富，這和他具體從事哪一種職業沒有直接關係。如今行業裏有一種風氣，就是以爲程序員寫好代碼就行了，不用關心本身作的事情是什麼。甚至社會上也給程序員打一些什麼「木訥」、「情商低」之類的標籤。我以爲不該該是這樣的，程序員也是社會人，也有他的社會責任，也有家庭責任，也須要陪伴他的伴侶，照顧他的小孩，不是天天只是面對代碼而無論其餘的事。人不要由於羣體印象就把本身限制住，人的生活就應該是多種多樣、豐富多采的，人生應該是有意義的。

就我我的而言，在過去的幾年，我所服務的產品不只加深了人們之間的溝通和理解，也使得國家的信息變得更透明。而我所作的工做對這樣的一個產品作出了貢獻，能夠說個人工做讓世界變得美好了那麼一點點。這讓我以爲個人人生增添了那麼一點意義。而當我搭建起前端框架後，我我的能起的做用變得愈來愈小，我能繼續創造的價值也愈來愈少，因此須要另外一個平臺來繼續發揮個人能量。

這時我有機會接觸到鏈家網，這家公司致力於解決人們的居住問題，它讓中國最大的市場變得透明、有序。我以爲鏈家網作的是頗有意義的事，同時，它僅僅用了不到兩年的時間，就集結了一批各領域的牛人，維護了國內規模最大的房地產交易系統，用技術手段讓房屋的買賣變的更輕鬆、透明、快捷。在與鏈家網的接觸中，我感覺到了那種積極解決問題的活力和務實作事的態度。再加上鍊家網中大部分技術人，在以前也都是各個大型互聯網公司的中堅力量，我想沒有什麼比與志同道合的人來一塊兒改變世界更使人激動的了。此時，鳥哥專門來邀請我加入鏈家網，我就絕不猶豫地贊成了。

教主答羣友問：Q：您對初級前端人員有什麼好的建議嗎？A：多嘗試一些解決方案，多想一想這些方案的特色，對別人的方案深究原理。Q：前端學習方面有什麼書籍能夠介紹嗎？A：如今前端書籍都挺多挺好多呀，我通常推薦高級程序設計，圖解CSS3。Q：您在擔任架構師這個角色中遇到的最嚴重的線上事故是什麼？當時是怎麼解決的？A：工做這麼多年，在前端應該就只有一次B級故障，作非前端的時候卻是經過大簍子，由於上線速度比較快，並且大問題也都是很明顯的解決方案，因此就是快速上線了。這個要感謝測試同窗，很給力，避免了不少線上故障。Q：學前端是否去參加商業培訓更見效？亦或是這種商業培訓反而更會僵化思惟？這樣流水線培訓出來的學員在企業承認度如何。A：我沒參見過商業培訓，也不太好評價，我是以爲被灌輸的知識可能不如本身躺坑得來的紮實吧。企業承認這方面，我基本只看能力。Q：對於您來講技術比較重要仍是產品比較重要？由於剛纔您說是由於以爲鏈家的「產品」比較有意義才考慮去的，那能理解爲你以爲產品比技術更重要嗎？A：我所說的產品不是「產品人員」，是公司的產出的服務。顯然對於一家公司來講，產品是最重要的，技術是如何實現產品的手段啊。Q：您以爲什麼樣的代碼纔算是可變化的代碼？這方面又作出了哪些實踐？有哪些系統化的產出？A：我說變化的代碼其實代碼是可控的，能夠方便的去調整項目，能夠一步一步的改造項目而不是重構，我作開發一致遵循這個理念。Q：前面提到搭建團隊可用的框架，但我感受這個工做量很是巨大並且須要不少改進和測試，教主當時有同感嗎？怎麼解決這麼大的工做量問題？A：我可能比較幸運，曾經有一段時間來調整結構，我是這樣想的，每當我向前邁一步的時候，我就是在進步，因此我沒有急於讓架構搭建一次到位，我會想好調整的步驟，每一步都會讓架構進步，把大問題拆解成小問題一步一步作。Q：小公司開發前端，因爲缺乏項目管理經驗，致使許多冗餘性的工做，請問教主在管理方面有何建議？A：這個不一樣公司的狀況都不同吧，不太好建議。Q：多嘗試一些解決方案和「一步一步逐步改進產品」是否矛盾？A：不矛盾啊，多嘗試不表明多實施啊。