iT邦幫忙

2021 iThome 鐵人賽

DAY 7
0

我理想的情況是,

事前planing好API(req、res),完成每隻api估時,妥善把開發過程分配在每週

API 開發,採開完就交付,交棒FE串接,讓PM達成在預期時間,可以測試預期功能

事實情況是

BE開發前置時間耗時過久(建立entity、開module、建立DB)、需求變更與討論(異動DB schema level )、BE開發意外情況(技術研究(GoogleStorage)、需求意外地無法達成)、邏輯規劃不完全等因素,導致

  1. api 雖然準時交付、但是品質不佳、規格不清,提升FE的溝通成本(確認用法、錯誤回報)
  2. 自身程式碼雜亂不彰,易讀性差、嚴謹度不夠

針對以上情況,我採取措施

  1. 以準時交付約定的API 為原則,完成度70%就可先上,至少讓FE可以先接、先測
  2. 阻礙夥伴開發的問題,優先解決
  3. api 錯誤回報、需求變更,訂定優先度,利用當周完成進度的 buffer time 進行處理
  4. 需求變更部分,另外開卡紀錄變更,也另外估時,便於回顧時檢視是否可以優化部分

這次做得好的部分

  1. api 都有如期交付
  2. 任務優先度安排,以交付api 優先,錯誤處理、需求異動次之

這次做得差的部分

  1. 重要文件缺乏完整性,讓文件使用者不易理解、取得必要資訊
  2. 交付api 品質不佳、程式碼雜亂,需要再花時間修整

如果再來一次,我可以怎麼樣做得更好(交付品質好API \ 去除不必要溝通成本)?

  1. 優先產出 API DOC
    1. swagger 用來提供完整的 api 串接(url \ req \ res \ error Exception \ 參數使用方式 )
    2. google doc 用來給FE report api bug 、error 、欄位異動告知,於上版後淘汰
  2. api 邏輯plaining 時候,應該再更細緻(api 資料流的flow \ 例外處理 \ 需要儲存的欄位 )
  3. plaining 時候,應該包含 module 架構、預計會產生的 dto 、enum 、config ,盤查哪些可能後續有效能問題
  4. 盡可能盤點所需之範例資源(要開權限的名單、資料匯出匯入格式、檔案上傳範例檔案、需分析欄位)

上一篇
開 api 日常心得筆記
下一篇
要上傳檔案,你需要知道的事-Content-Type
系列文
日常任務成長紀錄30
圖片
  直播研討會
圖片
{{ item.channelVendor }} {{ item.webinarstarted }} |
{{ formatDate(item.duration) }}
直播中

尚未有邦友留言

立即登入留言