基金基础服务发版过于频繁的总结

2018-02-03 上周四版本上线，我的服务有几次重复发版，负责人让我总结下原因，感觉一阵蛋疼。

基金基础服务发版过于频繁的总结

原因分析

1. 思考问题不全面
   • 在编写代码过程中，开发人员想到的场景可能不全。往往都会出现某些条件没有考虑的清形。例如：在飞鱼3.7.1基金终止上市该功能开发中，我只考虑到基金终止和正常上市的情况。而在上线之后，测试人员发现将“转型”过的基金（该基金由终止状态转换为正常上市交易）也设置为终止。导致上线之后需要修复该功能。
   • 测试环境只包含线上很少的基金数据，导致自测和测试都无法发现场景分支。
   • 业务能力不够。对基金业务仍不是非常了解，往往容易出现业务场景思考不足，导致代码容易出bug。
2. 测试覆盖不全面
   • 自测不到位。测试用例编写不够，很多时候只编写了少部分测试用例，只通过主功能，未考虑边界条件，同时未写测试用例分支也为考虑。
   • 测试人员测试粒度不够。有时代码优化功能，或者以前已经测试过通过的功能，做出优化重构之后未提交给测试，导致测试粒度不够，上线之后才发现bug。
3. “环境问题”
   • 测试数据与生产环境有一定差距。目前由于一些原因（恒生数据配置原因）导致测试环境数据和生产环境数据还是有很大的差距，会导致“环境问题”（测试环境无bug，生产上有bug，反之）。例如，代销基金列表，测试环境只有80只基金左右，而线上有将近2300只基金。而根据我经验，有时每只基金都可能会出现一种完全不同的情况，所以有时测试也很难测全面。
4. 兼容性问题（设计缺陷）
   • 由于飞鱼项目在app项目进度不一致，有时容易出现最开始设计的功能已经不再适用app的需求，而在上线之前未评估到这一情况，就会导致在上线之后才发现问题。同时前面设计的功能开发人员认为修修改改就能适用app（或者飞鱼），但实际情况可能不理想。
   • 由于OMS功能比较落后，而我们几个产品有时意见也很难统一，各自都有自己的特色。导致我们的设计很难顾全所有的产品。例如精选基金，app要求即按月份又要同时满足不同客户端的定制需求。而在前期的设计中没考虑不同客户端的问题，故在后期维护中难度较大。容易产生bug，不过后面经过协调产品达成一致。
5. 代码缺陷
   • 空指针问题。编写代码时非常容易出现的一个问题，代码判断不全面导致
   • 超时问题。接口比较慢导致超时，而未做任何处理，这一般是开发人员无法意料到的问题。恒生接口和巨灵数据库sql查询等容易出现超时。
   • 异常补偿机制。开发人员很多时候对可能出现bug的代码未做异常处理，而有些则是只是做了简单的try catch，没有异常补偿，只能保证前端接口的正常访问，却不能修复数据。例如组合收益率走势图bug等。
   • 数据源问题。数据源的切换没有做更加详细的测试，对源数据未加工，导致界面显示错误。例如货币基金7日年化异常，持仓收益率未计算等bug。

总结（改进）

1. 加强单元测试，自测。养成编写单元测试的习惯，不仅如此，还要养成对同一个场景编写尽可能全的单元测试用例，各个分支条件要覆盖到，还要对考虑边界条件测试用例的编写。多线程场景条件写的测试用例等。养成自测习惯。再小的功能点都需要编写测试用例。提高对测试用力的重视。
2. 提高自身意识，需提高对代码上线的严肃态度。目前由于上线流程简单，而微服务往往上线牵涉面比较广，而我们目前用户较少，上线发生的服务中断等用户反馈较少，导致开发人员普遍没有高可用意识，上线比较随意。同时测试或者其他人员催促较急，代码未经过完整的测试就上线，这不利于培养上线严肃的态度。但这需要把控个度。培养以用户为中心的思维习惯，能够提高开发人员对代码上线造成的服务不可用带来的思考。
3. 加强业务知识，业务理解。
4. 做好沟通交流。对优化的代码，功能点要及时发聩给测试人员回归测试。开发人员之间也要多保持交流，可以交换大家对业务的理解。也可提高编码能力。
5. 加强自身编码能力。对于边界条件的思考和复杂场景的处理，要做到尽善尽美。
6. 代码审查。定期代码审查或者代码（技术）分享能够提高大家能力，减少bug。分享不一定是开会，好的代码或者好的idea都可以分享。