加入 VeryBuy 已經一年半載
在這段時間內，跟著 VeryBuy 在一步一步成長，逐步改善研發團隊的開發流程
在保證網站的穩定性下，進而提升 VeryBuy 的使用者體驗，一直是我們努力的目標
然而在 2020 年初面對疫情的挑戰，大環境下充滿各種不確定因素
VeryBuy 管理團隊除了因應市場迅速調整策略外，也穩定了 VeryBuy 團隊的信心
進而在我們所擅長的領域，在因應外界環境的改變，仍踏踏實實地因專注在開發的工作上
而這篇文章是作為 VeryBuy 的後端工程師，每天處理各種開發上的樣貌
早上初到公司，首先會打開 JIRA，查看自己手上的各項工作的處理狀況
並確認一下今天的會議安排後，查看自己還有多少時間，可以用來處理手上的工作
我會安排一下今天處理工作的優先順序，稍作整理後，就開始一天的行程
圖一: JIRA的 Roadmap畫面
VeryBuy 是採彈性上下班時間制，團隊每個人到公司的時間都不一定
VeryBuy 早晨例會的時間則定在10點45分
而我多半會趁早上這段時間先處理完最重要的工作
像是撰寫技術文件、架構設計、Code Review、開發上的關鍵節點等等
在早晨例會的時候簡要地說明一下自己目前的狀況
也聽取其他夥伴目前手上的工作進度
配合團隊目前主要專案的狀況，再看看今天的預定工作項目有無需調整的地方
另外有需要進一步深入討論細節的話
就會趁早會結束後找相關的人討論，以順利推展專案的進程
一整天下來總免不了會有一些需要和其他團隊成員或不同職能的夥伴們(前端/PM/UED)合作的會議
討論的內容不外是需求規劃、使用者體驗及互動、工作切割及評估工作時數…等等
取決於手上的專案的狀況
在訂定會議就要先明確會議的目的及重點再展開會議
也要適度控制會議的時長，若會議已經達到目的話就提早結束會議
舉例來說，後端工程師通常在協助實現某些功能性需求時
通常會以提供 REST API 的方式提供給前端團隊
在 VeryBuy，團隊是透過 Swagger 作為 API Doc 的溝通工具
當後端要出新的 API 或調整現有的 API
我會在設計與實作前，先與前端夥伴溝通好API的 method、path、payload 及 response 外
並基於其呼叫頻次及應用場景設計 API，也會討論 API 可能回傳的 HTTP Status Code 及錯誤碼
以協助前端夥伴在串接 API 時易於做好例外處理
圖二: VeryBuy API 的 Swagger 畫面
對於較大型的專案，也會與更多夥伴們一同共同開發
這種類型的專案在 VeryBuy 通常會同時涉及金流、物流及資訊流
在專案實際執行前，透過 Planning 會議，與其他後端夥伴共同討論設計及實現方式
互相彌補彼此在擅長領域上的資訊落差
團隊會依需求的目標及場景進行來切割各個子工作
並且用 Planning Poker 的方式來評估完成該工作的初估工時
若是參與評估的夥伴們對某項工作所估算的時數不同，團隊成員會輪流說明其估值的理由
像是針對付款 API 的調整，我初估的時數為 8，但其他成員可能是 5 或 13
我可能會說明在部份需考慮在新增這些需求下
在不影響現在 API 的回應時間，該如何修改 API 的實作
而其他成員可能提及這部份的例外處理需額外考量那些錯等等
說明後團隊再重新評估，直到團隊成員都達成共識為止
最後，再基於估算的時數，初步給出團隊能夠交付專案的時程
討論的結果也會記錄在團隊的共享文件上
圖三: 某次 Planning後的記錄 (Confluence畫面)
作為一個後端工程師，大部份的時間都會花在開發上
但軟體開發並不是只有坐下來撰寫程式碼這件事 (在 VeryBuy 也可以站著撰寫程式碼 XDD)
我會和夥伴們討論架構設計、分析各個解決方案的優劣，嘗試方案的可行性等等
由於 VeryBuy 的網站在架構上大量整合 AWS 的服務
包含EC2、RDS、S3、DynamoDB、SQS、ElasticCache等服務
在實現一個需求時，就會依照其需求特性來進行評估
舉例來說，若有資料儲存上的需求的話，就會評估資料是否有為結構化的資料
還有資料量、成長速度、查詢等考量，再選擇合適的儲存方案
此外若某個需求不需要立即得到結果，且處理過程中可能會需要重試
我就會考慮是否以 SQS 來進行運算，並視情況設定 SQS 的參數
在 VeryBuy，後端團隊在單元測試及 API 測試上已經是標配
任何新增的功能都會要求為每一個函式撰寫單元測試
其基本要求是 Code Coverage 要達到一定程度以上
截至目前為止，團隊已經為現有的產品累積了數千個單元測試案例
而 API 測試則是在 API 在發佈前也會撰寫對應的測試案例，並整合到現有的佈署流程上
這些測試案例交織成一個防護網，協助團隊在交付功能上能有更好的程式碼品質
圖四: 整合 Bitbucket Pipeline 執行語法檢查及單元測試
圖五: 結合 API 測試工具在監控 API 的效能及穩定性
在開發進行到一個段落，團隊會將現在開發中的分支提交一個 Pull Requests
並邀請至少其他兩位後端夥伴協助 Code Review
在 Code Review 的時候主要會提出一些技術上的建議
主要是設計是否適宜、能否達成功能上的需求、程式碼的複雜度及可讀性、測試是否足夠等
我在這過程中除了能夠發現自己在開發上的盲點
也能從其他人的建議更能了解領域知識、開發及設計上的考量，進而改善整體的程式碼品質
圖六: 團隊某次 Code Review 上的討論畫面
在 VeryBuy 作為後端工程師，在至今為止的 636 天裡，每天都過得很充實
透過大小不斷的會議及討論，紮實的軟體工程實務，並逐步累積自身在電商領域的知識
而這篇文章只是到目前為止的現狀，我們會持續改善我們的開發流程，不斷精進
感謝許多陪著我一起成長的後端團隊夥伴
如果想了解關於更多VeryBuy後端工程師的工作內容，非常歡迎來公司找我們聊聊天！
by Kurt
