一個悄然崛起的國產(chǎn)軟件，低調(diào)又強大！

來自讀者投稿：

我在一家做微信營銷的公司干技術(shù) leader，帶 40 多個人，公司名就不說了。在這個位置上做了好幾年，把團(tuán)隊從小帶大，公司雖然不算風(fēng)口浪尖上的高增長業(yè)務(wù)，但技術(shù)這塊兒也從來沒出過什么問題，我還是蠻自豪的。

帶團(tuán)隊時間久了，就能發(fā)現(xiàn)整個 Team 都漸漸疲了。前兩年老板還專門買了個系統(tǒng)搞 OKR，現(xiàn)在也不大提了；Scrum 我們也搞了，用起來也就那樣；項目管理工具試了好幾個，禪道、Worktile、現(xiàn)在用 Coding，反正有一個能用的就行；微服務(wù)化改造從去年開始在吭哧吭哧搞，我們自己搞得覺得很厲害，但業(yè)務(wù)部門那邊就覺得沒啥差別，搞不懂你們研發(fā)部門每天在弄些什么，趕緊做我們提的需求要緊。

時間一久，很多原本不是問題的問題也會浮現(xiàn)出來。業(yè)務(wù)越做越復(fù)雜，一層層往上疊，迭代速度就越來越慢，感覺啥都沒干呢一個 Q 唰的就過去了。有核心老員工離職，很多東西只有他熟，他一兩天就能做出來的東西，新補上的人一兩周也弄不出來。新員工進(jìn)來也很懵逼，那么多業(yè)務(wù)那么多接口，學(xué)上一年也未必學(xué)得清楚。

我也三十多了，就感覺自己懂的招兒都用得差不多了。畢竟自己早就離開一線，多年不寫代碼了，真的要我去給他們解決那些代碼層面的問題，也有些力不從心。現(xiàn)在經(jīng)濟(jì)形勢不好，業(yè)務(wù)也不是高速發(fā)展期，也沒法挖一個大牛帶進(jìn)來一些先進(jìn)生產(chǎn)力。而且要是真的挖了大牛進(jìn)來，我自己往哪兒放呢。

測試團(tuán)隊的突破

突破最開始來自測試團(tuán)隊，這是我萬萬沒想到的。

測試組的組長是個 93 年的小姑娘，人很踏實能干，最開始團(tuán)隊還很小的時候她就在，后面研發(fā)團(tuán)隊擴(kuò)大，就讓她帶測試組了。這么多年下來，公司業(yè)務(wù)那么多細(xì)節(jié)可能沒人比她更懂。不過她在來我們公司之前只有一份小公司的工作經(jīng)驗，沒見過什么大廠的世面。

去年搞微服務(wù)化的時候，當(dāng)時幾個組長討論，就說可能對測試的要求會更高，得把自動化測試搞起來。后面測試組長就開始自己吭哧吭哧啃 Selenium，自己一個人折騰了好久，終于把 Selenium 架起來了。

測試這塊我不懂，幫不上什么忙，看她一個人弄也有點心疼。終于把框架搭好了，實際用起來的時候我就有點心涼。

干啥都要寫代碼，她自己學(xué)得還行，別的測試根本幫不上忙。這些國外的工具連中文資料都很少，沒有技術(shù)支持簡直都不算問題了?？墒沁B個自動生成的測試報告都沒有，這真的不能忍。

測試團(tuán)隊試了一兩個迭代，漸漸地就不提了，我也覺得沒必要。畢竟引入一個新工具，大家為的都是提效。弄一個只有高級人才才玩得轉(zhuǎn)的工具進(jìn)來，真的能者多勞了，勞久了對誰都沒好處。

有一天，測試組長發(fā)我一個文件。我打開一看，是個測試報告，長這樣兒。

一看到這個測試報告我眼就亮了。所有接口運行狀況一目了然，有問題的接口具體是什么問題都清清楚楚。我就回她消息：“真不錯??最近又在用心研究自動化測試工具了？這個測試報告挺好的，花了很多心思吧?！?/p>

她很快就回了：“沒有??昨天才發(fā)現(xiàn)的這個工具，還挺好用。好像還能做性能測試，我還在研究。”

我興趣就起來了。沒過多久，她又發(fā)了一個報告過來。我一看，好家伙，100 個線程同時跑！

我問她：“這個怎么跑的多線程？是那種要租客戶端的嗎？怎么收費??？”

她回：“免費的??”

