对话豆瓣张克军：前端，工程与人

个人简介 张克军，豆瓣前端负责人

百度技术沙龙是由百度主办，InfoQ负责策划、组织、实施的线下技术交流活 动，每月一期，每期由1个话题，2场演讲以及Open Space开放讨论环节组成。 旨在为中高端技术人员提供一个自由的技术交流和分享的平台。 每期沙龙会邀请1名百度讲师分享百度在特定技术领域的成果及实践经验，同时 还会邀请1名优秀的互联网公司或企业技术负责人对同一话题进行分享。活动主 要面向开发者、技术负责人、项目经理、架构师等IT技术人员。我们的口号 是：畅想•交流•争鸣•聚会。

   

1. 您好，欢迎您参加InfoQ的访谈，首先请自我介绍一下吧。

张克军：我叫张克军，现在豆瓣工作，我在豆瓣负责前端开发团队，我自己也是豆瓣社区产品线的前端工程师。

   

2. 您今天参加百度技术沙龙演讲主题是关于工程的话题，名字叫“工程之美”。首先请你和我们分享一下，你对工程是怎么给它下的定义？

张克军：工程的定义，如果按字面上的解释就是，为了解决问题按照一定的步骤去实施一个方案，这个就算是一次工程。

   

3. 工程与人有什么样关联呢，例如工程跟我们前端工程师有怎样的关联？

张克军：人的因素我认为特别重要，他是这个工程活动的参与者，也是控制者。人，决定了工程方案是什么，工程如何去实施，如何去保证工程产出最后的质量，这一系列的事情，人都是一个最重要的因素。

   

4. 也就是说人是思考工程问题，用工程思维来解决问题的一个重要角色。

张克军：他是操作者。

   

5. 我看你在演讲里面会讲到几个主题，例如借鉴SOLID原则，还有Exformation哲学的问题，这些是什么样的问题呢？

张克军：我觉得这可能是在工程开发中的一种塑造工程师能力的方式。例如代码架构问题，SOLID原则可能是面向对象的一个经典设计原则。在前端开发中不需要有这种过重的设计元素在里面，前端开发有自己的一些特点。所以这些设计原则我们可以借鉴它的精华，可能是对于前端开发来讲就是刚刚好。但总的来说这些设计原则不是技术问题，它是为了更好地解决工程问题的一些设计方法。Exformation，它是一位日本设计师原哉他提出的一个个人理论。我认为，他讲的是设计师思考问题的方式。那其实对于工程师来讲，它并不是机械地通过体力劳动编码的这种性质，工程师其实是在定义问题，然后在去设计代码结构，然后再去选择方案，这也是一个需要设计的活动。Exformation的意思，它是跟Information的定义是对应的。Information是指人们每天都接受各种各样的信息，这些信息它不是系统的，都是碎片知识。但是Exformation的意思正好是反向的，它是指在我已有的知识基础上，我怎么去思考一个问题，去发现这个问题存在的一些未知的东西，这说起来可能有点哲学。我觉得对于工程师来讲，吸收知识过程是非常重要的，这是一个储备能量的过程。但是反过来，你在功能开发过程中，你要做出一个具体东西的过程中，你怎么去发挥能量，这就是立足于你已有的知识基础上去发现这些东西不够健全的地方，或者说问题所在，这可能是一个更细致入微的思想方式。这点我觉得对前端工程师来讲特别重要。因为前端工程师是产品设计和产品开发这个衔接环节的关键角色。涉及到产品设计的问题是需要前端工程师在这个环节中主动去发挥个人创造力的。

   

6. 我记得你之前提到，提出Exformation这个理念的这位日本人，他有讲到平时他是遇到了现实某些设计上的问题，他遇到了怎样的问题，以及与实际程序设计有怎样的关系？

张克军：他们之间是有相似性的。他举了一个例子，像杯子是我们日常中都会用到的，设计师也是一个工作，所有设计师都在设计一个杯子，最后设计出来的东西大致都是这个样子。但是如果按照Exformation这种思维去思考的话，应该是说，你作为一个设计师，立足于你对杯子认识的基础上，去发现它有什么不足的地方，有什么可以改进的地方，然后你会发现，最后你设计出来的东西就会跟市面上其他杯子不一样，因此你这个作品产生的价值，就可能会比其他设计师设计出来的杯子要好。这对应到我们开发的过程也是类似的道理。

   

7. 也就是说对已知、已有的事物认知基础上，通过这种Exformation这种思维输出思考的一个结果更有价值。

张克军：我觉得这个特别受用。

   

8. 你今天的分享提到在豆瓣除了架构和组件，还有一些工程支柱的问题。例如性能、安全、工具等，为什么你认为这些是工程支柱？

