加班專案在這一個月

終於告一個段落

和PM驗收過後

修一些bug後就準備重新送審上架

原本以為會很順利

結果竟然在蘋果內購的出了問題

就是在向蘋果購買商品時

蘋果官方server回傳購買成功

但是要把來自蘋果的收據資料

寫回公司自家資料庫時

就會顯示失敗

原因是訂單重複

但是同樣的流程

套用在其他公司的App就沒有問題

看了半天確定前端流程沒錯

只能請後端同事幫忙檢查

顯示訂單重複錯誤的原因

忙了半天才發現

檢查訂單的那一道Api

在判斷訂單是否重複的條件當中

有一個欄位是”消耗型產品”不會有的值

也就是會預設帶0

所以全部的消耗型產品發票資料

都會被判定為訂單重複

同樣的前端購買流程

在其他App沒有問題的原因

就是因為其他App的商品

全部都是”續訂型商品”

所以才沒有發現這個Bug

加上原本舊有的Code

是串接舊的購買Api

直到這次把專案從Xamarin翻寫回原生

串接新的購買Api時

才發現這個問題

加班專案結束後

幾乎天天準時下班好不愜意

不過耍廢太久還是有一點空虛

之前把作業系統的線上看課程看完後

下一個要補足的課程

就是望之生畏的演算法

一樣先去圖書館找找看相關書籍

相比資料結構

演算法的書籍又更少了

如果要挑看得懂的

大概只剩一兩本

是說雖然看主題是演算法

不過一開始都還是講資料結構

從最基本的Stack, Queue, Tree, Heap

還有遞迴，搜尋排序等基本概念

接著才進入演算法的種類

首先是分治法

Devide and Conquer

將問題切割成類似的子問題

解決子問題後

再將子問題的解答合併成最終的解答

百分之九十九都是遞迴

(要寫成迴圈當然也是可以啦)

經典的例子如merge sort, quick sort

河內塔或是找最大質因數

以及樹狀結構以及link list的問題

因為他們在切割後仍具有原本的相同性質

不過問題就來了

目前工作實務上

會用到遞迴的情況少之又少

更別說是樹狀結構或是 link list了

不過LeetCode的網站一打開

全部都是Tree和link list

加上主管這次的實習考題

也是考兩個link list的數字相加

所以雖然很少用到

不過感覺還是很重要

而為了解決分治法當中

對於單一子問題重複計算的問題

(如費氏數列的遞迴寫法)

動態規劃法因應而生

動態規劃的核心精神

就是把重複問題的解答

用表格記錄下來

當遇到同樣的子問題時

就直接查表，而非再計算一次

說起來簡單

不過實作上卻滿複雜的

經典的例子如最短路徑問題

連鎖矩陣相乘，最大相同子序列等等

如果沒有看過書上的解法

還真想不出來動態規劃的解法

相比之下

貪婪演算法就直覺多了

透過特定的選擇程序

並且只取當下最有利選擇

例如換零錢問題，霍夫曼編碼

或是最小生成樹的問題

即使有些問題用貪婪法求出的並非最佳解

但通常和最佳解相去不遠

而且時間複雜度比起窮舉法低上很多

所以還是滿好用的

雖然目前工作還用不上這些高大尚的演算法

不過感覺還是念一下比較心安

拋開演算法

還是來講一下上班的專案

之前做的討論社群App

第一次送審就被退

雖然在預期之中

但是退審的原因卻是從來沒有遇過的

就是蘋果官方要求有有黑名單和檢舉機制

因為這支App是所謂的C2C產品

蘋果對於這類的產品審核較為嚴格

強調用戶要可以屏蔽他不喜歡的文章

並且檢舉不當內容

除了這個以外

因為這個產品沒有應用程式內購買

所以Apple就一直問

有沒有偷藏購買功能

前前後後問了兩三次

還警告如果發現就要停掉開發者帳號

但是沒有就是沒有

面對Apple落落長的疑問

我們的PM很酷地只回一句

“We followed the guide lines”

好在蘋果囉嗦歸囉嗦

還是給過了

只是因為還要優化功能

所以目前還沒開始做行銷宣傳

待之後真正把人流倒進來後

再視情況調整App的功能

這一個月還有一個比較重大的事情

就是同事研究的靜態程式碼檢查器終於完成啦

前兩個月iOS組討論好的coding Style

終於要在這一期實作了

我們是採用SwiftLint

據說是目前做Swift靜態檢查器

獨大而且唯一有在更新的三方套件

檢查的規則同事已經幫忙寫好了

我們只需要引用SwiftLint三方套件

並且在專案加上run script

告訴xcode編譯器檢查檔案的位置

一run下去就會告訴你幾個coding style錯誤

而且是紅色的警告

也就是不修正的話

專案就無法成功build起來

就興致沖沖的加上去

開啟專案一build下去

不得了，500多個錯誤

但是這些錯誤當然不可能一次修完

所以當然有一鍵修復錯誤的大招

就是在script前面加上#

編譯器會忽略這一段script

專案就可以正常編譯了

除了我們自己訂定的規則以外

SwiftLint也提供了很多黃色的警告

告訴你code該怎麼寫 

像是switch case 不該加break

沒有return值的方法不要加Void等等

大概一千多個黃色警告

真的是很貼心呢

另外一個重大變革

就是我們iOS手機組的共用專案

改成pod 的方式

讓原本大家參考的專案

直接變成三方套件

但是沒有上cocoa pod 

只能在本地端引用

而這個backend 專案

又有引用FB, Flurry等其他三方套件

所以之後各自的專案

只要引用backend專案後

就不用再pod 其他三方了

未來公司App共用的模組

如登入，自選股等等

也會直接進入backend專案

加速新App的開發流程

逐步優化手機組的工作流程

並邁向下一個新里程碑