不四：产品工程师的修炼之路

简介： 我是不四，毕业后一直在阿里和蚂蚁工做，不四是我在阿里的花名，社区中通常以另外一个花名 “死马” 出现。每个人的成长轨迹都不同，一路上遇到的机遇也各不相同，此次分享也仅站在一个普通工程师的角度来分享个人成长经历和贯穿其中的一些我的习惯。

做者 | 死马

我是不四，毕业后一直在阿里和蚂蚁工做，不四是我在阿里的花名，社区中通常以另外一个花名 “死马” 出现。工做这 8 年多来一直专一在 Node.js 和 Web 开发领域，也在社区参与了一些开源项目，包括 Koa、Egg 和 cnpm 等，很是幸运在 node 出生之初就开始参与其中，算是遇上了一波由 node 带来的大前端变革浪潮。每个人的成长轨迹都不同，一路上遇到的机遇也各不相同，此次分享也仅站在一个普通工程师的角度来分享个人成长经历和贯穿其中的一些我的习惯。

成长历程

实习

在 2011 年的夏天，大三暑假我来到了当时的淘宝数据平台实习。也不知道是运气好仍是运气差，我是以 C++ 工程师的身份被招聘的，分配到的数据产品部倒是一个作 Web 产品的团队，仍是用刚刚出生的 Node.js 做为服务端开发语言，并在实践全栈研发，还记得那时候 node 的版本才 0.4，而我是一个连 JS 和 JSP 都分不清楚的菜鸟，大学三年只写过黑框框的 C++，连 HTTP 是什么都不知道，无比忐忑的开始闷头学习 JS 基础。

多年之后和当时看的入门教材做者成为了同事。

幸运的是，当时的团队大牛云集，国内第一批 Node.js 的布道者，node party 的发起人空无、清笃、玄澄，以及国内 node 社区一直以来的核心贡献者苏千和朴灵等等都集中在了这个团队。跟随着他们的脚步，我在大半年的实习时间内，顺利的将 C++ 给忘光了，成为了一名新手 JS 工程师。

数据产品部

12 年毕业后正式入职淘宝数据产品部，那是大数据最火热的年代，咱们坐在淘宝数据平台的金山上，挖掘出来了数据魔方、淘宝指数、淘宝时光机等数据产品。随着我慢慢的深刻业务，也逐渐理解了团队为何选择 node 技术栈。大部分的数据产品自己的计算和业务逻辑相对不会太复杂，依赖大量后端数据源提供数据，是一个典型的 IO 密集型应用。而 JS 全栈也能够带来更高效的研发效率。

数据魔方

淘宝时光机

随着数据产品覆盖的场景愈来愈多，咱们须要对接到阿里集团的各类内部系统。因此咱们用 node 实现了内部的微服务框架、登陆系统、配置系统等中间件。而随着 node 生态的愈来愈繁荣，搭建一个内部的 npm 包管理系统也提上了日程。咱们尝试着用 npm 官方的解决方案搭建，可是难以运维，也不能彻底知足需求，最后咱们开发了 cnpm 用来搭建内部的 npm 包管理平台并提供了国内的 npm 镜像。后来的事实证实，一个快速的 npm 包管理平台对于促进 node 和大前端社区的繁荣起到了相当重要的做用。

刚毕业的这两年是我技术成长很是快的时候，一方面是团队有不少大牛能够学习，另外一方面也遇上了一波 node 技术初生的福利期，我也在这里完成了工做后的第一次晋升，从 P4 晋升到 P5。

天猫前端

在 14 年中的时候，因为团队的一些变化，我转岗到了天猫前端团队。当时的天猫前端团队其实没有专职的 node 开发工程师，团队遇到的一个很大挑战是运营活动页面以前都是运行在 php 上，随着 php 工程师在阿里的逐渐减小，那套年久失修的 php 系统已经难以继续支撑流量愈来愈夸张的双十一活动了。因此我开始着手经过 node 实现新一代的页面渲染服务。

新服务在 14 年双十一的时候在天猫首页进行验证，从性能和稳定性上比老的 php 服务高出不少。接下来咱们开始基于新的服务上层实现了新的可视化页面搭建系统，很是完美的支持了 15 年的双十一，这套系统也一直服务到如今，固然已经进化的更加完备和复杂了。

当时给 php 和 Node.js 系统作的 benchmark

