2016悄無聲息的過去了，再過不久便是農曆新年
這幾天相對清閒梳理了一下去年所做的工作，希望在新的一年能發展的更好
今年一共研發或升級了五款產品：合夥人、奪寶、開放平臺、應用市場H5版本及應用市場-易起賺專案
所有的總結會圍繞這五個專案展開，主要還是梳理存在的不足
合夥人
合夥人是部署在應用市場APP內開發的一款H5活動，在合夥人活動內使用者可通過下載安裝任務、分享給好友、抽獎等形式賺取獎勵；同時，使用者可以自助提現到微信紅包領取個人獎勵
該專案於2016年1月左右正式上線，初版有效研發週期約為一個月，後續由其他小夥伴更新了一個版本，已於2017年1月在各個渠道的APP內停止運營。
關於前端框架的選擇
在選擇專案的前端架構時主要考慮的是Bootstrap 3、AmazeUI和Framework7。由於該專案是部署於APP內的H5專案，我最終決定使用Framework7框架來進行前端架構，原因主要有以下幾點：
1、Bootstrap、AmazeUI、Framework7都是非常優秀的開源框架，社群活躍、應用廣泛、文件完善
2、元件豐富、編碼規範、相容性好並且易於進行二次開發
3、也是選擇Framework7的主要原因
Framework7 是一個開源免費的框架可以用來開發混合移動應用（原生和HTML混合）或者開發 iOS & Android 風格的WEB APP。也可以用來作為原型開發工具，可以迅速建立一個應用的原型。
基於以上原因我選擇了使用Framework7框架開發此專案因為它適合開發Web App，這很符合我們的專案應用場景
後端框架選擇
在公司我主要從事PHP的研發工作，並且同組的其它小夥伴基本都在使用ThinkPHP2.3版本。所以該專案一如既往的選擇了ThinkPHP框架2.3版本，理由有兩點：一是我
對TP2.3框架使用上比較熟練，二是假如其他小夥伴接手或參與到專案中，不會因框架陌生影響到研發效率。
踩到的坑
大體上來說，合夥人專案比較難處理的是新使用者的判斷、分享使用者的獎勵下發以及防作弊機制的處理(這一點我是後來才明白的)，至於其它的困難遇到的並不是太多
新使用者的判斷
合夥人專案立項時，我們的應用市場APP使用者量基本上就是千萬級的了。
然而應用市場的業務資料並不在我們專案組，所以當產品及運營明確新使用者的判斷規則後，在和原業務服務端開發的小夥伴溝通後，新使用者判斷開發有元業務服務端研發，同時以介面形式提供給我們使用
我們只需要關心完成判斷後對使用者信心的儲存處理。在該專案裡面無論新老使用者，我都會對使用者資訊進行儲存，這樣在活動的業務處理時便不再需要依賴於總庫，這樣處理相對方便
分享使用者的獎勵下發
關於此點由於我設計階段的工作做的不是很好，所以在產品運營過程中導致很多問題的發生，踩過的N多坑至今未被填滿
先來看看需求，進入活動的使用者分享到社交網路吸收新使用者，新使用者完成啟用下發獎勵到分享使用者**
當時，在設計時是這樣思考的：當使用者分享時，服務端解析源APK，並在APK內寫入分享使用者的標識，重新生成新的帶有使用者標識的APK；使用者通過分享連結下載的APP就是重新打包的APP；當使用者啟動APP時，APP檢測是否存在使用者標識與服務端互動完成分享使用者判斷及獎勵下發。
我是這樣想的，也是這樣去實現的
如果現在看到這些業務的處理，我會對著程式碼輕輕的說，這是哪個傻X做的。對，我就是這個傻X
以上的實現，在專案運營過程中至少帶來了三個嚴重問題：
1、APP每釋出一個新版本，專案都需要更新源APK，並且重新寫入和生成帶有使用者標識的APK
2、非常浪費儲存空間，要知道我們的使用者至少千萬級別，即使是千分之一的使用者參加到活動中，再有千分之一的使用者下載了，都意味著需要生成大量的相同的APP，然而其中並沒有什麼較大區別
3、分享使用者下發獎勵需要APP獲取分享使用者的標識，需要APP與服務端互動後才能完成啟用動作，整個過程都是不必要的
解決方案
其實很簡單，大多數的應用都是這樣處理的，每個使用者生成自己的分享碼，啟用使用者使用分享碼完成啟用，給老使用者下發獎勵
防作弊機制
由於缺少活動類專案的研發經驗，防作弊機制的處理是在專案上線後才加入到專案中的，主要還是依據ip等基礎資訊來阻擋使用者。這個處理其實不是很好，還有待進一步研究
一些收穫
羅馬並非一日建成，失敗永遠是成功之母，雖然在這個專案中踏入了許多未曾預料到的坑，但是這些失敗的經驗給了我很好的學習機會，在以後的工作中給了規避此類問題的方法。看起來像是一種藉口，但有時失敗的經驗確實很有用
奪寶
奪寶應用，PHP主要完成的工作是對接Java的業務服務介面並完成頁面渲染工作
初版由別的小夥伴完成，僅運營於安卓WebView中；後續需求中我實現了對iPhone裝置的支援；第三版重寫了H5版本，加入了第三方支付功能，相對來說這次升級是一個新的專案，以至於完全不需要依賴Android或iOS裝置
奪寶應用市面上已經有很多類似的產品了，所以規則及玩法基本上無需過多介紹。由於初版需求及開發工作都沒有參與，在接手專案後過了遍前端結構發現所有互動及元件都是現擼，並未使用市面上已有的優秀前端框架
從我個人角度理解上出發，後續需求變更中當需要實現某些常用UI元件樣式或互動時，基本上都需要現擼或者尋找合適的元件。但是像此類應用在UI設計上是趨同的，所以使用前端框架或許會減少這部分前端研發的工作
再來說一說專案研發過程中遇到的困難
其實業務和UI都不是很複雜，只不過由於每次升級給出的研發週期非常短，在需求、編碼、測試等各個階段都非常吃力
比如在開發對iOS裝置支援時，由於開放平臺專案也是我研發的，當iOS需要使用開放平臺支付SDK時，我在極端時間內既要實現奪寶專案對iOS裝置的相容，也要實現開放平臺支付功能對iOS支付支援。這些才是奪寶專案對我個人來講最大的挑戰和鍛鍊
而這個挑戰集中體現在對H5版本的重寫需求中。在專案需求和評估階段，我給出的研發計劃大概是25人日(包含研發、測試和上線運營)。但實際給到的研發週期為7人日、測試3人日；也就是說實際正常25天的工作量，需要在10天內完成，整個研發週期僅有正常評估的一半還不到
剩下的就是開啟了瘋狂加班模式，整個UI沿用APP版本的UI，但是與APP互動的部分則基本需要重寫，同時實現了對Android和iOS裝置的支援，並且由於是H5版本第三方支付也是重新接入並沒有使用支付SDK；幸好有一個小夥伴加入的研發工作中，去實現之前原生APP UI的那部分功能。所幸，保證了專案的按時上線
如果想用一句話總結這個專案，我只想說再也不要加班了
開放平臺
今年在開放平臺方面額研發投入並不多，主要還是它基本上算是一個穩定的專案，從14年11月上線至今穩定執行了兩年多，期間完成了多次更新和功能擴充套件
今年在開放平臺研發方面的投入，主要是實現了代金券下發與使用功能，同時支付功能實現了對匿名或登入使用者的支付支援。這些實際上都不是非常複雜的業務處理，並沒有太多需要特別提出的
但支付上，今年遇到了很嚴重的漏洞，這個漏洞並不是由於功能更新帶來的，而是一直存在只不過今年集中暴露出來了
1、第三方支付發起閘道器支付時，訂單金額並非從訂單庫中查詢獲取
2、第三方支付完成後，在回撥接收時的訂單處理時未對支付成功金額校驗
先說第一點，雖然在使用者支付過程中，服務端有對金額等敏感資料進行簽名處理，但是在跳轉至閘道器支付的處理邏輯中並未生成簽名，同時支付金額也不是從資料庫中獲取的，所以有些使用者在支付時篡改了支付金額
第二點則是，接收到第三方回撥後除了基本的簽名校驗外，原有的處理邏輯並未校驗資料庫中的支付金額和支付成功回撥的成功金額，其實這個問題也是由於問題一導致的
以上兩點都是很致命的支付漏洞，通過這次的漏洞事件，我至少明白了三點:
1、不要相信使用者輸入，即使是自己的程式同樣可能存在問題，對於支付這類敏感操作，所有重要的資料都需要校驗
2、對於支付功能，如果支付閘道器請求和訂單建立不再一個邏輯塊處理，支付金額需要查詢業務庫獲取支付金額並以此金額發起支付
3、支付完成接收非同步回撥時，請對敏感資料嚴格校驗，尤其是金額資料這十分重要
應用市場H5 、應用市場-易起賺
這兩個專案放在一起的原因是因為前一個是H5版本的應用市場專案，基本實現的應用市場APP版本的功能；後一個同合夥人專案一樣也是應用市場活動
從功能上來說都不復雜，主要的點還是在於研發週期，兩個專案研發、測試和上線加一起40人日（包含週末）。剩下的沒什麼好講的就是再次開啟了瘋狂加班模式
應用市場H5完成了所有的JS互動和資料的處理，實際研發週期約10人日、給出5人日測試；易起賺專案單擼的UI、互動和服務，研發週期14人日，給出5人日測試
一句話總結這兩個專案：Woc居然還是要加班的我忍不了
2017祝願所有的朋友，萬事如意