楊永林，人稱“教主”，八年前端開發經驗，原新浪微博前端技術專家，現任鏈家網前端總架構師。長期研究Web訪問效能最佳化和前端框架搭建。
作為初始團隊成員，教主參與了新浪微博所有PC版本的開發，其中4~6版以架構師的身份設計了微博PC版的前端架構。在新浪微博任職期間，教主設計實現了流水線載入技術與模組化程式碼組織，達到了在提高訪問效能的同時極大降低了開發成本的目的。主要研究方向是Web訪問效能最佳化與框架組織。在國內為數不多地實現了BigPipe技術，極大地提升了微博的訪問速度。同時，微博的前端程式碼基礎包、前端框架和構建工具均出自教主之手。
2015年年底，教主加入鏈家網，負責前端的整體架構工作。
在8年的前端開發生涯中，教主是如何一步一步地成為知名前端架構師的呢？為何選擇加入了鏈家網呢？
1. 您在微博和鏈家都是前端架構師，能說說前端架構師這個工種具體是做什麼的嗎？
楊永林：我對架構師所擔任的職責的認識是一步步變化，慢慢深入的。
在剛參加工作的時候，我覺得架構師就是程式碼寫得又快又好的人，是工程師的晉級版本。
工作過一些年以後，我發現僅僅提高自身的開發效率是遠遠不夠的，團隊需要整體的提升。發現這一點後，我開始製作並完善各種開發工具，編寫開發框架。
最近幾年，隨著迭代開發了一些產品本，我又發現之前能夠提升效率的框架工具很有可能在後來成了產品發展的絆腳石。這時，我開始考慮架構設計的指導原則，開始考慮取捨。一些在短期內能夠提升效率但不符合原則的東西，我就選擇不做或者想辦法在原則的指導下進行改進。比如我相信可變化的程式碼才是有生命力的程式碼，在架構設計上我也會趨向於讓專案的程式碼可以一點一點的變化演進，不是那種一言不合就重構到狀態。所以我認為前端架構師就是那種在前端領域提出開發的指導原則，在原則下設計開發框架和開發工具，讓更多的開發者可以協同工作的人。
2. 您在新浪微博的時候設計了前端架構，能否介紹一下包括了哪些組成部分，有什麼關鍵技術？
楊永林：主要是程式碼基礎包，頁面載入框架和前端構建工具。
早期前端開發面臨兩個主要問題是瀏覽器相容和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的結果的影響並沒有太大的差異，與其想著哪個更好哪個更牛逼，不如將其中一個玩熟玩透。
3. 如何保證團隊成員不會踩到同樣的坑？在設計框架和構建工具時有無這方面的考慮？請舉例說明。
楊永林：首先，制定規範、分享經驗是免不了的，但紙上得來終覺淺吧，很多時候，親身踩一次坑，得到的經驗才會深刻。而我所要做的是在團隊成員踩到坑的時候降低這件事造成的後果。比如我提供的開發環境是可以完全模擬線上環境的，測試程式碼和線上保持一致，很多意外情況都可以在開發、測試期被發現。同時，制定的開發規範要由工具檢測來保證，不符合規範的程式碼不能夠打包上線。對於規範程式碼可以使用工具計算出業務影響範圍，能有效保證測試覆蓋面。總的來說，踩坑不要緊，架構來幫你兜底，爬出坑的過程就成為了團隊成員所得到的財富。
4. 您認為對Web訪問效能的最佳化需要關注哪些方面？其中，最值得關注的點是什麼？為什麼？
楊永林：我覺得效能最佳化需要方方面面都要兼顧，包括網路時間、伺服器計算時間、頁面請求數、下載量、頁面載入模型等。而這裡面任何一項的效能提升可能都需要你修改大量程式碼或者調整架構來實現，但是得到的效果可能就是一點點。因此很少見到銀彈，一般都是一點一點地做出來的。我這裡談兩個我覺得比較值得關注但很容易被忽視的點吧。
一是你所服務產品的形態，使用者關心什麼，這是一些工程師比較容易忽略的。有些產品需要使用者開啟時很快，有些需要使用者使用時流暢；有些產品使用者可以容忍看舊資料，而有些則必須是新內容；有些產品使用者一天開啟很多次，而有些看一次就關掉了。這些產品需求的差異都會影響你的決策。
二是評測標準，用什麼來測量效能的好壞。一些人認為請求數或者請求量減少了，訪問就快了，其實這是不一定的，有可能你花了很大精力做的事情在使用者看來並沒有什麼太大變化。所以，找一個評測標準讓每一個最佳化在資料上有所體現是很重要的。
5. 度量前端效能的指標有哪些？如何對Web訪問效能進行監控？
楊永林：我所服務的產品一般都關注訪問效能，也就是使用者看到內容的快慢，所以我們一般用首屏時間來評估，一般的效能檢測服務商都能提供這個指標。
選這個指標有兩點考慮：一是因為它並不是一個技術指標，而是一個感知指標，所以更接近人類的感受。二是旁路檢測，它並不在系統內，不是系統彙報上來的資料，這樣就有效的規避了倖存者偏差的問題。當然它也有些不足：一是資料取樣小，二是可以被欺騙。所以可能需要一點兒統計學功底和效能監控的正確認識。
在監控的過程中，一是要關注長期趨勢的變化，如果不是突發狀況，單點的資料的絕對值是沒有意義的，要收集長期的資料，分析其中的變化，當有變更的時候尤其要關注資料的變化。二是關注最差25%的狀況，有些人，會在公司內網刷自己的產品，感覺挺快，其實不論你用什麼手段，只要網快，使用者的體驗都不會太差，體驗的差異在於最差那部分使用者。三是從不同維度分析資料，如地區、網路、時段、執行環境等。
6. 前端工程師如何成為前端架構師，除了程式設計能力和架構知識，還需要培養哪些能力？
楊永林：我想，大部分領域的架構師工作都是差不多的，就是搭建一個解決問題的框架，讓團隊成員能在框架下良好的配合工作，完成產品的開發需求。
我們知道，解決一個問題的手段有很多，在這個過程中取捨就很重要了，我們也知道，沒有銀彈，很少能遇見那種全面優勢的解決方案，大部分方案都是犧牲掉一部分東西來換取一部分東西。因此，作為架構師，不僅要對各個技術方案的特點、成本要熟知（也就是程式設計能力和架構知識），還要學會如何選擇。顯然，架構師需要根據產品的特點和發展方向做出決定，在前端領域的架構要能讓配合的團隊對接的順暢。那麼在這個過程中，良好的溝通能力、同理心、利他的思維方式，就顯得很重要了。因為我們不僅要完成開發任務，也要思考在自己的領域內如何幫助專案解決問題。
7. 據說有些同事在對技術的討論中以“擊敗”您為榮，您是如何看待的？這對團隊及其個人的發展帶來了哪些影響？
楊永林：這是我一個毛病，喜歡給別人的方案著茬。我覺得這是一個思辨的過程，透過從不同角度分析問題，去挑戰解決方案的合理性，才能讓問題解決的更穩妥。在知識的獲取中也是這樣，一次一次地去問為什麼，去追根溯源，才能讓知識體系更牢固。
我很喜歡在團隊內扮演一種“反派”的角色，從反面的角度分析問題，去挑戰別人的方案。其實，我不是真的去否定他，而是希望他的方案是經過反覆推敲、深思熟慮產生的，這樣的方案會更健壯。時間長了，他們會覺得我是一個愛抬槓的人，就會做足準備來“挑戰”我。能把我說得接不上話來，他們會覺得很開心。這個結果是我想看到的，因為這說明團隊成員在解決問題時進行了充分的思考。
8. 您為什麼放棄了在之前新浪微博的元老級身份，而選擇加入鏈家網？
楊永林：這可能源自我對工作的看法吧，我覺得人生活在社會上，工作是在為社會創造價值和財富，這和他具體從事哪種職業沒有直接關係。現在行業裡有一種風氣，就是覺得程式設計師寫好程式碼就好了，不用關心自己做的事情是什麼。甚至社會上也給程式設計師打一些什麼“木訥”、“情商低”之類的標籤。我覺得不應該是這樣的，程式設計師也是社會人，也有他的社會責任，也有家庭責任，也需要陪伴他的伴侶，照顧他的小孩，不是每天只是面對程式碼而不管其他的事。人不要因為群體印象就把自己限制住，人的生活就應該是多種多樣、豐富多采的，人生應該是有意義的。
就我個人而言，在過去的幾年，我所服務的產品不僅加深了人們之間的溝通和理解，也使得國家的資訊變得更透明。而我所做的工作對這樣的一個產品做出了貢獻，可以說我的工作讓世界變得美好了那麼一點點。這讓我覺得我的人生增添了那麼一點意義。而當我搭建起前端框架後，我個人能起的作用變得越來越小，我能繼續創造的價值也越來越少，所以需要另一個平臺來繼續發揮我的能量。
這時我有機會接觸到鏈家網，這家公司致力於解決人們的居住問題，它讓中國最大的市場變得透明、有序。我覺得鏈家網做的是很有意義的事，同時，它僅僅用了不到兩年的時間，就集結了一批各領域的牛人，維護了國內規模最大的房地產交易系統，用技術手段讓房屋的買賣變的更輕鬆、透明、快捷。在與鏈家網的接觸中，我感受到了那種積極解決問題的活力和務實做事的態度。再加上鍊家網中大部分技術人，在之前也都是各個大型網際網路公司的中堅力量，我想沒有什麼比與志同道合的人來一起改變世界更令人激動的了。此時，鳥哥專門來邀請我加入鏈家網，我就毫不猶豫地同意了。
教主答群友問：
Q：您對初級前端人員有什麼好的建議嗎？
A：多嘗試一些解決方案，多想想這些方案的特點，對別人的方案深究原理。
Q：前端學習方面有什麼書籍可以介紹嗎？
A：現在前端書籍都挺多挺好多呀，我一般推薦高階程式設計，圖解CSS3。
Q：您在擔任架構師這個角色中遇到的最嚴重的線上事故是什麼？當時是怎麼解決的？
A：工作這麼多年，在前端應該就只有一次B級故障，做非前端的時候倒是透過大簍子，因為上線速度比較快，而且大問題也都是很明顯的解決方案，所以就是快速上線了。這個要感謝測試同學，很給力，避免了很多線上故障。
Q：學前端是否去參加商業培訓更見效？亦或是這種商業培訓反而更會僵化思維？這樣流水線培訓出來的學員在企業認可度如何。
A：我沒參見過商業培訓，也不太好評價，我是覺得被灌輸的知識可能不如自己躺坑得來的紮實吧。企業認可這方面，我基本只看能力。
Q：對於您來說技術比較重要還是產品比較重要？因為剛才您說是因為覺得鏈家的“產品”比較有意義才考慮去的，那能理解為你覺得產品比技術更重要嗎？
A：我所說的產品不是“產品人員”，是公司的產出的服務。顯然對於一家公司來說，產品是最重要的，技術是如何實現產品的手段啊。
Q：您覺得什麼樣的程式碼才算是可變化的程式碼？這方面又做出了哪些實踐？有哪些系統化的產出？
A：我說變化的程式碼其實程式碼是可控的，可以方便的去調整專案，可以一步一步的改造專案而不是重構，我做開發一致遵循這個理念。
Q：前面提到搭建團隊可用的框架，但我感覺這個工作量非常巨大而且需要很多改進和測試，教主當時有同感嗎？怎麼解決這麼大的工作量問題？
A：我可能比較幸運，曾經有一段時間來調整結構，我是這樣想的，每當我向前邁一步的時候，我就是在進步，所以我沒有急於讓架構搭建一次到位，我會想好調整的步驟，每一步都會讓架構進步，把大問題拆解成小問題一步一步做。
Q：小公司開發前端，由於缺少專案管理經驗，導致許多冗餘性的工作，請問教主在管理方面有何建議？
A：這個不同公司的情況都不一樣吧，不太好建議。
Q：多嘗試一些解決方案和“一步一步逐步改進產品”是否矛盾？
A：不矛盾啊，多嘗試不代表多實施啊。