Just My Life & My Work

糟糕的API製作

一年前也就是2017/1/27的紀錄,我經手一個幼稚園案子,我以為只要負責開發App的部分即可,所以報價非常的親民,因為對方是我非常好的老闆朋友。不過最後證實,這個案子讓我公司虧錢,時間成本多出3倍,為了斬斷所有牽絆,在卡卡頓頓開發一年後,宣布不再接手維護。

以下就描述我身為軟體架構師觀察到的問題:

API開發

此案不明原因分成三個人⋯⋯

  • A創造規格人(實作原型)
  • B建立架構人(實作雛形)
  • C開發實作人(實作成品)

幼稚園案子.gif

照理說,ABC要同一人才是!因為每個人的邏輯思考不同,若分為三個人接續製作,最後成果極度可能四不像,那可是會大大增加開發成本!

現在我可以請教的是開發實作的人C,可是他不太了解建立架構的人B為何如此建立,於是就放著B做過的API,我請C幫忙單元性測試與連續性測試,無法讓他自動自發去測試所有API,是否有下列問題:

單元性測試:

畫面欄位與回傳資料對不起來,也就是缺少key和value,無法讓我套完一個view。

很明顯API製作人沒有照著畫面規劃!

連續性測試:

一個完整的功能會有多個頁面,每個頁面基本上就是一支API回傳的資料可以顯示。上一個頁面通常會與下個頁面有關聯,於是API傳遞參數也跟著有關係。比如上一頁選擇班級,就會有classId要傳到下一頁,下一頁選擇學生,就會有studentId要傳到下下一頁,同時上一頁的classId也要傳到下下一頁。

原本我的工作是實作App的開發者,沒想到要同時做溝通API的專案管理人,我是可以勝任沒錯,然而我非全職做此專案,所以若當初時程規劃得相當緊湊,面臨突發的狀況或過去設計的問題就非常可能延遲專案時程⋯⋯

資料庫架構:

這兩週跟API開發人也就是C來回修正問題後,感覺到起初的資料庫架構似乎有潛在問題!許多功能有同樣的畫面如選擇班級或學生,然而順序上並不一樣,使得API傳遞的參數有些差異。

我遇到的問題是下一頁的API參數我無法傳入,因為之前的頁面並沒有回傳,第一次回報修正後說要加頁面來取得該參數,第二次發信跟我說已修好該API,也就是並不需要該頁面⋯⋯於是我加入該頁面後又移除該頁面⋯⋯

還有個問題是儘管都是選擇學生頁,然而畫面要顯示的資訊卻不太一樣,呼叫同一支API會得到相同的資料,此時就有多或有缺的key和value,讓我串的時候感到疑惑,要再次確認是否有提供完整的資料。

另外潛在問題是,原先架構已經確定,後來陸續加了些欄位,這些欄位的關聯可能就有問題!

設計功能流程畫面與資料庫架構:

這是設計階段要配合好的兩個部分,實作階段基本上不太會動到,是有某些例外在實作時才會發現,那就另當別論。我遇到的是view和API沒有對起來,有時是view的問題有時是API的問題,負責做API的人應該早就要發現才是。

以上是我剛接手案子的紀錄,之後勉為其難繼續開發,使得我一整年的情緒多少受影響。出包的人應增加預算~

阿遠最近跟我談到他接的案子,API數量高達50支,前後API開的方式有差異,後來知道是三個人陸續接手開發,使得問題從隱約而現形!還記得去年我跟他提到,有個案子卡關很久,現在他應該知道我當時表達的感受!

我們也一致同意,開發API的人必要跟製作界面的人溝通好!也就是我上述的設計階段。才不至於把問題累積到實現整合的App開發者!未來若有突發問題,可考慮要求預算,再接續開發~

雖然第一次遇到這麼難搞的API,不過也因此學到很多,感謝魯蛋給我這個機會哪~

未來決定若非必要,絕不開發基礎沒打好的案子!我做案子的態度都是把它當作自己產品來開發,這是我對人生負責的規矩!還是做自己的產品最棒囉~

工作規矩.jpg

 

廣告

發表留言

在下方填入你的資料或按右方圖示以社群網站登入:

WordPress.com 標誌

您的留言將使用 WordPress.com 帳號。 登出 /  變更 )

Google+ photo

您的留言將使用 Google+ 帳號。 登出 /  變更 )

Twitter picture

您的留言將使用 Twitter 帳號。 登出 /  變更 )

Facebook照片

您的留言將使用 Facebook 帳號。 登出 /  變更 )

連結到 %s

標籤雲

%d 位部落客按了讚: