我的离职遗产

·

1 min read

image.png

今天,经历人生中第二次离职,同样也是自己提出的离职,同样也是干满了两年,与第一次工作初出茅庐不谙世事相比,这次离职,多了一些厚重感。

这份工作,于我的职业经历来说,并非浓墨重彩的一笔,但也留下了一些个人认为比较有意义东西。因为离职去杭州是早有打算的事情,在几个月以前,就已经陆续将项目的一些文档聚集到gitlab的wiki上了,方便大家使用。说到文档这事,记得去年开年的时候,我就有跟当时的Leader提过文档集中化管理,因为当时部门内的产品设计文档、开发设计文档、第三方对接资料等都比较零散的个人电脑里面,很不利于问题追溯与信息汇总,特别是当有新同事入职时,基本上只有靠face to face的讲业务,甚至是查阅代码了,花费时间长,效率低下。由于我很早就开始使用石墨文档,因此我有几次对接需求的时候,使用石墨文档出需求说明和设计,也向周围的同事推荐这个在线文档工具,逐渐在团队内部推广开来,其实也不算推广,它的好处显而易见:文档共享。今年,大家的文档与设计包括休假时的一些事项说明、与第三方对接文档说明、包括我的离职交接文档等,都是使用石墨文档,这是一件很小的事情,但却是我觉得特别有意义的一件事。

在软件快速迭代的过程中,功能的变化有时是靠产品经理来推动的,有些生产问题是测试人员来记录,奇怪的时,有时候历史上线版本、上线了什么功能开发自己竟然会不知道(好记性不如烂笔头嘛),这是一件很尴尬的事情。我毕竟参与过开源社区的项目,对开源项目的规范流程很是认可,其实只需要在项目里面加一个Changelog就可以了,哪一个版本,上线了什么功能,也不会费多少时间,一切清清楚楚。于是我带头这么干了,有些同学看到我这么干了,也默默加上了Changelog,这是一个好习惯,理应推广,虽然不是所有人都接受,但是我很欣慰,自己的行为还是影响到了一些同学,这相信,这些影响是正面的,即使它看起来是多么微不足道的一件事。

真的是受了开源的影响,我连写代码也会不自觉的尽可能多的写测试代码,在提交到主分支的时候,一定要让别人review一下我的代码,虽然刚开始看起来有一些假把式,但是却多了一份对代码的敬畏感,我让别人review我的代码,别人也会礼尚往来的让我review他们的代码,一来二去,大家都很自觉的以PR的形式提交代码,也会核对代码逻辑、上线版本等。其实我什么也没有做,我只是试着把开源社区的一些好的行为习惯带到团队里面,试着让自己,让团队变得更好,这也是我的初衷。有点遗憾,写测试代码这些事情,因为种种原因,我本来可以做的更好、更完善的。

可测试性,是测试同学教给我的。当测试同学发现bug的时候,我期望他们提上来的bug是清晰的,有前置条件、所属环境、现象、期望结果等,但结果往往不尽于人意,很多时候还是靠问,靠face to face、靠钉钉。所以我在JIRA上建任务的时候,开始有意识的去描述清楚我做了什么,结果是怎么样的,在哪个环境,什么版本,可以的话会具体到哪些接口。你说这些事情难吗?真的不难,我想的是,如果别人看到我写的杂乱无章,他们会没办法展开工作,就会来问我,占用了双方的时间,真的不划算,交心比心,就能做的更好。

回顾这两年,我也算兢兢业业,没有留下惊世骇俗的代码(应该会留下一些bug), 但,我留下了一些微不足道的习惯。