我在去年中旬加入了 VeryBuy 團隊,一眨眼就過了快一年,記錄一下這段時間做了哪些事情,也為這陣子的忙碌生活做一個回顧。
其實從剛開始工作以來,一直都有想要創業的打算,但隨著年紀越來越大,可以承擔的風險也越來越低,最後漸漸放棄了這個念頭。因為阿邦的熱情邀約,在 VeryBuy 第一次跟創辦人 Jeremy 與 Audrey 面試的時候,感受到他們的熱情,他們帶領這個團隊一路上披荊斬棘走了幾個年頭,用有限的資源,找到切入點就拼了命的放大,撐起了一間公司,並且有合理的商業模式與收益,能加入這個團隊而有機會陪著一間公司成長、茁壯,真的是非常難得的機會。
坦白說一開始我對電商是沒有太大的興趣,市場競爭激烈、手法互相抄來抄去,好像沒什麼可以發揮的機會,但仔細瞭解才發現 VeryBuy 跟傳統電商的打法不同,除了 TA 不同之外,也有很特別的學習機制來建立起商業模式。
老闆 Jeremy 決策快、想法遠,總是會多想好幾步,強調各個節點都做對了就會通往成功的方向, Audrey 很會分析需求以及跨部門分工協調, Yo 在很短的時間就把技術建立起來快速驗證,阿邦加入後把技術團隊再往上提升一個檔次,就這樣慢慢把事業越做越大,這真是太精采的故事,不出個書嗎?
做前端開發也很長一段時間了,很希望找到一個可以發揮的舞台,將技術的能量協助公司通往成功的方向。
VeryBuy 主打女性客群,希望打造出一個適合女生逛街購物的網站,並且面對全世界用戶。現有的電商網站都在強調搜尋、比價,但這對女性商品購物模式未必是最重要的考量點。
人類藉由購物來尋找自我的定位,這不僅僅是價格可以決定的。 VeryBuy 在這之中找出了女性商品的特性:風格、新鮮、推薦、情境、獨特…等,縮短了在千萬種商品中搜索出真正想要的商品的時間。
建立自動化測試
想像很美好,但現實不會是完美的,每間公司都有技術債, VeryBuy 也不例外,這在加入的時候就已經知道,沒有過去欠債 Try 出來的商業模式,就不會有今天的 VeryBuy ,這是可以理解的。資深工程師的價值就在於有足夠的經驗判斷什麼時候該還債?什麼時候可以欠技術債?用什麼形式來還?在這個過程之中還是要能添加新功能創造新的價值。
累積了六七年的程式碼,義大利麵的 coding style 也是蠻正常的,沒有前後端分離的架構,把切板工作交給外包,一不小心就很難維護了。因此在重構之前我們需要降低每次上新程式碼的風險,在與團隊討論之後,決定投資一些資源來開發自動化測試。
VeryBuy 沒有專職的 QA 團隊,因此我們決定用前端的力量來做自動化測試,主要選擇的 test framework是 testcafe,在 e2e 團隊的努力之下,到目前為止已經累積了 9x 個 test case 來避免一些重要流程的錯誤,像是登入登出流程、選擇顏色、尺寸、加入購物車、結帳、付款方式等等,確保每個環節都是可以正常運作。
用 testcafe 的好處就是我們可以讓它運行在實體的手機上來做自動化測試。也可以跑在不同的 browser 做測試,甚至可以跑在 windows 上測試 IE browser ,再也不用擔心受怕 「IE 不能動,還有什麼能讓我心痛」。
![broken image](http://custom-images.strikinglycdn.com/res/hrscywv4p/image/upload/c_limit,fl_lossy,h_9000,w_1200,f_auto,q_auto/876437/1_urovdo.png)
(圖一)VeryBuy e2e 團隊的心血
並且接上 bitbucket pipeline 用 puppeteer 來運行自動化測試,設定排程定時測試或者手動觸發。
![broken image](http://custom-images.strikinglycdn.com/res/hrscywv4p/image/upload/c_limit,fl_lossy,h_9000,w_1200,f_auto,q_auto/876437/2_wftq2k.png)
(圖二) pipeline 排程跑自動化測試
![broken image](http://custom-images.strikinglycdn.com/res/hrscywv4p/image/upload/c_limit,fl_lossy,h_9000,w_1200,f_auto,q_auto/876437/3_awsj3a.png)
(圖三)每次跑完就可以產生 report,並會定時發送警示。
當然關於自動化測試踩到的坑與實作還可以另外再起個主題,之後有機會再說囉!
Pull Request Review
由於之前大家開發都蠻隨性的,因此建立了一些 Pull Request 的規範,例如跟畫面有關需要附上 screenshot ,補上適當的說明解釋 pull request 的用意,加快 review 速度等等,並鼓勵 pull request 的討論,從中發現問題。
![broken image](http://custom-images.strikinglycdn.com/res/hrscywv4p/image/upload/c_limit,fl_lossy,h_9000,w_1200,f_auto,q_auto/876437/4_vcho3b.png)
(圖四)Our pull request
雖然都會有 PR review ,但有時不一定可以完全了解 PR 的來龍去脈與細節,每週一次的 PR sync meeting ,讓大家有更多機會做知識分享、踩雷紀錄等等。我蠻喜歡這個 part 的,算是教學相長,彼此累積經驗。
在有了強大的 UED 團隊加入之後,注入了產品的生命力與新思維,我們也開始慢慢的調整許多過時的 UI ,以及改善舊程式碼的技術債與效能、統一架構等等,細節非常的多,真的是有賴團隊的互相支持才能不斷的一點一滴地前進。
MobileWeb
![broken image](http://custom-images.strikinglycdn.com/res/hrscywv4p/image/upload/c_limit,fl_lossy,h_9000,w_1200,f_auto,q_auto/876437/5_beygjp.png)
(圖五)Item Page Before / After
回頭看以前的樣式還真是驚悚😱😱😱
![broken image](http://custom-images.strikinglycdn.com/res/hrscywv4p/image/upload/c_limit,fl_lossy,h_9000,w_1200,f_auto,q_auto/876437/6_odcs2s.png)
(圖六)Cart Page Before / After
App
![broken image](http://custom-images.strikinglycdn.com/res/hrscywv4p/image/upload/c_limit,fl_lossy,h_9000,w_1200,f_auto,q_auto/876437/7_x18dny.png)
(圖七)App Before / After
react-native
為了讓未來 maintain 的成本降低,不用 iOS/Android 各自開發一套,我們決定用 react-native 來開發 App ,對團隊來說,用 react-native 是從 0 開始,從做中學,慢慢的也把 RN 的特性摸熟。
在團隊一起衝刺了一段時間之後 VeryBuy iOS 終於上架,可喜可賀,接下來就會是上架 Android 版本,以及支援 web 開發。
值得一提的是我們在一開始的時候就決定導入 TypeScript,這在後續開發也帶來許多好處,避免 js 弱型別容易產生的低級錯誤。
![broken image](http://custom-images.strikinglycdn.com/res/hrscywv4p/image/upload/c_limit,fl_lossy,h_9000,w_1200,f_auto,q_auto/876437/8_ijgta1.png)
(圖八)VeryBuy iOS 終於上架啦!可喜可賀!
對了最近也順利升上 react-native 0.59 了,所以想要用 hooks 也完全沒問題!
自己的程式自己測,除了從測試發現問題之外也可以保護自己的程式。
在程式碼不斷增加的情況下,團隊依然有保持單元測試的水準,雖然 Code Coverage 的高低不能保證不會有問題,但有了 unit test 的保護,避免了許多改 A 壞 B 的情況,在做 refactory 也會比較有信心。
![broken image](http://custom-images.strikinglycdn.com/res/hrscywv4p/image/upload/c_limit,fl_lossy,h_9000,w_1200,f_auto,q_auto/876437/9_ajntov.png)
(圖九)VeryBuy codecov.io
下面的圖可以發現程式碼不斷增加,但 Test Coverage 還是有維持在一定的水準。而在每次團隊的反饋也不時會分享測試帶來的好處。
![broken image](http://custom-images.strikinglycdn.com/res/hrscywv4p/image/upload/c_limit,fl_lossy,h_9000,w_1200,f_auto,q_auto/876437/10_csyoz0.png)
(圖十)Code Coverage (藍色) 與 程式碼行數(紅色)
CI/CD
由於經歷過 CI/CD 帶來開發上的便利,因此在開發初期就將 CI/CD 建立起來,除了加速開發之外,也可以避免犯低級錯誤的機會,保證程式碼的品質,讓每一次 merge 都能 build 出一個可運作的版本。
![broken image](http://custom-images.strikinglycdn.com/res/hrscywv4p/image/upload/c_limit,fl_lossy,h_9000,w_1200,f_auto,q_auto/876437/11_nd9naq.png)
(圖十一)bitrise CI/CD
並且隨時可以找到目前最新的版本,不同環境的版本,自動部署到 testflight 然後上架。
身為前端技術主管,需要協助團隊將石頭搬開,或者往前多看幾步路,而不是放手讓團隊自己撞牆。導入 scrum 開發流程之後,工程師有了更多可以向上溝通的機會,也避免傳統 waterfall 開發方式產生的資訊落差,以及冗長的迭代成本。
![broken image](http://custom-images.strikinglycdn.com/res/hrscywv4p/image/upload/c_limit,fl_lossy,h_9000,w_1200,f_auto,q_auto/876437/12_fr2tpn.png)
(圖十二)Scrum 團隊佔領所有牆壁
![broken image](http://custom-images.strikinglycdn.com/res/hrscywv4p/image/upload/c_limit,fl_lossy,h_9000,w_1200,f_auto,q_auto/876437/13_vgsopx.png)
(圖十三)Jeremy 與 Audrey 接受大家的挑戰
Next
把基礎穩定之後,接下來就要實作更多更有趣的功能了,我們的目標是共用同一份程式碼或是將商業邏輯拆出來,各個 platform 可能會有各自的呈現,但盡可能做到共用以降低開發與維護成本。不久的將來就要可以同時 ship Desktop Web/Mobile Web/ iOS/ Android 了。
![broken image](http://custom-images.strikinglycdn.com/res/hrscywv4p/image/upload/c_limit,fl_lossy,h_9000,w_1200,f_auto,q_auto/876437/14_upx8jk.png)
(圖十四)VeryBuy 團隊(號稱平均年齡 25 歲)
感謝跟著我一起長大,並且越來越可靠的前端團隊,如果你對 VeryBuy 的職缺有興趣的話,可以來信 hr@verybuy.cc。歡迎加入我們這個溫馨的大家庭。
本文出自 從零開始建立可靠的前端團隊
by 等媽祖托夢的Bingo