web 前端轉行 app 之路

前言

來到 VeryBuy 也已經一年半多了

從最初的 web 轉戰到 app，開發上的體驗變化挺大的

想說來寫篇心得記錄一下好了

前面大致會簡單說下一開始在 web 碰到的事

之後轉到 app 所經歷的坑與雷

 

初來乍到

一年半前，剛來到 VeryBuy 從事前端工作

當時沒人與我交接，我甚至是當時唯一的前端

沒其他前端前輩可問，也沒文件，完全得靠自己摸索

當時是直接接手購物車的業務

最大的困擾就是不知道有哪些商業邏輯，什麼團購的活動（當時還有團購）、coupon 的折扣、付款方式的 pay by……等

常常發生改Ａ壞Ｂ的情況

當時總在想：「原來還有這個啊...」

慘點的是產品發佈後才發現 bug

此時就得請人查錯失了幾單，之後就是估算掉了多少多少的業績

前五個月（大概五個月吧...）都在滿痛的情況下完成專案

 

人生第一個金流

來到 VeryBuy 沒幾個月，馬上接到的一個挺大的專案

要在付款方式多新增一個「Direct pay」

它能讓使用者直接在購物車頁輸入完信用卡資料

在成立訂單的當下，就能知道付款成不成功了

平時有在網購的人都知道，有些網站是你選「信用卡付款」，按下「送出訂單」後會帶到輸入信用卡的頁面，再讓你填信用卡資料，之後進入「等待付款，請勿關閉或重整」之類的頁面，接下來才能知道訂單狀況如何

 

剛開始開發時，因我沒事先想好流程圖，當時是邊開發邊想接下來有哪些功能

在這之間，PM 總是要反覆測專案的完成性

因我很容易做完 C 後，前面的 A B 就壞了

雖最後還是完成了，但那些 code 到今天我依然不敢直視

 

無形的框

一直到接近年中才開始有了其他前端夥伴加入，包含前端主管

此時 app 開啟了重啟的計畫，因為一直沒有 ios app 工程師的加入，所以導致久久沒更新

故前端主管決定使用 RN (React Native) 來製作 app，所以有了 app team

但我依然還是在排在 web 的部分，並且除了我以外的前端都去了 app team

這個時候就會變成，除了主管以外，web 的前端專案只有我比較清楚，所以當專案到了 CR (Code Review)，沒參與的人較看不懂整體在幹嘛

故那段時間，沒辦法從做業務中學到其他的東西，不知道除了我當下用的方式外，有沒有更優秀的實現方式可以選擇，這個狀態一直保持到加入 app team 之前。

 

初入 App

在 app team 運作了幾個月後，前端團隊決定做人力的調度

也因此我加入了 app temp，開始我的 app 旅程了

若說進入新的團隊不緊張都是假的，擔心的點很多

像是不熟悉團隊當前用的技術：「React、RN (React Native)、Redux、TS (TypeScript)、Jest ...」

原本團隊高質量的 code，在我加入後變得低下，我接下的 case 瘋狂 delay …… 之類的

但還好比想像中快進入狀況

雖然一開始有許多不熟悉與不喜歡的點，但很快的就習慣了

這些不熟悉與不喜歡的會在後面說到

當時有個同事說我比他想像中還要快熟悉，他覺得我應該會卡在 Redux 上才對

但還好之前有玩過 Vuex，所以大致概念都差不多

雖然 Redux 較繁瑣，但換個角度想一下就通了

當時還有個滿有趣的橋段

上面寫到人力調度，被調去 web 的人跟我聊到這一段：

那些年 App 的眉眉角角

加入 app temp 也快三個月了，雷很多，坑很多，在此我一一敘述下：

• 不習慣 co-work：

因過去 web 只有我一個人寫，能跟其他工程師合作的經驗只有跟後端串接 api

沒有跟其他前端討論說：「這裡你先給我 interface，到時我們兩邊就可以直接接起來了。」的經驗
剛開始開發 app 的時候，有個 UI 塊會在 A 與 B 區域用到

