如何包装你的代码？优秀的工程师不会告诉你的秘密

工程师最大的冤屈莫过于辛辛苦苦写的代码却不受待见。其背后的原因往往与release做得不够好有关。 Release直译为“发布”，其实是“更新”的意思，是软件开发的重要环节。自动驾驶的工程师们和互联网行业的软件工程师们一样，需要通过release证明自己的工作成果。和互联网产品不同的是，自动驾驶的release成果看不见也摸不着，一切只能上路测试见分晓。 然而在疫情期间，各个公司都已暂停了路测。路测是代码的试金石，一旦没有了试金石，就需要工程师们更加用心做好release，通过纯软件的方法，证明自己的代码的价值。 其实，不论有没有路测，工程师都应该认真做release。假设一个项目需要50天完成，写代码本身可能只需要30天，剩下的20天完全用于release，一点也不为过。一次高质量的release往往要经历以下几个步骤。

测试：越用心做，收获越大。

毋庸置疑，未经测试的代码不可以被更新。问题是，我们该如何测试，又该测试哪些部分。代码完成之后，工程师首先要写的一份文档应该是测试文档。在文档中，我们要把测试分为几个步骤：单元测试、模块测试、集成测试。然后根据每个步骤分析代码中所牵扯的各个环节，分析与其他部门代码之间的关系。让自己的工程经理或产品经理去和这些部门协调，保证更新之后部门之间的代码不会发生“摩擦”。

指标与报表：白纸黑字证明你的实力。

我们需要思考，可以通过哪些方式衡量自己代码的影响力。假设你的代码是为了提高计算速度，那么，你就要证明之前的计算速度有多慢，现在有多快，然后将这些数据清清楚楚地反应在一份报表上。这份报表最好可以自动更新，用图表显示出速度提升的前后对比，让同事和老板们都可以定期看到。

掌握好更新的节奏。

你打算多久更新一次？下一次更新需要做哪些？讲清你的近期规划有助于增进同事对你代码的信赖度。

你是否需要留一些保留项目？如果想一口气把所有功能都做出来，就会需要更久的时间。我们需要思考哪一部分可以作为V0。

如果公司对的代码反响很好，想让你多加一些功能，你该如何处理？这一过程很像“客服”，也需要提前讲清。

人靠衣装，code靠doc装。

你可以把你的代码想象为一款办公软件，没有用过的用户其实很难了解这款软件到底值不值得买。这时就需要靠包装与产品说明了，也就是文档（doc）。一次优秀的更新往往需要多种文档，包括一些几种。

文字文档，也是最常见的文档，比如Google Docs

代码文档，比如markdown

公司内部网的网站

最后，通过邮件、做报告会议等方式，为这次更新做宣传。

如果以上这几方面都可以做到，不但可以保证release的质量，同时也可以提升自己在公司的影响力，为其他同事树立榜样，营造积极地工程师文化。