查看原文
其他

新来个技术总监,给团队引入了这款开发神器,同事直呼哇塞!

IT码徒 2022-12-16

来自读者投稿:

我在一家做微信营销的公司干技术 leader,带 40 多个人,公司名就不说了。在这个位置上做了好几年,把团队从小带大,公司虽然不算风口浪尖上的高增长业务,但技术这块儿也从来没出过什么问题,我还是蛮自豪的。

带团队时间久了,就能发现整个 Team 都渐渐疲了。前两年老板还专门买了个系统搞 OKR,现在也不大提了;Scrum 我们也搞了,用起来也就那样;项目管理工具试了好几个,禅道、Worktile、现在用 Coding,反正有一个能用的就行;微服务化改造从去年开始在吭哧吭哧搞,我们自己搞得觉得很厉害,但业务部门那边就觉得没啥差别,搞不懂你们研发部门每天在弄些什么,赶紧做我们提的需求要紧。

时间一久,很多原本不是问题的问题也会浮现出来。业务越做越复杂,一层层往上叠,迭代速度就越来越慢,感觉啥都没干呢一个 Q 唰的就过去了。有核心老员工离职,很多东西只有他熟,他一两天就能做出来的东西,新补上的人一两周也弄不出来。新员工进来也很懵逼,那么多业务那么多接口,学上一年也未必学得清楚。

我也三十多了,就感觉自己懂的招儿都用得差不多了。毕竟自己早就离开一线,多年不写代码了,真的要我去给他们解决那些代码层面的问题,也有些力不从心。现在经济形势不好,业务也不是高速发展期,也没法挖一个大牛带进来一些先进生产力。而且要是真的挖了大牛进来,我自己往哪儿放呢。

测试团队的突破

突破最开始来自测试团队,这是我万万没想到的。

测试组的组长是个 93 年的小姑娘,人很踏实能干,最开始团队还很小的时候她就在,后面研发团队扩大,就让她带测试组了。这么多年下来,公司业务那么多细节可能没人比她更懂。不过她在来我们公司之前只有一份小公司的工作经验,没见过什么大厂的世面。

去年搞微服务化的时候,当时几个组长讨论,就说可能对测试的要求会更高,得把自动化测试搞起来。后面测试组长就开始自己吭哧吭哧啃 Selenium,自己一个人折腾了好久,终于把 Selenium 架起来了。

测试这块我不懂,帮不上什么忙,看她一个人弄也有点心疼。终于把框架搭好了,实际用起来的时候我就有点心凉。

干啥都要写代码,她自己学得还行,别的测试根本帮不上忙。这些国外的工具连中文资料都很少,没有技术支持简直都不算问题了。可是连个自动生成的测试报告都没有,这真的不能忍。

测试团队试了一两个迭代,渐渐地就不提了,我也觉得没必要。毕竟引入一个新工具,大家为的都是提效。弄一个只有高级人才才玩得转的工具进来,真的能者多劳了,劳久了对谁都没好处。

有一天,测试组长发我一个文件。我打开一看,是个测试报告,长这样儿。

测试报告

一看到这个测试报告我眼就亮了。所有接口运行状况一目了然,有问题的接口具体是什么问题都清清楚楚。我就回她消息:“真不错👍最近又在用心研究自动化测试工具了?这个测试报告挺好的,花了很多心思吧。”

她很快就回了:“没有😂昨天才发现的这个工具,还挺好用。好像还能做性能测试,我还在研究。”

我兴趣就起来了。没过多久,她又发了一个报告过来。我一看,好家伙,100 个线程同时跑!

性能测试

我问她:“这个怎么跑的多线程?是那种要租客户端的吗?怎么收费啊?”

她回:“免费的😂”

我就叫上后端组长前端组长,跟测试组长一块儿去会议室讨论了一下她用的这个叫 Apifox 的工具。后端组长说:“哦我知道这个玩意儿,不是跟 Postman 差不多吗,怎么还能做自动化测试?”

测试组长说,她就是把我们做的接口文档导进去 Apifox 了,也就花了二十分钟配置,自动化接口测试就跑起来了。

后端组长问:“那这玩意儿能不能做接口监控呢?定时跑一下?”测试组长说:“好像也可以。这边帮助文档里写可以做持续集成。”

后端组长跟测试组长一块儿又花了二十分钟研究,然后就把我们的 Jenkins 和 Apifox 上写好的自动化测试用例打通了,自动化测试每小时跑一次,自动就会生成一个测试报告。

我就很感慨。去年搞微服务的时候也学了不少大公司的微服务架构,看他们搞高大上的微服务治理,每个服务的业务量和响应速度监控,真是让人眼馋。没想到我们一家小公司,接口监控、性能测试,一个小时就搞出来了?

这个 Apifox,有点东西。

这真的是联调吗

