本文是第十四届-前端早早聊成长晋升专场，也是早早聊第场，来自蚂蚁金服-死马的分享
一、自我介绍我是不四，毕业后一直在阿里和蚂蚁工作，不四是我在阿里的花名，社区中一般以另一个花名“死马”出现。工作这8年多来一直专注在Node.js和Web开发领域，也在社区参与了一些开源项目，包括Koa、Egg和cnpm等，非常幸运在node出生之初就开始参与其中，算是赶上了一波由node带来的大前端变革浪潮。每一个人的成长轨迹都不一样，一路上遇到的机遇也各不相同，这次分享也仅站在一个普通工程师的角度来分享我的成长经历和贯穿其中的一些个人习惯。
二、成长历程实习在年的夏天，大三暑假我来到了当时的淘宝数据平台实习。也不知道是运气好还是运气差，我是以C++工程师的身份被招聘的，分配到的数据产品部却是一个做Web产品的团队，还是用刚刚出生的Node.js作为服务端开发语言，并在实践全栈研发，还记得那时候node的版本才0.4，而我是一个连JS和JSP都分不清楚的菜鸟，大学三年只写过黑框框的C++，连HTTP是什么都不知道，无比忐忑的开始闷头学习JS基础。
多年以后和当时看的入门教材作者成为了同事
幸运的是，当时的团队大牛云集，国内第一批Node.js的布道者，nodeparty的发起人空无、清笃、玄澄，以及国内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年，我在一个公司内兜兜转转，但是一直专注在一个技术领域上，并在底层技术、基础服务、产品研发等不同的方向做探索。成长过程中可能有很多的幸运，你能遇到什么样的团队和老板，可以做什么样的事情，这些可能我们都很难完全控制，但是我们能够控制的是作为一个工程师，你如何提升自己的技术能力，做好抓住机会的准备。
三、工程师成长密码回过头再来看这几年，我在工作和社区中养成了一些习惯，这些习惯可能是对我的技术成长影响非常大的。
坚持写代码显而易见，作为一个工程师，我们最重要的职责就是写代码。熟能生巧，坚持写代码一定是工程师成长手册中最重要的一点。不论是在做技术项目还是带团队，写代码一定是我日常工作中最重要的一部分。
然而低质量的重复是毫无意义的，我们要坚持写代码，更要坚持写好代码。
什么是好的代码？这个问题可能不同的人眼中有不同的答案，对我而言，好的代码起码要满足这三个条件：
好的代码是简单的，简单的代码架构清晰，并且让编码变的更轻松；好的代码是给人看的，绝大部分的应用都是要持续维护的，不给别人挖坑，也是不给未来的自己挖坑；好的代码是可测试的，通过编写单元测试，既保障代码的逻辑完备，减少Bug，也利于后期维护与重构。保持代码简洁先从简单说起，简单的代码是容易理解的，然而想要编写简单的代码，架构起来又是更复杂的。这是给自己提出更高的要求，不断优化重构，在这个过程中得到成长。当遇到一些复杂需求的时候，我始终坚信一点：如果一个逻辑我们作为实现者都很难梳理清楚，代码中一堆的ifelse条件判断，那用户也一定是无法理解的。
所以当遇到这种情况，我们需要从产品侧和架构侧去思考，到底是什么原因导致了复杂度？我们应该是去优化产品需求还是去优化底层架构。这也会迫使我们在产品和架构上有更深入的思考。
CodeReview另外一个我和团队一直在坚持的习惯是CodeReview。CR是一个非常好的提升代码质量的方式，它是需要团队投入大量精力的事情，但是一定收获不菲。
我们直面CR的灵魂三问：
为什么要做CR？业务催的那么紧，哪有时间做CR？谁来做CR？是团队的主管、核心工程师才能帮别人CR吗？CR是一件很费精力的事情，如何才能坚持下来呢？CodeReview的主体是人，Review的对象是代码
对于代码提交者的人来说，当你知道你的代码会被其他人看到的时候，是肯定会更加注重代码质量的。我还记得我开始向社区成熟开源项目提交代码的时候感受到的巨大压力，它会让你在提交代码前更仔细的设计和编码。经过一次次的CR后，你会发现你的代码质量会飞速提升。对于评审人来说，每一次CR都可以增加你对整体代码库或者不同业务的熟悉程度，还可以传授经验、提升团队影响力。最后，通过CodeReview，我们可以提升项目代码的质量与可维护性，统一团队的代码风格，并让每一个业务逻辑都能尽量找到backup。CR是一件三赢的事情。CR是一件很有意义的事情，但是我们应该怎么去做呢？
第一步还是要从自己做起，通过自己的主动与坚持，带动团队一起参与。在提交代码的时候，写好