专访 · 赵望野：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.