Tech Lead 成长之决策方式

案例介绍

我将以我之前某个项目落地推行的一个外部依赖数据 mock 方案进行介绍。

背景

银行金融业务项目，作为面对终端用户的业务方，需要整合所有外部依赖而且外部链路特别长，任何一个环节出问题，都会导致数据获取失败。

因为是测试环境，经常有外部系统不稳定，导致请求失败。外部依赖中，有一个数据源 A 经常挂掉，经常阻塞开发测试进度。有些一次性数据，比如：激活等；使用一次后数据就永久性变更，需要重复找数据源头给我们造数据。

我们当前已经有在使用的多套 mock 数据方案：smockin，jmeter，硬编码配置等。

在这个情况下，想要提出一套新的数据 mock 方案是非常困难的。新学习一个东西是有认知成本的，现存的 mock 方案也能满足当前一些痛点。但需求是变化的，团队也是在不断进步的，总有新的方案出来革新。

事情起源

最开始开发过程是非常痛苦的，因为外部依赖问题，导致测试和开发闹一些矛盾，而且一些测试用例很难复现。直到一些老成员把部门正在使用的一些 mock 工具介绍给我们后，这个情况才有所缓解。但那个时候开发需求量非常大，新团队内部需要磨合，对外合作方式也需要磨合，一大堆事情等着，这种事情压根排不上号。但种子已经埋下来了，只等着生根发芽。

契机出现

我们先分析当前系统存在的所有请求调用：http 请求占据 50%，MQ 发送与监听占据 50%；其中 MQ 分为 3 个软件，A、B、C 分别占比：30%，15%，5%。C 是逐渐朝 A 迁移，可以暂时忽略。

从上述分析中，MQ 的 mock 是需要我们纳入考量的，并且项目痛点也来源 MQ mock 数据困难。单纯 mock http 请求的话，已经在使用的 smockin 可以很好的满足需求。所以我的目标就放在能支持同步和异步两种请求的框架上。

直到发现 mountebank 这个框架，它是一个支持多协议的虚拟化工具，并且还可以支持自定义新协议。发现这个框架的时候只是觉得找到了希望，但是因为进度问题也暂时搁置。

落地实施

开发团队还是如期完成了功能开发，大概有一个月时间是留给测试人员测试的。这个时候测试数据不足，以及外部服务宕机问题又暴露出来，刚好开发也相对轻松，有条件去实施之前的想法。

我们大概花费了三周的时间，成功搭建出一个无侵入的 mock 服务，通过修改配置就能 mock http 和 MQ A，也就是说只要持续使用，我们就能把 80% 外部请求给 mock。如果再有一两周，就能完成所有外部依赖的 mock。

我离开的时候，这套方案已经在两个市场的研发团队开始推广了（PS：回头把方案思路也整理发布）。

决策逻辑

团队需求

作为一个 Tech Lead 做出各种决策之前，都需要考虑内部目标，大到需求评审，小到技术引进，都是需要根据团队当前需求来动态决策。没有一成不变的决策，只有不断调整的团队。

在上述案例中，团队初期开发任务紧，基于都是优先考虑进度，考虑团队磨合问题。需要对问题进行优先级排序，始终聚焦在重要且紧急的任务上。mock 数据是一个重要但是不怎么紧急的事情，长期来说可以提升开团队的体验和效率。数据源掌握在自己手里的时候，一些极端场景就可以反复模拟，从而提升程序的健壮性和安全性。

外部诉求

当一个决策确定后，外部团队凭什么配合自己团队？这是每个 Tech Lead 都需要思考的事情，了解外部团队诉求，才能使得外部团队配合。

在上述案例中，底层数据团队愿意配合，但他们也有自己重要的事情需要做，能帮助的时间有限。加上时差关系，我们上午发现问题上报，要下午两点才能约到具体处理人员，他们处理完成差不多五六点。本来上午就能完成的工作，给搞到加班才能做完。

长期下来，就会导致进度延迟，只能靠周末加班来弥补。这也逼迫自己团队，在有能力的时候，去做一些具有长期收益的重要事情。

小结

了解自己团队目标，了解合作团队诉求，才能做出更好的决策。