软件工程师成长密码

1、坚持写代码，更要坚持写好的代码
好的代码是简单的，简单的代码架构清晰，并且让编码变的更轻松；
好的代码是给人看的，绝大部分的应用都是要持续维护的，不给别人挖坑，也是不给未来的自己挖坑；
好的代码是可测试的，通过编写单元测试，既保障代码的逻辑完备，减少 Bug，也利于后期维护与重构。
2、保持代码整洁
先从简单说起，简单的代码是容易理解的，然而想要编写简单的代码，架构起来又是更复杂的。这是给自己提出更高的要求，不断优化重构，在这个过程中得到成长。当遇到一些复杂需求的时候，我始终坚信一点：如果一个逻辑我们作为实现者都很难梳理清楚，代码中一堆的 if else 条件判断，那用户也一定是无法理解的。
所以当遇到这种情况，我们需要从产品侧和架构侧去思考，到底是什么原因导致了复杂度？我们应该是去优化产品需求还是去优化底层架构。这也会迫使我们在产品和架构上有更深入的思考。
3、Code Review
为什么要做 CR？业务催的那么紧，哪有时间做 CR？
谁来做 CR？是团队的主管、核心工程师才能帮别人 CR 吗？
CR 是一件很费精力的事情，如何才能坚持下来呢？

Code Review 的主体是人， Review 的对象是代码
对于代码提交者的人来说，当你知道你的代码会被其他人看到的时候，是肯定会更加注重代码质量的。我还记得我开始向社区成熟开源项目提交代码的时候感受到的巨大压力，它会让你在提交代码前更仔细的设计和编码。经过一次次的 CR 后，你会发现你的代码质量会飞速提升。
对于评审人来说，每一次 CR 都可以增加你对整体代码库或者不同业务的熟悉程度，还可以传授经验、提升团队影响力。
最后，通过 Code Review，我们可以提升项目代码的质量与可维护性，统一团队的代码风格，并让每一个业务逻辑都能尽量找到 back up。CR 是一件三赢的事情。
CR 是一件很有意义的事情，但是我们应该怎么去做呢？
第一步还是要从自己做起，通过自己的主动与坚持，带动团队一起参与。在提交代码的时候，写好 commit message，做好自测，注意代码的可读性。抽时间来 Review 团队其他人的代码，为每一行代码负责。
但是 CR 毕竟还是一个团队的事情，如何保持团队 CR 的质量呢？我们一定要严抓新人的第一次 CR。一般来说我们团队新人的第一个 PR 都会收到比较大的挑战。新人对代码不熟悉，编码风格也和团队可能不一致，第一次 CR 非常重要，需要让大家都对齐对代码质量的标准和要求。
对新人重拳出击
除了代码之外，更上层的设计与架构也需要做 Review，让每一次系统功能设计、架构升级都经过 Review，不仅可以让系统更稳定，也可以快速提升自己的系统架构能力。
4、Unit Tests
你的代码质量如何度量？
你是如何保证代码质量？
你敢随时重构代码吗？
你是如何确保重构的代码依然保持正确性？
你是否有足够信心在没有测试的情况下随时发布你的代码？
如果对这些问题没有答案，或者没有 100% 的信心，那你需要给你的代码做单元测试。
现在说起单元测试，大家其实还是有体感的。然而在 12、13 年我刚工作的时候，单元测试还是一个相对陌生的概念，但是当时的 node 开源社区其实已经慢慢开始流行起来写单元测试了，当你给其他开源项目提交代码的时候，没有测试是不可能被合并的。当时高产的 TJ 不仅仅提供了 express connect 等 Web 框架，同时也提供了一系列底层配套的测试模块，包括测试用例驱动器 Mocha，断言库 should.js，http 请求测试库 supertest 等等。
跟随社区一起，我们很早就把单元测试引入了我们的工作中，基本上从我正式工作开始编写的第一行项目代码开始就在写单元测试了，这个习惯让我在 8 年的工作经历中保持了不错的代码质量，在没有测试工程师测试过我的代码的情况下，没有搞出重大故障被阿里开除。
说起对业务代码写单元测试，可能大家的第一反应还是哪有时间写单元测试啊？其实写单测真的没有那么耗时，只要你找对工具和方法。对于单元测试来说，只需要四个步骤：
创建一些初始数据；
对外部依赖进行 mock；
最小粒度的执行要测试的方法；
对结果做断言。
剩下的就是按照这个方式构造测试用例输入，尽可能的覆盖代码中的每一个分支和边缘场景。
Web 应用中的单元测试更加重要，在 Web 产品快速迭代的时期，每个测试用例都给应用的稳定性提供了一层保障。API 升级，测试用例可以很好地检查代码是否向下兼容。对于各种可能的输入，一旦测试覆盖，都能明确它的输出。代码改动后，可以通过测试结果判断代码的改动是否影响已确定的结果。我们在做 Egg.js 的时候，最重要的一件事情就是给它编写对应的测试框架，让业务方能够更简单、没负担的写单测来保障代码质量。
而把代码的覆盖率提高，看到测试覆盖率的报告全绿，不仅对上线代码更有信心了，同时也是一件很有成就感的事情。
5、持续分享
如果说坚持写代码是练习和输入，那另一个对我成长帮助很大的习惯就是分享，这看起来是一个对外的输出，但在我看来它更是一个非常好的学习机会。