所以把此 UI 拆出去，在 A、B 各別引入就好

而此 UI 就由我來開發，那時完全沒跟開發 B 的人討論

我單方面覺得我用得到 XXX，他應該也要用吧！

所以就把 XXX 加進去了，結果最後 B 根本沒要這個 XXX 的鬼東西

前前後後修改了不少次，成本多了不少

• 不熟悉 RN / TS / Jest：

對於 RN 切版我依然還是覺得不太容易，最不習慣的就是 flex 的順序部分，跟web css 是反過來的

在預設情況下，web css 是水平排列，而 RN 是垂直排列，在切版上總要轉個角度去想
而 TS 的部分，習慣 JS 的弱型別，突然去寫 TS 的強型別挺不習慣的

而且其實我以前很討厭強型別，所以當初在大學，只要寫到 C#、Java 就覺得很煩

可能是編輯器太強大的關係，寫 TS 的體驗挺好的

它能在編寫的過程就檢查出一些事，能提醒我有時會忘記的事情

雖然有時在寫物件型態的取值時，TS 的警告還是會覺得很煩
Jest 是單元測試的部分，在過去從沒有寫單元測試的經驗

雖然知道它是用程式來測程式，但還是很陌生

一直到現在，依然還是只會寫很低端的測試...

• 很難專注在一件事上：

在 web 專案，只要在 deadline 前交出就好

所以我可以先弄 A 專案，若是卡住就換做 B 專案，有時間再回去弄 A 專案
但在 app 上不能這樣，因 app 是每兩週 (每兩週一個 sprint) 有幾個固定的專案要實現

有時甚至只有一個專案，故不像 web 一樣可以跳來跳去的

還記得有次是在處理 android 的 UI bug，但一直找不到解法，弄得挺煩的

但當時只剩這個要處理，所以也不能換做別的轉換心情 ?

•  原生的很難寫：

有次 sprint 要實現 deeplink，deeplink 需要寫到原生的

而原生的完全看不懂，只能用試的，總是在不知為何加了這段，或砍了這段就能運作了...
而在我寫這篇的前幾個禮拜，ios app 面臨 crash 之災，追了很久都不知原因在哪

後來覺得可能是 RN 原生部分跟某套件通信時發生點狀況，導致 crash

是這方面的可能性機率還挺高的，而此時又是跟原生有關，所以也卡在這部份

• Debug 很麻煩：

其實說起來不是 debug 麻煩，而是電腦慢到會讓人覺得很麻煩

在寫 app 時，要 debug 得開另外一個工具來跟手機模擬器做連接

而連接起來後，模擬器會變得非常慢

尤其 android 會慢到按下一個按鈕得等 2~4 秒才會有動作，動畫效果甚至會卡到以為是 bug

也因此很討厭在 android 上 debug

• 不同平台的困擾：

團隊在使用 RN 的目標就是統一 app 雙平台 + web

目前已經統一 app 雙平台了 (IOS / Android)，開始發現 android 的雷真的不少

像前幾週在處理個圖片的問題，用某個套件在 ios 上能正確的抓到圖片的真實寬高

但 android 拿到的卻不是真實的，只好因此換個做法

 

總結

雖然上面寫了不少 app 遇到的悲劇事，但進了新的 team 我還是受益良多

像是 app 用了不少我沒用過的技術與套件、可以跟其他人討論設計與實現方式、有了開發 app 的經驗......等

現在回頭去看 web，尤其是我經手最多的購物車頁的 code

在 app 的專案，一般檔案是不會超過 200 行的，能拆出去的都會拆出去，盡量減少一個檔案的行數而 web 的購物車，js 的部分就有 2500 行左右...

2500 真的不是一個開玩笑的數字

 

以上便是過去原是寫 web 的，之後轉戰 app 的心得

目前 app 的經驗還不足三個月，相信之後會有更多的心得

以及更多模糊、沒概念的區塊在等我摸索著