我就叫上后端組長前端組長，跟測試組長一塊兒去會議室討論了一下她用的這個叫 Apifox 的工具。后端組長說：“哦我知道這個玩意兒，不是跟 Postman 差不多嗎，怎么還能做自動化測試？”

測試組長說，她就是把我們做的接口文檔導(dǎo)進(jìn)去 Apifox 了，也就花了二十分鐘配置，自動化接口測試就跑起來了。

后端組長問：“那這玩意兒能不能做接口監(jiān)控呢？定時跑一下？”測試組長說：“好像也可以。這邊幫助文檔里寫可以做持續(xù)集成?！?/p>

后端組長跟測試組長一塊兒又花了二十分鐘研究，然后就把我們的 Jenkins 和 Apifox 上寫好的自動化測試用例打通了，自動化測試每小時跑一次，自動就會生成一個測試報告。

我就很感慨。去年搞微服務(wù)的時候也學(xué)了不少大公司的微服務(wù)架構(gòu)，看他們搞高大上的微服務(wù)治理，每個服務(wù)的業(yè)務(wù)量和響應(yīng)速度監(jiān)控，真是讓人眼饞。沒想到我們一家小公司，接口監(jiān)控、性能測試，一個小時就搞出來了？

這個 Apifox，有點東西。

這真的是聯(lián)調(diào)嗎

我對自己的評價，還是一個有追求的技術(shù)人。前幾年我就要求開發(fā)團(tuán)隊必須把接口文檔寫好，畢竟公司業(yè)務(wù)很復(fù)雜，開發(fā)的人不寫清楚，后面的新人更加搞不清楚。

我們的工作流，產(chǎn)品需求出來之后，前后端會先開個會，討論清楚有哪些接口和輸入輸出，然后同步進(jìn)開發(fā)。后端寫接口的時候，Swagger 自動就把接口文檔生成了，就還挺方便的。

自動化測試這個事情之后，后端組長就對這個 Apifox 很有好感。他研究了一下發(fā)現(xiàn) Apifox 可以定時導(dǎo)入 Swagger，不但測試可以直接用來測接口，后端也可以把 Apifox 當(dāng) Postman 用，省得自己拼參數(shù)寫請求了，直接填參數(shù)值就能自測，就讓后端開發(fā)都用起來了。

我們?nèi)芤粋€迭代，一般都會留一周做測試，第二周的周三就得進(jìn)聯(lián)調(diào)，周五下班提測。前幾年還可以，可最近一年問題越來越多。聯(lián)調(diào)往往三四天還弄不完，遲遲沒辦法提測，就只能往后拖，周末加班還不一定搞完。進(jìn)到測試環(huán)節(jié)，還會不斷有低級 bug 出來，修 bug 時間也越來越長，每個迭代都要延期。

問題大家也都清楚。無非就是我前面說的幾個情況，架構(gòu)越來越復(fù)雜，牽一發(fā)動全身，很多新人又不了解業(yè)務(wù)，做事慢不說，還總是會踩坑。很多問題自己寫代碼的時候發(fā)現(xiàn)不了，等到聯(lián)調(diào)的時候就全暴露出來了。后端組長也跟開發(fā)們反復(fù)強調(diào)要自測，可業(yè)務(wù)壓力又大，寫代碼都寫不完，哪有工夫自測得那么仔細(xì)呢。

我記得很清楚，那天是個周五，早上晨會的時候，我心想不知道今天能不能提測啊，這個需求老板盯得挺緊，可別延期了。結(jié)果測試組那邊說，昨天就已經(jīng)提測了！已經(jīng)測了一下午了！

什么情況！？聯(lián)調(diào)可以這么快的嗎？

到周一開周會的時候，測試組長說，測得比較順利，估計明天能測完。

我就憋不住了，問前端和后端組長，是這個迭代的需求特別簡單嗎？

后端組長說，也不是需求簡單，就……這次的接口質(zhì)量特別好，一調(diào)就過了，我們也很納悶。

前端組長也說，以往前端寫的請求接口跟后端經(jīng)常對不上，就要花很多時間調(diào)，這次也不知道怎么回事，基本上都是一兩遍就過了。

后端骨干說，我覺得……可能是因為我們用了那個 Apifox……

我：？？？

不就一個調(diào)接口的工具嗎，還能讓人寫的代碼質(zhì)量提升了？作為一個十幾年的技術(shù)人，我覺得這根本沒啥關(guān)聯(lián)啊。

我就讓他們給我演示一下到底這個 Apifox 是怎么用的。我們討論了整整兩個小時，我總算是搞明白了。

這里面有幾個關(guān)鍵點。