在我刚工作在数据产品部的时候，我们团队组织了一个 Show Me The Code 的内部分享沙龙，是一个形式非常随意的分享会，不需要准备正式的 PPT，不需要很长的分享时长，就简单的分享一下最近学到的新知识，看到的有趣的代码。这个培养了我去分享的习惯。那时候经常为了找一个分享的话题，去主动研究一些新的模块，看他的源码，自己也会去造一些小的轮子来解决实际工作中遇到的重复性工作。而现在在语雀团队，我也在组织内部双周分享会，已经坚持了一年多的时间了。
再小的分享也会有收获
工作的这些年我也陆陆续续在外面的会议进行了不少的外部分享。基本上每一次分享，都需要自己先认真的对要分享的内容查漏补缺，并尝试着将它准备到浅显易懂。每一次演讲过后，都会让你对这个演讲主题的领域有更深的感受。
分享对我来说更多的是给我提供了一个非常好的阶段性总结的机会，最好的学习方法就是教会别人，因为谁也不想在台上出糗对吧。去听一场技术分享，听到的知识转眼就忘了，而你认真的去准备一场演讲，那场演讲收获最大的一定是你自己。
6、参与开源
对我的技术成长影响很大的另一个因素是开源，当然开源本质上也是一种分享。
现在是一个百花齐放的年代，开源世界的项目越来越多，根据 GitHub 的数据，2019 年有 4400 万个新项目被创建。每一个有技术追求的工程师可能都想过要去 GitHub 上写点什么。但是开源并不是指的在 GitHub 上提交代码，开源更多的是一种心态。
开源意味着你要将你的代码给所有的开发者审阅，就像前面 Code Review 的时候说的，把代码给别人看是一件很有压力的事情，更何况提交到 GitHub 后，所有人都能看到，你的同事、面试官都能看到。一定要认真的对待每一行代码，每一次提交。
同时当有人使用你的开源项目时，意味着你要承担起责任。尽管开源协议可能是很宽松的 MIT，但还是要对你写的代码负责。
开源应该让你感受到 “痛苦”，需要对开源代码提出更严格的要求，追求最优的代码架构，测试完备，描述清晰，编写高质量代码的过程会让你感受到痛苦，但是会有更快的成长。
可能我们有时候很难自己想到一个很好的想法，或者很难自己实现一个那么高质量的开源项目，不要着急，参与开源的门槛其实也没那么高。
第一步，挑选一个工作中可以用到的领域的高质量开源项目，为什么工作中可以用到很重要，因为这样你才能更好的找到改进的方向，找到痛点。例如我当时选择深入参与的开源项目是 Koa，因为我工作的重点也是在 Web 研发领域，而我觉得 Koa 当时基于 co 提供的那套异步编程模型一定是未来的趋势。
第二步，逐步参与进去，一开始可能只是修一下文档，找找 Bug 修复一下，补充几个测试用例。慢慢的随着你对代码和周边生态的完善，可以进一步去实现一些缺失的周边生态，尝试根据自己实际遇到的问题给项目提交一些功能改善。
国外有很多高质量的项目，我们也可以帮他们做文档的翻译。不要小瞧文档翻译，翻译一遍文档就意味着你要深入理解这个项目，其实也是一件很难并且很有收获的事情，还能够提升社区影响力。
开源是一个成就感驱动的事情，因为你无法从中获得看得着的收益。所以能够持续的参与开源最重要的一点是你要能够从中找到成就感。
7、和团队一起成长
说了这么多个人成长的事情，我还是想再稍微说一下团队。我们作为个人在团队中工作，只有帮助团队一起成长，拿到业务价值，才能将我们的技术成长 “变现”。而之前提到的 Code Review 亦或是单元测试，都是需要团队一起来配合的。
如果你的团队还没有内部的分享会，尝试着自己去组织一个定期的内部分享会；
从现在开始做 CR 和单测，用自己来影响团队；
尝试着在团队中建立契合团队的工程师文化。
前两点其实在之前的分享中都已经提及到了，这也是我们团队一直在坚持和倡导的。我想说一下语雀的团队文化，在语雀我们希望每一个工程师都是产品工程师，他是产品的技术合伙人，参与产品讨论、完成产品功能研发，同时他也是某一个具体领域的技术专家，例如前端 UI 组件、编辑器领域、服务端领域等等。在我们的工作流程中，所有的工程师都是以全栈的身份参与项目研发，跟进项目从产品设计、到系统分析、研发自测，CR 以及上线的全流程。通过产品工程师文化，我们鼓励每一个工程师都能够在业务和技术上找到自己的成长方向，并陪着团队和业务一起快速成长。
个人成长很重要，同时想要取得好的结果得到晋升，一定要将个人的成长和团队的成长绑定起来。通过把自己的事情做到极致，帮助团队创造业务价值，在这个过程中提升自己在团队内外的影响力。找到那个个人和团队双赢的点去发力，可以得到事半功倍的效果。