2018年5月7日 摄于日本北海道神宫

犀牛君最近比较忙，一方面需要控制好产品的交付质量，另一方面，本身也需要参与到具体到质量控制流程中，在非常忙碌的产品测试交付中发生了2件小事，分享出来，与大家一起看一看聊一聊。

小事一：

一个产品的商品排序接口在测试过程中发生了问题，问题其实挺简单的，排序并不是按照PRD的要求以时间升序对商品排序。很自然，测试人员上报了这个缺陷并且和对应开发一起定位具体原因。在沟通过程中，意外发现，开发将一个紧急的功能对应的数据加到了这个接口中，但是在开发和产品沟通的最后截止日，产品无法给出对应参数明确的数据原型，于是，该接口必须在这个迭代中以硬编码的方式被改造回去。于是出现了排序对原有数据的失效问题。这个修复历经大约半个小时。

小事二：

在开发提交完分支代码后，测试开始在jenkins中将代码打包并且将服务部署到对应的测试环境中，在jenkins中代码全部编译通过并且代码扫描符合相关的规范和约定，最后的结果在log中明确显示为成功。然后，意外的事情发生了，按照经验，部署完毕相关的服务会自动启动，但是，在服务器查找相关的服务时发现有一个jar包对应的服务一直处于失败。于是，仍然很自然地去看对应的log，查了半天没有发现异常，最后不得不找对应的开发来查看服务情况。在排查了所有可能性后，开发恍然大悟地表示，自己忘记修改对应的小版本号了，测试此时的心情百（cao）感（ni）交（ma）集。这个排查解决大约历经不到15分钟。

犀牛对上面2件小事最后都给出了解决的大致时间，从时间上看，其实和解决一些技术含量高的问题所花费的时间来说，真的可算是九牛一毛，但是仔细想想，从技术、工程、团队协作等层面来考虑，滚雪球的效应也许在不久的将来可见一斑。

首先，从技术和工程的角度来看，有这么几个问题：

1）以硬编码的方式添加可能性。这里的可能性指的是承接多种数据的可能性。硬编码本身是没有问题的，但是，一旦和可能性衔接在一起，那么这种组合绝对是在给自己喝下毒药。

2）接口没有版本概念。从第一个小事我们看到，接口其实需要做一次降级，从类似版本1.1.1降到1.1.0时候的版本，从而快速地完成对不确定性的抛弃。而目前能做到的是，在一个没有版本的接口中，通过调整原有所有代码的方式来进行降级。试问，如果问题复杂度比较大的话，这种降级可能就不止半个小时能解决了。从而进一步来想，如果接口不止对接一个端或者在之后的调整中需要兼容新老业务，那么没有版本概念绝对是一次灾难。

3）开发对敏捷迭代工具不重视。CI和CD做到现在其实也经历了从开始的整体规划到整体使用推行的过程，在这个过程中，对一些必要的参数进行配置化是正常不过的事情。研发在平常的使用中，基本都只处在用的状态，通常来说，只要不是代码编译不过的问题，基本上不太关注后续的结果。从而我大胆推导目前一些公司的敏捷状态和结果是禁锢在各自角色中的，如果敏捷只是处在一种守（比如遵守3355这样的敏捷内容的Doing状态），到不了破（breaking状态）和离（Being状态），敏捷最后还是会走到可预见的负收益的最终结果。犀牛以前感叹，敏捷之殇，责任（能力）无法承受之重。

从团队协作角度来看，其实也是一个老生常谈的问题：产品和技术的沟通，永远隔着一条巨大的鸿沟。还记得各个技术论坛、技术QQ群中那一张张充满恶意的动图吗？嗯，痛苦之所以存在，是在于处于两个世界的人并不是一定有机会能走到一起。所谓的人人都是产品经理，犀牛一直认为是一种对其价值的恶意评价。

小事就讲到这里吧，问题出现了大家还得坐下来想办法、想对策，以积极的态度面对这些“小”事，从基本面去解决这些问题，和团队一起成长，并且充满好奇心，才能在不确定性中找到解决各种小事的方法论和工具集。