第一，后端雖然定義好了接口的輸入輸出，也有文檔，但是寫出來的代碼未必符合文檔里的定義。這里少個字段，那里把 integer 輸出成了 string，都是很經(jīng)常發(fā)生的情況。很多問題讓后端自測，他們自己根本看不出來。

而后端用了這個 Apifox 之后，有一個特別好用的功能叫數(shù)據(jù)結(jié)構(gòu)校驗，自動就可以判斷接口出參跟文檔定義是不是一致。很多問題，后端一發(fā)送請求就自己發(fā)現(xiàn)了，根本不會到聯(lián)調(diào)的時候才暴露出來。

第二，Apifox 還有一個“動態(tài)值”的功能，可以隨機(jī)生成一系列不同的參數(shù)值，數(shù)據(jù)結(jié)構(gòu)定義起來也很方便。后端就用這個功能，把一個接口自動跑上 10000 遍，連邊界值都測出來了，啥問題都自己發(fā)現(xiàn)了。

第三，后端把 Apifox 也推薦給了前端，前端拿這個當(dāng) Postman 用的時候，意外發(fā)現(xiàn)還能做 Mock 數(shù)據(jù)。最離譜的是，Mock 規(guī)則根本不用寫，根據(jù)字段名稱就能智能 Mock 出很合理的數(shù)據(jù)，比之前用的 Mock.js 方便多了。

前端直接就拿 Apifox Mock 出來的數(shù)據(jù)放到界面里用，不但省了自己做數(shù)據(jù)的時間，最重要是跟接口文檔是完全一致的，就算后端中途改了接口定義，雖然接口還沒做出來，但 Mock 數(shù)據(jù)已經(jīng)自動就變了，前端立刻就發(fā)現(xiàn)了，就趕緊去問后端怎么回事。

咱們做軟件的都知道，問題越早發(fā)現(xiàn)，修復(fù)的成本就越低。前端和后端都能在最早的環(huán)節(jié)就發(fā)現(xiàn)問題，效率可不就上來了嗎！

為什么聯(lián)調(diào)每次都那么耗時間？最主要的原因就是因為前端要的數(shù)據(jù)跟后端給的數(shù)據(jù)對不上。而用了這個 Apifox 之后，前端跟后端的數(shù)據(jù)自然而然就對上了！還能自動檢查數(shù)據(jù)格式！

半天就聯(lián)調(diào)通過了，這還是聯(lián)調(diào)嗎??？

我就……又很感慨。很多事情是我們習(xí)以為常的，覺得聯(lián)調(diào)肯定是痛苦的，就從來沒想過為什么這個環(huán)節(jié)會存在問題，如何去解決這里面的問題。

這個 Apifox，真是牛逼。

我又讓幾個技術(shù)骨干都試一下功能，確認(rèn)一下符合我們的研發(fā)流程。到第二周部門周會的時候，我就跟大家說，全部門都把 Apifox 用起來。

如何搞定合作方

又過了些日子，有一天后端組長嘿嘿笑著來找我，說發(fā)現(xiàn)了一個牛逼的東西。

我們的業(yè)務(wù)性質(zhì)，經(jīng)常需要跟銀行、運營商之類的合作，就會用到他們提供的 API。銀行的研發(fā)人員，技術(shù)未必好，做出來的文檔也不咋地，更不會提供測試環(huán)境。每次要用真實數(shù)據(jù)的時候，我們都是戰(zhàn)戰(zhàn)兢兢地，就怕出了問題，那損失就大了。

后端組長說，先前說的那個 Apifox 的 Mock 功能，我最近又研究了一下，發(fā)現(xiàn)除了能 Mock 前端用的數(shù)據(jù)，還有另外一種用法。

我們手里不是有銀行提供的 API 文檔嘛，我們就把這套 API 維護(hù)到 Apifox 里面去，做成一個項目。他們有一個“云端 Mock”的功能，可以直接訪問服務(wù)端接口獲取 Mock 數(shù)據(jù)。我們可以把這個數(shù)據(jù)當(dāng)作銀行服務(wù)器的測試環(huán)境來用，每個后端都能訪問，也沒有次數(shù)限制，隨便怎么測都行！

我點點頭就讓他趕緊去搞了。這個 Apifox，能玩出什么花來我都不奇怪了。

過了兩天后端組長又嘿嘿笑著來了，說 Apifox 能生成 API 文檔，想把我們官網(wǎng)上對外的接口文檔換成 Apifox 生成的文檔。

