Goodideas Studio — 好想挑戰賽 Day 2（心得分享）
前言：
每天都是對自己的人生大挑戰啊！
剛結束一個精實的第一天的臨時挑戰賽，不例外的當然比賽沒有這麼快就結束了（ 之前 iOS Camp 也就是我們 Camp 還有過為期一個禮拜精實的比賽啊！ ），只是這次可能活動為工作室的學員們一起參加，所以疲勞程度也是大幅提升，只是為了增進自己的實力，只要是挑戰都來吧
抽卡創業挑戰賽：
今天讓大家體驗創業會碰到的兩個元素，如何用最小的成本去測試商業模式，和時間賽跑。
Web 與 App 將通過 WebView 來進行溝通。
挑戰賽內容：
這一次，我們需要快速的生出一個能夠通過消費代幣來抽卡牌的 App。利用起現有的資源來進行 App 開發，Web 工程師負責抽卡的邏輯， App 負責介面和存儲的邏輯。
但你們只能通過 WebView 來溝通。
Web
- 將前一次的挑戰賽的抽卡動畫，實作成「隨機抽卡」應用，每一次使用者點「抽卡」都能夠隨機獲得一張卡片。
- 抽卡動畫右上方顯示使用者的餘額。
iOS
- 將 Web 所做的抽卡應用整合到 iOS App 當中（通過 WebView 操作）.
- 呈現目前使用者已經抽到的卡片。
- 通過 Tab 切換兩個畫面。
其他
- 為你的遊戲取名字
- 抽卡需要消耗代幣、餘額不足要跳提示並防止繼續抽卡。
- 餘額和卡片資料要永久存儲（強關 App 在打開，要能還原資料）
因為當天就是用白板來講解題目，這邊就由我來簡單述說一下畫面與需求
界面 A：
- 除了畫面上的元件以外，所有呈現畫面都是 WebView。
- 進到 APP 之後，WebView 必須顯示玩家金額。
- 點擊 WebView 的抽獎鈕點擊之後，必須扣除玩家金額。
- 玩家重新打開 APP 之後，WebView 顯示金額必須為玩家剩餘金額。
畫面 B：
- 畫面 B 必須顯示玩家抽過的卡片紀錄。
- 抽卡如果有重複必須判斷是否為同一張，並且該張卡片的數量增加。
- 重新打開 APP 之後，抽卡紀錄必須存在。
事前規劃 & 分工
因為前一天也學到了一些教訓跟啟發，就決定在今天開始前要好好討論一輪，並且確定每個部分該怎麼處理比較完善，所以一開始的動作是各自搜集資料並傳到群組中討論，並以討論需求畫面該如何分工及實作，例如：「 玩家餘額該存在哪端？」「 畫面呈現需要什麼？」。
開始實作：
- Web：
首先因為我們有兩個 iOS 與一個 Web 的組員，因為 Web 組員從需求來看，首先就先改寫原本遊戲邏輯，讓他能夠重複遊玩以及可以隨機抽到的卡片，因為最終 Demo 是在手機上，我只是負責用 WebView 顯示它所顯示的網頁，所以一開始就專心改寫遊戲邏輯。
- iOS：
因為我的實做能力比較強，所以讓另外一位 iOS 來輔助我們，可能先幫我們看最後如何讓 Web 與 iOS 溝通的方式，或者是當我們卡住幫我們找解決方案，而我的部分就先把 APP 所需畫面呈現出來，並建立一些之後可能會用到的資料存放方式以及建立資料格式。
這邊我覺得我做的比較好的一點是，因為 Web 必須改寫遊戲邏輯，所以可能需要消耗部分時間，所以我在刻好整個 APP畫面之後，因為畫面 B 整個都是 APP 來處理的，我們只差在沒有資料可以顯示，所以我就開始建立之後可能會需要的方法，例如：「 我的抽卡紀錄是不是要放到一個 Array 存在本地？」「 畫面顯示的圖片及名稱的方法是不是可以先建立好？」「 玩家金錢什麼時候呼叫？」 。
所以當 Web 完工之後，我們其實只缺互相溝通方面的問題，就可以馬上測試功能了，所以我在遊戲初期就寫好 B 所有可能會用到的方法，像是是否抽到重複的卡片判斷也都先做好了，因此減少了很多閒置時間。
碰到的障礙：
因為這個題目我們兩端學員都是第一次接觸到，所以可能會碰到許多問題，很多時候都是實作到一半發現不可行，而必須換個方法實作，我以下列出我們碰到的問題：
- 該元件或是方法不支援：
我記得我一開始使用一個 WKWebView ，因為他在效能方面大於一般的 WebView，可是他可能無法支援我們討論出來的溝通方式，因此我可能就必須換使用 WebView 來實作。
- 文章審視不完全
因為我們看的都是同一份文章，所以我們各自定義各自的方法，其中也有提到：「 我們方法該命名什麼？」 「 參數傳遞格式是什麼？ 」，但我們可能少看到了文章定義方法方式格式可能跟我們平常的定義不同，當時我們沒有看到 Swift 的參數前面必須加上底線時，就發生了無法與 JS 溝通的問題，加上這種問題在程式上是不會有錯誤提示的，它就只是失去了功能。
賽後檢討：
其實後來我們這組算是順利完成了所要的需求，真的是可喜可賀，幸好我們所碰到的問題都以不到半小時的時間解決了，雖然大部分問題都發生在 APP 這邊，幸好我的解決能力還可以，也有一個 iOS 隊員在旁邊輔助幫我 code review 讓我在碰到問題時詢問這樣判斷是否比較好。
這邊我們也因為要實作沒碰過的問題，所以大多方法都是查看別人寫的文章，但我們往往忽略了：「 這個方式還能實作嗎？」「 是否已經過時了？ 」等等問題。其實我們在挑戰的時期是可以查看這些文件是沒有問題的，但我們在完賽之後應該要好好的去查看官方文件或是查看他背後的原理，才疼真正了解他是如何運作的。
這兩天的活動也真的是很充實，雖然導致我的文章稍微難產一些（ 絕對不是想不到題目 ），但是增強的不僅僅是程式和實務方面還是，重要的還有與團隊的合作溝通，遇到困難才會感覺自己的有扎扎實實的成長一輪，希望未來也有許多類似這樣的臨時挑戰賽，逼死各位夥伴們成長（ 嘿嘿
附上當天挑戰賽活動 Github 連結，我們是 Team A：
