工作

今年我离开了ZStack,那时的我其实明白自己想要什么——诸如想要什么样的生活、想做些什么事、还想知道些什么,于是我来到了现在这家公司.而我的愿望也的确被满足了.

而我的工作也不再仅仅是在编码上了,我参与了很多事,比如关注团队成长、开发规范的推进、大量的参与招聘等等...在此之中,我也获得了成长,在这里,可以举几个例子.

开发规范

以开发规范为例,当一些规范并未落地时,会增加许多事后看来不必要的成本.以我们熟知的自动化测试为例,项目终于到了可以交给测试同学测试的阶段了,然而测了半天有问题,交由给你,你改好了代码,自己测了一遍,测试同学测试后发现这个问题的确解决了,之后几个问题也如愿解决.但是最后一刻,测试同学发现原本的功能遭到了破坏,于是又是一遍你改代码手测交给测试同学的循环,总算在客户生产环境上线了,结果又发现了问题,从交付同学call到pm或到测试,测试再找到开发,又是几轮测试下来.如果问题多的话,不知道会有多少人力成本浪费在里面,而客户对这个公司的印象又会变得如何呢?

而我们的软件总是越来越庞大的,我们发现我们要测的功能会越来越多,测试同学的负担会越来越重.....

如果这些手测能够交给机器来做,是不是可以省下很多成本呢?——这就是自动化测试带来的价值.

把话题展开来,今年类似开发规范推进的事,我做了这些:

基于GitLab的Continuous Integration ——尝试使用GitLab-CI
Functional Spec (Or Proposal)
CodeReview
解放前端:API文档+SDK

CI

利用GitLab的CI让每个commit跑一遍自动化测试,粗略算了一下,目前所在的小组平均每周跑的测试有5000多个.引入CI做这件事,正是因为我信奉:

一个bug被发现的越早,fix的成本越小
能通过机器来做的事,就不要让人去做

Funstional Spec

编写这个文档的习惯来自于ZStack.FS是以Feature为基本单位,用来约定PM、测试、前端和后端如何在这个Feature中的工作一个Spec.里面必须写的内容有:背景、原理介绍、接口设计、相关数据结构、测试用例.并且保证在编码前这个文档足够完善,在编码时完全依据此文档来编程.

而引入它的理由则是希望有个文档来约束各个角色在这个Feature中会产生意外的可能性,比如测试一看说这个API的结果明显应该是这么期待的啊,开发你怎么肥4.然后再测试阶段开始重构,再测...天呐...

不仅如此,也是给后来的新人留下了有效的文档.

而在实践中,发现这玩意儿还有约束PM意外能力.哪天PM改需求了,就和PM说:看!你当时不是这么说的.然而没什么软用,爸爸让你改你还是要改.

逛过K8S社区的人知道,其实这个FS和里面的Proposal有点像.

CodeReview

CodeReview配合FS是很棒的一件事,因为这样Review的人能很快的得知上下文,并参考里面的约定来Review代码.

而CodeReview带来的好处则是有效的(或者说言传身教的?)保证了项目代码的规范,且避免一些低级明显的错误被提交上来.

当一个新人问我“为什么要这么改”的时候,有时给我带来的思考收获甚至超过一天的编码.

解放前端

在实践中,我认为ZStack对前端并不友好,从外部来看,它对于异步API支持轮询和webhook,轮询真的太挫了,而webhook意味着前端要编写一些服务器逻辑.而从内部来看,它的RestServer.java抽象程度并不好,二开则意味着紧耦合开发.最后为了解决这个问题,引入了WebSocket.

再之就是给前端同学提供了文档,因为我觉得来回问这个API那个API效率很低...后来发现,我给前端API文档,前端还是要照着写Request和Response的回复啊,那为什么不用元编程提供一套SDK给他们直接用呢?后来就这么做了.这样前端同学就是可以专注他们自己的业务了,而不是后端定义的数据结构上.

能通过机器来做的事,就不要让人去做.