在 Verybuy 的第一個開源專案：
今天來聊聊這個專案背後的故事以及心酸血淚史，沒有太深奧的詞彙，大家就當故事看看吧。
三年前一開始決定要用 RN 開發 Verybuy App 之後，隨之而來的很大問題就是 payment，當時 Verybuy 已經在用 Tappay 了，但 Tappay 並沒有 react-native 的版本，當時我想說，先用 webview 擋著吧，也許哪天就有人開源了，或者 Tappay 會有官方支援 react-native。
這麼一等就是一年過去了，後來我才知道，我們只能當那個人
我依稀記得，那一年的冬天，當時負責的 PM 來找我：「Bingo，跟你說喔，這是原本 Android 的進購物車之後的結帳轉換率，這是新的 app 的結帳轉換率，你可以看到新的 app 上線之後，轉換率就直接掉了一個很大的斷層，我判斷是跟 webview 有很大的關係….」，一直不想面對自己接 native SDK 的我，看著這摔下的斷層，身為技術人，還是得接下這個重責大任。
payment 用 webview 會有各種問題，比方說無法得知使用者輸入狀態，卡在3d 驗證，卡在輸錯卡號，不小心跳離頁面等等。而且因為需要載入更多的資源，非常容易掉單，使用者好不容易要結帳了，卻卡在結帳，轉換率流失的看得我也是很緊張。
第一階段 Prototype
當時有熟悉 Android 的工程師，被我逼著要寫 react-native，雖然後來他還是比較愛 Android develop，預計一個多月要離開了，因此我將他身上的工作都排掉，希望他一起來協助開始這個燙手山芋。
於是我們開始嘗試直接呼叫 tappay 提供的 UI 元件來進行操作，這是他們官方提供的 demo。
其實看文件還算簡單理解，他有提供一個 TPDForm 讓你直接使用，可以簡單設定一些狀態顏色，等等。然後提供一個 FormUpdate 的 callback function，就可以接上你要串的行為了。self.tpdForm = TPDForm.setup(withContainer: Your View)tpdForm.setErrorColor(UIColor.red)
tpdForm.setOkColor(UIColor.green)
tpdForm.setNormalColor(UIColor.black)tpdForm.onFormUpdated { (status) in
if (status.isCanGetPrime()) {
// Can make payment.
} else {
// Can't make payment.
}
}
因此一開始我們很天真的想要可以在專案裡頭可以直接引入
看起來很完美，就可以完成信用卡輸入框。
採用的方法是 react-native native UI Component 來做出這個元件，當然 iOS/Android 是各自的 SDK，因此要用不同語言來實作。RD 也很給力的在離開之前給出了一個可以動的版本，並且可以順利的走完刷卡流程。不過很快的我發現有非常大的問題：
- 樣式不易調整，而且可以客製化的地方很少。
- 用 native UI Component 實作難以維護，畢竟是要寫 native code 來產生 component，跟原本用 js/ts 來撰寫 component 的概念不太一樣，除了對 native 程式的熟稔度，也需要對 component 的 lifecycle 非常理解。
因此樣式問題成了這個專案最大的阻礙。糟了卡關。
第二階段 刻 UI
真的要客製化的話就要用 Android 刻 UI，然後接入 tappay withoutForm，但這非常複雜，如果考慮到還有各種信用卡互動的行為（輸入信用卡號碼自動跳下一欄，檢查卡號為 visa/master 等等），等於是要完全重刻信用卡操作的行為，非常麻煩。
樣式問題困擾了我一陣子，某一天我突然想到，不對啊，前端不就都一直在刻樣式，UI/互動讓前端處理，愛長怎樣就長怎樣，等使用者送出再去 Call Tappay SDK 做檢查，將 UI 與刷卡流程分開處理，不就可以了嗎？這麼一來 UI 反而變成一件簡單的事情了。
為了驗證這個想法，我們很快的將幾個重要的 method 用 native modules 串接起來。！！可以(在心中雀躍了一番）！！
由於 native 層只處理刷卡，實作的方式也變得相對單純，幾乎都是字串以及成功與否的 response。Android 實作成功之後，當時還有一個 backend 同學以前有寫過 iOS，也被我抓來一起實作。
同一時間，我也請前端同學 survey 是否有現成的信用卡 UI，接下來就火力全開，Android/iOS/Frontend 全力衝刺最後順利接起來了。
下方的實作，隨心所欲客製化
第三階段 Open Source
其實在 open source 之前，我們還經過了很多 feature 的開發，加上 Line Pay 的支援，解決了許多互動之間的 bug，升級 SDK 等等。一直以來，我對公司產品公開到 github 都是小心翼翼的，一來是開發的時間與產品都是屬於公司的資產，沒有特別的理由為何要公開。
不過某一次聽到一位前輩 (Sam Huang) 分享他們開源了一個 library，卻反而被競爭公司使用了的經驗，其中有一個點我覺得很好：「其實開源就是飲水思源，如果這個開源套件不是你公司賴以生存的核心基礎，那開不開源根本無所謂。反之如果這個套件是你公司賴以生存的核心基礎，那你反而要思考為何這麼依賴這個套件。」這個觀點讓我留下一個很深的印象，我反思我們這個套件核心其實也只是去 call Tappay 的 SDK，我們也不是因為這個套件才成功的商業模式，Open Source 只是順手，除了讓開發能量可以被看到，又能實現開發人員飲水思源的理想，何樂而不為。
很快的我跟技術長與 CEO 討論了這個想法，他們也都蠻支持我的想法的，因此前端團隊就開始將 package 拆出來到 github 了，其實拆 package 的過程就是一個蠻有趣的過程，一方面開源等於裸奔，你會重新審視你的程式是否有任何問題，另一方面會解耦，消除許多複雜的 dependency，在團隊有適度能量時，我認為都是利大於弊的。
小結
這就是我們第一個開源的 library 的小故事。不過我印象最深刻的是將 UI 思維從 native 抽離的過程，直接看結論好像很簡單，但當初我們都落入的這個陷阱。將 native SDK 當成是 API 來呼叫一切都變得很簡單了。轉個想法路就通了，這真的很有趣。
另外就是開源對開發者激盪出的火花與熱情，我認為是很好的實作過程，在公司有餘力時順手做的話並不會多花很多時間。不知道業界對開源的想法怎樣？有多少用 tappay 的開發者？若有興趣一起交流也很歡迎。如果覺得這篇文章有幫助到你的話，也可以來 github 給顆星星，給我們的開發團隊鼓勵一下。
by 說完故事的Bingo
文章出處是Bingo的Medium Blog，內有其他相關技術與心得文，歡迎點閱
