专访 · 赵望野：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 领域花的精力比一线业务多，最初的动机并不是因为我对这个领域更感兴趣，而是因为豌豆荚的前端团队随着人数的增加和负责业务的膨胀，研发质量和效率都跟不上实际的需求了，所以工程的标准化和自动化是必须要做的事情。深入研究下去后，发现这个领域也很有趣，层出不穷的新技术和解决方案，而将这些东西应用在实际业务中的实践过程，是可以让一个工程师快速成长的。总结起来就是要有目的性的去学习和积累。
问：您在面试前端开发时的标准是怎样的？怎么样才算是一个合格的前端工程师？
答：我会特别看重两个因素：
- 首先是 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 目前除工具产品外，还提供企业和团队目标管理相关的培训和咨询服务，可以通过官网 InnoKit OKR 了解更多信息和申请试用。我们目前的产品是一个基于 web 的 SPA，具体的技术栈信息可以查看 InnoKit - InnoKit | StackShare 了解。目前在寻找在技术方面有热情的 candidate，希望他在技术方面比较全面，了解整个 E2E 的技术体系，并且对于技术有永无止境的追求，在我们这里可以毫无限制的去验证新想法。
关于掘金专访
通过与开发者的日常接触，我们发现优秀的开发者大多非常低调，他们在媒体和社交网络上的曝光度并不是很高，这也让大部分用户没办法接触到代码、产品背后真正的人，没有机会去了解背后的思考、理念。「掘金专访」是我们作出的一次尝试，我们希望通过与开发者的交流，让开发者有机会表达自己，也让大家有机会能够真正接触到他们。
如果您有意愿参与专访，可以发邮件到 liutao@xitu.io 或者添加微信 404096378.