我对自己的评价,还是一个有追求的技术人。前几年我就要求开发团队必须把接口文档写好,毕竟公司业务很复杂,开发的人不写清楚,后面的新人更加搞不清楚。

我们的工作流,产品需求出来之后,前后端会先开个会,讨论清楚有哪些接口和输入输出,然后同步进开发。后端写接口的时候,Swagger 自动就把接口文档生成了,就还挺方便的。

自动化测试这个事情之后,后端组长就对这个 Apifox 很有好感。他研究了一下发现 Apifox 可以定时导入 Swagger,不但测试可以直接用来测接口,后端也可以把 Apifox 当 Postman 用,省得自己拼参数写请求了,直接填参数值就能自测,就让后端开发都用起来了。

我们三周一个迭代,一般都会留一周做测试,第二周的周三就得进联调,周五下班提测。前几年还可以,可最近一年问题越来越多。联调往往三四天还弄不完,迟迟没办法提测,就只能往后拖,周末加班还不一定搞完。进到测试环节,还会不断有低级 bug 出来,修 bug 时间也越来越长,每个迭代都要延期。

问题大家也都清楚。无非就是我前面说的几个情况,架构越来越复杂,牵一发动全身,很多新人又不了解业务,做事慢不说,还总是会踩坑。很多问题自己写代码的时候发现不了,等到联调的时候就全暴露出来了。后端组长也跟开发们反复强调要自测,可业务压力又大,写代码都写不完,哪有工夫自测得那么仔细呢。

我记得很清楚,那天是个周五,早上晨会的时候,我心想不知道今天能不能提测啊,这个需求老板盯得挺紧,可别延期了。结果测试组那边说,昨天就已经提测了!已经测了一下午了!

什么情况!?联调可以这么快的吗?

到周一开周会的时候,测试组长说,测得比较顺利,估计明天能测完。

我就憋不住了,问前端和后端组长,是这个迭代的需求特别简单吗?

后端组长说,也不是需求简单,就……这次的接口质量特别好,一调就过了,我们也很纳闷。

前端组长也说,以往前端写的请求接口跟后端经常对不上,就要花很多时间调,这次也不知道怎么回事,基本上都是一两遍就过了。

后端骨干说,我觉得……可能是因为我们用了那个 Apifox……

我:???

不就一个调接口的工具吗,还能让人写的代码质量提升了?作为一个十几年的技术人,我觉得这根本没啥关联啊。

我就让他们给我演示一下到底这个 Apifox 是怎么用的。我们讨论了整整两个小时,我总算是搞明白了。

这里面有几个关键点。

第一,后端虽然定义好了接口的输入输出,也有文档,但是写出来的代码未必符合文档里的定义。这里少个字段,那里把 integer 输出成了 string,都是很经常发生的情况。很多问题让后端自测,他们自己根本看不出来。

而后端用了这个 Apifox 之后,有一个特别好用的功能叫数据结构校验,自动就可以判断接口出参跟文档定义是不是一致。很多问题,后端一发送请求就自己发现了,根本不会到联调的时候才暴露出来。

数据结构校验

第二,Apifox 还有一个“动态值”的功能,可以随机生成一系列不同的参数值,数据结构定义起来也很方便。后端就用这个功能,把一个接口自动跑上 10000 遍,连边界值都测出来了,啥问题都自己发现了。

动态值

第三,后端把 Apifox 也推荐给了前端,前端拿这个当 Postman 用的时候,意外发现还能做 Mock 数据。最离谱的是,Mock 规则根本不用写,根据字段名称就能智能 Mock 出很合理的数据,比之前用的 Mock.js 方便多了。

前端直接就拿 Apifox Mock 出来的数据放到界面里用,不但省了自己做数据的时间,最重要是跟接口文档是完全一致的,就算后端中途改了接口定义,虽然接口还没做出来,但 Mock 数据已经自动就变了,前端立刻就发现了,就赶紧去问后端怎么回事。

智能 Mock 数据

咱们做软件的都知道,问题越早发现,修复的成本就越低。前端和后端都能在最早的环节就发现问题,效率可不就上来了吗!

为什么联调每次都那么耗时间?最主要的原因就是因为前端要的数据跟后端给的数据对不上。而用了这个 Apifox 之后,前端跟后端的数据自然而然就对上了!还能自动检查数据格式!

半天就联调通过了,这还是联调吗!?

我就……又很感慨。很多事情是我们习以为常的,觉得联调肯定是痛苦的,就从来没想过为什么这个环节会存在问题,如何去解决这里面的问题。

这个 Apifox,真是牛逼。

我又让几个技术骨干都试一下功能,确认一下符合我们的研发流程。到第二周部门周会的时候,我就跟大家说,全部门都把 Apifox 用起来。

如何搞定合作方

又过了些日子,有一天后端组长嘿嘿笑着来找我,说发现了一个牛逼的东西。

