摘要：楊永林，人稱教主，八年前端開發經驗，原新浪微博前端技術專家，現任鏈家網前端總架構師。年年底，教主加入鏈家網，負責前端的整體架構工作。

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

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

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

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

工作過一些年以后，我發現僅僅提高自身的開發效率是遠遠不夠的，團隊需要整體的提升。發現這一點后，我開始制作并完善各種開發工具，編寫開發框架。

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

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

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

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

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

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

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

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

前端構建工具前后有Grunt/Gulp、Webpack、npm scripts等，您對這些工具有什么看法，哪個更好？如何選擇適合公司產品的工具？應從哪些方面考慮？

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

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

楊永林：首先，制定規范、分享經驗是免不了的，但紙上得來終覺淺吧，很多時候，親身踩一次坑，得到的經驗才會深刻。而我所要做的是在團隊成員踩到坑的時候降低這件事造成的后果。比如我提供的開發環境是可以完全模擬線上環境的，測試代碼和線上保持一致，很多意外情況都可以在開發、測試期被發現。同時，制定的開發規范要由工具檢測來保證，不符合規范的代碼不能夠打包上線。對于規范代碼可以使用工具計算出業務影響范圍，能有效保證測試覆蓋面。總的來說，踩坑不要緊，架構來幫你兜底，爬出坑的過程就成為了團隊成員所得到的財富。

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

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

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

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

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

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

選這個指標有兩點考慮：一是因為它并不是一個技術指標，而是一個感知指標，所以更接近人類的感受。二是旁路檢測，它并不在系統內，不是系統匯報上來的數據，這樣就有效的規避了幸存者偏差的問題。當然它也有些不足：一是數據采樣小，二是可以被欺騙。所以可能需要一點兒統計學功底和性能監控的正確認識。

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

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

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

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

據說有些同事在對技術的討論中以“擊敗”您為榮，您是如何看待的？這對團隊及其個人的發展帶來了哪些影響？

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

我很喜歡在團隊內扮演一種“反派”的角色，從反面的角度分析問題，去挑戰別人的方案。其實，我不是真的去否定他，而是希望他的方案是經過反復推敲、深思熟慮產生的，這樣的方案會更健壯。時間長了，他們會覺得我是一個愛抬杠的人，就會做足準備來“挑戰”我。能把我說得接不上話來，他們會覺得很開心。這個結果是我想看到的，因為這說明團隊成員在解決問題時進行了充分的思考。

您為什么放棄了在之前新浪微博的元老級身份，而選擇加入鏈家網？

楊永林：這可能源自我對工作的看法吧，我覺得人生活在社會上，工作是在為社會創造價值和財富，這和他具體從事哪種職業沒有直接關系?，F在行業里有一種風氣，就是覺得程序員寫好代碼就好了，不用關心自己做的事情是什么。甚至社會上也給程序員打一些什么“木訥”、“情商低”之類的標簽。我覺得不應該是這樣的，程序員也是社會人，也有他的社會責任，也有家庭責任，也需要陪伴他的伴侶，照顧他的小孩，不是每天只是面對代碼而不管其他的事。人不要因為群體印象就把自己限制住，人的生活就應該是多種多樣、豐富多采的，人生應該是有意義的。

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

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

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