在天猫能够说是以前那段工做经历积累后的爆发期，用一个全新的技术栈实现了一个重要的业务系统，并取得了很大的业务价值，因此在 15 年的时候我也从 P5 晋升到了 P7。

蚂蚁体验技术部

可能仍是有想作更底层一点技术的念头，我在 16 年初的时候决定从天猫前端团队转岗到蚂蚁的体验技术部给大前端团队作内部的 Web 框架和 BFF 研发模式的支持。其实在去蚂蚁以前，我也一直在维护者 Koa 和一些 Web 框架生态和中间件的服务，到蚂蚁以后参与作的第一件事情就是从当时蚂蚁的 Web 框架 Chair 中抽出来了 Egg.js，以统一阿里经济体各不一样 BU 的大前端 Web 研发体系。Egg.js 也随后面向社区开源。

Egg.js 生态

经过两年多时间的发展，BFF 研发模式也慢慢的被蚂蚁、阿里经济体甚至是国内接受了。我也在这里晋升到了 P8。

语雀

随着一次内部组织架构调整的机会，我来到了语雀团队。它是蚂蚁体验技术部内部的一个创新孵化项目，为十万阿里人提供知识协同和文档管理的服务，18 年的时候，语雀也开始对外服务。兜兜转转的走了一圈，我又回到了使用 JS 全栈进行应用开发。在语雀团队，咱们践行着产品工程师文化，高效的完成产品研发。

语雀产品工程师文化

简短的总结毕业后的这 8 年，我在一个公司内兜兜转转，可是一直专一在一个技术领域上，并在底层技术、基础服务、产品研发等不一样的方向作探索。成长过程当中可能有不少的幸运，你能遇到什么样的团队和老板，能够作什么样的事情，这些可能咱们都很难彻底控制，可是咱们可以控制的是做为一个工程师，你如何提高本身的技术能力，作好抓住机会的准备。

工程师成长密码

回过头再来看这几年，我在工做和社区中养成了一些习惯，这些习惯多是对个人技术成长影响很是大的。

坚持写代码

显而易见，做为一个工程师，咱们最重要的职责就是写代码。熟能生巧，坚持写代码必定是工程师成长手册中最重要的一点。不管是在作技术项目仍是带团队，写代码必定是我平常工做中最重要的一部分。

然而低质量的重复是毫无心义的，咱们要坚持写代码，更要坚持写好代码。

什么是好的代码？这个问题可能不一样的人眼中有不一样的答案，对我而言，好的代码起码要知足这三个条件：

1. 好的代码是简单的，简单的代码架构清晰，而且让编码变的更轻松；
2. 好的代码是给人看的，绝大部分的应用都是要持续维护的，不给别人挖坑，也是不给将来的本身挖坑；
3. 好的代码是可测试的，经过编写单元测试，既保障代码的逻辑完备，减小 Bug，也利于后期维护与重构。

保持代码简洁

先从简单提及，简单的代码是容易理解的，然而想要编写简单的代码，架构起来又是更复杂的。这是给本身提出更高的要求，不断优化重构，在这个过程当中获得成长。当遇到一些复杂需求的时候，我始终坚信一点：若是一个逻辑咱们做为实现者都很难梳理清楚，代码中一堆的 if else 条件判断，那用户也必定是没法理解的。

因此当遇到这种状况，咱们须要从产品侧和架构侧去思考，究竟是什么缘由致使了复杂度？咱们应该是去优化产品需求仍是去优化底层架构。这也会迫使咱们在产品和架构上有更深刻的思考。

Code Review

另一个我和团队一直在坚持的习惯是 Code Review。CR 是一个很是好的提高代码质量的方式，它是须要团队投入大量精力的事情，可是必定收获不菲。

咱们直面 CR 的灵魂三问：

1. 为何要作 CR？业务催的那么紧，哪有时间作 CR？
2. 谁来作 CR？是团队的主管、核心工程师才能帮别人 CR 吗？
3. CR 是一件很费精力的事情，如何才能坚持下来呢？

Code Review 的主体是人， Review 的对象是代码

• 对于代码提交者的人来讲，当你知道你的代码会被其余人看到的时候，是确定会更加注重代码质量的。我还记得我开始向社区成熟开源项目提交代码的时候感觉到的巨大压力，它会让你在提交代码前更仔细的设计和编码。通过一次次的 CR 后，你会发现你的代码质量会飞速提高。
• 对于评审人来讲，每一次 CR 均可以增长你对总体代码库或者不一样业务的熟悉程度，还能够传授经验、提高团队影响力。
• 最后，经过 Code Review，咱们能够提高项目代码的质量与可维护性，统一团队的代码风格，并让每个业务逻辑都能尽可能找到 back up。CR 是一件三赢的事情。

