資視月誌：與外的合作開發經驗
2019.05 一步步地紀錄，這些得來不意的點點滴滴。
五月我們的重心放在早期就定好的一個合作案：一款睡眠手錶 App 的開發。這是集合了五間公司的合作案：手錶公司、設計公司、兩個系統廠商、App 開發公司（敝公司），算是成立公司以來第一個與外合作開發的案子，也因此我們都想要很好的表現一下。
原本以為是這樣子的…
最後兩個禮拜感覺就像這樣…
應用層屬於整個產品線的最下游
我們在這次合作案子裡面負責的是開發 IOS & Android 兩款 App，連結手錶，顯示監測結果給使用者，會有其他廠商公司開發 API 間接系統層面的應用。所以我們屬於整個產線的最下游。
最下游也就意味著，當其他人卡住的時候，你什麼也不能動ＱＡＱ
雖然原本就有預估被卡住的風險，已經做好了基本 UI，原本想想到時候也就是套個 API、微調 UI 之類的，很顯然的我們太大意了…
除了與系統串接本來就會遇到一些意外問題之外，中間一來一往的溝通就已經耗費漫長時間，有的時候兩邊的需求竟然還不太一樣，需要在等待案主來做決定。同時也邊完善其中 App 的一些具體需求。
身為專業的前端工程師，UI 的細節、產品體驗往往是最難去調整的，又因為這是一款真正上架的 App（以前都只開發 Demo 用），也就意味著我們必須去注意更多。所以我們在最後兩個禮拜根本是大翻修 Code，去調整細節，做到每一個 Button 與設計稿上絲毫不差，讓每一種裝置體驗起來也都更為順暢。
謹記：
- 如果可以的話，盡可能的再多跟合作夥伴確認一下彼此需求的重要性。
- 即使需要等待，也盡可能地先想到就多做。（每多一次經驗，就會多知道可以做些什麼）
最大的問題：硬體設備傳輸的效能瓶頸
其實對我們整體來說最大的問題都不在軟體應用層面上，因為那些都可以靠肝來換取，但事實上最難以去解決的就是硬體設備上的瓶頸。
我們這次遇到兩個最大的問題：
- 硬體傳輸的資料格式 “有時候” 與它實際的說明書不同。
- 為了得到所需的資料，傳輸太過頻繁，導致 App 讀取資料太久。
第一個解法就是：不斷的去 handle 格式不符的資料。（缺點就是我們完全不知道哪些欄位有可能不見，所以我們只能遇到了再去 handle…）
第二個效能瓶頸就是最惱人的「調校」：我們把讀取的邏輯 func 每一個拆開來單獨測時間，最後發現是因為每一筆資料必須分很多次讀取有關，與硬體限制有關係。而我們只能盡量去調整讀取的流程，想辦法讓某些地方再加快一點點這樣子…
簡短小總結
雖然說這次是與外的合作案，但開發產品還是學到了很多新東西。
- 藉機參與了一個產品的開發案，更多的了解之後可能會遇到的問題（包括心累程度）
- 算是完整的使用 RN 走了一回 App 這一趟旅程，更瞭解了這些生態系。
- 其實我們有很多必須檢討的地方，像是有一度曾經覺得對方好像也沒那麼積極，自己這麼在意幹嘛的這種心態。但卻忘了不管如何我們都必須去做好我們的本分，因為這樣才對得起我們自己，也才會真正學到東西。
- 如果下一次再開發，我想對我們來說可以減少個一半的時間左右吧。
最後推廣一下，我們後來自己開發的 react-native-template, react-native-use-persist-storage ～～
想了解更多，歡迎關注我們
👇掌聲給他用力拍下去，我們會很開心 ><