张克军：这点我在今天的分享中也会提到，这些工程问题它不是凭空定义、凭空想象的。它完全是我们根据产品开发特点就会产生的问题。举个例子，灰度上线。豆瓣产品要上线一个新的功能是非常慎重的，尤其社区这块用户非常敏感，你上线一个新功能，做了一点点改版就会引起用户很大的反响。所以自然而然，在一个新产品做出来之后，上线策略就会选择灰度上线、AB测试，对工程师开发就会提出要求。那么自然而然，这些要求就会转化成相应的工程问题。因为你想，如果灰度上线的话，意味着新旧两种代码同时在线上运行，AB测试也是这样的道理，甚至不止说AB测试两种，可能是四五种方案，让不同的用户群看到。这样整个开发的复杂性，就远远超过于单个方案本身技术问题的难度。这是一个例子，这种自然而然会产生相应的开发问题。我在今天分享中会提到我工作中遇到的12个支柱问题，我称它们为支柱问题，其中我认为它是最基础的。

   

9. 刚好下一个想问的就是，工程问题的提出主要是为了描述哪些问题？它又解决了什么样的问题？

张克军：它描述的其实就是需求，在我看来，描述的是一个较深层次的需求。

   

10. 需求抽象化，把它定义成一个工程问题，这就是定义工程问题的方向是吗？

张克军：对，这种问题定义是非常关键的。今天活动主题是如何提高前端开发效率，提高效率最主要、最基本的前提是，你首先要选择一个最佳方案。如果工程没有定义清楚，盲目进入到开发中，可能会导致后续工作中的混乱，它的作用没有起到，反而是会弄巧成拙。

   

11. 是指抽象出来的需求？

张克军：对，抽象出来的需求。还是刚才产品上线策略的例子，这是一个需求。这个需求会关联很多代码，新旧代码维护问题，同时在线上运行怎么去维护。要维护代码又会涉及到你能用什么更好的手段去维护，模块化、组件化是一种方式。那么前端组件化应该怎么实现，你会发现它逐步会引发出连锁反应，很多公共问题就会引发出来。所以前端开发中工程问题的定义，就是把引发出来的这些问题清晰地进行定义，以后其他产品遇到类似问题，把经验普及到其他产品开发中。

   

12. 实际上是说，你今天讲到的12个工程支柱问题是基于豆瓣产品和业务的特点，实际遇到的问题。

张克军：对。豆瓣遇到这样的问题，技术团队需要把这个问题定义出来。其他产品团队，可能会根据他们的技术产品要求和特点，定义出相应的问题。但是你会发现，把这些工程问题全部提炼出来之后，它既有针对性，也有普遍适应性，有很多其实是大家都会遇到的问题。

   

13. 效率没有提升，反倒可能是延期了？

张克军：提高效率的第一步是应该把问题定义清楚，寻找一个更合理的方案。

   

14. 现在移动化是整个互联网的趋势，不知道豆瓣在这方面有没有具体规划，或者有没有一些平台移植的产品给大家分享？

张克军：移动技术上有两种方案，它们存在争议，或说有竞争，经常会拿出来对比，一个是原生Native开发，一个是Web方案。其实对于产品是不关心技术优劣的，关键是最后你是不是能达到产品策略的要求，最后做出来的效果如何。豆瓣也是这样，在我们内部，Native方案和Web方案都在尝试，只不过是不同团队来做。显然Web方案就是前端团队在负责，我们从去年7月份开始，在尝试一个响应式方案，目的是想把我们现在互联网网站以一种更低成本、更高效率进行适配，这是针对各种终端手机、小屏幕智能设备的方案。现在正在做，有一些如豆瓣小组已经是实现了。这当中遇到一些问题，也有一些坑，这些都在探索当中。

   

15. 看来下次可以邀请你给我们分享一下移动开发的经验了。

张克军：今年会有负责这方面工作的工程师，以后有机会可以专门讲讲这块。

   

16. 我以前采访过豆瓣后端架构工程师刘洪清，不知道你们之间合作有没有火花碰撞出来？

张克军：在豆瓣是经常会有前后端的合作。我来豆瓣之前在其他公司呆过，尤其是一些大公司，跨部门合作是比较困难的。但是在豆瓣这种合作还是比较容易达成的。举个例子，静态文件管理系统，它是前端提出需求，需要后端来提供技术支持的项目。如果完全用前端思维去解决这个问题，我认为最后得出的不是一个最优方案，这个时候就会跟算法工程师、系统工程师、其他后端工程师一起去，把我们的需求提出来，大家来看怎么把它更完美、更无缝的跟我们现有的系统结合在一起。

   

17. 以用户体验或效率作为统一目标，进行合作的一种方式？

张克军：对，现在我们这个文件系统已经有一年多的使用经验了，效果非常不错。像刚才提到那些复杂的业务逻辑，前端组件化、模块化的实现，都跑在这个静态文件管理系统上。这个问题完美解决了，之后包括移动化都是建立在这个基础之上，给我的感觉就是，在很多问题上不能单纯用前端思维来解决问题，需要跟其他算法、服务端的一些优秀工程师碰撞出更接近于完美的一个方案。

   

18. 回过头来看，这可能也比较符合你今天要讲得主题，工程之美，就是把需求转换成工程问题，考虑方案解决，而不是单纯停留在前端技术或后端技术这个问题。

张克军：技术仅仅是一个手段，不应该局限于一定要用前端技术解决，只要最终达到更好的效果，用什么技术手段其实是不重要的。

InfoQ：非常感谢您参加今天InfoQ访谈，期待您能在InfoQ做更多分享，谢谢。