摘要：由于初版需求及開發工作都沒有參與，在接手項目后過了遍前端結構發現所有交互及組件都是現擼，并未使用市面上已有的優秀前端框架從我個人角度理解上出發，后續需求變更中當需要實現某些常用組件樣式或交互時，基本上都需要現擼或者尋找合適的組件。

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版本的應用市場項目，基本實現的應用市場APP版本的功能；后一個同合伙人項目一樣也是應用市場活動

從功能上來說都不復雜，主要的點還是在于研發周期，兩個項目研發、測試和上線加一起40人日（包含周末）。剩下的沒什么好講的就是再次開啟了瘋狂加班模式

應用市場H5完成了所有的JS交互和數據的處理，實際研發周期約10人日、給出5人日測試；易起賺項目單擼的UI、交互和服務，研發周期14人日，給出5人日測試

一句話總結這兩個項目：Woc居然還是要加班的我忍不了

2017祝愿所有的朋友，萬事如意