2016年终工作总结

摘要：由于初版需求及开发工作都没有参与，在接手项目后过了遍前端结构发现所有交互及组件都是现撸，并未使用市面上已有的优秀前端框架从我个人角度理解上出发，后续需求变更中当需要实现某些常用组件样式或交互时，基本上都需要现撸或者寻找合适的组件。

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祝愿所有的朋友，万事如意