CR 是一件颇有意义的事情，可是咱们应该怎么去作呢？

第一步仍是要从本身作起，经过本身的主动与坚持，带动团队一块儿参与。在提交代码的时候，写好 commit message，作好自测，注意代码的可读性。抽时间来 Review 团队其余人的代码，为每一行代码负责。

可是 CR 毕竟仍是一个团队的事情，如何保持团队 CR 的质量呢？咱们必定要严抓新人的第一次 CR。通常来讲咱们团队新人的第一个 PR 都会收到比较大的挑战。新人对代码不熟悉，编码风格也和团队可能不一致，第一次 CR 很是重要，须要让你们都对齐对代码质量的标准和要求。

对新人重拳出击

除了代码以外，更上层的设计与架构也须要作 Review，让每一次系统功能设计、架构升级都通过 Review，不只可让系统更稳定，也能够快速提高本身的系统架构能力。

Unit Tests

• 你的代码质量如何度量？
• 你是如何保证代码质量？
• 你敢随时重构代码吗？
• 你是如何确保重构的代码依然保持正确性？
• 你是否有足够信心在没有测试的状况下随时发布你的代码？

若是对这些问题没有答案，或者没有 100% 的信心，那你须要给你的代码作单元测试。

如今提及单元测试，你们其实仍是有体感的。然而在 十二、13 年我刚工做的时候，单元测试仍是一个相对陌生的概念，可是当时的 node 开源社区其实已经慢慢开始流行起来写单元测试了，当你给其余开源项目提交代码的时候，没有测试是不可能被合并的。当时高产的 TJ 不只仅提供了 express connect 等 Web 框架，同时也提供了一系列底层配套的测试模块，包括测试用例驱动器 Mocha，断言库 should.js，http 请求测试库 supertest 等等。

跟随社区一块儿，咱们很早就把单元测试引入了咱们的工做中，基本上从我正式工做开始编写的第一行项目代码开始就在写单元测试了，这个习惯让我在 8 年的工做经历中保持了不错的代码质量，在没有测试工程师测试过个人代码的状况下，没有搞出重大故障被阿里开除。

提及对业务代码写单元测试，可能你们的第一反应仍是哪有时间写单元测试啊？其实写单测真的没有那么耗时，只要你找对工具和方法。对于单元测试来讲，只须要四个步骤：

1. 建立一些初始数据；
2. 对外部依赖进行 mock；
3. 最小粒度的执行要测试的方法；
4. 对结果作断言。

剩下的就是按照这个方式构造测试用例输入，尽量的覆盖代码中的每个分支和边缘场景。

Web 应用中的单元测试更加剧要，在 Web 产品快速迭代的时期，每一个测试用例都给应用的稳定性提供了一层保障。API 升级，测试用例能够很好地检查代码是否向下兼容。对于各类可能的输入，一旦测试覆盖，都能明确它的输出。代码改动后，能够经过测试结果判断代码的改动是否影响已肯定的结果。咱们在作 Egg.js 的时候，最重要的一件事情就是给它编写对应的测试框架，让业务方可以更简单、没负担的写单测来保障代码质量。

而把代码的覆盖率提升，看到测试覆盖率的报告全绿，不只对上线代码更有信心了，同时也是一件颇有成就感的事情。

持续分享

若是说坚持写代码是练习和输入，那另外一个对我成长帮助很大的习惯就是分享，这看起来是一个对外的输出，但在我看来它更是一个很是好的学习机会。

在我刚工做在数据产品部的时候，咱们团队组织了一个 Show Me The Code 的内部分享沙龙，是一个形式很是随意的分享会，不须要准备正式的 PPT，不须要很长的分享时长，就简单的分享一下最近学到的新知识，看到的有趣的代码。这个培养了我去分享的习惯。那时候常常为了找一个分享的话题，去主动研究一些新的模块，看他的源码，本身也会去造一些小的轮子来解决实际工做中遇到的重复性工做。而如今在语雀团队，我也在组织内部双周分享会，已经坚持了一年多的时间了。

再小的分享也会有收获

