專訪 · 趙望野：first an engineer, then a UI specialist

本期專訪，咱們邀請到了趙望野老師。

趙望野，前豌豆莢 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 領域花的精力比一線業務多，最初的動機並非由於我對這個領域更感興趣，而是由於豌豆莢的前端團隊隨着人數的增長和負責業務的膨脹，研發質量和效率都跟不上實際的需求了，因此工程的標準化和自動化是必需要作的事情。深刻研究下去後，發現這個領域也頗有趣，層出不窮的新技術和解決方案，而將這些東西應用在實際業務中的實踐過程，是可讓一個工程師快速成長的。總結起來就是要有目的性的去學習和積累。

問：您在面試前端開發時的標準是怎樣的？怎麼樣纔算是一個合格的前端工程師？

答：我會特別看重兩個因素：

1. 首先是 candidate 知識面的完整性。完整性體如今兩個方面，一是軟件工程和計算機相關的基礎知識的紮實程度，二是整個 end to end 的技術體系的瞭解程度。不少 candidate 對於「某個 CSS 屬性能取什麼值」、「JavaScript 有哪些基本數據類型」這些很是 detail 的技術細節瞭解不少，面試以前也會特別準備，但在工程架構、編程思想、數據結構和性能等等這些更重要的領域則疏於瞭解，知識體系頭重腳輕。技術細節的積累，在基礎知識很是紮實的前提下是很大的競爭力，但反之則不是，由於一個工程師在成長方面的 potential 是由基礎知識和素質決定而不是某個細分領域的經驗決定的。End to end 的技術體系的瞭解，和最近不少人在討論的全棧會比較像，由於如今整個研發體系分得愈來愈開，致使不少作客戶端的人對服務端的原理和工做特色瞭解很少，這對一個完整的產品體系來說是很是不利的。
2. 其次，我會特別看重一我的對細節的敏銳程度。一個 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.