本文是个人的一些总结，有些因为是内容和数据是机密就不详述了，主要记录了一个算是大型项目开发过程中需要考虑的地方，当一个用户量多后，很多东西都不能用常识来估量，也会出现各种奇妙的情况。
1、项目初期
了解项目需求、功能点分析、整个项目的业务流程、需要接入的外围系统及其产品负责人、开发负责人。当前项目的周期、开发人员、测试人员。
和市场人员确认活动影响力，评估访问流量UV、PV、QPS（峰值），后继问题如果影响力不足，如何降低门槛；如果超出预期如何做。
2、项目开发
o 开发：
§ 代码开发时候后使用的框架、代码架构模型，不同的团队可能有不同的思维和方法，大家约定好之后按照统一的方式来编码才能避免之后代码风格不同、杂乱乃至失控。
§ 开发过程中的单测很重要，即使在初期因为赶项目进度，也要把单测的环境准备好，而且因为数据访问层基本没有业务逻辑，这个部分的单测一定要有，在开发的时候进行数据验证、SQL检测用处很大，在自测联调的时候就不用因为数据库访问部分代码的错误频繁重启服务。
§ 业 务种类分为2种：活动业务和常态业务。最杯具的情况是活动业务只做一次（如果3-4/年那就是喜事了），而且业务规则和常态业务基本没有相同的地方。在短 时间内为了实现这些规则写了很多一次性代码：例如因为节省前端资源，所有的运营数据的全部用excel导入，后台编写了大量的excel解析和数据验证逻 辑。需要设计人员区分这些一次性的代码、易变的代码、以后有可能被用到的代码、肯定会被用到的代码，尽量搁置在不同的类中：有些当做基础共用的代码、有些是临时的数据逻辑转换代码，通过面向接口的设计来兼容不同的数据导入和解析方案（例如从excel转为web传入、生成展示数据的策略由每日改为每小时 等），用单测来保证无用代码被删除后对整个业务影响度为0。
§ 根据业务复杂度来决定是否进行模 块切分：业务功能来纵向切分成不同的子模块、同一个业务功能的优先级来进行分组切分（可以通过代码配置进行软切分）、基础服务相同但是使用场景不同进行横向切分（Web端、MobileNative端、MobileH5端用的都是同一套基础服务，但是使用不同的接口API）
§ 根 据预估的数据量来决定是否使用数据库or使用配置；使用哪种类型的数据库，配置的数据是否经常会变化。在本次活动项目开发中初期因为数据量少，需要创建的表少，为了加快开发的进度，开发初期直接使用了另外一个项目的测试环境的数据库，之后上预发环境才让DBA单独建库。使用配置文件，如果配置的数据会有机率变化（虽然比较低，而且数据量少），这种数据量小而且有一定变化机率的数据可以考虑依赖内部配置平台：diamond/configserver，例如系统早期时候的用户权限配置模块、一些枚举型数据
3、测试与产品体验
· 测试同学在产品启动初期就开始参与进来，熟悉产品需求，review开发人员的架构和设计方案，编写测试用例。进入测试阶段之后，汇总每天的测试状况，根据测试结果提出产品改进的方案，决定产品是否能上线。
· 测 试同学全程参与产品整个生命周期，在开发阶段任何实现的调整都应该通知到他们，否则使用旧的测试用例来测试修改后的产品-conflict！！！开发同学 在编写代码的时候一定要注意功能的易测试性，例如：如果产品是和时间有关系的：某个时间点功能才会有效，一定要有后门界面供测试使用；如果业务的最终数据是流向其他系统，要考虑数据查询工具供测试同学验证数据；业务出错后的信息提示是否明确，作为首批用户而且是了解业务的用户都不了解错误信息，那就说明设 计出问题了。。。
· 在每次做项目/产品的时候，发现UED同学占用开发的时间，开发同学占用测试的时间，测试同学占用？？？他们没得占用，只能在deadline之前苦逼的加班，开发同学也只能陪着苦逼的解bug。上线日期确定的情况下，如果时间 不充足，每次的需求调整对开发，特别是测试同学都是很大挑战，本次活动大量的时间在做功能回顾，有些产品上的体验细节大家都没有注意到，导致上线之后又发布紧急修复：页面刷新导致用户之前选择消失，这种体验细节只需要几分钟的开发成本，但是对于用户来说是很不友好的情况都没有精力去关注了。。。
· 为 了产品的进度，会要求开发人员分模块开发，然后按模块提交测试，有个问题就是开发同学刚刚完成代码开发，并没有充分自测，这个时候测试同学就开始介入，会出现大量的bug，开发一边开发新的功能，一边修复bug，会导致bug reopen率高，开发效率降低的问题。需要测试同学排出每个bug的优先级和紧急程度。
4、项目稳定性
功能提交测试之后，开发人员的任务只是进行了一半。根据之前预测的访问量，需要理出每个业务流程耗时、耗资源的步骤、哪些依赖是必须的、哪些依赖是可以容错的（在必要时候可以进行依赖降级）、在压力过大的情况对外提供的服务是否可以进行服务降级。
- 依赖：在本次活动中，商品信息、交易系统是强依赖，用户购买资质的判断是弱依赖（即使这个服务出问题，做好相对的规划进行依赖降级，依然不会对整个购买主流程产生影响）。任何和金钱相关的交易（包括优惠信息）都是强依赖，在整个业务流程中是不可以被绕过的。
- 限 流：当前当前服务接口被访问的次数超过预估的峰值或者服务内部出现异常，需要考虑使用根据访问者的业务优先级、访问的频率对部分访问或者全部访问进行限 流。这些限流降级措施需要和服务使用者预先进行讨论，告之做好相应的容错预案。至于限流的技术可以通过代码、通讯协议层、硬件路由实现。
访问频率、系统依赖之类的数据需要有相应的监控系统完成，这是公司基础技术设施必要的组成部分。例如：eagleeye可以查询系统依赖及其某一个业务流程在不同系统之间的调用频率和访问路径。至于QPS/RT/机器负载之类的监控已经有很多开源解决方案。
为了真实模拟线上真实请求的压力，引入双11巨牛的“全链路压测”来分析业务中是因为哪个依赖系统导致的木桶短板。然后确认造成短板的原因：编码原因（锁、多余数据库访问步骤、cache） or 系统硬件环境（虚拟机情况下的io瓶颈、跨机房时候的网络瓶颈）
当这些降级限流方案确定之后，由相应的开发人员完成并且提供给业务方集中使用，每次开启使用之前应该明白相应的后果、应该如何回滚。
5、上线运营
· 本次活动时间仓促，有些数据录入页面可能只使用一次，故未开发，使用excel的方式导入到系统，数据是由运营同学整理录入。这种方式有点是没有负责的前后端交互，但是缺点很明显：录入的数据因为没有页面交易，很容易出现不符合格式的数据：格式错误、数据重复等等，有些可以预料，以后由代码处理，但是有些已 经超出想象。时候反省：任何数据如果没有校验，都是不可信的，即使明确告之单元格的内容完全是固定的，这样需要后台代码校验。这也是做UGC产品的尴尬之 处，有很多代码就是用来校验数据有些性的，真正涉及到业务的代码可能只有50%
· 上线之后开发应该和PD、运营确认需要哪些维度的汇总数据，这个时候已经有时间来做数据汇总和显示的开发了。有些数据可以由兄弟部门帮忙的话，需求最好在产品发布在预发环境的时候就要提出来-早些提出来时间更充裕。
· 运营和PD会根据销售数据统计分析，基于日期、地址来分析销售状况，临时决定使用哪些营销推广策略来拓展市场不好的地区。不能对自己估计过高，提前找好退路，指定一些营销补救措施。
· 有些异常状况是程序无法补救的，需要制定好规则帮助用户弥补：相应的赔款方案、退货规则。例如:
o 用户购买需要线下使用的电子券，当输入的手机号错误，要有可靠凭证证明用户在线下能够合法的使用订单，例如通过交易记录、卡券包信息之类的。
o 或者用户忽悠导致自己购买的东西有效期、使用时间不正确，要想办法统计这些交易数据，并通过短信、应用消息的方式尽早通知用户。
o 有些商品有购买门槛的限制，如果因为某些原因误够，导致没有资格再次购买，后台需要有工具来恢复用户的资格，否则就要面临用户的多次申诉
后记
- 3.7 日活动已经进入尾声，对于技术人员来说已经可以放松了，运营同学还要继续忙一段时间，这种O2O业务前一半任务是如何把商家的SKU数据全部展示出来供用 户容易购买，后一半任务是如何保证用户购买的东西被线下接受、核销，这一部分的流程更重要，线下需要和商家的服务人员接触--服务质量难免参差不齐，用户 不爽，以后基本上会被用户拉到黑名单中，线上业务也基本遭殃。
- 个人感觉，O2O业务和互联网业务区别在于：互联网没有地域局限，在互联网上用户是真正处于地球村，任何信息、网络虚拟服务都不受距离的限制（不要拿那些传 说中的网站和我擡杠~(≧▽≦)/~）。O2O服务是帮商家把所有的SKU以跟友好、方便的方式提供给用户随时查看，用户不需要打电话给商家咨询哪一天能 提供哪一种服务，去之前要不要预定，等等（最恼人的是遇见你拨打的用户正忙，请稍后再拨的提示）；用户使用O2O业务一般是因为能够便捷、优惠购买自己物 理距离之内能享受的线下服务，这也意味着O2O不会如互联网业务那样有了流量就有了一切，O2O更应重视在当前线下客流总量下尽力培训忠诚用户，回头客和 口碑比流量更重要。