工做的这些年我也陆陆续续在外面的会议进行了很多的外部分享。基本上每一次分享，都须要本身先认真的对要分享的内容查漏补缺，并尝试着将它准备到浅显易懂。每一次演讲事后，都会让你对这个演讲主题的领域有更深的感觉。

分享对我来讲更多的是给我提供了一个很是好的阶段性总结的机会，最好的学习方法就是教会别人，由于谁也不想在台上出糗对吧。去听一场技术分享，听到的知识转眼就忘了，而你认真的去准备一场演讲，那场演讲收获最大的必定是你本身。

参与开源

对个人技术成长影响很大的另外一个因素是开源，固然开源本质上也是一种分享。

如今是一个百花齐放的年代，开源世界的项目愈来愈多，根据 GitHub 的数据，2019 年有 4400 万个新项目被建立。每个有技术追求的工程师可能都想过要去 GitHub 上写点什么。可是开源并非指的在 GitHub 上提交代码，开源更多的是一种心态。

1. 开源意味着你要将你的代码给全部的开发者审阅，就像前面 Code Review 的时候说的，把代码给别人看是一件颇有压力的事情，更况且提交到 GitHub 后，全部人都能看到，你的同事、面试官都能看到。必定要认真的对待每一行代码，每一次提交。
2. 同时当有人使用你的开源项目时，意味着你要承担起责任。尽管开源协议多是很宽松的 MIT，但仍是要对你写的代码负责。
3. 开源应该让你感觉到 “痛苦”，须要对开源代码提出更严格的要求，追求最优的代码架构，测试完备，描述清晰，编写高质量代码的过程会让你感觉到痛苦，可是会有更快的成长。

可能咱们有时候很难本身想到一个很好的想法，或者很难本身实现一个那么高质量的开源项目，不要着急，参与开源的门槛其实也没那么高。

第一步，挑选一个工做中能够用到的领域的高质量开源项目，为何工做中能够用到很重要，由于这样你才能更好的找到改进的方向，找到痛点。例如我当时选择深刻参与的开源项目是 Koa，由于我工做的重点也是在 Web 研发领域，而我以为 Koa 当时基于 co 提供的那套异步编程模型必定是将来的趋势。

第二步，逐步参与进去，一开始可能只是修一下文档，找找 Bug 修复一下，补充几个测试用例。慢慢的随着你对代码和周边生态的完善，能够进一步去实现一些缺失的周边生态，尝试根据本身实际遇到的问题给项目提交一些功能改善。

国外有不少高质量的项目，咱们也能够帮他们作文档的翻译。不要小瞧文档翻译，翻译一遍文档就意味着你要深刻理解这个项目，其实也是一件很难而且颇有收获的事情，还可以提高社区影响力。

开源是一个成就感驱动的事情，由于你没法从中得到看得着的收益。因此可以持续的参与开源最重要的一点是你要可以从中找到成就感。

和团队一块儿成长

说了这么多我的成长的事情，我仍是想再稍微说一下团队。咱们做为我的在团队中工做，只有帮助团队一块儿成长，拿到业务价值，才能将咱们的技术成长 “变现”。而以前提到的 Code Review 亦或是单元测试，都是须要团队一块儿来配合的。

若是你的团队尚未内部的分享会，尝试着本身去组织一个按期的内部分享会；
从如今开始作 CR 和单测，用本身来影响团队；
尝试着在团队中创建契合团队的工程师文化。
前两点其实在以前的分享中都已经说起到了，这也是咱们团队一直在坚持和倡导的。我想说一下语雀的团队文化，在语雀咱们但愿每个工程师都是产品工程师，他是产品的技术合伙人，参与产品讨论、完成产品功能研发，同时他也是某一个具体领域的技术专家，例如前端 UI 组件、编辑器领域、服务端领域等等。在咱们的工做流程中，全部的工程师都是以全栈的身份参与项目研发，跟进项目从产品设计、到系统分析、研发自测，CR 以及上线的全流程。经过产品工程师文化，咱们鼓励每个工程师都可以在业务和技术上找到本身的成长方向，并陪着团队和业务一块儿快速成长。

我的成长很重要，同时想要取得好的结果获得晋升，必定要将我的的成长和团队的成长绑定起来。经过把本身的事情作到极致，帮助团队创造业务价值，在这个过程当中提高本身在团队内外的影响力。找到那个我的和团队共赢的点去发力，能够获得事半功倍的效果。

本文来自 蚂蚁集团高级前端技术专家 不四在前端早早聊成长晋升专场的分享。