我們業(yè)務(wù)會對接不少公司客戶，他們要把自己的業(yè)務(wù)系統(tǒng)跟我們的營銷工具做對接，所以我們專門有一個組是對接客戶的，主要就是教他們怎么調(diào)我們的接口。

這些客戶的開發(fā)人員，水平更加一言難盡。畢竟大都是小公司，很多連專職的開發(fā)都沒有，都是外包的。很多客戶嚷嚷著我們接口有問題，遠(yuǎn)程一看，接口參數(shù)根本就沒拼對。

我想著 Apifox 那個接口文檔我見過，做得還可以，好處是能實時更新，不用專門維護(hù)，就同意后端組長把官網(wǎng)上的文檔換掉了。

文檔換掉之后，過了兩周，周會的時候我就發(fā)現(xiàn)，客戶支持組那邊，事情好像少了很多。

我問客戶支持組長，最近是新客戶變少了嗎？感覺你這邊以往加班不少，最近都不需要加班了。

客戶支持組長說，最近新客戶還有變多呢。可客戶的問題就變少了很多。我感覺應(yīng)該是新版的 API 文檔的緣故。

怎么回事？換個文檔頁面，還能讓人智商提升了？作為一個十幾年的技術(shù)人，我覺得這不科學(xué)啊！

我會后拉著客戶支持組長聊了一個小時，算是搞明白了到底發(fā)生了什么。

以往，之所以客戶問題多，很大原因是我們的接口比較復(fù)雜，參數(shù)很多，客戶需要照著抄一遍到 Postman 里調(diào)好，再到自己代碼里拼接，就很容易出問題。

而 Apifox 生成的接口文檔，有一個“在線運行”的功能，點開就是一個發(fā)送接口的界面，長得跟 Postman 差不多。客戶根本不用自己去拼接參數(shù)，直接在頁面上就把接口給調(diào)通了。

而且，這個在線運行還能設(shè)不同的環(huán)境，后端組長直接搞了一個測試環(huán)境開放出去，客戶隨便調(diào)都不會出問題。

最離譜的是，這個接口文檔還能生成代碼？接口調(diào)好了，直接就能一鍵生成請求代碼和數(shù)據(jù)結(jié)構(gòu)代碼，客戶復(fù)制一下就能直接用了。這個生成代碼還支持二十多種語言，啥框架都能用。

我算是明白了，容易出問題的環(huán)節(jié)都被工具解決了，客戶可不就沒問題了嘛。

這個 Apifox……前途無量啊。

提升了多少效率

我算了一下。

后端，寫接口文檔的時間能省 80%，自測和改 bug 的時間能省 50%，質(zhì)量能提升30%。用到第三方接口的話，調(diào)接口的時間能省 60%。

前端，Mock 數(shù)據(jù)花的時間能省 100%，調(diào)接口的時間能省 40%。

聯(lián)調(diào)時間能省 80%。

接口測試時間能省 60%，回歸測試時間能省90%。還能實現(xiàn)接口自動化監(jiān)控和性能測試。

客戶服務(wù)對接的時間能省 70%。

還是那么多人，整個迭代還是三周，但是效率高了，能做的需求比以往更多，質(zhì)量也更好了，大家也不用苦逼逼地晚上周末加班了。加在一起，Apifox 對我們團(tuán)隊，真的能提升 100% 的效率。

尤其難得的是，我們好像也沒經(jīng)歷什么轉(zhuǎn)型的陣痛，內(nèi)部團(tuán)隊的阻力，似乎一切順理成章地就下來了。明明引入了一個新工具，開發(fā)效率也大幅提升了，可是工作流程還是先前的流程，都不需要做什么專門的調(diào)整。

我以前跟一位前輩聊，他說了一句讓我印象深刻的話：“產(chǎn)品是最佳實踐的載體?！币郧拔也欢F(xiàn)在我好像懂一些了。

上個月開上半年總結(jié)會，老板狠狠夸了一頓研發(fā)團(tuán)隊，說最近的開發(fā)效率超出預(yù)期，系統(tǒng)穩(wěn)定性也一直很不錯。業(yè)務(wù)部門的老大也說，之前提了很久的一些需求，近期嘩嘩地都實現(xiàn)了，一線業(yè)務(wù)同事們都很滿意。

還是挺爽的。

而且，公司一分錢都沒花呀。

Apifox 還是個中國團(tuán)隊做的，真心希望他們越做越好，把整個中國的研發(fā)團(tuán)隊的效率都提升一大截。

中國該有個厲害的研發(fā)工具出來了。