我们的业务性质,经常需要跟银行、运营商之类的合作,就会用到他们提供的 API。银行的研发人员,技术未必好,做出来的文档也不咋地,更不会提供测试环境。每次要用真实数据的时候,我们都是战战兢兢地,就怕出了问题,那损失就大了。

后端组长说,先前说的那个 Apifox 的 Mock 功能,我最近又研究了一下,发现除了能 Mock 前端用的数据,还有另外一种用法。

我们手里不是有银行提供的 API 文档嘛,我们就把这套 API 维护到 Apifox 里面去,做成一个项目。他们有一个“云端 Mock”的功能,可以直接访问服务端接口获取 Mock 数据。我们可以把这个数据当作银行服务器的测试环境来用,每个后端都能访问,也没有次数限制,随便怎么测都行!

我点点头就让他赶紧去搞了。这个 Apifox,能玩出什么花来我都不奇怪了。

过了两天后端组长又嘿嘿笑着来了,说 Apifox 能生成 API 文档,想把我们官网上对外的接口文档换成 Apifox 生成的文档。

我们业务会对接不少公司客户,他们要把自己的业务系统跟我们的营销工具做对接,所以我们专门有一个组是对接客户的,主要就是教他们怎么调我们的接口。

这些客户的开发人员,水平更加一言难尽。毕竟大都是小公司,很多连专职的开发都没有,都是外包的。很多客户嚷嚷着我们接口有问题,远程一看,接口参数根本就没拼对。

我想着 Apifox 那个接口文档我见过,做得还可以,好处是能实时更新,不用专门维护,就同意后端组长把官网上的文档换掉了。

文档换掉之后,过了两周,周会的时候我就发现,客户支持组那边,事情好像少了很多。

我问客户支持组长,最近是新客户变少了吗?感觉你这边以往加班不少,最近都不需要加班了。

客户支持组长说,最近新客户还有变多呢。可客户的问题就变少了很多。我感觉应该是新版的 API 文档的缘故。

怎么回事?换个文档页面,还能让人智商提升了?作为一个十几年的技术人,我觉得这不科学啊!

我会后拉着客户支持组长聊了一个小时,算是搞明白了到底发生了什么。

以往,之所以客户问题多,很大原因是我们的接口比较复杂,参数很多,客户需要照着抄一遍到 Postman 里调好,再到自己代码里拼接,就很容易出问题。

而 Apifox 生成的接口文档,有一个“在线运行”的功能,点开就是一个发送接口的界面,长得跟 Postman 差不多。客户根本不用自己去拼接参数,直接在页面上就把接口给调通了。

而且,这个在线运行还能设不同的环境,后端组长直接搞了一个测试环境开放出去,客户随便调都不会出问题。

在线运行

最离谱的是,这个接口文档还能生成代码?接口调好了,直接就能一键生成请求代码和数据结构代码,客户复制一下就能直接用了。这个生成代码还支持二十多种语言,啥框架都能用。

我算是明白了,容易出问题的环节都被工具解决了,客户可不就没问题了嘛。

这个 Apifox……前途无量啊。

提升了多少效率

我算了一下。

后端,写接口文档的时间能省 80%,自测和改 bug 的时间能省 50%,质量能提升30%。用到第三方接口的话,调接口的时间能省 60%。

前端,Mock 数据花的时间能省 100%,调接口的时间能省 40%。

联调时间能省 80%。

接口测试时间能省 60%,回归测试时间能省90%。还能实现接口自动化监控和性能测试。

客户服务对接的时间能省 70%。

还是那么多人,整个迭代还是三周,但是效率高了,能做的需求比以往更多,质量也更好了,大家也不用苦逼逼地晚上周末加班了。加在一起,Apifox 对我们团队,真的能提升 100% 的效率

尤其难得的是,我们好像也没经历什么转型的阵痛,内部团队的阻力,似乎一切顺理成章地就下来了。明明引入了一个新工具,开发效率也大幅提升了,可是工作流程还是先前的流程,都不需要做什么专门的调整。

我以前跟一位前辈聊,他说了一句让我印象深刻的话:“产品是最佳实践的载体。”以前我不懂,现在我好像懂一些了。

上个月开上半年总结会,老板狠狠夸了一顿研发团队,说最近的开发效率超出预期,系统稳定性也一直很不错。业务部门的老大也说,之前提了很久的一些需求,近期哗哗地都实现了,一线业务同事们都很满意。

还是挺爽的。

而且,公司一分钱都没花呀。

Apifox 还是个中国团队做的,真心希望他们越做越好,把整个中国的研发团队的效率都提升一大截。

中国该有个厉害的研发工具出来了。

赶紧点击“阅读原文”去下载吧

下载链接:http://apifox.cn/a101itmatu1

您可能也对以下帖子感兴趣

文章有问题?点此查看未经处理的缓存