離開 KKTOWN 一段時間,紀錄一下在 KKTWON 的一些小事。

機緣

因為 Zonble (楊維中) 在社群分享技術的關係,在剛開始接觸 iOS 開發就嚮往著加入高手如林的 KKBOX ,當時還在 Hiiir 時間軸科技剛開始學習著 iOS ,每月也勤於參加社群補充新知,認識業界的高手們。

終於在 CocoaHeads Taipei 做了兩次 Share 後鼓起勇氣向 Zonble 毛遂自薦,但當時 iOS Team 剛好沒有缺,所以轉而面試新產品開發部門的 iOS 工程師一職。

記得當時面試主管問說:「我看你還很年輕,你怎麼證明你能把 iOS 做好?」 而我的回答是:「我確實很年輕,但面對開發的問題我會以這樣的策略進行。首先,我會嘗試在網路上找解答,如果卡關太久,我會去請教 Zonble 他們,如果這些問題他們沒解決方法,或許我們該討論有沒有其他的方式達到一樣效果,讓產品保持持續前進。」能夠從無到有打造產品是我有興趣,也一直在做的事情。

加入不久之後我們就開始做 KKTOWN。

KKTOWN 是一個 C2C 電子商務服務,最重要的是確保交易安全與正確性,不容許有些微差錯,無論是交易狀態以及訊息通知都很重要,為此必須透過一些開發方法提升軟體品質,才不至於惹出交易糾紛。

Shared mock data

單元測試要執行的穩定,要快的話就必須不穩定因素隔絕在外,而「網路」就是時常不穩的的因素之一,可能是辦公室網路斷線,抑或是伺服器後端正在部署造成某些 API 暫時無法使用,都會影響單元測試的結果。

為了將網路的不穩定因素排除,我們建立了一個 repo 把 API mock 資料集中管理,並由前後端共同維護,如此一來即使再斷網的情況下,iOS 的單元測試依然可以順利執行,並給出正確的結果。即使 API 格式有任何的修改單元測試都會替我們把關,幫助我們快速的修正程式碼去符合新的 API 格式。

但很不幸的,這個 repo 大多數的時間只有 iOS 的團隊成員,也就是我跟 Jefferey 在維護。

API 整合測試

簡單來說,透過 API Client 模擬兩個 User 的交易行為。

其中的步驟大致如下: 1. 賣家建立商品 2. 買家購買商品 3. 賣家必須收到商品售出的通知,並且商品狀態要是已出售 4. 賣家出貨確認,商品運送狀態要為運送中 5. 買家要收到出貨通知 6. 買家確認收到貨並給評價 7. 賣家給評價 8. 交易完成

上面的步驟再乘上 7–11 金物流,全家金物流,貨到付款等等不同情境,加起來有十幾種不同的流程。

在 KKTOWN iOS 這邊不止測單隻 API 是否正常運作,也測了所有情境整合測試。做這樣的事情雖然辛苦,但是能在開發 UI 前就確保交易流程正確,除了後續保證 API 功能的正確以外,還可以減少整體開發時間,也算是一石多鳥。

KKTOWN 後期

在 2016 年底萌生去意,一部分是因為公司發展方向與我期望的不一樣,但也因為我只是個 iOS 工程師無法改變什麼。仔細想想也與我當初加入 KKBOX 的目的不太一樣,還沒有一探 KKBOX iOS team 的開發方式,沒有在 Zonble 底下學習過,於是在 2017 年 1 月申請內部轉調回 KKBOX 。

雖然不捨自己一手打造的 KKTOWN iOS,但也渴望能夠在更強的團隊內學習,能夠讓真強者檢視自己的實力,在 KKBOX iOS team 裡修練,成為更獨當一面的工程師。

Like what you read? Give Liyao Chen a round of applause.

From a quick cheer to a standing ovation, clap to show how much you enjoyed this story.