本期專訪，我們邀請到了趙望野老師。
趙望野，前豌豆莢 Front-end Engineering Team Manager，畢業於中國傳媒大學數字媒體藝術專業。2011 年 2 月加入豌豆莢，負責豌豆莢 2.0 的前端架構設計和主要研發工作。2013 年開始負責 Front-end Infrastructure 的研發，推動豌豆莢前端研發體系的工程標準化和自動化。2016 年 5 月開始創業，目前在做的產品叫 InnoKit OKR，致力於幫助更多企業和團隊實施基於 OKRs 的目標管理，長期遠景是通過 data-driven 的方式幫助企業的驅動內部管理和運營。
First an engineer, then a UI specialist
問：您什麼時候開始接觸前端？當初前端還沒有像現在這麼火熱，為什麼選擇前端開發作為職業方向？
答：我最早接觸的並不是 web 前端。我父親是大學教師，所以小學三四年級（95 年前後）的時候就有機會接觸了計算機，最早接觸的是 Basic 和 Logo 語言，學著寫了一些非常簡單的東西。後來發現我父親有一本 Visual Basic 的教材，我就對著這個教材裡面的例子實現了一個老虎機的小遊戲，但過程中我是完全看不懂我輸入的程式碼是什麼意思的，非常機械的照著書上的步驟實現。這個過程中我第一次對如何做 UI 這件事情產生了非常濃厚的興趣，覺得做出一個可以互動的應用是非常酷的事情。後來到了初中，剛好趕上網際網路的高速發展，就開始自己學著做網頁，給學校做，給老師的朋友做，才算真的開始接觸我們現在所說的 web 前端，但那時候瀏覽器端的開發還比較輕量，主要還是寫 ASP（VBScript）。大學選專業的時候學了數字媒體藝術，也是因為之前的經歷，我特別希望自己能做一些直接被使用者接觸到的終端產品，並且這個產品的設計和體驗都能讓人喜歡，所以慢慢的就在 web 前端的方向上深入下去了。
問：原來您這麼早就接觸計算機啊。小編看您在介紹中說您在13年成為豌豆莢的前端負責人，那麼您從入門到成長為前端團隊負責人，有沒有什麼經驗或方法論可以分享一二？
答：我個人的經驗是在技術的學習過程中，不要隨大流的去跟潮流，著眼正在負責的業務，多思考如何用技術去解決這些業務問題。我過去兩三年在 Front-end Continuous Integration 和 DevOps 領域花的精力比一線業務多，最初的動機並不是因為我對這個領域更感興趣，而是因為豌豆莢的前端團隊隨著人數的增加和負責業務的膨脹，研發質量和效率都跟不上實際的需求了，所以工程的標準化和自動化是必須要做的事情。深入研究下去後，發現這個領域也很有趣，層出不窮的新技術和解決方案，而將這些東西應用在實際業務中的實踐過程，是可以讓一個工程師快速成長的。總結起來就是要有目的性的去學習和積累。
問：您在面試前端開發時的標準是怎樣的？怎麼樣才算是一個合格的前端工程師？
答：我會特別看重兩個因素：
- 首先是 candidate 知識面的完整性。完整性體現在兩個方面，一是軟體工程和計算機相關的基礎知識的紮實程度，二是整個 end to end 的技術體系的瞭解程度。很多 candidate 對於「某個 CSS 屬效能取什麼值」、「JavaScript 有哪些基本資料型別」這些非常 detail 的技術細節瞭解很多，面試之前也會特別準備，但在工程架構、程式設計思想、資料結構和效能等等這些更重要的領域則疏於瞭解，知識體系頭重腳輕。技術細節的積累，在基礎知識非常紮實的前提下是很大的競爭力，但反之則不是，因為一個工程師在成長方面的 potential 是由基礎知識和素質決定而不是某個細分領域的經驗決定的。End to end 的技術體系的瞭解，和最近很多人在討論的全棧會比較像，因為現在整個研發體系分得越來越開，導致很多做客戶端的人對服務端的原理和工作特點了解不多，這對一個完整的產品體系來講是非常不利的。
- 其次，我會特別看重一個人對細節的敏銳程度。一個 UI，響應慢了那麼 50ms，尺寸差了那麼 1px，會不會讓你洗澡沒洗乾淨一樣渾身難受，是我特別看重的品質。合格的前端工程師，我覺得就是能滿足我上面說的兩個特質的人，first an engineer, then a UI specialist.
問：初學者如何系統的培養您說的這兩個特質，您有什麼相關經驗可以簡要分享一下麼？
答：關於第一點，首先就是別用「前端工程師」這個定義給自己設邊界，客戶端開發領域的問題模型都是相近的，合格的工程師應該能在掌握具體語言後快速的進入一個新的工程領域。仔細思考一些共性問題，比如渲染效能這個非常細節的問題，在 web 會遇到，在 Android、iOS 也會遇到，在不同平臺解決這個問題的具體手段不盡相同，但分析和思考過程都是相似的。對於第二點，我理解更多的是一個人的基礎素質決定的，在基本素質滿足的前提下，通過多使用、研究優秀的產品實現可以培養對細節的敏銳程度。
小程式和框架
問：微信小程式1月9日釋出正式版了，怎麼看微信小程式？小程式對前端開發有怎樣的影響呢？
答：從純技術的角度說（不考慮商業和生態相關的因素），我不會對微信小程式有特別多的看法。Android、iOS、瀏覽器都是客戶端開發，微信小程式目前是一個複雜度遠遠遠遠低於以上幾個平臺的客戶端環境而已。別說它目前使用的技術棧同 web 前端很相似，因此前端工程師可以非常快的上手，就算是其它平臺的工程師讀讀文件一個下午入門都因該不是難事。所以從純技術角度講，對前端沒什麼影響，根本是兩個目標平臺。但從實際角度講，如果微信小程式的普及度足夠高，商業價值足夠大，市場需求也就會相應擴大，對相關人才的需求自然也會成上升態勢，對整個前端（目前用人單位會覺得這是前端，雖然我覺得不是）市場的人才結構的確會產生很大影響，兩極分化的情況會加劇。所以我的態度是，討論這個問題之前，先確定 problem space，如果只討論技術層面，其實對工程師而言沒有多少可研究的新內容，也不足夠 fancy。但小程式這個平臺本身的技術實現倒是可以研究一下，蠻有趣的。
問：有人說微信小程式就是一個類似 React Native 的輪子，那你對微信小程式的技術實現有哪些研究和結論呢？
答：不太同意這種說法。我理解工程領域的「輪子」，是指可以複用的技術解決方案，解決方案的形態可以是框架或者一整套規則。小程式首先就不滿足可以複用這一點，它只為微信這一個目標平臺或者說生態體系服務，而且它也不是為了實現某個工程上的目標而做的，從這個角度講他同 React Native 是兩個維度的東西。但在技術實現上還是可以對比一下的。比如，小程式體系中的 WXML 同 JSX 是一個維度的東西，都是用來描述 UI 結構的 DSL（JSX 表達能力更強），差異在於這個 DSL 最終怎麼渲染到螢幕上。目前幾個流行的能使用 JSX 的技術棧裡，都實現了 UI Representation，包括 React.js、ReactNative、Vue.js 和 Weex。從解決思路上看，它同 ReactNative 等所採用的 JavaScript-driven 的開發體驗是殊途同歸的，但在具體實現上非常不一樣，WXML 目前還是交給 X5 核心來渲染，所以很多人認為這還是 web 開發，但實際上在小程式這個目標平臺中做開發，面臨的 problem space 同 web 開發雖然有相似之處，更多的則是不同。
問：說完小程式我們來討論一下現在的 Vue.js 和 React.js 之爭，您是怎麼看待的？框架的選擇是否真的這麼重要？
答：我其實很少參與前端圈子裡面關於框架的爭論，因為大多數討論的參與者都不會把自己的觀點加上一個場景和業務特點的限制，在這種沒有 context 的環境下討論，最後只能是羅生門。雖然之前豌豆莢的前端團隊從 2011 年開始使用 Backbone.js（豌豆莢 2.0），2012 年使用 AngularJS（豌豆莢 Web），2013 年使用 React.js（豌豆莢百寶袋），這些都是在主要業務線的重要產品中使用過的主流框架，內部產品中 Ember.js、Knockout.js、Polymer 這些也都多多少少嘗試過。但用得框架越多，越會了解到框架的價值到底是什麼。我認為每個框架都是有獨特價值的，而這個獨特性就體現在它對工程問題的理解方式和解決方案上，在這個前提下，框架就沒有好壞之分，只有合適與否之別。React.js 剛出現時（我們是從 v0.3 開始接觸的），我們理解它最獨特的是基於 Virtual DOM 實現了 DOM Representation 這個概念，到後來 ReactNative 其實也只是在此之上實現了 UI Representation，細節千差萬別，但核心思想沒變。實踐過程中發現，JSX 的表達能力雖然非常強，但程式碼對應到 UI 上 mind cost 太大，說白了就是不好讀（寫出來也不好看），而我們當時大多數產品的 UI 調整很頻繁，業務變更則相對少，這種情況下 React.js 對比 AngularJS 在 UI 表達和業務實現的分離上就會差一點，所以多數情況下還是會更願意用 AngularJS，而且 React.js 也算不上框架，對複雜應用來說還是需要引入很多元件才能把環境搭起來。到現在，我個人從實踐角度來講更喜歡 Vue.js 一點，繼承了 React.js 和 AngularJS 所有我喜歡的特性，可以說小右是站在了巨人的肩膀上。但最後要說，現在的框架越來越重，對業務模式的侵入程度越來越深，如果一個應用完全構建在 React.js 系、Vue.js 系的解決方案上，框架對開發者來講實際上就形成了一箇中介軟體，我們已經不是在瀏覽器環境中開發而是在框架的環境中開發了。對有經驗的人來說，這可以極大的提升效率，但對新人來講，如果被一葉障目忽略掉框架背後是瀏覽器這個事實的話，未來技術更新換代時的學習成本也會非常高，過程甚至會很痛苦。把精力放在技術本身和業務上，遠比放在爭論框架上來得實際，這就跟爭論編輯器一樣，Jeff Dean 就算只能用紙和筆寫程式碼，產生的價值比大多數人用裝了無數外掛的 VIM 寫的程式碼都要大。想明白了這些，框架重不重要的答案就很明顯了，它重要的前提是對自己面臨的 problem space 和框架本身的優劣勢有足夠明確的認識，否則它就一點都不重要。
關於創業
問：對你來說 2016 年裡最大的挑戰是什麼？又是如何應對的呢？
答：2016 年的大部分時間是在創業和準備創業，應該說除了寫程式碼對我都是挑戰。要思考具體的業務問題，content marketing、客服和銷售也要親力親為，還得想怎麼能把這些環節都串起來，相比之下對我而言還是寫程式碼更簡單一點。沒有了工程師的身份限制，從不同角色的視角去看同一個問題的時候，可能會有完全不一樣的結論，過程體驗也很不相同。我解決這些問題的方式，其實主要是聊天啦，同以前豌豆莢的同事，以及其它公司各種有經驗的大牛們聊天，大家也都會非常關愛我們這些苦逼的創業者，提供非常多的寶貴意見。
問：可以介紹一下目前創業在做的專案嗎？
答：我現在做的專案叫 InnoKit OKR，為企業組織提供實施基於 OKRs 的目標管理的工具產品和配套的培訓諮詢服務。長期是希望用 data-driven 的方式幫助企業組織做內部管理和運營。現在的公司已經學會了如何用 data-driven 的方式做產品研發、營銷和銷售，但在自己最核心的資產，也就是人上面資料所貢獻的價值還太小，所以我希望在這方面做一些事情。另外還有一個動機就是豌豆莢一直非常善於利用工具，我們之前大量採購國外的工具產品，自主研發的也不少，這些工具都極大地改善了員工的工作效率和工作環境，但中國本土各個領域能夠稱得上好用的企業級工具太少了，這也是我希望能夠去做這件事情的一個原因，就是幫助大家更好地工作。
問：OKR 和 KPI 各有什麼利弊呢？
答：OKRs 和 KPI 都是非常典型的目標管理（MBO，Management by Objective）工具，OKRs 的優勢是 Objective 本身就是最重要的 context 約束，Objective 的制定和分解是最重要的過程，也需要團隊整體參與進來。而 KPI 中的 I（indicator）只是 Objective 在數學上的表達，在實踐中這個數學表達的漲跌又與個人利益的得失繫結，導致團隊成員根本不知道 Objective 本身是什麼，即使知道又受制於個人利益而很難直接去推動 Objective 本身。
問：對於創業團隊採用哪種方案有什麼建議？
答：對於創業團隊，並不一定需要把目標管理的流程做得很重，但對業務目標有足夠深入和清晰的思考則是必不可少的，因此「目標管理」的意識是還是要有的。無論哪種方案，都應該把精力放在目標的制定和分解上，也就是說保證團隊在做「正確的事」，而不要放在結果的評估上，這對一個小步快跑的團隊來講非常重要，從這個角度講 OKRs 是更合適的工具，因為它本身是業務目標管理工具，同績效評估分離。
問：可以分享一下日常工作中都有哪些好用的工具產品嗎？這些產品如何幫助你提升工作效率？
答：知乎上有我以前總結的一個答案，主要是跟開發相關的。除去這些，日常工作中，Google 企業套件、Asana、Slack 這些都是必不可少的工具。Asana 近期剛剛上線了 Kanban 功能，我已經完全放棄了 Trello，現在 Asana 不管是用來做專案管理還是 SCRUM 開發管理，都非常合適。一些輕量的場景還可以用來做 issue tracking。
問：開發工作量和工作壓力都比較大，那你平時是怎麼注意保養的？對程式設計師保持健康有什麼建議？
答：可能都是一些老生常談的建議，健康飲食、規律作息、經常鍛鍊等等吧。但實際執行起來其實是比較考驗一個人的自律性的。我自己之前有一年多的時間每週四到五天健身，控制飲食不吃夜宵等等，體重和體質都得到很好地改善。但現在創業忙起來，就會給自己找太忙了、太累了等等各種各樣的藉口不繼續堅持，其實還是在自律性上放鬆了。所以大家共勉吧，程式碼寫得再多再好也得保證生活質量才行。
最後，感謝趙望野老師接受我們掘金專訪，大家如果有其他問題可以在下面留言~
關於 InnoKit OKR
InnoKit OKR 目前除工具產品外，還提供企業和團隊目標管理相關的培訓和諮詢服務，可以通過官網 www.innokit.com 瞭解更多資訊和申請試用。我們目前的產品是一個基於 web 的 SPA，具體的技術棧資訊可以檢視 stackshare.io/innokit/inn… 瞭解。目前在尋找在技術方面有熱情的 candidate，希望他在技術方面比較全面，瞭解整個 E2E 的技術體系，並且對於技術有永無止境的追求，在我們這裡可以毫無限制的去驗證新想法。
關於掘金專訪
通過與開發者的日常接觸，我們發現優秀的開發者大多非常低調，他們在媒體和社交網路上的曝光度並不是很高，這也讓大部分使用者沒辦法接觸到程式碼、產品背後真正的人，沒有機會去了解背後的思考、理念。「掘金專訪」是我們作出的一次嘗試，我們希望通過與開發者的交流，讓開發者有機會表達自己，也讓大家有機會能夠真正接觸到他們。
如果您有意願參與專訪，可以發郵件到 liutao@xitu.io 或者新增微信 404096378.