image.png
今天，经历人生中第二次离职，同样也是自己提出的离职，同样也是干满了两年，与第一次工作初出茅庐不谙世事相比，这次离职，多了一些厚重感。
这份工作，于我的职业经历来说，并非浓墨重彩的一笔，但也留下了一些个人认为比较有意义东西。因为离职去杭州是早有打算的事情，在几个月以前，就已经陆续将项目的一些文档聚集到gitlab的wiki上了，方便大家使用。说到文档这事，记得去年开年的时候，我就有跟当时的Leader提过文档集中化管理，因为当时部门内的产品设计文档、开发设计文档、第三方对接资料等都比较零散的个人电脑里面，很不利于问题追溯与信息汇总，特别是当有新同事入职时，基本上只有靠face to face的讲业务，甚至是查阅代码了，花费时间长，效率低下。由于我很早就开始使用石墨文档，因此我有几次对接需求的时候，使用石墨文档出需求说明和设计，也向周围的同事推荐这个在线文档工具，逐渐在团队内部推广开来，其实也不算推广，它的好处显而易见：文档共享。今年，大家的文档与设计包括休假时的一些事项说明、与第三方对接文档说明、包括我的离职交接文档等，都是使用石墨文档，这是一件很小的事情，但却是我觉得特别有意义的一件事。
在软件快速迭代的过程中，功能的变化有时是靠产品经理来推动的，有些生产问题是测试人员来记录，奇怪的时，有时候历史上线版本、上线了什么功能开发自己竟然会不知道（好记性不如烂笔头嘛），这是一件很尴尬的事情。我毕竟参与过开源社区的项目，对开源项目的规范流程很是认可，其实只需要在项目里面加一个Changelog就可以了，哪一个版本，上线了什么功能，也不会费多少时间，一切清清楚楚。于是我带头这么干了，有些同学看到我这么干了，也默默加上了Changelog，这是一个好习惯，理应推广，虽然不是所有人都接受，但是我很欣慰，自己的行为还是影响到了一些同学，这相信，这些影响是正面的，即使它看起来是多么微不足道的一件事。
真的是受了开源的影响，我连写代码也会不自觉的尽可能多的写测试代码，在提交到主分支的时候，一定要让别人review一下我的代码，虽然刚开始看起来有一些假把式，但是却多了一份对代码的敬畏感，我让别人review我的代码，别人也会礼尚往来的让我review他们的代码，一来二去，大家都很自觉的以PR的形式提交代码，也会核对代码逻辑、上线版本等。其实我什么也没有做，我只是试着把开源社区的一些好的行为习惯带到团队里面，试着让自己，让团队变得更好，这也是我的初衷。有点遗憾，写测试代码这些事情，因为种种原因，我本来可以做的更好、更完善的。
可测试性，是测试同学教给我的。当测试同学发现bug的时候，我期望他们提上来的bug是清晰的，有前置条件、所属环境、现象、期望结果等，但结果往往不尽于人意，很多时候还是靠问，靠face to face、靠钉钉。所以我在JIRA上建任务的时候，开始有意识的去描述清楚我做了什么，结果是怎么样的，在哪个环境，什么版本，可以的话会具体到哪些接口。你说这些事情难吗？真的不难，我想的是，如果别人看到我写的杂乱无章，他们会没办法展开工作，就会来问我，占用了双方的时间，真的不划算，交心比心，就能做的更好。
回顾这两年，我也算兢兢业业，没有留下惊世骇俗的代码（应该会留下一些bug）, 但，我留下了一些一些微不足道的习惯。
网友评论